IAC-07-D3.4./D3.5/E5.5.08

LESSONS LEARNED FROM DEPLOYING AN ANALYTICAL TASK MANAGEMENT DATABASE

Mr. Daniel A. O'Neil 1 daniel.a.oneil_nasa.gov Ms. Clara Welch 1 [email protected] Mr. Joshua Arceneaux Booz Allen Hamilton Houston, TX 77058,United States [email protected] Mr. Dennis Bulgatz 2 [email protected] Mr. Mitch Hunt 2 [email protected] Mr. Stephen Young 2 [email protected]

1National Aeronautics and Space Administration (NASA), Huntsville, AL 35812, United States 2Analytical Mechanics Associates (AMA), Huntsville, AL 35816, United States

ABSTRACT

Defining requirements, missions, technologies, and concepts for space exploration involves multiple levels of organizations, teams of people with complementary skills, and analytical models and simulations. Analytical activities range from filling a To-Be-Determined (TBD) in a requirement to creating animations and simulations of exploration missions. In a program as large as returning to the Moon, there are hundreds of simultaneous analysis activities. A way to manage and integrate efforts of this magnitude is to deploy a centralized database that provides the capability to define tasks, identify resources, describe products, schedule deliveries, and generate a variety of reports. This paper describes a web-accessible task management system and explains the lessons learned during the development and deployment of the database. Through the database, managers and team leaders can define tasks, establish review schedules, assign teams, link tasks to specific requirements, identify products, and link the task data records to external repositories that contain the products. Data filters and spreadsheet export utilities provide a powerful capability to create custom reports. Import utilities provide a means to populate the database from previously filled form files. Within a four month period, a small team analyzed requirements, developed a prototype, conducted multiple system demonstrations, and deployed a working system supporting hundreds of users across the aeros pace community. Open-source technologies and agile software development techniques, applied by a skilled team enabled this impressive achievement. Topics in the paper cover the web application technologies, agile software develapment, an overview of the system's functions and features, dealing with increasing scope, and deploying new versions of the system. INTRODUCTION CAIT - Constellation Analysis Integration Tool Defining mission and system requirements for large aerospace projects involve a myriad of CxP - Constellation Program trade studies conducted by geographically DAC- Design Analysis Cycle distributed teams. Ensuring efficient use of DIO - Directorate Integration Office resources requires a tremendous coordination ER - Entity Relationship effort. Within NASA's Constellation Program, ESMD - Exploration Systems Mission the Architecture Trades and Analysis (ATA) Directorate Office defines the analysis cycle goals, FOSS - Free Open Source Software GNU - GNU's Not Unix objectives, and to integrate the analyses across the Constellation Program (CxP). Before HTML - HyperText Markup Language 2007, this process, known as the Integrated HTTP - HyperText Transfer Protocol Design and Analysis Cycle (IDAC), used a IDAC - Integrated Design and Analysis Cycle Microsoft Word document form called a Task MS&DA - Modeling, Simulation, and Data Architecture Description Sheet (TDS) to define a study MVC - Model Viewer Controller task. Collecting, coordinating, and reporting on the TDS forms required several people RoR Ruby on Rails who found it difficult to track the status and SQL - Structured Query Language dependencies among the studies using TBx - To Be Determine, Resolved, Supplied, Microsoft Excel. Between October 1st and (TBD, TBR, TBS) December 7th, of 2006, a small development TDS - Task Description Sheet team with representatives from NASA, Booz RoR - Ruby on Rails Allen and Hamilton (BAH), and Analytical Mechanics Associates (AMA) defined requirements, designed, developed, and deployed the Constellation Analysis Integration Tool (CAIT) database. Using CAIT, the ATA office can collect, coordinate, integrate, and report on all of the study Process / activities within the program. In February of / '\ 2007, the Directorate Integration Office (DIO) within NASA's Exploration Systems Mission Directorate (ESMD) defined requirements to expand the scope of the database from managing tasks for one program to managing Figure 1: Functions identified in the requirements document and reporting tasks throughout ESMD. This paper describes the process applied by the Application Objectives development team and the lessons learned With the creation of the CxP program office in about developing an enterprise task 2006, the ATA office executed the first management database. iteration of the IDAC for the CxP, IDAC 2. The IDAC 2 process involved study team Acronyms leaders creating hundreds of TDS in Microsoft AMA - Analytical Mechanics Associates Word and storing the files in various ATA - Architecture Trades Analysis directories of a web-based product data BAH - Booz Allen and Hamilton management system. Access to the directories where the TDS forms were archived were limited to organizationalpersonnel; consequently,peoplewho did not haveaccess Recognizing the issues associated with to the TDS archivedirectoryrelied on copies managing so many tasks through Word that weree-mailedto them.During thecourse documents and Excel files, the ATA requested of astudy,aTDS authormight changethe the Constellation Modeling, Simulation and contentof theform andupdatethefile in the Data Architecture (MS&DA) office to create a archiveor contentthattheform "linked to" centralized database for managing tasks might changewithout anyonebeing made associate with the IDAC. Joshua Arceneaux, awareof the changes.Personnelwho were from BAH, served as the "voice of the working with thecopy of theoriginal might customer" by writing a requirements notreceivetheupdatedversionof theTDS. document that explained the database Also, giventheflexibility of theWord form, functions and fields needed to capture severalTDS authorsmodified or addedfields sufficient data for IDAC management. Figure to clarify their tasks;thisactionledto 1 identifies the functions specified in the inconsistenciesamongtheTDS files. ATA's database requirements document.

FUNCTIONS AND FEATURES Why does a program conduct studies? Some Built upon a a MySQL database, The CAIT studies resolve problems or provide needed application contains 89 tables, storing detail for requirements. Other studies everything from users to Analysis tasks and determine methods for mitigating risks the links between them. The Ruby On Rails associated with a design. A task within CAIT (RoR) framework makes it easy to change the can link to a specific TBx associated with a database to Oracle, SQL-SRV, or other, as the requirement or a particular risk. database connection logic is largely stored in the RoR model fries. With CAIT, study Linking tasks to people, products, tools, managers create Task Description Sheet requirements, risks, and issues provides the (TDS) to define the work, resources, products, most powerful function of the CAIT database. and schedules. Table 1 presents the elements Data produced by one task can be an input to of a TDS. another task. Multiple tasks may involve the Introduction Description, Title, Points of Contact same human resources and requirements. A Timeline Current Status, Projected Completion TDS record specifies dates that particular Date, Priority review boards receive the results of the task. Links to Requirements (system and mission) Reports within the database identify the External Risks (potential problems and impact) dependency among the tasks. Items Models (analytical tools used) Issues (current problems) Review Boards Filters implement a search function for finding Resources (analysts, facilities, etc.) records based on criteria ranging such as Analysis Inputs organizations, teams, status, scope, and key- Data Outputs words. Scope indicates whether the focus of a Board Deliverables study is a component, system, multiple Supporting Design Reference Missions Information Methodologies systems, or a complete exploration Mission Phases architecture. Report generators use the filters Purpose to produce status and dependency reports. System Elements Table 1: Elements of a TDS Administrative functions provide the capability to create user accounts, assign peopleto teams,andbaselineTDS records.A • Programmers don't have time to provide databaseadministratorcanlock or "baseline" instant help-desk support, records,which preventsconstanttweakingof • Custom application tend to have thetasksthroughouttheIDAC process. insufficient documentation, • Quality of custom software does not DESIGN PHILOSOPHY match commercial applications, Benefits derived from a custom database • Continued dependence on the include process driven design and maximum development team that wrote the code flexibility to respond to the changing needs of an organization. When an organization Free Open Source Software (FOSS) alleviates procures a commercial application for these concerns through standards, community, managing a process, it is bound by the and automation. Applications created with concepts and terminology embodied in that F0SS benefit from standardized tools, application. If the application is general practices, templates, and reusable code. These purpose enough to accommodate any kind of standards mitigate the risk of one programmer process then the organization has to determine becoming a single point of failure and enable how to apply the application to the business future maintenance by programmers other process. Often, sophisticated general purpose than the original developers. Well established applications require extensive training. With a FOSS has large communities that thoroughly custom developed application, representatives test and document the systems. Online forums from the organization participate in the hosted by these communities provide requirements definition and system design. technical support to developers. By building Custom developed applications embody the upon FOSS, the development team gains organizational process so less training is tremendous leverage in documentation. Websites dedicated to the FOSS provide required because the user community understands the concepts and terminology. required documentation about the internal structure, application programming interface, and tutorials. This foundation allows the Owning the source code positions the application developers to respond quickly to development team to focus on the user's guide new requirements. Commercial applications and documenting the business logic portion. often have a number of customers who wish Standards and automation ensures quality for a wide variety of functions and features. through templates and code stubs. An organization might have to wait years Standardized file structures and templates before a commercial product implements a ensure that everything has a place and the desired feature. An organization could pay the code is consistent. Automated generation code vendor to implement a desired function but stubs enable development of function and how is that different than developing a custom regression tests. Programmers populate the application? The vendor saves research and code stubs with expected inputs, calls to development funding and releases the new functions, and error checking code to capture functions in the next version of the proprietary potential bugs. Applying standards, receiving product. assistance from the community, and gaining leverage from automation enables a Leery project managers express concerns development team to offer the technical about custom applications because: support, documentation, and quality that users • A small development team might have a would expect from any commercial .single point of failure, application. valuesof agile softwaredevelopmentandto Accordingto theAgile SoftwareDevelopment deployaworking systemwithin threemonths. Manifestol,Thisdesignphilosophyvalues: • Individualsandinteractionsover Designphilosophiesappliedin the CAIT processesandtools developmentprocessinvolvedbuilding upon • Working softwareovercomprehensive FOSS,applyingthevaluesof agilesoftware documentation development,anddemonstratingearlyand • Customercollaborationovercontract oftenthroughrapidprototyping.Building with negotiation FOSSenabledrapidprototypingbecausethe • Respondingto changeover following a developmentteamgainedleveragefrom the plan standardsandautomation.Agile software developmentvaluesensuredthattheATA Initially, the CAIT developmentteam organizationacceptedthedeployedsystem. analyzedmorethanhundredwritten Rapidprototypingengagedthecustomerand requirements.After developingaprototype enabledthedevelopmentteamto deploythe the CAIT teamdemonstratedit to key systemon atight schedule.To applythese personnelwithin theATA. Commentsabout philosophies,thecustomerhadto acceptthat theprototypewerepositiveandindicatedthat testinganddocumentationwould comeafter the CAIT teamunderstoodtheneedsof the systemdeployment.Developersacceptedlong customer.ClaraWelch,whohadconducteda hardhoursduringtherapidprototypingphase thoroughanalysisof therequirements,pointed andtheprojectmanagerhadto manage outtheprototypeimplementedonly asmall customerandstake-holderexpectationsabout fractionof thedocumentedrequirements. deliveryschedules. Thoughthedocumentidentifiedeverything thecustomercouldpossiblywant,the DEVELOPMENT PROCESS prototypecapturedwhatthecustomerneeded Developing the CAIT database involved to getthejob donein thenearterm.After the requirements analysis, system design through demonstration,theCAIT developmentteam entity-relationship diagrams, rapid andtheATA office agreedto movefrom a prototyping, configuration management, traditionalwater-fallapproachto an agile functional and regression testing, system softwaredevelopmentmethod.Workingwith deployment, and meeting with the user JoshArceneaux,thedevelopmentteam community to discuss future improvement. iteratedtherefinementof theprototypeeach Figure 2 depicts the iterative nature of the weekuntil it becauseadeployableapplication. process. Rapidprototypingenabledtheteamapplythe

U

Comments L__i Anatyze t_l _Cre_eEnt_tY2'>Z__. 1N ! Appl_ca[ionDeve_° _:] App_ica_on H " Receive ] Commun_, J I u_acYar!!_._jI t

Config_atioil & Regression I Manage H DevelopTestsFunction _[ DeNoy

Figure 2 System Development Process DB Designer 4 Designer for free. Figure 3 presents a screen- LaMonte Dent, who works at the University shot of an ER diagram that derived from the of Alabama in Huntsville, made significant requirements document. contributions to the project by developing an Entity-Relationship (ER) diagram and a After several iterations of the diagram, the prototype of the user interface. Working with development team produced a prototype of the LaMonte's ER diagram and tool of choice, system. With the deployment of the system, Dennis Bulgatz and Josh Arceneaux used DB the emphasis shifted from the design to Designer 4 to identify the data objects and system improvements so the development interfaces within the CAIT database. team ceased work on the ER diagram. Plans Integrating design, modeling, creation, and for future development will retum to the ER maintenance into a seamless environment, diagram to document the "As-Deployed" Fabulous Force Database Tools offers DB version of the system.

Figure 3: Sereenshot of the CAIT ER Diagram in DB Designer 4

Solution Stack Ruby is an interpreted, object oriented, dec larations to keep in sync, no compiler scripting language created by Yukihiro specific words, and no framework code. 3 Matsumoto. 2 According to the Pragmatic Programmer's Guide, Ruby follows the Rails, a development framework, enables principle of least surprise, meaning that things production of database-backed web work the way you expect with few exceptions. applications based on the Model-View- Proponents claim that Ruby programmers can Controller (MVC) pattern. 4 The MVC pattern write more code in one sitting, with seldom decouples the user interface, or view, from the syntax errors, no type violations, and fewer data, or model. Separating the model and the bugs when compared to other languages. view allows programmers to make changes in These claims are based on language features the front-end or back-end of the application such as no end of line semi-colons, no type without affecting the other end. Also, MVC separatesbusinesslogicfrom data framework, application server, and web presentation.Controllersrespondto events, server. typically useractionsandmight involve changesto themodel.5 A three stage system involved a development server, staging server, and production server. Mongrel is a fastHyperTextTransferProtocol By making the development server publicly (HTTP) library andserverfor Rubythat is accessible, the development team provided a intendedfor hostingRubyweb applications.6 capability for the customer to interact with TheApache'web-servercanbe configuredto prototypes and provide comments. With the forwardall or sometraffic to Mongrel.With staging server identical to the production thepossibility of two or moreusershitting the server, the system administrator applied applicationserversimultaneously,it is operating system patches and determined how possibleto createmultiple Mongrel instances.7 they affected the application without running For a Ruby-on-Railsapplication,Mongrel the risk of interrupting the production system. servestheweb-pageswith embeddedRuby After approval from the customer on code scripts. changes and successful tests of operating system updates, the system administrator Debianis afreeoperatingsystemthat usesa deployed new versions of the application on Linux kernelandbasictoolsfrom the GNU the production server at the end of the project. Startedin 1993,thenameDebian workday. derivesfrom thedeveloper'snameIan Murdockandhis wife Debra.8Debianhasa Configuration Management world-wide developmentcommunityready The development team chose Subversion andwilling to assistdevelopers.For example, (SVN) as the code repository server and StephenYoungdiscoveredabugin Debian Tortoise SVN as the client. Version control thatpreventeda RubyGemslibrary from systems solve the problem of enabling users to working.Stephendeterminedthesourceof the share information and preventing them from bugaprogrammerin Japanwhowaswilling overwritin_ one another's changes in the to updatethecodebase.Within two days, repository." As a project, CAIT used a Stepheninstalledthe updatedoperating development repository and a production systemthatenabledtheRubyGemslibrary to repository. Developers check new code into work. the development repository, where it is integrated with other new code. At the end of CAIT a development cycle, the code is promoted to testing- where integration testing is done, and then when ready, the code is promoted to Debian 4.0 Operating production.

IBM Experiences of the development team found that merging code between multiple branches Figure 4: Solution Stack to be a tedious, error prone, and time Deployed on a virtual computer within an consuming process. To make better use of IBM mainframe, the CAIT database is built code branches, focus the code on a single task upon the previously describe systems. Figure because merging code with unrelated changes 4 depicts this solution stack of the virtual complicates the process. computer, operating system, database, Code and Data Migration LESSONS LEARNED With Ruby on Rails, developers can generate Experiences associated with deployment of a migration scripts for changing code and web-based task management database have content. Benefits of migration scripts include taught the team valuable lessons about updating code on multiple development requirements definition, system design, systems, rolling out new baselines on a software development, configuration production system, and providing a roll-back management, testing, deployment, and capability for debugging. continuous improvement. Generically, these lessons sound familiar to systems engineers Functional and Regression Testing and project managers with experiences in Ruby on Rails provides a capability to auto- software systems development. The project generate code stubs for functional and management and programming gems among regression tests. As the development team these lessons pertain to the tools and discovered bugs in the code, Clara Welch techniques applied on this project or their incorporated error checking code to look for recommended alternatives. the specific bug. As the team defined work- flows, Clara created regression tests that Requirements Definition executed the code based on use-cases. Originally, the development team began with a traditional requirements document with over Elevating the Application to the Enterprise 100 requirements. Contents of the document Initial operations of the CAIT database began included a high level process description and in the first week of December 2006. By detailed data tables. While this type of February 2007, there existed a sizable user document provided a starting point for community and a substantial amount of creating ER diagrams, it did not convey the content. Within the ESMD-DIO, Nantel business model, detailed work-flows or Suzuki advocated the application of the specifications for a graphical user interface. database to manage task descriptions for The development team found DB Designer 4 studies sponsored by the enterprise. With an to be a fine ER diagramming tool but it did operational system and on-going not capture the system behavior and implementation of Constellation requirements, interactions. Recommendations for rapid prototyping proved difficult. To define requirements definition range from using a and incorporate new requirements identified graphical notation like the Unified Modeling by the DIO, Daniel O'Neil and Nantel Suzuki Language 2 (UML) to writing a user's manual developed "As-Is" and "Go-To" screen-shots. complete with mock screen-shots. PowerPoint presentations contained current Developed by the Object Management Group screen-shots of the user interface and revised (OMG) consortium, the UML offers 13 images that depicted new fields and diagrams that depict the structure, behavior, recommended revisions to labels. After and interactions of a system.l° A user's implementing changes depicted on the go-to manual and mock screen-shots focus on the screen-shots, Mitch Hunt and Dennis Bulgatz step-by-step workflow of a user interacting demonstrated the system to Nantel on the with the system. Also, it serves system testing development server. Upon receiving approval and verification because users can follow the of the revisions from Nantel, the development manual and determine whether the deployed team deployed the new system. application matches the document. System Design prototyping capability without stopping Other than developing ER Diagrams in DB service on the production system. Designer 4, the design of the CAIT database evolved through rapid prototyping. The Rapid prototyping involves fast and furious development team produced a version of the programming. This approach can lead to a database and presented it to the ATA office. Mad Hatter's Tea Party where "there is never Based on consolidated comments provided by time to do the dishes." Automated document the voice of the customer, the team improved generation enables a team back-out a design the system and conducted another from the code so documentation is not demonstration. From October 2006 through sacrificed for rapid prototyping. For MySQL February 2007, the team deployed one or two and other databases, DB Designer 4 provides a .... 11 versions per week. By February, the system reverse engineering capablhty. For Ruby on had several hundred registered users so the Rails, there exists RDoc and RailRoad. With team was careful about making frequent major RDoc, programmers can generate HyperText changes to the graphical user interface. Based Markup Language (HTML) documentation on conversations with the end-users, the from Ruby source code. 12 With RailRoad, development team implemented user interface programmers can generate class diagrams to improve clarity, navigation, searches, and from Ruby on Rails source code. 13 announcements. Figure 5 presents an image of the summary screen for a TDS. Notice the Software Development "bread-crumb" trail above the title of the TDS, Between October 15 th and December 7 t_, which indicates the location within the 2006, the CAIT development team learned system. Highlighting in yellow indicates the RoR and developed several versions of the active menu. On the left side, a vertical area database and application. After deployment, presents buttons for the active menu. As the the team continued improving the product and team implemented requested revisions, the the associated development process. To customer Viewed the application on the update the database and roll the baseline code, development server instead of the production the team learned a powerful technique known server. This approach provided some rapid as migration scripts. As mentioned in an earlier section, migration scripts provide a capability to change schema and content of a database. Code written for the CAIT database was Main Summary for: ATA-OO-OOZ

Constellation Mission Mode developed without an Integrated Design

=.. _ IntroducUon _ll,l_l,t vl,., Environment (IDE). Benefits of an IDE _DS TPde and O_fiption ' _alId IRe_ronce Unks to Re aran_ Do.merits 0 mfamn_s IDesc_otion OCs, sponsoring and Perfo_ n_ Orgs vatld include text color coding, code completion, IP._ ..... debugging, and statistics. The Rails IDE

status and Timeline value_ Ivalid Minus Eclipse (RIDE-ME) is an open source,

Links windows based environment designed Ill I_ |l'llt Recuirement LJnks to R_u_rements lg reQu reh_en_, : Risk L_nks to Ris_s 0 dsk_ specifically for RoR development. 14A Modesrequ ed o theTOS_aly_s .... 2motJels ' l_sues issue CodeSnippet manager in RIDE-ME support _nard lssoda_on _oards Ass_dated w_ the TO_ i_ 0 board_ • Resour_ Resour_ required for the T_S _,nalysis 1 resource software reusability. When this project started, roles and responsibilities were not assigned, which served as a source of frustration and Supporting Informat_on If,]_llq'l_ ...... 1[iiii overlapping effort. Eventually, everyone

H _ion Phase go_ Nission Phase _eledoons val'd _wtemPumose Elemen_ purgose,Fo_ _s_emcom_let:lonELementsCdt_fiaSelec_onsand PJsk_ invalidinvaf_ erJ_etJa _and inwlid _u_Jose

Figure 5: Sereenshot of a TDS summarv naffe memberdiscoveredareaswherethey could solution stack. At the beginning of the project, contribute.Early in a project,it is a goodidea the team did not know that the production to identify tools,techniques,andtalents.For system would be a virtual machine within an example,to useRDoc, developersmustto IBM Mainframe. The Debian operating embedformattedcommentssothetool can system worked well on both the desktop generateHTML documents. development server and the mainframe. As mentioned earlier, a bug discovered in the Configuration Management Debian operating system was corrected within A release manager merges of source code two days. A significant change in the solution from multiple programmers. Responsibilities stack was switching from Apache's FastCGI of this person involve establishing a process to a Mongrel cluster. In both cases, the FOSS for receiving, accepting, integrating, and community provided technical support and releasing code. A team should use one needed documentation. centralized configuration management system such as Subversion to check-in their code. CONCLUSIONS Everyone on the team should understand and A summary of the lessons learned from adhere to acceptance criteria such as formatted deploying a web-based task management comments for document generation, results of system include: functional tests, and comments about the 1) Define use cases and illustrate changes. Integration or regression tests enable requirements with structural, behavior, and the release manager to determine whether the interaction diagrams new baseline works and if any old bugs have 2) Apply open source systems such as crept back into the system. A release manager Debian, Ruby on Rails, MySQL, Mongrel can set a cadence by developing a schedule for and Apache' accepting code and delivering the baseline 3) Ask for help from the open source system to the deployment team. community if problems arise in the solution stack Testing 4) Assign roles and responsibilities for A code generator, provided by RoR, enables development, release management, and development of functional tests. With deployment functional tests, developers can determine 5) Document procedures for comments, how code will react over the range of inputs migrations, testing, and configuration and check for previously discovered errors. management Integration tests focus on the performance of 6) Write with an Integrated Development the system to ensure robustness against any Environment and build a library of combination of user inputs. Applying the reusable code system requirement's use-case scenarios, 7) Evolve the system design through rapid integration tests can step through the user prototyping on a development server workflows. Writing test code requires the 8) Engage customers in the system design by developers to think through inputs that are out asking for screen layouts and prototype of range or wrong type as well as the critiques combinations of input data. 9) Capture the system design with automated document and diagram generators Deployment 10) Develop functional tests along with the Working with FOSS provided flexibility in code and integration tests based on the deployment of the production sever and use-cases References 1. Manifesto for Agile Software Development, http://www.agilemanifesto.org/ 2. Ruby Programming, http://en.wikibooks.org/wiki/Ruby_rogramminglanguage 3. Programming Ruby, http://www.mby-doc.org/docs/ProgrammingRuby/ 4. Ruby on Rails, http://www.rubyonrails.com/ 5. Model-Viewer-Controller, http://en.wikipedia.or_/wiki/MVC Design Pattern 6. Mongrel, http://mon_el.rubyforge.org/ 7. Apache Best Practice Deployment, Charles Brian Quinn, http://mongrel.rubyforge.org/docs/apache.html 8. About Debian, http://www.debian.org/intro/about 9. Version Control with Subversion, Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, http://svnbook.red-bean.com/ni ghtly/en/svn-book.html#svn.basic 10. Introduction to OMG's Unified Modeling Language, http://www.omg.org/gettingstarted/what is uml.htm# 12DiagramTypes 11. DBDesigner 4 Features, http://www.fabforce.net/dbdesigner4/features.php 12. RDoc Documentation from Ruby Source Files, http://rdoc.sourceforge.net/ 13. RailRoad Ruby on Rails diagrams generator, http://railroad.mbyforge.org/ 14. Riding Rails on Windows!, http://www.projectrideme.com/ "Lessons Learned from Deploying an Analytical Task Management Database."

Mr. Daniel A. O'Neil NASA Mr. Joshua Arceneaux Booz Allen and Hamilton

Presentation Abstract

Large space exploration development programs involve geographically distributed teams conducting a wide variety of studies to mitigate risks and eliminate "To Be Determined" (TBD) from requirements. A web-accessible database to manage the task plans saves time and effort because everyone can contribute information about data products, analysis expertise, reviews, and task descriptions. Developing and deploying such a database involves integration of requirements from multiple offices at different layers of the organization, design of a schema and user interface that accommodates those requirements, and applying web-technologies. This presentation explains lessons learned from deploying a web-accessible task management database. Lessons Learned from Deploying an Analytical Task Management Database

A Presentation to the 58 th International Astronautical Congress

Mr. Daniel A. O'Neil NASA Mr. Joshua Arceneaux Booz Allen and Hamilton

September 26 th, 2007 Overview of the Constellation Analysis Integration Tool (CAIT) Database Objectives - Report the status of studies sponsored by NASA's Exploration Systems Mission Directorate (ESMD) via a password protected web-accessible database. - Integrate Design and Analysis Cycles (DAC) conducted by projects sponsored by the Constellation program. - Generate schedules from the data and relationships defined by the contents of the database. Elements of a Task Description Sheet (TDS) Functional Requirements Introduction • Description, Title, Points of Contact

Timeline Current Status, Projected Completion Rl_eqate_Priority. Planning Links to mtemefit_'fsystem and mission) External Risks (potential problems and Items impact) Publish Analysis Models (analytical tools used) Execution Issues (current problems) Review Boards • Resources (analysts, tacilities, etc.) Monitor Issue Analysis Data Ifi_uts Process Resolution Outputs Board Deliverables Database Supporting Design Reference Missions Informati Methodologies Mission Phases on Purpose System Elements Overview of a T==sk Management Database Supported Process

• Analysts • Sys. Engineers I ,_10 • Designers Team(s) Create t • Specialists Produce Data _-- i Presentatio n i

• Trade Study Managers • Line Managers Review & Approve ° Project Managers Comment & Concur

N(

• Working Groups • Review Boards CommentReview & t2 6

_r 8 Search _ " Existing Tasks t Workflow 1 5 Record Approval 1 Database & Update Status i Functions _w_2_ [ ...... Manager _ Capture L 9 , r Comments --_ InputFoq"" 4_ E-Mail l kinks to I Store Update t Status & _ Save 1 I | N°tifier i Version Archive l Development Philosophy and Process

Agile Software Development Manifesto

Individuals and interactions over processes and tools documentation

Rapid Prototyping

• Discussed requirements with "voice of the customer" and stake-holder representatives • Quickly developed and demonstrated code via the Web and teleconferences • Iterated the design of the graphical user interface and database reports based on comments • Created "As-Is" and "Go-To" screen shots as designs to implement later requirements il

I -Analyze' |lCreateEntity_ Relationship _-_IPl_ Devel°p _ "_ Dem°nstrate U "1 cCOmmuenitsommntyReceive Kequ!remems! l, Diagram .

Manage LI Develop Function I .I Configuration & Regression _ Deploy Software =-_.., _'==_*_ ...... Development Tools

• Notepad ++ 4.1.1 code editor • Ruby on Rails language and development framework _._& "_;" i_"==*=_.._, '...... i ...... _'7 ; _..... i'...... ,' ...... • MySQL 5 for the database • Debian 4 for the operating system • Apache' 2 for the web server • Railroad 0.4 to generate Entity Relationship (ER) Diagrams

• Graphviz 2.1.2 to generate a ./ / / printable image of the ER diagram _ I'_,1

Railroad and Graphviz were used to generate an Entity Relationship Application Architecture

• The NASA Data Center (NDC) hosts an IBM Z Series Mainframe computer • Two virtual computers within the --1 mainframe serve as a test environment and a production environment / Current operating system is Debian 4.0 J I Planned migration to Suse Linux so we I IBM V al r I can access external data storage. • MySQL 5 is the open source database • Ruby on Rails is a free computing language and library for developing web applications • Mongrel provides the capability to serve dynamically generated web pages. • Apache' is the open source web-server that manages the application web site. • The Constellation Analysis Integration Tool (CAIT) application is the Ruby-on- Rails, Javascript, and HyperText Markup Language (HTML) code. Screenshot of TDS Status Page

Design Features

_= _:_TDS_A'rA_o0_O0! > Edit • Navigation bar with high- Main Summary for: ATA-OO-OO1

lighted text to indicate Constellation Mission _lodel

the current menu. Introduction • A menu on the left side Reference • A "bread-crumb" trail to

indicate the path to this Timeline screen

• A heading that identifies Links the type of information and the record number • Links to "drill-down" to lower levels of detail Oata • Descriptions of attributes identified on the page. • Status column with numerical metrics Supporting Information that indicate the completeness of the record

I Svsten" Elements, I Form System Elements Selections l invalid I Lessons Learned

A summary of the lessons learned from deploying a web-based task management system include Define use cases and illustrate requirements with structural, behavior, and interaction diagrams Apply open source systems such as Debian, Ruby on Rails, MySQL, Mongrel and Apache' Ask for help from the open source community if problems arise in the solution stack Assign roles and responsibilities for development, release management, and deployment Document procedures for comments, migrations, testing, and configuration management Write with an Integrated Development Environment and build a library of reusable code Evolve the system design through rapid prototyping on a development server Engage customers in the system design by asking for screen layouts and prototype critiques Capture the system design with automated document and diagram generators Develop functional tests along with the code and integration tests based on the use-cases