• Like
Slide 1
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.



Published in Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Test levels Unit testing tests the minimal software component and sub-component or modules by the programmers. Integration testing exposes defects in the interfaces and interaction between integrated components(modules). Functional testing tests the product according to programmable work. System testing tests an integrated system to verify/validate that it meets its requirements. Acceptance testing testing can be conducted by the client. It allows the end-user or customer or client to decide whether or not to accept the product. Acceptance testing may be performed after the testing and before the implementation phase. See also Development stage Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users. It should be noted that although both Alpha and Beta are referred to as testing it is in fact use emersion. The rigors that are applied are often unsystematic and many of the basic tenets of testing process are not used. The Alpha and Beta period provides insight into environmental and utilization conditions that can impact the software. After modifying software, either for a change in functionality or to fix defects, a regression test re-runs previously passing tests on the modified software to ensure that the modifications haven't unintentionally caused a regression of previous functionality. Regression testing can be performed at any or all of the above test levels. These regression tests are often automated.


  • 1. Can Agility Work With a Waterfall Project Management Process in a Research Administration Setting? Romerl Elizes, DPS, MBA May 8, 2009
  • 2. Agenda
    • Introduction
    • Limitations
    • Background
    • Problems
    • Framework
    • Literature Review
    • Relevance
    • Current Work
    • Future Work
    • References
    • Questions and Answers
  • 3. Introduction
    • Presentation goals:
      • introduce the concept of an Agile-based Waterfall Project Management Framework
      • will explore its applicability in a limited staff engagement within a research administration setting at a major medical university
  • 4. Limitations
    • The proposed framework is a work in progress
      • The framework will change
      • The framework was completed successfully using one major project only – the rest of the projects will be completed within the year
      • The framework is focused only on research administration only
  • 5. Background
    • Research Administration Systems (RAS) – conduit between Research and Information Technology departments of the University of Medicine and Dentistry of New Jersey (UMDNJ)
    • RAS has used agile methodologies to complete projects successfully:
      • Feature-driven development
      • Frequent delivery
      • Test-driven development
      • Self-organization
  • 6. Background
    • UMDNJ IT created a Project Management Office (PMO)
      • Oversee proper planning and execution of IT projects
      • Concern over projects that are subject to regulatory auditing by federal and state agencies
      • Create a unified Project Management Methodology (PMM) - Waterfall in nature!!!
  • 7. Project Management Methodology (PMM)
    • Project Initiation
      • Stakeholders develop request
      • Project Sponsor obtained
      • Creation of High Level Achievements (HLA)
      • Kickoff Meeting expedited
      • Assessment of Risks
      • Development of Requirements
    • Project Planning
      • Develop project plan
      • Creation of Implementation Team
      • Assignment of Roles
      • Initiate mandatory team meetings
      • Document all processes
      • Development of Test Plan
    • Project Execution
      • Complete project items leading up to completion of HLAs
      • Conduct mandatory team meetings
      • Document processes
      • Test completed items according to developed Test Plan
    • Project Resolution
      • Mandatory meeting to determine project completeness
      • Creation of Lessons Learned documentation
      • Project completion signoffs
  • 8. Problems
    • Fractured relationship between Research and IT
    • RAS staff limitation
    • Budget limitations
    • Research resistance to outside control
    • Regulatory auditing
  • 9. Agile-based Waterfall Project Management Framework
    • Agile Way
    • A1. Constant Engagement with Stakeholder
    • A2. Going the Extra Mile
    • A3. Periodic Changing of Top 10 Stories
    • A4. Shorter Iterations
    • A5. Engaging Stakeholder in Testing Process
    • A6. Keeping the Stakeholder in the Straight Path
    • Waterfall Way
    • W1. Constant Engagement with PMO
    • W2. Make PMM less Waterfall
    • W3. Documenting Agile Practices
    • W4. Strategic Division of Projects
  • 10. Literature Review
    • Academic literature reveals comparisons between agile practices and waterfall project management methodologies:
      • Molokken-Ostvold showed that projects following flexible methodologies had less overruns than projects following traditional project management methodologies [MOL].
      • Maurer showed how agile methods promoting individuals and interactions have been successful over processes and tools of waterfall development [MAU].
      • Indiana University demonstrated how it converted from an older online learning application to a newer one for enterprise-wide use using rapid prototyping and agile approaches over waterfall development [PAV].
  • 11. Literature Review
    • Findings:
    • No literature showed that Waterfall methodologies are better than Agile.
    • No literature showed how Agile practices can be inserted into current Waterfall methodologies.
    • No literature showed how Agile practices can be utilized in auditable environments.
  • 12. Relevance
    • The work involves a large medical institution with diverse stakeholders that stand to benefit from this framework.
    • The work proposes a solution based on a limited funding model that is common in other educational institutions.
    • The work proposes how a traditional Waterfall project management model can benefit with some agile practices while adhering to regulatory requirements.
    • The work furthers the field of research administration informatics.
  • 13. Current Work
    • Success with Coeus implementation - proposal development, proposal submissions to grants.gov, and reports development.
      • Driven entirely by project champion (me).
      • Divided project into smaller autonomous projects (W4).
      • Used iterative development on an almost daily basis (A1).
      • Encouraged the stakeholders to test the reports for viability ( A5 ).
      • Some of the stakeholders requested for additional functionality and the author negotiated with the stakeholders on a constant basis to determine which features could be delayed ( A3 ) for a future release.
      • Make the Waterfall process transparent to the stakeholders ( W2 ) by establishing and resolving tactical meetings on an as needed basis during project bottlenecks.
      • Required stakeholders to document their changes via a shared project group email so that other stakeholders were aware of the potential impact of project changes ( W2 ).
  • 14. Future Work
    • Current/Future Research Administration projects which will include this framework:
      • Implementation of ClickCommerce enterprise-wide application for the Internal Review Board (IRB) stakeholders.
      • Implementation of Rutgers enterprise-wide application for the Institutional Animal Care and Use Committee (IACUC) stakeholders.
      • Data integration project between Coeus and Sungard Banner applications for the Finance Department.
      • Clinical Trials website/database upgrade project that includes data integration between Coeus and IRB applications for the Office of Research.
      • Implementation Negotiations module in Coeus application to support Legal and Regulatory documents for the Legal Department.
  • 15. Future Work
    • Conference/Academic literature possibilities:
      • Submitted a presentation to NJEDGE.Net Conference 2009 under the topic: “Technology Management”
      • Preparing a paper for submission to Society of Research Administrative Professionals or National Council of University Research Administrators on “Data Integration of Divergent Research Applications”
  • 16. References
    • L. Anderson, G. Alleman, K. Beck, J. Blotner, W. Cunningham, M. Poppendieck, R. Wirfs-Brock. “Agile management – an oxymoron?: who needs managers anyway?” In Proceedings of the Eighteenth Annual ACM SIGPLAN Conference on Object-Oriented Programming. pp. 275-277. Anahiem, CA. 2004
    • B. Boehm, R. Turner. “Balancing Agility and Discipline: A Guide for the Perplexed.” Addison-Wesley, Pearson Education Publishing. Boston, MA. 2005.
    • “ Coeus Consortium.” Web site. Massachusetts Institute of Technology. 2007. Link: http:// www.coeus.org/coeus -cons/
    • F. Keenan, S. Powell, G. Coleman, K. McDaid. “Learning project planning the agile way.” In Proceedings of the Eleventh Annual SIGCSE Conference on Innovation and Technology in Computer Science Education. pp. 324-324. Bologna, Italy, 2006.
    • Luqi , Lin Zhang, Valdis Berzins, Ying Qiao, "Documentation Driven Development for Complex Real-Time Systems," In IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 936-952 . Dec. 2004.
    • F. Maurer, G. Melnick. “Agile methods: moving towards the mainstream of the software industry.” In Proceedings of the Twenty-Eighth International Conference on Software Engineering (2006), pp. 1057-1058. Shanghai, China, 2006.
    • K. Molokken-Ostvold, M. Jorgensen. “A Comparison of Software Overruns – Flexible versus Sequential Development Models.” In IEEE Transactions on Software Engineering, Vol. 31, No. 9, pp. 754-766, September 2005.
    • R. Pavolka, V. Mount, A. Neymeyr, C. Rhodes. “From waterfall to rapid prototyping: supporting enterprise-wide adoption of the oncourse collaboration and learning (CL) environment at Indiana University.” In Proceedings of the Thirty-third Annual SIGUCCS Conference on User Services. pp. 312-319. Monterey, CA. 2005.