1 / 41

NA-MIC Software Engineering

NA-MIC Software Engineering. "If you come to a fork in the road, take it.". Closed. Open. Google Hits “Open Source”: 26,900,000. NIH National Centers For Biomedical Computing. … NIH does have goals for software dissemination… …software should be freely available …

leia
Download Presentation

NA-MIC Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NA-MIC Software Engineering

  2. "If you come to a fork in the road, take it."

  3. Closed Open

  4. Google Hits “Open Source”: 26,900,000

  5. NIH National Centers For Biomedical Computing • …NIH does have goals for software dissemination… • …software should be freely available … • …permit the commercialization of enhanced or customized versions … • …include the ability of researchers outside the center and its collaborating projects to modify the source code and to share modifications …

  6. Successful Open Source Projects

  7. Visualization Toolkit - vtk Open source toolkit for scientific visualization, computer graphics, and image processing www.vtk.org

  8. Computer Vision Library - vxl • Based on Target jr and Image Understanding Environment • Numerics • Imaging • Geometry • Camera models vxl.sourceforge.net

  9. Slicer • Developed by Brigham and Womens Surgical Planning Lab • User interface plus plug-ins for applications • Segmentation • Registration • Image Guidance www.slicer.org

  10. National Library of MedicineSegmentation and Registration Toolkit $12 million over 6 years Leading edge algorithms Open Source Software www.itk.org

  11. Open Source Menu for Success • A Community with a common vision • A pool of talented and motivated developers/scientists • A mix of academic and commercial • An organized, light weight approach to software development • A leadership structure • Communication • A business model

  12. NIH National Centers For Biomedical Computing http://www.bisti.nih.gov/ncbc/

  13. In search of a new software development process

  14. Google Hits “Extreme Programming”: 904,000

  15. Extreme Programming

  16. A Light Weight Software Engineering Process • Based on the new Extreme Programming process • High intensity design, test, implement cycle • Supported with web-enabled tools • Automated testing integrated with the software development

  17. Extreme Programming Compresses the standard analyze, design, implement, test cycle into a continuous process

  18. A process supported by a suite of portable, open source tools • Apache, perl, php • Web services • cvs • Revision control • Doxygen • Automated documentation • CMake • Cross-platform program build • Dart • Continuous and distributed test reporting

  19. Extreme Programming The community owns the code Although the identity of the original author is kept, other developers are free to correct defects and enhance each other's code In the end, all of the software should appear as though one author wrote it

  20. Extreme Programming Release early, release often Although developers are tempted to keep their code under wraps until it is perfect, the process encourages them to release their code as soon as it passes some minimum tests The longer the code is visible to the community, the better integrated it will be

  21. Extreme Programming Continuous integration There is no scheduled porting to computer platforms All new software builds supported platforms every evening

  22. Extreme Programming All developers agree to keep the software defect free. Although everyone is encouraged to submit their code early, the code must compile and pass tests nightly A continuous build process sends e-mails to developers who check in code that does not compile More effectively, the community enforces the commitment though peer pressure

  23. Development Cycles • Daily – dashboard • Weekly – telephone conferences • On demand – architecture/requirements reviews • Quarterly – developer meetings • Yearly – AHM

  24. Extreme ProgrammingDaily Testing Is The Key • Testing anchors and drives the development process (Dart) • Opens up the development process to everyone • Developers monitor the testing dashboard constantly • Problems are identified and fixed immediately • Developers receive e-mail if they“Break the Build”

  25. Results posted on web(the dashboard) How DART Enables Collaboration CVS maintainssource code revisions DART compilessource code, runs tests CVS Developers check-in code Developers review results

  26. Dart Dart

  27. Multi-Platform Builds

  28. Regression Testing

  29. Continuous System Monitoring

  30. Someone broke the build!

  31. Observations: The Good • Good mix of commercial and academic • Communication is critical • The daily rhythm of Extreme Testing • The Whole >>> Sum of the parts • Process automation reduces the burden on developers • This process can be repeated

  32. Observations: The Bad • Communication • Early in the Insight project, communication was limited to the mailing list and the Quarterly meetings. Almost a year passed before we added the weekly telephone conferences. Developers felt isolated and the impersonal electronic communication methods failed to build the personal relationships required for any software development process. • Lack of Design Reviews • The lightweight process has its drawbacks. The current process emphasizes coding and testing. This process is well defined and benefits from automation. But, the design process is not well supported by the current mechanisms. • Unstable Application Programming Interfaces (API’s) • The nightly test/build was so effective in empowering programmers to make changes, that API changes occurred too frequently without the necessary buy-in from the development community. 

  33. Insight Observations: The Bad • Insufficient Automation • Automation is critical to maintain consistent style and robust software. Although the project provided many automatic techniques to catch developer errors, the project would benefit from more automation. • Complexity and Feature Creep • Like most software development projects, this software suffers from complexity and feature creep. Early designs and implementations used many features of the C++ language to an “extreme”. The team realized and began removing the complexity.

  34. Insight Observations: The Ugly • Still need a stick • Someone needs to monitor the daily process. • XP is not everyone’s cup of tea • Almost all ITK contractors bought into the process. A few tolerated it.

  35. From NA-MIC Summary Statement This Core may in fact be a textbook example of proper software engineering practices for centers for biomedical computing. The plan provides mechanisms for verifying code, version control, support for multiple platforms and operating systems, and much more. The philosophy of extreme software engineering was used and that allows all phases of software development to proceed in parallel, and this seems to be an excellent way to manage and coordinate all levels of software development in such a complex setting.

  36. Parting Thoughts (from Robert Fulghum) • Share everything • Play fair • Don’t hit people • Put things back where you found them • Clean up your own mess • Don’t take things that aren’t yours • Say you’re sorry when you hurt someone • Wash you hands before you eat and… • Flush

  37. Open Source Resources • www.opensource.org • sourceforge.net • www.itk.org • www.vtk.org • vxl.sourceforge.net • www.slicer.org

  38. "You've got to be very careful if you don't know where you're going, because you might not get there."

  39. The Old Way The NA-MIC Way

  40. NA-MIC Software Engineering

More Related