r can be more valuable in instances of GUI driven calculations. Test cases make assumptions about the end users’ actions which works well for command-line style processes, but is limited for event-driven applications or rich web applications requiring real-time interaction.

3.4.3.3. Production

Once the software and experimental results agree or the software is useful for laboratory consumption, the software is moved into production. In an adaptive environment, it is easier to use web-based applications or services for the production environment. Any updates to the software are made in a single server location and users would not have to reinstall or possibly fall behind the current software version, patches, fixes, or updates as commonly seen in desktop installations.

4. Model Assessment

The L2APP model is an agile software development model focused on providing quality software quickly by working in parallel with a laboratory or research group. Working in parallel can lead to knowledge transfer based solely on proximity that reinforces the project goal and helps both groups understand the context of their work [10]. This parallelism promotes one of the core phases of adaptive software development: learning.

4.1. Focus on Results, Not Plans

A solid software plan in a classic SDLC can solidify a project and provide all involved a shared vision for the project. Unfortunately, changes to the plan can have disastrous effects on the project as a whole. In our experience using this model, experimental results continually change or update software requirements. In a research environment, software development must be driven by the end result and not by overly embellished planning. With each iteration, the collaborative nature of the software development cycle and the learning focus of the reviews put forth a model that promotes improvement of the results through iteration rather than a heavier initial planning phase. Focusing on the result, rather than planning the path to acquire the result, saves time and effort.

4.2. Time to Production

Using this model, time to production for software ultimately depends on quality experimental and software practices working in parallel. By working in parallel, setbacks in the laboratory can also setback software development. However, being an agile software methodology, those setbacks, changes, failures have a small impact on the overall time to completion for a software project. An error made in the laboratory is communicated and known to the software team and the software can re-enter another iteration of development, thus protecting the overall project timeline. Using other methods of software engineering, the software team would wait until the experimental results were gathered, analyzed and validated before even planning a software product. The L2APP model rewards the quality development of experiments and software in parallel by reducing the time to production. When the experimental data is gathered and validated, the software should be ready to move into production.

4.3. Value during Development

Since a project cannot enter the adaptive development life cycle until it has value to the laboratory or research group, the software can be used immediately upon commitment. Constant use of the software, in any form, is valuable to both the researchers and the software team. The researcher or laboratory staff member can continuall validate the software with each iteration and the software team receives valuable feedback. The L2APP model is a real-time trade off of value: the software team provides tools to aid the researcher and the researcher provides feedback/validation.

4.4. Projects and Portfolio Have Value

Any project in this model begins as a lean prototype and is immediately discarded if it lacks or loses value. By using a conditional lean prototyping phase, the model introduces its own project portfolio quality control. Software teams rarely work on a single project at a time and often have a portfolio of current projects. It is important to only add projects that add value to the portfolio just as it is important to add only features to software that have value. The conditional lean prototyping phase allows the software and research groups to protect the project portfolio from losing value and wasting resources on software that has little value. Using this model, the software team’s project portfolio is protected from poor project selection.

4.5. Lean Prototypes Are Often Enough

An interesting outcome of this model in some instances is the acceptance of the lean prototype as a production worthy application. End users have a difficult time realizing and identifying their needs, thus the choice of agile methods of software development. With each iteration, the end user and software team work together to better define the needs and eventually build a solid software product. However, we’ve seen cases where end users find enough value in the prototype and its placed into production for use. At first the end user may have had grandiose requirements, but quickly realized a prototype containing partial requirements was all that was truly needed.

4.6. Lean Methods Continue Throughout

A side effect of the initial lean prototyping phase that we’ve experienced is continuation of lean ideas and goals throughout the adaptive development as well. Though there is a clear distinction made between the lean prototyping phase and the adaptive development phase, we’ve seen smooth transition between the two, as the lean methodology fits well with the adaptive methodology. Software teams often have difficulty switching between software development methods such as SCRUM, classic SDLC, and XP because the relationships of stakeholders, coding standards, and development organization are quite diverse [11]. The L2APP model promotes a transition between a very lean prototype and what could be considered a less lean (adaptive) prototype.

4.7. People

The individuals involved are very important to the success of a project and application of a software methodology [2,10]. Some individuals do not conform well to an agile software environment and any methodology used would have to be adjusted to accommodate. It is possible to educate individuals on the best practices of agile development [12] but education and the willingness to adopt do not go hand-in-hand. Adoption of an agile method is easiest for those who are lean by nature and difficult for those who thrive on planning, meetings, and paperwork. This is also true for the method presented in this publication.

4.8. Speed vs Results

Experimental results are often slow to acquire, organize, and analyze in hopes of ensuring the upmost quality and reproduciability. Web development however has been seen to focus merely on speed [9]. In our experience using an agile method for web software in a research environment, timing can be an issue as quality is non-negotiable in experimental design but seen as negotiable in prototyping.

5. Discussion

Previous research consolidated the characteristics of agile software projects as incremental, cooperative, straightforward, and adaptive [1]. The L2APP model shares these characteristics with other agile methodologies by promoting cyclical development, collaboration between research and software during development, being easy to understand and modify, and flexible to changing requirements without disastrous effects to the project or timeline. It is not recommended however that our interpretation of an agile methodology is better than those with less or more definition, but rather an interpretation that we find useful in our research environment.

Our model modifies the adaptive development software model by introducing parallelism, lean principles and a conditional lean prototyping step. Parallelism can reduce resource slack, improve collaboration, increase stakeholder understanding of project context, and constantly align the timelines of the experimental and software groups. Parallelism is however dependent upon quality in this model. Quality experimental results can define requirements for software development or be used to assess the software product. Quality software can be used to aid in experimental design, prediction and visualization. In either case, a lack of quality could continually return the software project to the development cycle.

Lean principles are introduced to reduce time to production. By not providing documentation, mockups, or object models during development, the software team can focus on the result and research requirements. In health science research, assays are only as good as their outcome and the same is true for software projects. In contrast, some very important details are left out of the development cycle including quality objectives, risk management, and detailed specifications of software [9].

A concern for many bioinformatics teams is the ability to manage and funnel projects into the development environment. Academia promotes collaboration and this is also true in decision-making. As more groups, researchers, and staff become involved in a project, the ability to manage the portfolio of projects is crucial in prioritizing resources. The initial lean prototype condition introduced in this model helps preserve the project portfolio’s value. Most projects received by our team have value in their intent, yet a small percentage quickly lose value due to changing requirements, limitations of technology, and the discovery of external software. The lean prototype provides validation of the proposed software project by 1) ensuring technological feasibility and 2) asserting project value.

Bioinformatics groups and research laboratories have a large reference set in which to learn software methods that best fit their expertise, talent, motivation, and managment style. Unfortunately, very few of the references are creble, rigorous or detailed enough for academic acceptance [11,13-15] or adoption and only recently has software development been a focus for bioinformatics environments [3].

Interesting future work would include a survey of not only agile software practices in bioinformatics, but adoption success, project management techniques [16], and organizational optimization for successful research driven software projects. In this publication, we’ve described an agile method of software development that fits well with smaller, research driven environments lacking in dedicated project management resources in hopes of spurring research into the best practices of bioinformatics, health sciences, and laboratory driven software projects.

6. Conclusion

The lean-to-adaptive prototyping in parallel method is a useful agile software methodology that can be used by teams in research environments to build quality software quickly and manage the value of the projects committed to.

7. Acknowledgements

We would like to thank the Wittwer DNA Lab at the University of Utah, Canon US Life Sciences Inc., and Idaho Technology Inc. for their consistent feedback in the development of internal and public software, which led to the creation of the L2APP model.

REFERENCES

  1. J. Highsmith, A. Cockburn and B. Boehm, “Agile Software Development: The Business of Innovation,” Computer, Vol. 34, No. 9, 2001, p. 3. doi:10.1109/2.947100
  2. D. W. Kane, M. M. Hohman, E. G. Cerami, et al., “Agile Methods in Biomedical Software Development: A MultiSite Experience Report,” BMC Bioinformatics, Vol. 7, 2006, p. 273. doi:10.1186/1471-2105-7-273
  3. K. Rother, W. Potrzebowski, T. Puton, et al., “A Toolbox for Developing Bioinformatics Software,” Brief Bioinform, 29 July 2011.
  4. J. Pitt-Francis, M. O. Bernabeu, J. Cooper, et al., “Chaste: Using Agile Programming Techniques to Develop Computational Biology Software,” Philosophical Transactions of the Royal Society A, Vol. 366, No. 1878, 2008, pp. 3111-3136.
  5. R. S. Sadasivam, K. Delaughter, K. Crenshaw, et al., “Development of an Interactive, Web-Delivered System to Increase Provider-Patient Engagement in Smoking Cessation,” Journal of Medical Internet Research, Vol. 13, No. 4, 2011, p. e87. doi:10.2196/jmir.1721
  6. K. Gary, A. Enquobahrie, L. Ibanez, et al., “Agile Methods for Open Source Safety-Critical Software,” Software: Practice and Experience, Vol. 41, No. 9, 2011 pp. 945- 962. doi:10.1002/spe.1075
  7. Z. Dwight, R. Palais and C. T. Wittwer, “uMELT: Prediction of High-Resolution Melting Curves and Dynamic Melting Profiles of PCR Products in a Rich Web Application,” Bioinformatics, Vol. 27, No. 7, 2011, pp. 1019- 1020. doi:10.1093/bioinformatics/btr065
  8. S. Raman, “Lean Software Development: Is It Feasible?” Proceedings of the 17th Digital Avionics Systems Conference, Vol. 1, 1998, pp. C13/1-C13/8.
  9. R. Baskerville, B. Ramesh, L. Levina, et al., “Is Internet-Speed Software Development Different?” IEEE Software, Vol. 20, No. 6, 2003, pp. 70-77. doi:10.1109/MS.2003.1241369
  10. A. Cockburn, J. Highsmith and B. Boehm, “Agile Software Development: The People Factor,” Computer, Vol. 34, No. 11, 2001, pp. 131-133. doi:10.1109/2.963450
  11. J. Erickson, K. Lyytinen and K. Siau, “Agile Modeling, Agile Software Development, and Extreme Programming: The State of Research,” Journal of Database Management, Vol. 16, No. 4, 2005, pp. 88-100. doi:10.4018/jdm.2005100105
  12. V. Devedzic, S. Milenkovic, et al., “Teaching Agile Software Development: A Case Study,” IEEE Transactions on Education, Vol. 54, No. 2, 2011, pp. 273-278. doi:10.1109/TE.2010.2052104
  13. T. Dyba and T. Dingsøyr, “Empirical Studies of Agile Software Development: A Systematic Review,” Information and Software Technology, Vol. 50, No. 9-10, 2008, pp. 833-859. doi:10.1016/j.infsof.2008.01.006
  14. T. Dyba and T. Dingsoyr, “What Do We Know about Agile Software Development?” IEEE Software, Vol. 26, No. 5, 2009, pp. 6-9. doi:10.1109/MS.2009.145
  15. M. Aoyama, “Web-Based Agile Software Development,” IEEE Software, Vol. 15, No. 6, 1998, pp. 56-65. doi:10.1109/52.730844
  16. D. Karlstrom and P. Runeson, “Combining Agile Methods with Stage-Gate Project Management,” IEEE Software, Vol. 22, No. 3, 2005, pp. 43-49. doi:10.1109/MS.2005.59

Journal Menu >>