Partitions are pieces of an application that share a high degree of cohesion. This cohesion must be visible from a developer’s perspective. It may also be visible from a user’s perspective. The dominance of the developer’s perspective is because partitions are only relevant when counting SNAP points, not function points. They will only come into play when estimating changes to existing functionality, not the addition of new functionality. An example of the identification of partitions is in an application developed with a client-server architecture. The client and server portions are considered separate partitions. Developers know whether they are working on the client or server partition. Often, they are using different computer languages to develop each one. In modern client-server applications, the distinction is often invisible to the users. In older two-tier architectures, users might have been aware that they were using part of an on-line application to build a transaction file that would be processed in a batch partition later on. The on-line and batch portions of the application would be two separate partitions. Unfortunately, partitions are a little like pornography. It is a concept that is difficult to define, but people recognize it when they see it. Examples of partitions will be given in this post to demonstrate how to recognize them.
When initial user stories are developed, there is usually no indication of any architectural decisions that will be made. In agile development, there is a principle to do the simplest thing that works. This means that the architecture may not emerge until several iterations have occurred. The same is true for applications where different user functionality is mapped into different partitions. For example, in a blogging application there might be separate partitions for the functions that worked with posts and those that worked with static pages. This distinction might not become clear to the developers until the code had been refactored a few times. All of this is fine. The number of petitions does not directly influence the size of the project. In other words, there are no points awarded for a partition. When changes to a transaction are evaluated, the size of those changes is influenced by the partitions that are involved. By definition, these changes are not part of the first iteration. Everything in the first iteration is being added and therefore sized using function points. Early iterations tend to be dominated by added functionality while later iterations usually call for changes to existing functionality. SNAP becomes a more significant part of the sizing of these later iterations. This is where identifying partitions becomes more relevant.
In a one tier architecture it is common to have a single partition. An example of this is a program developed using Microsoft Excel. There is little distinction between the data, the program logic and any presentation. Everything is intermixed in the same spreadsheet. The fact that the application is developed in a single programming language is an indication that there is probably a single partition. However, this is not always the case. Sometimes partitions are indicated by families of functionality with a high cohesion. Even in these cases, there are clues. In an Excel application, different partitions are probably implemented in separate spreadsheets in the same workbook. If the application is implemented in a language like Java, the separate partitions may be in separate classes or subroutine libraries. In these cases, there is a one-tier architecture with multiple partitions. This can happen but it is not common. Most applications with a single tier architecture have a single partition. In these applications, there is no need to consider the internal data movement of data in the application.
Identifying partitions in a two tier architecture is usually pretty straight forward. There are two common two tier architectures. In the first, there is an online portion and a batch portion. The batch portion is often referred to as a batch partition. Historically, users would interact with the online portion. That portion might be written in a scripting language on the computer being used. The online program would check for syntax type errors like invalid dates. The use could correct these on the spot. The program would produce a transaction file. That file would be processed by a series of COBOL programs in the batch window, usually at night. The batch program would uncover other errors like a customer exceeding their credit limit. This information would go to the user the next day. The user could make adjustments using the online portion of the system. This evolved into the client-server applications that are common today. Here, the client and server are two separate partitions. In web development, it is common to use Hypertext Markup Language (HTML) and Cascading Style Sheets (CSS) on the client side of the application and PHP on the server side. Sometimes, different team members must work on each partition because any one developer may be unfamiliar with some of the technologies used.
In a three tier architecture there are usually three partitions. One partition is for presentation. This is like the client petition in the client-server architecture discussed above. It might be implemented using HTML and CSS. Obviously, there are many other choices for implementing this presentation partition but they all have the same functionality. In the three tier architecture, the second tier is for program logic. In the client-server example it was mentioned that the server portion might be implemented in PHP. This is only one of dozens of possible programming language choices. In the client-server example, data is also stored on the server. It has to be. Virtually all applications must maintain some type of data in order to function. Sometimes that data is stored in the system files by the programming language in question. Sometimes a relational database like MySQL is used. However, in a three tier architecture the data is clearly in a separate partition. Usually, it is on a separate machine. It is often a DB2 or Oracle database on a mainframe computer. In any case, it is loosely coupled from the presentation and programming logic partitions.
Separate servers are often separate partitions. One example is a fax server. If the application uses a fax server, then the fax server would probably be a separate partition. If the application uses a print server, then the print server would probably not be a separate partition. The difference is that the fax server is probably visible to the developers. They will need to send setup strings to the fax server. The print server tends to be invisible. If the computer language has a print command, then it will use the print server without the developer really being aware of it. This developer visibility is key. If the developer must do special things in order to access a server, then it is a separate partition. The same server might be a separate partition or not depending upon the application. Graphic servers are an example of this. Some applications use a graphic server just like they use a print server. The developers are barely aware of what the server is doing for them. Other applications must explicitly send set up information to the graphic server. Blockchain servers are usually separate data partitions the applications that utilize them.
A Service Oriented Architecture (SOA) is a software development approach where the application development depends heavily on the use of loosely coupled software components. Each service is a self contained black box that performs a business function. It also corresponds to a partition. There are many technologies that might indicate that this approach is being used. Web Service Definition Language (WSDL) and Simple Object Access Protocol (SOAP) are a pair of technologies that are often used to implement SOA. Representational state transfer (REST) is another such technology. There are other modular approaches that have similar characteristics. Applications that are done in WordPress often rely on a subset of over 50,000 plugins that are available to provide some type of functionality. These plugins could be considered separate partitions. When a transaction of the application changed, the estimator would need to evaluate the partitions that were involved.