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.

Code tables are a type of configuration table for an application. An example is the table of airport abbreviations that most travel related applications use. It facilitates data input because Newark International Airport can be abbreviated as EWR. This saves key strokes but also insures consistency. Otherwise, one person might enter Newark Airport and another might input Newark International Airport. However, there is more involved than consistency and saving keystrokes. This code table limits the airports that will be accommodated by the application. To recognize a new airport, an abbreviation must be assigned and the abbreviation-airport name pair must be added to the table. Adding that pair might be done with a text editor, SQL, another utility or transactions built into the system. If there are screens that maintain a code table, then an administrator might use it to update a code table.

The other extreme of configuration is a complete system dedicated to configuration. In the seventies, Digital Equipment Corporation was selling its line of PDP minicomputers. When someone bought a minicomputer, the DEC salesperson would have to configure it for them. Peripherals would be selected, usually by the client. However, the salesperson would have to know what type of cables and device drivers to sell with it. The client might end up buying equipment that was missing a component that was needed to have a workable system. Some of the items purchased might be incompatible. DEC decided they needed a system to insure that complete and workable systems were being delivered. They decided to build an expert system, called XCON, to achieve this.

There are cases between these in complexity. An example would be part of an order entry that applied promotions to the orders. The system allowed communications services to be ordered. Promotions would apply discounts to certain combinations of products. For example, if someone ordered voice mail and caller id, then they would be given a certain discount. They could receive this discount even if they already received a senior citizens discount. However, they could not receive both a senior citizen discount and an active military discount. There were many complications like this. The team built this into a table, but the table was complicated. It sometimes required symbols to be defined to keep track of certain situations. There were conditional structures built into the table. For all practical purposes it required someone with some programming ability to enter the promotions. Promotions were set up for each geographic market. Different geographic markets only supported a subset of the company’s products. When the company entered a new market, it had to enter dozens of new promotions for that market. Despite the fact that there were no changes to the computer language statements that made up the application, there was significant effort in constructing new entries into the Promotion table.

Code tables are usually not identified in the initial user stories. The need for these tables often becomes apparent after development has begun. Thus these tables are not counted when they are initially added. Neither are the transactions that are used to maintain the code table itself. Usually, it is not necessary to estimate any changes to the content of a code table. Adding, changing or deleting an entry in a code table is usually trivial and can be done by either an end user or a developer. There is an exception.

Occasionally, an application will have some business logic associated with the code table built into the application. Suppose that somewhere in the application there was logic that prevented booking a flight from EWR to LGA. Then, when there were changes to the code table, there would need to be testing of any transaction that utilized the code table. For example, a Book Flight process would have to be tested. If there were 10 or less changes to the code table, then there would be 12 SNAP points counted. This would have been 6 * 2 attributes (the abbreviation and the full name). Even in this case, in the unlikely event that there are changes to the transactions that maintain the code table themselves, no Function or SNAP points are counted.

The XCON application is not really an example of using configuration files. The configuration logic was built into the application itself. XCON was written in OPS5. This was an expert system shell that is no longer widely used. It had a language level between 5 and 6. OPS5 programs are made up of production rules. These rules held the configuration information. Changes are sized by using the other techniques discussed in other posts. This is the case for most applications. Code tables are usually only used to enforce data consistency. Reference tables are usually maintained by end users who are entering various rates like currency exchange rates, not by development personnel who are using them embed business rules into the tables. In these cases, there are no user data configuration files to consider.

In the other example above, the Promotion file is definitely a reference ILF. It may have been designed so that end users could extend there own application by adding new promotions. It this works out, then the Promotion file is not user data configuration file since it does not require a developer to add more promotions. When promotions are added, they are added by end users and the time required is not estimated using any of the guidelines in this methodology. Promotions involve business analysis and design activities that are unrelated to software construction. For example, they may require the use of focus groups to decide whether the promotions will be effective.

Sometimes, an application is designed to be extendable by end users, but it is found that the configuration information is too complicated for the end users to enter. Other times, the application is designed to use configuration files that will be maintained by developers. Again, in these cases the configuration files are ILFs, unless they are code tables. The screens or transactions that maintain them are elementary processes. Changes to any of these things are counted as explained elsewhere. However, when content of these files is changed it requires time and effort from the development staff. This is when sizing the changes to the user data configuration files becomes important. For example, suppose that the Promotion configuration file had 10 attributes. If 50 new entries had to be added to the file in order to enter a new market, then this would e 120 SNAP points. Because there are over 30 new records, the size is equal to 12 * 10 (number of attributes).

Niklaus Wirth developed the Pascal programming language. He also wrote a book titled “Algorithms + Data Structures = Programs.” There are things that could be said about the language and the book but the critical message at this time is that data plays an important part in an application. For estimating proposes, logical files + processes = applications. Logical files are either Internal Logical Files (ILFs) or External Interface Files (EIFs). The nouns in a user story are clues to the logical files. In the user story “As a Customer Service Representative, I can add customer information for a new customer,” customer information would be called out as a possible logical file. It is usually impossible to do a complete data analysis from the initial user stories. It would also add too much overhead to the estimating process Therefore, some higher level structures are used in estimating. Unspecified Generic Data Groups are used when it is not possible to decide whether a logical file is an ILF or an EIF. General Data Groups are used when it is too early to identify specific logical files but the estimator has reason to believe that there are clusters of logical files that can be identified.

Internal Logical Files (ILFs) are the groups of data that are maintained by the application. Historically, they correspond to master files. In days of old, a master file might consist of card images on a computer tape. For an order master file, there would be a record corresponding to each order. There might be separate record types for ship-to addresses and bill-to addresses. There would probably be a separate record type for each line in the order with the product, quantity, price and other descriptive information like color. In more modern implementations, this might be implemented in a relational data base with the order lines in a separate table because they are a repeating group. Even though there are different record types or tables, a user would think of this as a single logical file containing orders. When identifying ILFs, it is the user perspective that carries the day. Another example might be a human resources application with ILFs for Employees and Departments. An employee might be assigned to a department or perhaps assigned to multiple departments. This calls for an associative entity to tie these ILFs together. This would not be a third ILF if users did not think of this as a separate data group. However, if these assignments started to have significance in themselves, then it would be an additional ILF. This would happen if the start and end dates of the assignments were added, as well as some type of appraisal information.

The function point weight of an ILF is determined by the number of Record Element Types (RETs) as well as the number of Date Element Types (DETs) that it contains. Usually, these are unknown until a sprint is well under way. Roberto Meli analyzed a corpus of function point counts and came to the conclusion that the most likely size of an ILF was 7.7 function points. This should be used for estimating purposes.

The examples given above involve business data. When running a business it is common to gain new customers, acquire new employees, transact business with the customers and pay the employees. Most applications deal with only a subset of these situations. However, if there was a customer ILF, then we would expect to have user stories about how to add new customers. If these are missing, then an estimator should check to see why. If the user stories are actually missing, the functionality of the application will be understated unless they are added. If the data groups are being maintained by another application, then they are External Interface Files (EIFs), not ILFs. EIFs are discussed below.

Some ILFs consist of reference data. Reference data is usually indicated by a user story like, “As an administrator, I can maintain a list of fee multipliers for each country that we do business in.” This might be used by a consulting company. In the United States, a daily consulting fee might be charged. In Mexico and Canada, that same fee might apply. Their multipliers would be 1. However, that multiplier might be 1.5 in most countries in South America. It might be larger in some. The relationship is not commutative. We know Mexico has a value of 1 but a fee multiplier of 1 would apply to the United States, Canada or Mexico. Knowing the fee multiplier is not enough to identify the country involved. There are many possible examples of this type of ILF. A table that specifies costs for different shipping zones might also be one. Sometimes, it is not clear whether the ILF is business data or reference data. It does not matter. Both types of ILF have the same function point weight. Estimating this as 7.7 function points makes the most sense.

There are files that are not functional in nature and therefore do not have any function points associated with them. One of these is a code table. A typical example is the table of abbreviations that are used by the travel industry to correspond to airports. For example EWR corresponds to Newark International Airport. Unlike the reference ILF above, there is a one-to-one correspondence between the code and the value. Theoretically, a user should be able to enter either one. In practice, if someone had to enter the entire name, it would frequently be inconsistent. One person would enter Newark Airport and another would enter Newark International Airport. There is no added functionality. This is a technical solution to facilitate inputs within the application. Code tables are not logical files. However, they are considered when counting SNAP points for estimating changes.

There are other files that are not counted with the data groups. The source files that contain the programs that implement the application are not considered. The same is true of object files. Many applications have files that contain settings for various processes. Unless you are developing a compiler or similar application, none of these are considered as part of the functionality. For compilers, the source and object codes are considered to be inputs and outputs.

External Interface Files (EIFs) are other application’s ILFs that are being referenced in this application. As was stated before, most of the nouns in a user story refer to data groups. If the data groups are maintained in the application, then they are ILFs. If they are maintained in another application and simply referenced in this one, then they are EIFs. This must be evaluated functionally. If a copy of an ILF from another application is made to this one, then it is still an EIF. The transactions used to duplicate the logical file are not counted as part of the functionality being estimated. Like ILFs, the functional weight of an EIF is a function of the number of Record Element Types (RETs) and Date Element Types (DETs) being referenced. Just as in the case of the ILFs, this information is usually unknowable before the iteration where the development is being done. Therefore, it is best to use the value of 5.4 function points that was established by Roberto Meli’s research.

When software is developed using the waterfall methodology, all of the analysis is done early in the life cycle. ILFs and EIFs are identified before any design or coding is done. When using agile development methodologies, analysis, design and coding take place concurrently. By the time any data modeling has been done, the code is already being developed to access it. It is too late to use that information for estimating purposes. There are two other data constructs that can be used before logical entities can be accurately identified. These constructs are Unspecified Generic Data Groups (UGDGs) and General Data Groups. Both of these are described below. Identifying data groups at that level is sufficient for estimating new development. However, that only works for the first iteration of an agile development and the added functionality in subsequent iterations. In order to estimate the impact of changes to a data group, it is necessary to have identified the data groups down to the ILF or EIF level. This is not a problem. Once the team has implemented a data group, they will have an understanding of the data down to the level of ILFs and EIFs.

Unspecified Generic Data Groups (UGDGs) are used when a logical file is identified, but it is not clear whether it is an ILF or an EIF. This is common when working with initial user stories. Some data will be needed, but it will not be clear whether this information must be maintained by the application or whether it can be read from another one. EIFs are usually files that can be directly accessed by a key. It is often data that is accessed by using a program language interface. If it is found to be an ILF, then transactions will be necessary to maintain it. This will add to the application, but might come into play in a later iteration. Here is a possible situation. Initially, it appears that some data may be read from another application. You estimate and begin the iteration based on this assumption. As you work with this data, you realize that it is not reliable. You will need to maintain a clean version of the data. You would probably complete the iteration with the sub-optimal data and then turn the UGDG into an ILF with the necessary maintenance transactions during a later iteration. Estimate each UGDG as 7.1 function points.

General Data Groups are another construction that can be used when ILFs and EIFs cannot be identified completely. They come in three sizes:

• Small (GDGS) contains 2-4 ILFs, EIFs or UGDGs and has an expected size of 21.4 function points
• Medium (GDSM) contains 5-8 ILFs, EIFs or UGDGs and has an expected size of 46.3 function points
• Large (GDSL) contains 9-13 ILFs, EIFs or UGDGs and has an expected size of 78.3 function points

General Data Groups are used when the estimator suspects that there are relationships in a data group that will eventually cause them to be divided into several ILFs or EIFs. In the example with the Employee data group, the estimator might anticipate that an Assignment ILF will eventually be required. The Employee data would then be considered a GDGS instead of an ILF. A similar situation frequently occurs with EIFs. The application being estimated may require 10 pieces of data from another application.  This may require that one ILF be accessed in that application, 10 ILFs or any number between them. This would mean there would be from 1 to 10 EIFs in the application being estimated. Estimating this as a GDSM might be reasonable until more is known.

There is a rule of thumb that is worth considering. In most IT applications, there tends to be a 70%/30% split between transaction functionality and data functionality. Transaction functions include EIs, EOs, EQs and any of the estimating generalizations such as UGOs and UGPs. Data functions are the ones discussed above. This is only a rule of thumb. If you have deviated a little, like 60%/40%, it is not worth worrying about. If you have deviated a lot, then you are probably still right if you understand why your application is unusual.

There are 21 effort multipliers used by the estimating model. 16 are historically COCOMO effort multipliers while the other 5 are historically CORADMO effort multipliers. CORADMO effort multipliers are used a little differently from CORADMO ones. This will be explained. This post is organized by the subject area of the effort multiplier.

Architecture / Risk Resolution (RESL)

This effort multiplier is in a class by itself. It is also a COCOMO scale factor as was explained in Cost Drivers – Scale Factors. In that section, it was also explained what values to use when it is used as a CORADMO an effort multiplier. This must cost driver must be used as both a scale factor and an effort multiplier and it must be evaluated in the same way.

Product Factors

Size is the primary determinant of the amount of effort and schedule required for software development. Size is a function of the amount of functionality, often measured in function points, and the programming language used to develop the software. However, no one should expect that two 500 function point applications implemented in Java will take the same time to develop. Product factors will explain some differences.

Required Software Reliability (RELY)

This is a measure of the importance of the software performing properly. It is arrived at by considering the impact of software failure. The descriptions and associated multipliers are:

• Slight inconvenience – Very Low – .82
• Low, easily recoverable losses – Low – .92
• Moderate, easily recoverable losses – Nominal – 1.00
• High financial loss – High – 1.10
• Risk to human life – Very High – 1.26

Database Size (DATA)

This really measures the impact of the number of test cases. The database size refers to the size of the database used in testing, not production. Take the ratio of kilobytes of test data to SIZE as was calculated in Transforming Size into Schedule and Effort. Use the resulting ratio to assign an effort multiplier using these rules:

• DB KB / SIZE < 10 – Low – .90
• DB KB / SIZE < 100 – Nominal – 1.00
• DB KB / SIZE < 1000 – High – 1.14
• DB KB / SIZE >= 1000 – Very High – 1.28

Product Complexity (CPLX)

Two applications can have the same number of screens and reports, but be much different in terms of complexity. The more complex one should take more effort to develop. There are six levels of complexity to choose from, from very low to extra high.

A nominal application would be programmed using the simple conditional statements that are part of most programming languages and decision tables. It might use standard math and statistics routines. Input and output processing might include the selection of an appropriate device, checking its status and reporting errors. Data management might include files or complex COTS-DB queries and updates.

Very low and low complexity would be more simple. Very low might contain straight line code with a few  conditional operations. Low complexity might include nested control structures. Computationally, very low would only include general arithmetic, while low might include use standard functions like SQRT. Very low would read and write from and to default devices, low complexity also has no cognizance of device, but might have writing of binary information. Simple and moderately complex COTS-DB functions might be used. Very low complexity applications use simple input forms and report generators; low complexity might use simple GUI builders.

High, very high and extra high are also possible choices. At the coding level, they might use capabilities like recursion. Very high may handle fixed priority interrupt handling while extra high might handle dynamic priority ones. Extra high includes the type of programming that is necessary for distributed real-time control. Computationally, these higher levels might involve numerical analysis,  simple partial differential equations or analysis of stochastic data, respectively. Device dependent operations might include physical storage transactions, performance intensive embedded systems or performance critical embedded systems, respectively. Data management might involve complex data restructuring, search optimization or natural language data management, respectively. The user interface might involve multimedia, dynamic graphics or virtual reality, respectively.

The effort multipliers for these complexity rating levels are:

• Very low – .73
• Low – .87
• Nominal – 1.00
• High – 1.17
• Very High – 1.34
• Extra High – 1.74

Developed for Reuse (RUSE)

It is common for code that is developed to be reused throughout the project. If a new screen similar to an existing one is to be developed, much of the code will be reused. This has a rating level of nominal. Occasionally, “throw away” code is developed that has no possibility of reuse. This has a rating of low. Otherwise, code is developed that will be reused across a program (high), a product line (very high) or multiple product lines (extra high). A program would probably be for a single type of family of applications for a single organization. Like several sales applications. The higher forms of reuse are for situations where there are multiple types of applications, like sales and marketing. Also, a higher form a reuse might involve multiple organizations.

There is a relationship between the required reliability and reuse. The value for RELY should be at most one level below the RUSE rating. The effort multipliers are

• Low – .95
• Nominal – 1.00
• High – 1.07
• Very High – 1.15
• Extra High – 1.24

Documentation Match to Life-Cycle Needs (DOCU)

For any project, especially an agile one, the value should be 1.00. This means that just the right amount of documentation is being produced. This is normally user stories and backlogs. There is a relationship between RUSE and DOCU. If RUSE is very high or extra high, then DOCU should be at least high. The descriptions rating levels and effort multipliers are:

• Very Low – Many life-cycle needs uncovered – .81
• Low – Some life-cycle needs uncovered – .91
• Nominal – Right-sized to life-cycle needs – 1.00
• High – Excessive for life-cycle needs – 1.11
• Very High – Very excessive for life-cycle needs – 1.23

Platform Factors

These factors apply to the target machine where the application will be placed into production.

Execution Time Constraint (TIME)

The descriptor, rating levels and effort multipliers are:

• Nominal – Less than 50% use of available execution time – 1.00
• High – 70% use of available execution time – 1.11
• Very High – 85% use of available execution time – 1.29
• Extra High – 95% use of available execution time – 1.63

Main Storage Constraint (STOR)

The descriptor, rating levels and effort multipliers are:

• Nominal – Less than 50% use of available storage – 1.00
• High – 70% use of available storage – 1.05
• Very High – 85% use of available storage – 1.17
• Extra High – 95% use of available storage – 1.46

Platform Volatility (PVOL)

The platform consists of the hardware, operating system, network and database management system. The descriptor, rating levels and effort multipliers are:

• Low – Major change every year – .87
• Nominal – Major change every 6 months – 1.00
• High – Major change every 2 months – 1.15
• Very High – Major change every 2 weeks – 1.30

Personnel Factors

The personnel factors are the most important factors in determining effort and schedule for a system of a given size. They can be used in two ways. If the team has been assembled, then their capabilities can be considered to develop the best estimate possible. If the team has not been assembled, then each of these capabilities can be entered as nominal. Alternatively, the estimator can specify what attributes the team must possess in order to complete the project in the required time frame and with a certain degree of effort. This can then guide the recruiting process used to assemble the team.

In is important to recognize that these factors apply to the team as a whole, not the individuals. In an agile team, everyone is responsible for analysis, design, construction, testing and management tasks. The team may be strong in capabilities that certain members completely lack.

Analyst Capability (ACAP)

This driver considers capabilities in analysis and design. The ability to communicate and cooperate are also considered. Experience is considered in other factors. This one is strictly capability measured by the team’s standing relative to others, as shown in this mapping of percentile to effort multiplier:

• Very Low- 15th percentile – 1.42
• Low – 35th percentile – 1.19
• Nominal – 55th percentile – 1.00
• High – 75th percentile – .85
• Very High – 90th percentile – .71

Programmer Capability (PCAP)

This driver considers capabilities in programming. It considers efficiency and thoroughness. The ability to communicate and cooperate are also considered. Programmer capability is independent of the computer language that will be used. That, along with experience, is considered in other factors. This factor is strictly capability measured by the team’s standing relative to others, as shown in this mapping of percentile to effort multiplier:

• Very Low- 15th percentile – 1.34
• Low – 35th percentile – 1.15
• Nominal – 55th percentile – 1.00
• High – 75th percentile – .88
• Very High – 90th percentile – .76

Personnel Continuity (PCON)

This factor considers the percentage of the team that leaves every year and needs to be replaced. Note that this is turnover, and it is the inverse of continuity. The mapping of this percentage to the effort multiplier is:

• Very Low- 48% – 1.29
• Low – 24% – 1.12
• Nominal – 12% – 1.00
• High – 6% – .90
• Very High – 3% – .81

Application Experience (APEX)

This factor considers the experience of the team with the business area or type of application being developed. The mapping experience to the effort multiplier is:

• Very Low- 2 months or less – 1.22
• Low – 6 months – 1.10
• Nominal – 1 year – 1.00
• High – 3 years – .88
• Very High – 6 years – .81

Platform Experience (PLEX)

This factor considers the experience of the team with the graphic user interface, database and networking that will be used in the project. The mapping experience to the effort multiplier is:

• Very Low- 2 months or less – 1.19
• Low – 6 months – 1.09
• Nominal – 1 year – 1.00
• High – 3 years – .91
• Very High – 6 years – .85

Language and Tool Experience (LTEX)

This factor considers the experience of the team with the programming language being used. This also considers the entire development environment, including text editors, debuggers, source code managers.  The mapping experience to the effort multiplier is:

• Very Low- 2 months or less – 1.20
• Low – 6 months – 1.09
• Nominal – 1 year – 1.00
• High – 3 years – .91
• Very High – 6 years – .84

Reuse and Very High Level Languages (RVHL)

This measures the team’s experience with rapid prototyping. Reuse here is non-code reuse. For example, if the team uses a design guide to help quick start some user decisions. Very high level languages (VHLL) are often domain specific languages that the team will use, usually for prototyping.

This cost driver was historically from the CORADMO set. These drivers may impact effort and schedule differently. The mapping from team prototyping experience to effort and schedule multipliers is:

• Very Low – None of the team members have any experience using rapid prototyping – Both effort and schedule multipliers are 1.01
• Low – On average, team members have experience in less than one project using rapid prototyping – Both effort and schedule multipliers are 1.00
• Nominal – Most team members have worked on more than one project using rapid prototyping – Effort multiplier is 1.00 and schedule multiplier is .99
• High – On average, team members have worked on more than 2 projects using rapid prototyping – Effort multiplier is .99 and schedule multiplier is .98
• Very High – All team members have worked on 3 projects using rapid prototyping – Effort multiplier is .98 and schedule multiplier is .97

Project Factors

COCOMO II recognized two project factors: the use of software tools and multi-site development. These are still important, but agile development must consider some additional factors. These additional factors are taken from the CORADMO model.

Use of Software Tools (TOOL)

This factor considers the type of development tools that will be used for this project. The mapping of tool type to the effort multiplier is:

• Very Low- simple editors, compilers and debuggers – 1.17
• Low – Simple CASE tools with little integration – 1.09
• Nominal – Basic life cycle tools with moderate integration – 1.00
• High – Strong life-cycle tools that are moderately integrated – .90
• Very High – Strong tools well integrated with the organization’s development processes – .78

Multisite Development (SITE)

In the perfect world of agile development, all developers and users are collocated. This is usually impossible. People can be virtually collocated if they have interactive multimedia connections to bind them together. This factor only considers the developers. These guidelines are used to assign an effort multiplier:

• Very Low – An international team communicating by snail mail and pay phones – 1.22
• Low – Multi-city and multi-company with phones and faxes – 1.09
• Nominal – Multi-city or multi-company with basic e-mail – 1.00
• High – Same metro area or wide-band electronic communications – .93
• Very High – Same building complex or occasional video conferencing – .86
• Extra High – Fully collocated, either virtually or in reality – .80

Development Process Re-engineering and Streamlining (DPRS)

This measures the project’s ability to re-engineer and streamline development processes. To a large extent, this is the inverse of bureaucracy. To determine this consider the following project attributes:

• Number of approvals required per task
• Time taken per approval
• Reduced task dependencies and critical path tasks
• Tendency to follow-up to expedite task completion
• Process measurement and streamlining

This cost driver was historically from the CORADMO set. These drivers may impact effort and schedule differently. The mapping from bureaucracy to effort and schedule multipliers is:

• Very Low – Heavily bureaucratic – Effort multiplier is 1.15 and schedule multiplier is  1.16
• Low – Bureaucratic – Both effort and schedule multipliers are 1.06
• Nominal – Basic good business practices – Both effort and schedule multipliers are 1.00
• High – Partly streamlined – Both effort and schedule multipliers are .98
• Very High – Fully streamlined – Effort multiplier is .95 and schedule multiplier is .94

Pre-positioning Assets (PPOS)

This reflects the assets that are made available to the project at the very beginning. These may be design guides, processes, tools or components. They have been developed for this project before the project began.

This cost driver was historically from the CORADMO set. These drivers may impact effort and schedule differently. The mapping from the type of asset to effort and schedule multipliers is:

• Nominal – Basic project legacy with no tailoring – Both effort and schedule multipliers are 1.00
• High – Some tailored assets – Effort multiplier is 1.03 and schedule multipliers are .93
• Very High – Key assets are tailored – Effort multiplier is 1.06 and schedule multiplier is .86
• Extra High – All assets are tailored – Effort multiplier is 1.1 and schedule multiplier is .80

Collaboration Efficiency (CLAB)

Agile development is impossible without collaboration between the stakeholders and the developers. This factor that spans several other areas. The stakeholders must be committed, the development team must be capable and everyone must be able to communicate effectively. This factor becomes a fuzzy average of the TEAM scale factor, all of the personnel factors and the SITE factor. It is fuzzy because a significant weakness in any of these factors will drive CLAB much lower.

This cost driver was historically from the CORADMO set. These drivers may impact effort and schedule differently. The mapping from the fuzzy average to effort and schedule multipliers is:

• Very Low – Effort multiplier is 1.12 and schedule multiplier is 1.13
• Low – Both effort and schedule multipliers are 1.06
• Nominal – Both effort and schedule multipliers are 1.00
• High – Effort multiplier is .97 and schedule multipliers are .96
• Very High – Effort multiplier is .93 and schedule multiplier is .92
• Extra High – Effort multiplier is .91 and schedule multiplier is .89

Transforming Size into Schedule and Effort uses 26 cost drivers in the equations that are used to estimate effort and schedule. The diagram above shows how these cost drivers are divided. There are 5 scale factors. The scale factors influence the size of the project. The size is raised to a power that is a function of these 5 scale factors. Like the name implies, the effort multipliers multiply the amount of effort necessary to complete the job.  The multipliers can have values of less than one which will reduce the amount of effort necessary. The equations make a distinction between the first 16 effort multipliers and the last 5. The first 16 are taken from the COCOMO II software cost estimation model. The last 5 are from the CORADMO model which is intended to take the estimates from COCOMO and post process them based on the use of certain agile and rapid application development techniques. The CORADMO cost drivers are also used a little differently than the COCOMO ones. At least one of the CORADMO effort multipliers impacts effort and schedule differently.

While scale factors and effort multipliers are used differently by the estimating equations, from a practical point of view they are the same. An estimator must choose the most appropriate values for each of the cost drivers in order to get the best estimate of effort and schedule. A developer should also look to optimize these values when possible. For example, one of the scale factors is precedentedness measures whether the organization has experience with similar projects. A lack of experience will mean that the project will require more effort. A strategy around this might be to partner with a firm experienced with this type of project or to hire people who are experienced. The rest of the post will present the definitions and values associated with the scale factors.

Precedentedness (PREC)

This measures how much the product being developed is similar to previously developed products. Consider the organizations’s understanding of the objectives and experience working with related systems. If there is new hardware or software involved in this project, then the precedentedness will be lower. Following is a short description of the amount of prededentedness along with the scale factor values to use:

• Very Low – thoroughly unprecedented – 6.2
• Low – largely unprecedented – 4.96
• Nominal – somewhat unprecedented – 3.72
• High – generally familiar – 2.48
• Very High – largely familiar – 1.24
• Extra High – thoroughly familiar – 0

Development Flexibility (FLEX)

This measures the degree to which the product must conform to some preexisting specification. This might be a requirements document, some type of external interface specifications or both. Any premium placed on early completion also detracts from this measurement. Following is a short description of the amount of flexibility along with the scale factor values to use:

• Very Low – rigorous – 5.07
• Low – occasional relaxation – 4.05
• Nominal – some relaxation – 3.04
• High – general conformity – 2.03
• Very High – some conformity – 1.01
• Extra High – general goals – 0

Architecture / Risk Resolution (RESL)

This measure is both a scale factor and a CORADMO effort multiplier. It only needs to be evaluated once. For example, if it has a value of high for scale factor, then it must also be high for the effort multiplier. For calculation purposes, a high scale factor will have a different value than a high effort multiplier. CORADMO effort multipliers may impact effort and schedule differently.

An application’s architecture considers its user interface, use of commercial off the shelf (COTS) components, hardware, technology and performance. These components are all necessary, but all carry an element of risk. Finding out that there is a performance problem right before a schedule release can be devastating. This scaling factor/effort multiplier considers the amount of time dedicating to establishing the architecture as well as the percent of required architects that were available to the project. For the RESL rating to be extra high, 40% of the schedule should be devoted to architecture and 120% of the required architects should be available.

Risk management requires the identification of risk items as well as plans to resolve them. Risk items can be critical or non-critical. From 2 to 4 critical items are considered to be a nominal number. Following is a short description of the architecture / risk resolution showing how many of the risk items have mitigation plans along with the scale factor and effort multiplier values to use:

• Very Low – little (20%) – 7.07 for scale factor – 1 for effort/schedule multiplier
• Low – some (40%) – 5.65 for scale factor – 1 for effort/schedule multiplier
• Nominal – often (60%) – 4.24 for scale factor – 1 for effort/schedule multiplier
• High – generally (75%) – 2.83 for scale factor – .94/.95 for effort/schedule multiplier
• Very High – mostly (90%) – 1.41 for scale factor – .88/.91 for effort/schedule multiplier
• Extra High – full (100%) – 0 for scale factor – .82/.86 for effort/schedule multiplier

Team Cohesion (TEAM)

This measures the ability of the team to work together. Team does not mean only the developers. Team in this context includes all of the stakeholders. Their objectives and cultures should be consistent. They should be ready to accommodate one another’s objectives. Experience of the stakeholders in operating as a team is a plus. There should be team building activities to foster this cohesion. Following is a short description of the extent of team cohesion along with the scale factor values to use:

• Very Low – very difficult interactions – 5.48
• Low – some difficult interactions – 4.38
• Nominal – basically cooperative interactions – 3.29
• High – largely cooperative – 2.19
• Very High – highly cooperative – 1.10
• Extra High – seamless interactions – 0

Process Maturity (PMAT)

This measures the organizations process maturity as defined by the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM). Following is a mapping from the SEC CMM to the scale factor values to use:

• Very Low – CMM Level 1 (lower half) – Initial – Every organization starts at this level, even if it has made no effort to identify its software development processes. – 7.80
• Low – CMMI Level 1 (upper half) – Still Initial – An organization has begun to identify and document their software development processes. – 6.24
• Nominal – CMM Level 2 – Repeatable – An organization has identified and repeatable processes that they can use for software development. – 4.68
• High – CMM Level 3 – Defined – Sets of development processes have been defined, documented and accepted as the standard practices of the organization. – 3.12
• Very High – CMM Level 4 – Managed – The software development processes are quantitatively managed using agreed upon measures and metrics. – 1.56
• Extra High – CMM Level 5 – Optimizing – At this level an organization is using the measurements and metrics that were identified in previous levels to continually improve and innovate the development processes. Very few organizations have achieved this level. – 0