,MSE Project Evaluation
CIS985
Kansas State University, fall 2005
UML Sequence Diagram Generator
Project Evaluation
Author Major Advisor
Samer Alisaleh Bill Hankley
Table of Contents
Introduction 3
1. Process Evaluation 4
1.2 Expected Time vs. Actual Time 4
1.2 Phases Break Down 5
1.3 Phase 1 Tasks Break Down 6
1.4 Phase 2 Tasks Break Down 7
1.4 Phase 3 Tasks Break Down 8
1.5 Estimated Development Time vs. Actual 8
2. Delivered Product Evaluations 9
2.1 Line of Code Evaluation 10
2.1.1 Top-Down LOC Estimate 10
2.1.2 Bottom-Up LOC Estimate 10
2.1.3 Actual Line of Code vs. Estimate 10
3. Project Challenges 11
4. Lesson Learnt 12
5. Future Work 13
6. References 13
Introduction
This document will evaluate the software process and the delivered product. The software process will be evaluated using the time log to measure the productivity and time distribution between the different components. Line of code will be also measured and estimated, then compared the actual size. The delivered product will be evaluated based on its usefulness and checked if it fulfills the idea presented in the requirements and the project vision. Graphs and diagram will be provided to clarify some numbers resulted from evaluating both process and delivered product. At the end of the document there will be a list for the challenges encountered during the process and how each challenge is handles. A list of learnt things will be also provided, besides a list for what can be added to make the plug-in more practical and useful.
1. Process Evaluation
The process followed for developing this plug-in is by iteration. There were three iterations for this process, where each iteration contributed in maturing the product and the documentations that come along. The first phase was for requirement analysis and process planning. The second process is more for architecture design using UML, and providing an executable prototype the covers some features for all the requirements mentioned in the software requirement specification. The last phase is used to insure the quality in the developed product by stabling the architecture design, testing the code and finalizing the documentations with commented source code.
After each phase, there will be some action items requested from the committee, where time was assigned to document each action item and the way it was addressed.
1.2 Expected Time vs. Actual Time
The following table compares the time expected start and finishes time to the actual start and finish time with the total number of days for each phase.
Phase / Expected Start Time / Expected Finish Time / Total days / Actual Start Time / Actual Finish Time / Total days1 / January 14th, 2005 / April 15th, 2005 / 91 / January 14th, 2005 / April 15th, 2005 / 91
2 / May 1st, 2005 / June 20th, 2005 / 51 / August 16th, 2005 / Nov. 1st, 2005 / 77
3 / June 22ed, 2005 / July 21st, 2005 / 29 / Nov 8th, 2005 / December 5th, 2005 / 26
The following chart summaries the data in the previous table in graphical way:
From the table and the graph above, we calculate the percentage of error between the expected and actual # of days for each phase, as follows:
Phase 1 Error % = 0% (Exact Estimate).
Phase 2 Error % = (77-52)/52 = 48% (Under Estimate).
Phase 3 Error % = (26-29)/29 = -10% (Over Estimate).
1.2 Phases Break Down
The following Doughnut graph shows the process phases break down. This graph uses two doughnut charts, the internal chart used for the general phases break down, and the external shows tasks break down for each phase. The doughnut chart is very interesting when comparing the whole process and the different tasks in different phases.
1.3 Phase 1 Tasks Break Down
The following is a pie chart for the first phase tasks break down, each sector is assigned task name, number of hours and the percentage.
1.4 Phase 2 Tasks Break Down
The following is a pie chart for the second phase tasks break down, each sector is assigned task name, number of hours and the percentage.
1.4 Phase 3 Tasks Break Down
The following is a pie chart for the final phase tasks break down, each sector is assigned task name, number of hours and the percentage.
1.5 Estimated Development Time vs. Actual
The COnstructive COst MOdel ( COCOMO ) model was used in the software project plan document to estimate the development for this project, and it was found to be 5 months. From the time log posted on my web page, it was found that total time calculated from summing all the days spent on each phase is close to 4 months , starting from August 16th, 2005 to December 5th, 2005. The productivity varies from each phase. The following diagram shows the productivity given in hours/day for each week during the last two phases. Note that phase one is not included because there was a big time gap between working on the first phase and the second phase, besides phase 1 was a very small phase in time and in productivity, therefore its not considered as part of this graph.
Note that in the August 30th week the productivity was Zero, and that because a serious bug was found in the tool plug-in architecture that might have jeopardize the whole project, therefore a contact was initiated to the developer of the VP-SDE tool to fix the bug, and It took almost a week to fix the bug and get a reply with the new release.
The increase of productivity at the end phase to almost 8 hours was reasonable compared to the estimated time, since the estimated time (close 5 months) is based on the assumption of productivity of 4 hours/day. 3 months are almost consumed by the first and the 2ed presentation, so based on the estimation 2 months are left, however 1 month is left for the fall semester, therefore to compensate for the that period of time, the productivity must be almost doubled, and that explains the 8 hours productivity at certain time in phase 3 compared to the 4 hours/day productivity in phase 1 and 2.
2. Delivered Product Evaluations
This Section will discuss the final product of this project, which is the plug-in tool developed for the VP-SDE software. The line of code (LOC) will be compared between the estimated and the actual value. At the end of this section, the learnt lessons from the overall software engineering project beside a future work will be addressed.
2.1 Line of Code Evaluation
There are two ways for estimating the LOC, one is top-down estimates using the COCOMO model, and another is bottom-up using the architecture design developed for this project.
2.1.1 Top-Down LOC Estimate
COCOMO model was used estimate the LOC based on the function point calculation. For more information about the calculation please refer to the Software Project Plan document developed in phase 3.
The estimates for LOC using this model was found to be equal to 2097 LOC
2.1.2 Bottom-Up LOC Estimate
The class diagram is used for this model, and the calculation is done by predicting each operation LOC for each class.
Based on the assumption above, it was found that LOC is equal to 1643 LOC
For this model, it was expected that the estimate will be less than the estimate in the top-down model and even in the actual number, since the class model usually is not complete by not listing all the operations that is going to be part of the class when coding, the reason for this is because the class model usually exposes the important operations only, besides when estimating the operation LOC, its hard to count for all the details and exceptional cases that can sum up to considerable amount of LOC.
2.1.3 Actual Line of Code vs. Estimate
To get an accurate count for the final product line of code, a tool called LOCC is used to count the total LOC for each file, for more information about the tool, click here.
Using the LOCC tool it was found that the LOC of the final product is 1905 LOC.
Given the actual LOC and the estimates above, we can calculate the Percentage of Error between the actual the estimate as follows:
- Percentage of Error for the top-down model:
(2097-1905)/1907 = 10% (Over Estimate).
- Percentage of Error for the bottom-up model:
(1643 – 1905)/1907 = 13% (Under Estimate).
3. Project Challenges
- Choosing the suitable development tool:
That was the biggest challenge in the project, which is to find the suitable tool that support writing plug-ins and provide enough material and documentation to learn the plug-in architecture. A lot of time was spent researching and studying different tools until I decided to with Visual Paradigm Smart Development Tool, because it has a simple plug-in architecture with some documentation on how to start the process for writing plug-in.
- Learning Curve:
A big time was spent on learning how to write a plug-in for the chosen tool, besides testing the different features and some of API libraries to conclude if the tool fulfills the product requirements and the vision document.
- Plug-in Architecture Limitations:
It has been found that the simplicity of creating a plug-in for the VP-SDE tool comes across having a lot of limitation to interact with the tool. Such limitations made it difficult to create the anticipated user interface for the plug-in. For example the only way I found to send information from the tool to the plug-in based on the user action is by selecting menu item or clicking on tool bar icon only, and there isn’t any way to send events through other action, such as mouse actions.
- Bugs in Plug-in API:
A lot of bugs where found during the development of the plug-in through using different API classes operations. Some of the bug were crucial and could have jeopardized the whole project, however the tool support people were very helpful in fixing the bugs and sending me new releases with fix after informing them with problem.
- Debugging the Plug-in:
Debugging the plug-in was not possible since the VP-SDE tool doesn’t generate any messages or exceptions if there is some kind of run time error, and if that happens; the VP-SDE tool will either not upload the plug-in, or not respond to the user action. Therefore it was hard to trace the source of error.
- Coding vs. Time vs. Documentation vs. Requirements:
The amount of documentation required for the MSE project, besides the amount of time available makes really hard to only focus on satisfying all the anticipated plug-in requirements and goals, therefore some of the requirements and functionality were not implemented in the final release.
Its important to mention that despite all the limitations and problems encountered by using the VP-SDE tool, still the important factor for choosing this tool was the simplicity of learning the plug-in architecture which was crucial for developing the anticipated product that achieve the given requirements with available amount of time.
4. Lesson Learnt
Overall, the knowledge achieved though this process was great. I have learned a lot in term of the software engineering process and in term of using different software and tools to develop the anticipated product. The three development phases taught me a lot about the software life cycle and how the software evolve through the different phases iterating through analyzing, designing and developing the prototype until the final product is delivered. Some software engineering concepts and methodologies were used to verify, measure and estimate the overall process, such as the COCOMO model, which made the process more challenging and interesting at the same time, in order to achieve the goals for the used concepts. A lot of skills were also gained from writing the different documentation for this project
A lot of tools were used to develop this plug either for coding or documentation purposes. The following is a list of some of the used tools:
- Eclipse IDE 3.1 Compiler.
- Eclipse Java-doc feature.
- Eclipse Jigloo plug-in for GUI Builder.
- Visual Paradigm Smart Development Environment.
- Visual Paradigm Plug-in Architecture and API.
5. Future Work
Despite that the sequence diagram generator is not 100% complete, still I found it very interesting way to connect different UML diagrams together and make them consistent, and this idea can be extended and applied to other diagrams, such as collaboration diagram, activity diagram…etc. There is a lot of potential to improve the current product by adding new features to make the tool more interactive, such as suggesting solutions to the user when he/she is trying to invoke a message from a class that has no association with the caller class; providing a way to add predicates or iterations for the generated messages; synchronizing the class and the sequence diagram information when changing message name or creating object of new class type….etc.
The current plug-in architecture probably is not powerful enough to support such features, however this architecture is going through a lot of development and changes and hopefully later releases will be dynamic enough to support such features.
6. References
1