osfa Doctrine

Background

The volatility of Software Requirements can have negative impact on a software product under development if these requirements
are discovered in the later stages of the software development process. It is a common practice that the Client/end user must be involved earlier to fully
understand the end user needs before the design of the system begins. It is well understood that beginning the Software project with not well understood
requirements can have significant negative impact on the project as we will discuss in the next and subsequent paragraphs. Unclear requirements may cause Project
Delay and Increase Cost of developing the Software Product.

Project Delay (Longer Development Time as was expected)

One of the reasons why Software product Development time take longer is due to the misunderstood requirements. Imagine reaching the
coding phase of the Software process or even the Testing phase when the client is initiating a requirement change request. In such situation rework has to be
made and it could mean restarting from the beginning again. Analyzing the requirements, designing, coding and testing. In such scenario the product
development time will be prolonged and these could trigger a rising cost which we will see in our next paragraph.

Rising Cost (Increased Development Cost)

Let us look at a scenario where the product has to be released in a fixed date. That is it has to be released sooner from competitors
to control the market. Now if the Requirements are not well understood or the requirements are well understood but new requirements emerged and if these is
realized in the later phases of the development process, the project manager might want to add more resources to speed up the rework process so as to meet
the deadline. Now in doing so the cost of rework plus new added resources will increase the cost of developing the product significantly.

OSFA
DOCTRINE

As we can see in the above paragraphs how the requirements can have impact on the Software project. The creator and the
client are tightly coupled to achieve a good outcome in any Software Project. The Creator cannot begin without the client approval of the requirements. The
main goal of OSFA is to decouple the two; Creator and Client and this will lead us to the first principle.

1.      OSFA Segregation principle

This principle states that to achieve the best outcome in any Software Project, the Creator must not depend on the client to start the project. The creator should not focus on the client and the requirements to complete the project. The creator focus should be on the architectural design, coding and testing but not on the requirements. Below is the Client, Creator and predictor roles;

CLIENT/STAKEHOLDERS: Requirements addition and removal should be done by the Client alone. The client knows the requirements better than the creator. The client can add and update the requirements through its designated Predictor.

CREATOR: The Creator should focus on defining the patterns and designing and coding the architecture accordingly as well as creating templates and security patches in the long run. The creator should be responsible for the design, coding, architecting, testing and creating UI templates that the user (Client) can choose from to customize the appearance /organization of the UI based on patterns.

PREDICTOR: Have better understanding of the patterns and how to write and update the predictor books whenever requirements change. The predictor is able to transform the requirements to the given patterns.

Segregation in OSFA is the separation of Creator of the System from the Client (User). The creator should do its job independent of the Client and vice versa. When the creator designs the system, it should not worry about the client and its requirements but should focus on accommodating changing requirements. On the other hand, the client should not worry about the system but focus on adding and updating requirements.

You might ask but how on earth is this possible. How can the development team go ahead with the project without the complete requirements? Now this leads us to the second principle.

2.      Design and Code to Patterns

The idea is to insert a layer between the requirement and design phases and this layer defines how the requirements should be presented to the system (Software Product).In this way the creator do not have to worry about the requirements. As long as the system agrees with the
Patterns the system will be just fine.

3.      Create the System Once

OSFA states that the system has to be created once and never go back unless new templates and security patches has to be added. You can add but not rework. The requirements volatility should not be the reason for rework. The only reason when a rework can be done is when the patterns change.

4.      Change Equals Input (CEI))

      Anything that can change should be an input to the System. The requirements should not be the major influence to the Architectural Decisions but be the inputs to the system.

This includes formulas used in calculations and the navigation system. The patterns itself should be the major influence of the Architecture since it is the basis of the architectural design.

5.      The System is a one size fits all

The system should be a ready-made product. Any Client can use it anytime it needs it. Because the clients’ requirements are the inputs which makes it possible. The system is able to switch between different problem domain.

6.      OSFA Architecture

There has to be an architecture that support all the principles for a given Software project to be considered an OSFA Solution.