Code Animation Generator

1. Code Animation Generator Team 4: The Green Evolution Ninja Monkeys!

2. Team Members • Alex Bermudez (Doxygen Lead) • David Callies (Parsing Team Lead) • Jose Suarez (Quality Assurance Lead) • Kevin Tiller (GUI Designer) • David Weston (Technical Lead) • Matthew Znoj (Webmaster)

3. Need • As projects continue to grow in scope, they become hard to grasp in their entirety. • Raw documentation isn’t enough anymore (too much really)

4. Solution • Look through source control repository for major revisions. • Reverse engineer code into graphical form. • Generate a coherent animation of the source. • Recursive design (Self-Testing)

5. Concept of Operations

6. Concept of Operations • The User Requirements is the collection of thoughts from several meetings that were held between the client and team members as an effort to clarify the dimensions and scope of this project • This document reflects the User Requirements of the stakeholders involved in the system based on: • Needs • Expectations • Desires • The mission of this team is to take the User Requirements and translate them into the Software Requirements Specifications

7. The Current System • Developers have to inspect the repository of archives to identify the progress of a given project • The situation is even more difficult for non-technical users who relay completely on the information provided by developers • Administrative users are unable to participate actively when needed

8. The Proposed System • Needs • A software tools to illustrate the development of a large scale project • Increase developers’ productivity in both: • Tracing the state of a project • Assistance with high level technical presentations and progress reports within the enterprise

9. The Proposed System • Users • Developers: Responsible for implementing the new system • Client: Active participant to define requirements and specifications • Stakeholders: All personnel involved in the project

10. The Proposed System • Modes of Operations • Illustrative reports generated for any version of the project's archives • Graphical representation of the code's evolution throughout the whole life cycle of the project

11. Sample of an Illustrative Report

12. Alternative for Graphically Represent the Code’s Evolution • E:\3d-evolution.html • 3d-evolution.html

13. The Proposed System • Operational Features Must Have: • User-friendly interface to interact with any of the stakeholders at any time • Standardized comment style comparable with the software tool to be implemented in the system

14. The Proposed System • Operational Features Would Like to Have: • Computer platform independent • Variety of shapes generated by the new system to accommodate different preferences

15. The Proposed System • Expected Impacts • Improvement in communication between the different parties of the project • Increase of productivity is expected in the development team

16. The Proposed System • Analysis • Expected Improvements: Productivity and communication throughout the enterprise. • Disadvantages: Development time required for implementing the new system • Limitations: Time constrains and economical resources to acquire better software tools. • Risks: The election of inappropriate software tools could generate a drawback and delays. • Alternatives and Tradeoffs: Some specialized tools would provide faster results but budget constrains limit the options.

17. Project Management Plan

18. Interesting Standards • GENM decided to use its own coding standard, based on C++ style • CamelCase functions • CAPITAL constants • G_prepended globals • C_CamelCase classes • Typewriter punctuation spacing: • Document standard. Single space. EM space

19. Prototype Model + Incremental

20. The Iterative Prototype Model and YOU • The development cycle allows for unique risk management • Also allows for incremental design and feature addition • Easy to adapt to technical shortcomings, changes in the client feature requests, etc

21. PERT

22. Software requirements specification

23. Introduction • What does it do? • Source Base • Animate! • What is defined? • Doxygen • Subversion (SVN) • .NET Framework 3.5

24. What are we assuming? • Doxygen • RAM • Graphics • XP

25. Who has a stake? • Dr. Damla Turgut • Antoniya Petkova • Green Evolution Ninja Monkeys

26. Use Case Diagram

27. Functional Requirements • Check major revision • Reverse engineer into graphical form • Produce coherent animation

28. Interface Requirements • Get source base from user • Display animation • Prompt user to save data

29. Environment Requirements • Microsoft Windows XP or later capable machine • .NET Frame 3.5 installed

30. Users and Human Factors Requirements • Usable by anyone • Does not to need to understand how software works • Provide help for advanced functions

31. Documentation Requirements • Both available on-line and printed • http://cop4331group4.webatu.com • Audience includes customers, users, and software designers

32. Data Requirements • Retrieve source locally or from SVN server • Make comparisons between times, dates, version numbers, etc. • Option to save raw code, data file, or animation video

33. Resource Requirements • 6-person student development team • Physical resources provided by the University of Central Florida • Microsoft Visual Studios 2008 • Microsoft XNA Game Studio 3.0 • Doxygen • Subversion Repositories • 000webhost.com • Google Code

34. Security Requirements • .NET Framework 3.5 provides secure platform • User is responsible for source code security • Program will not backup or restore data

35. Quality Assurance Requirements • Will implement exception handling • Have at least 99% uptime • Response time should be measured in seconds, not minutes

36. Test plan

37. Test Plan • The main objective of the project is to develop an application that will represent the history/evolution of a project’s code in a graphical fashion, making it easier to anyone working on said project to track the changes that have been made through time. • Testing will allow the development team to find any possible errors in the application, and to correct them in an organized and efficient manner. • It will allow the team to have a polished Released Candidate version that will be presented to the client. • It will help in the development of a more robust software.

38. Description of Test Environment • The following is a list of hardware and software specifications under which the application will be tested: •  Windows XP SP 3 and Windows Vista·         Microsoft XNA • Tortoise SVN (Tentative) • Doxygen • No other thirds party applications*

39. Description of Test Environment • Testing of the application will be conducted by: • Developers • Client  Ideally, the software will operate in an environment that has the same specifications as the ones used for testing, or at least one that closely resembles the testing environment.

40. Stopping Criteria • The software will be on three (3) test cases at a time, and the following criteria will be used: • 1. Each test case will be run five (5) times, and two (2) different machines, or until a fatal error is found. • 2. Records of all non-fatal error will be kept. • 3. Testing will undergo on a specific test case until successful completing of the task, or until a fatal error is encountered. • 4. If the software takes more than 10 minutes to complete its task, testing on the current test case will be concluded.

41. Stopping Criteria • 5. A general meeting will take place to discuss errors, if any, decide on an approach, and delegate tasks to all team members. • 6. If no errors* are found on any of the test cases, a meeting will be set up with the client for a final demo, and if the client is content with the results, the software will be declared to be good to deliver. • 7. Otherwise, errors encountered on the demo will be corrected, and/or new functionality asked by the client will be implemented, and the whole testing process will take place again.

42. Description of Individual Test Cases • Case 1: Open Source CMS (Joomla) • Poorly documented • Large Project • Multiple File Extensions

43. Description of Individual Test Cases • Case 2: Code Evolution Animator • Small Project • C# • Well documented for Doxygen

44. Description of Individual Test Cases • Case 3: • Doxygen Sample Project • Documented Specifically for Doxygen • Mid Size Project • Graphical Representation of the project structure

45. The End • Questions?