OSFA technologies

Software development is a daunting process which if not done almost right can lead to unexpected results. The challenges faced with the waterfall process are somehow alleviated by the agile process model but still agile has its own flaws.

OSFA believes that the problems faced with the ever-changing requirements can be solved or reduced significantly by the right architecture. We believe that the right architecture should be built on certain principles outlined in the OSFA Doctrine paper. The two main pillars of this doctrine are 1). OSFA Segregation principle and 2). The CEI (Change equals input) principle. I will briefly dive into these two main pillars as outlined below;

1). OSFA Segregation Principle

In the Waterfall and Agile process models the developer must liaise with the client and affected stakeholders during requirements elicitation process to be able to obtain the complete and clear requirement in the waterfall model or initial requirements in the Agile process model. The project initiation begins with collaborating with the client and important stakeholders. Therefore, the developer (Team of architects, programmers, engineers, quality team etc) and the Client (including affected stakeholders) are tightly coupled. The OSFA Segregation principle simply separates the Developer and the Client. The developer can go ahead with the system development without the client. This is achieved by separating the system into two parts the 1). OSFA System (Developer System) and 2). The Client System. By doing this both parties concentrate on building their own systems without affecting the other.

2). The CEI principle

The client software requirements are very volatile and can change from time to time. The CEI principle simply states that anything that can change must not be built into the Architecture but must be treated as inputs to the System. Therefore, with this regard the requirements do not drive the software architecture but be the inputs to the system. By this way the requirements will not affect the System architecture when change is inevitable.

To set more light on this we discuss this further in three sections on this site;

1. OSFA Doctrine – outlines the principles behind this concept
2. OSFA Architecture – outlines the important parts of the architecture
3. Coding to Patterns – discusses the mechanism which makes it possible.