Software Development


We don't just program web applications—we engineer projects. The engineering methodology we use to deliver the work is based on a simplified blend of classic Software and System Development Life Cycle (SDLC) approach mixed with Agile Development practices commonly used in systems and software engineering disciplines.

Here's an overview overview of our methodology. The classic SDLC high level phases are important to keep track of the bigger picture of the project (and any additional future work required) and not get lost in the inevitable large amount of small pieces of work required in most software projects. Also, we propose adopting the Agile Development methodology throughout the SDLC phases where a more interactive and flexible process is used and where collaboration with the client takes precedence over contract negotiation (Refer to Agile Manifesto for details.) This element is important for a number of reasons:

  • it avoids deviating too much from the client's needs and expectations;
  • avoids bad surprises;
  • keeps tighter control of the costs of a project;
  • more inline with clients expectations/needs;
  • more output for the same amount of time and of higher quality.

We typically starts by preparing a planning report which is then use to document all activities and time frames throughout the life cycle of the project to be distributed among stakeholders. An draft sample of such document is included as an addendum for your perusal.
Other activities of our planning phase include:

  • Meet the team and spend time with involved participants;
  • Skills assessment;
  • Orientation activities;
  • Start getting an understanding of the needs and existing capacity of client.

Then we try to absorb as much information about the organisation's needs as possible. Some typical activities of this phase include:

  • Gather as much data as possible using interviews, questionnaires, etc.;
  • Discuss needs and future plans with client;
  • Orientation activities;
  • Start some data modelling and prototyping for better discussions with stakeholders and other software developers;

For larger projects, we start synthesizing everything into a professional Stakeholder-System-Software Requirements Specification (SRS) Document outlining a comprehensive and unambiguous set of functional and non-functional requirements specification. An draft sample of such engineering document is included as addendum for your perusal.

Is where we start designing the "blueprints" of the system. Here are some of the activities we typically go through:

  • Refine and complete data model started in planning and analysis phases;
  • Design the whole system architecture at a high level;
  • List necessary Application Programming Interfaces (API) for internal and external interactions to other systems

For larger projects, we would prepare a design and architecture document of the system and the activities of this phase would be narrowed to small careful incremental changes to the existing system.

This is where we "contruct" the system. We start (or continue) developing the system supporting all functional and non-functional requirements specifications outlined in the SRS Document or in the Terms of Reference (ToR) for smaller projects. The main activities are:

  • Writing test code describing the functional requirements;
  • Writing code to realise the functional requirements;

Some times in test-drive development style, other times tests are written after, but tests should be present at all times covering all features of the system. The importance of tests while developing the software artifacts are too often overlooked (programmer bad habbits, lack of funding) but are critical to a high quality software project. In fact, the ideal project would have running essentially describing the SRS Documents as closely as possible.

This is where we enter maintenance mode. For most our clients, this phase means things like software warranty, managed services and training. Typical activities include:

  • User training as the project evolves into a more stable useful product;
  • Develop documentation for the support, maintenance and posterity of projects;
  • Technical training can be provided for clients with Elite On-Premise or Elite Cloud Hosting managed services plans.
  • Warranty period starts
  • Hosting either starts officially with Nuzusys or passed to other hosting provider;

Depending on the nature of the project, our documentation can include a Developer Guide for programmers that would/will work on this system as all systems evolve with needs, a Systems Administrator Guide for people in charge of deploying the system, conducting backups, testing disaster recovery scenarios and a Users Guide for all users. All guides are prepared with a technology enabling their exports to publication quality PDF report, HTML for online access and ePub for mobile devices.


During the Implementation/Testing phase is where most of the software coding takes place. We follow a best practive DevOps workflow to save time and improve quality of our products.


We carefully manage the evolution of code bases. Depending on the nature of the project (e.g. open source library, a client's software) this could be a public Github/Bitbucket repository or a private repository on Nuzusys' Git server.


We constantly improve our process of writing tests and feature code. Every change to code goes through an automated process of checking code quality, tests execution and optimization of files before going into production.


Our deployment process is fully managed like any other of our systems—using the Ansible, a system deployment, configuration management and orchestration tool.


We support the following programming languages and platforms (e.i. framework, libraries). We may be able to support others as well but this would need to be discussed with client.


Nuzusys is flexible and prefers to offer a number of options when it comes to technologies. Software solutions are grouped in two main models, one where all components of the system are completely free open source software (FOSS) while the other is a mixed of FOSS and proprietary software. All these choices largely depends on the client though we almost always prefer and recommend the completely open source model.


Consists in a system built with several components each one carefully chosen from the best-of-breed FOSS projects in the world. A typical stack would include Linux as the operating system, PostgreSQL as the relational database management system (RDBMS), Python/Django as the flexible and secure server-side (backend) web application development framework, either Bootstrap or the newer Material Design Specifications by Google to design a modern responsive custom HTML/CSS/Javascipt theme, AngularJS as the client-side (frontend) web framework for more advanced web "applications" along with several other auxiliary components as needed. Every component is chosen based on several important factors including:

  • the wide availability of support by other people and organisations in the world;
  • active community to benefit from on-going improvements;
  • no vendor lock-in;
  • strict adherence to open standard;
  • high quality of project with good documentation and well defined RESTful API for interoperability between components and the custom system to be developed; and,
  • project with long life expectancy.

Consists mostly in a mixed between some of the same FOSS projects as above with others replaced by Microsoft technologies, namely:


Both options offered are of the very highest quality on the market. While they have several tools in common they have siginificant differences as well. Simply put, the MIXED FOSS AND PROPRIETARY MODEL has added upfront and on-going licencing cost of significance which makes the solution's total cost of ownership (TCO) higher. This means that for an equal budget the COMPLETELY FOSS MODEL can often offer more deliverables and at a higher development pace. Note that we understand this is an opinion often argued, and that most "published" papers on it are self-funded and hence biased. We will in the future post links to what we think are the least biased and best studies on the subject, but note that the TCO is often very sensitive to the specific circumstances.

That said, there is often fear, doubt and uncertainty of free software. It is hard to believe—even for technology experts—that free software would come at equal and often higher quality then paid for software. While this phenomenon has been studied by many it still remains bewildering. However, this is the actual reality and here are some verifyable convincing facts:

  • A great deal (60-70\%) of the Internet is powered by free software;
  • Giants such as Facebook, IBM and Google build their global empires with a great deal of free software, and even Microsoft is joining in by open sourcing many of their products;
  • Many large governments around the world are migrating towards open standards and free software;
  • Most of the worlds supercomputers used in scientific research run on free software;
  • The London Stock Exchange and others are some of the world world's most advanced real-time high frequency financial transaction systems and they run on free software;
  • Most smart phones on the planet are powered by Android, a free software operating system based on Linux.

With software development one of the most important question is whether you want to develop everything from sratch, adopt an existing solution or a mixture of both. Here is a greatly simplified take on this from our perspective.

  • Developing a custom software from scratch is attrative as one can develop the exact features following the client's needs
  • But this approach should be adopted with extra care. The efforts and costs involved in designing, constructing and maintaining a custom software is very high without necessarily the guaranty of successful implementation.
  • Adopting existing solutions are much more cost effective as one starts with a proven solution used by others around the world. This minimize risk and often leads to adoption of open standards.
  • However, those have the compromise that it may not always be exactly how you would like it.
  • When possible an approach that takes the best of both worlds is recommended.

Nuzusys recommends starting with a thorough needs analysis and the documentation of all functional requirements. Once this list of functional requirements is clear and unambiguous look for the closest robust solution out there and start building on that one by adding the missing parts and improving on the existing solution.