The goal of this project is to develop a software package that derives information from program source files. This software tool will provide data to estimate and track the size of software development projects. Initially, this application will focus primarily on non-comment lines of code (NCLOC). Because the actual act of NCLOC counting can be made rather trivial with the proper coding standard the goal of this project is to focus on the management and tracking aspects of this problem. (For example, as we are counting lines, a format that puts all braces on separate lines will generate a higher LOC count than a more condensed standard format. There are more sophisticated methods that address these issues, such as counting expressions and statements, but these are significantly more complex and are beyond the scope of this project.) In fact, a properly designed code counter can be easily reconfigured to count to multiple coding standards and languages by separating the standard/language aspect from the actual counter. Your project will be required to support such a mechanism. (Hint: Use a Line of Code base class or similar mechanism.)
Note: Because part of the software engineering process is the elicitation and definition of requirements, this specification is purposely vague in some details and may be missing other relevant information. Please consult your client (the professor) for any needed clarification.
This project is based on an assignment developed by Dr. Welch, which, in turn, draws on work done by Watts Humphrey of the Software Engineering Institute. Elements of this project are taken from Humphrey's text on the Team Software Process (TSP). Humphrey has written several software engineering books, including two on the Personal Software Process (PSP) and one on the Team Software Process.
The program information application analyzes a specified set of source files. You may chose to analyze either C++, Java, or C# files (your analyzed language choice does not need to be the same as your coding language choice; indeed, your application will be extensible so that modifications allowing analysis of source files from a wide variety of languages will be possible. When analyzing C++, you must support both ".h" and ".cpp" files. The user specifies which files are to be analyzed. Note that the files may be in more than one directory, and there could thus be more than one file with the same name.
The number of non-comment lines of code in each file is to be counted and reported, by file and in aggregate. At a minimum, the "//' comment style must be supported.
The analysis results should be displayed on the screen and, upon user request, saved as a text file containing file names and size (NCLOC) for each file, and the total size for all files.
The software package must operate properly in the Windows XP environment; it is expected that that an appropriate GUI framework will be used (e.g., MFC for C++, Swing for Java, Windows Forms for C#). Student teams wishing to use other frameworks should get permission from the professor before doing so.
The following features are optional additions for Cycle 1:
In this cycle, all the Cycle 1 capabilities must be retained. In addition, the program information application must also determine the size (NCLOC) of individual classes. This new information includes the total size of each class (definition, all member functions, etc.), the number of methods (member functions) in each class, and the average size for all the methods in each class.
The various analysis options (at least the file LOC and object/method LOC) must be individually selectable by the user, and any or all may be chosen at one time.
[Implementation note: the specification does not require you to write a parser for the analyzed language. It is permissible to use other techniques (such as embedding special comments {perhaps using JavaDoc with a coding standard that includes comment formatting} to identify sections of source code. Hint: Using comments isn't necessary if you use a coding standard that rigorously specifies formatting, perhaps including indentation, columns for braces when ending a method, etc.
The following features are optional additions for cycle 2: