A New Paradigm From Function Points or Lines of Code For Sizing Software Systems

<body topmargin=0 leftmargin=0 marginheight=0 marginwidth=0> <table cellpadding=0 cellspacing=0 border=0><tr> <td valign="top" rowspan="3" width=170 BGCOLOR="#000099" TEXT="#F7F7FF" background="02ebbc00erkqpg.jpg"> <div> Return to <A HREF="tr_as_size_meas.htm" TARGET="_top" TITLE="Testable Requirements as a Sizing Measur">Testable Requirements as a Sizing Measure</A></div> <div> ----------------------------------</div> <div> <A HREF="tr_vs_test_cases.htm" TARGET="_top" TITLE="Testable Requirements Vs Test Cases">Testable Requirements Vs Test Cases</A></div> <div> <B>A New Paradigm From Function Points or Lines of Code For Sizing Software Systems</B></div> </td> <td valign="top" colspan=2 height=60 BGCOLOR="#FFFFFF" TEXT="#080000"> <div> <B>A New Paradigm From Function Points or Lines of Code For Sizing Software Systems</B></div> <bR> <bR> <div> </div> </td> </tr><tr> <td valign="top" height=396 width="100%" colspan=2 BGCOLOR="#FFFFFF" TEXT="#080000"> <div> Testable requirements is a new paradigm for measuring of the size of a system.  One way to illustrate the differences between lines of code, function points and testable requirements is to look at how each would compare a system developed using a character-based user interface (e.g., DOS, 3270 mainframe), and the equivalent system developed using a graphical user interface (e.g., Windows).</div> <bR> <div> <A HREF="glossry_lines_of_code.htm" TARGET="_top" TITLE="Glossary"><I><IMG BORDER="0" SRC="Symb075c00b700f000000000.png" HEIGHT="16" WIDTH="24" ALIGN="bottom" HSPACE="0" VSPACE="0">LOC</I></A><I> perspective</I>:  It would be very hard to make a comparison using LOC because of the differences in the way the interfaces are developed.  Since the "language" used to code screen or window functionality is not procedural, it is very difficult to measure LOC, let alone make valid comparisons between two different technical platforms. </div> <bR> <div> <A HREF="glossry_function_points.htm" TARGET="_top" TITLE="Glossary"><I><IMG BORDER="0" SRC="Symb075c00b700f000000000.png" HEIGHT="16" WIDTH="24" ALIGN="bottom" HSPACE="0" VSPACE="0">Function Point</I></A><I> Perspective</I>:  Function points would consider them equivalent since they are providing the same functionality to the user (e.g., the same number of logical inputs and outputs).  The value adjustment factor could be used to make the GUI a higher function point count.  (The value adjustment factor is essentially a complexity factor used to adjust a raw function point count because of factors related to the complexity of the system.)</div> <bR> <div> <I><IMG BORDER="0" SRC="Symb075c00b700f000000000.png" HEIGHT="16" WIDTH="24" ALIGN="bottom" HSPACE="0" VSPACE="0">Testable Requirements Perspective</I>:  Testable requirements would give a much higher count to a graphical user interface (GUI) than its character-based equivalent.  There are simply more conditions (i.e., testable requirements) that are supported by a GUI than are supported by a character-based interface.  For example, there is usually only one way to enter a command in a character-based interface - through the menu.  In the equivalent GUI, there are usually at least three - the menu, the keyboard, and the icon.</div> <bR> <div> Testable requirements can also be used to measure and analyze a system in ways that are not possible with other measures. Because testable requirements can measure external user requirements as well as internal technical requirements, it is possible not only to size the user requirements, but also to quantify their impact on the technical design.  Performance requirements, for example, may contribute relatively few testable requirements when viewed from an end user perspective.  The performance requirements may, however, require a complex real time technical design to meet the requirements and therefore require many testable requirements when viewed from a technical perspective.</div> <bR> <div> Similarly, some types of systems such as process control and scientific systems may have relatively few external requirements, but have a very complicated internal technical design.  The testable requirements paradigm does not require a complexity factor to account for this.  Rather the complexity will manifest itself in the size of the design or the size of individual programs.  Complexity, in essence, means that there are more testable requirements somewhere.</div> <bR> <bR> </td> </tr><tr> <td valign="top" colspan=2 height=24 BGCOLOR="#FFFFFF" TEXT="#080000"> <div> <A HREF="tr_vs_test_cases.htm" TARGET="_top" TITLE="Testable Requirements Vs Test Cases"><B><IMG SRC="02711110.png" border=0 width="17" height="17" ALT="prev" ALIGN="BOTTOM" HSPACE="0" VSPACE="0"></B></A><B> </B><IMG BORDER="0" SRC="1x1.gif" HEIGHT="17" ALIGN="BOTTOM" HSPACE="0" VSPACE="0" WIDTH="17"><B>     </B><A HREF="tr_as_size_meas.htm" TARGET="_top" TITLE="Testable Requirements as a Sizing Measur"><B><IMG SRC="02611110.png" border=0 width="17" height="17" ALT="up" ALIGN="BOTTOM" HSPACE="0" VSPACE="0"></B></A><B> </B><IMG BORDER="0" SRC="1x1.gif" HEIGHT="17" ALIGN="BOTTOM" HSPACE="0" VSPACE="0" WIDTH="17"><B>          </B><B>               </B><A HREF="http://www.mosaicinc.com" TARGET="_top" TITLE="http://www.mosaicinc.com"><B>Mosaic Home</B></A></div> <bR> </td> </tr></table></body>