Wednesday, March 20, 2013
A Unified Software Development Lifecycle
Recently, in response to an audit, I was asked to document our Software Development Lifecycle across all our platforms - clinical, financial, and web. Here's what I wrote. I hope you find it useful.
1. Project Definition
Multi-stakeholder governance bodies of business owners and IS professionals meet on a regular basis to define the scope and requirements of new projects. The priorities of these new projects are based on business owner strategic alignment, regulatory/compliance requirements, quality/safety imperative, impact factor (employees, clinicians, patients), and return on investment. Governance Committees with oversight over the software development life cycle include:
Clinical - webOMR User's group sets ambulatory development priorities. Inpatient Clinical Applications Steering Committee sets inpatient development priorities.
Financial/Billing - IS project manager and IS fiscal manager work with Patient Financial Services stakeholders to mutually agree on the work tasks of all programmers.
Financial/Supply Chain Manaagement/Research/ERP - Human Resources/Payroll, General Accounting, Research Finance and Supply Chain Management Steering Committees set Peoplesoft and related application priorities
Web Applications - the Portal steering committee sets web development priorities
Once a project is approved by a governance committee, it is assigned a tracking number and assigned to programmer
In addition to project definition, these committees also oversee the portfolio of work their specific domain. This includes monitoring progress and identifying/eliminating barriers to success.
2. User Requirements Definition, Analysis and Design
The development process for approved projects begins with user requirements definition. This is a collaborative effort involving developers, analysts and business owners. It is an iterative process in which a prototype is developed based on an initial set of user requirements and then modified in response to user feedback. Multiple cycles of revising requirements and prototypes typically occur. We employ an agile development methodology with source code control systems/versioning for every development platform.
3. System requirements definition
Application projects may have infrastructure implications. An infrastructure project manager is engaged if additional server capacity, novel desktop configuration, or new client hardware (mobile, specialized printers, bar code scanners) is required as part of the application
4. Testing
BIDMC maintains dedicated development and testing environments that are separate from live/production. Developers first unit test their changes. Application analysts independently test changes. End users perform acceptance testing.
Test scripts are used to perform integrated testing before go live.
No code is moved into production before end user signoff approval.
5. Go live and continuous improvement
Go live is planned in collaboration with business owners which includes communication and post go live support planning. Changes to infrastructure and communication plans for major go lives are presented to the IS Change Control Board to ensure awareness and coordinate timelines among all IS projects.
The push of code from a testing environment to a production environment is done via a source control system, is logged for auditing purposes, and may be rolled back quickly. For clinical applications, this push is done by the most experienced developer, as experience has shown that this person is most able to ensure a successful deployment and rapidly identify any defects, minimizing risk. For financial/billing applications, this push is done by the non-IS Production Control group, since mainframe workflows are more batch oriented and more amenable to segregation of duties in go live processes. The organization accepts this difference between the clinical and financial/billing go live process as necessary to reduce overall risk.
Once the go live push is completed, success of the process is validated by the most experienced developer, the analysts, and/or the business owner as is appropriate for the application.
Based on feedback during the go live validation process, a rollback may be done if there are unexpected consequences. This is a very rare event, but it supported by the source code control systems which drive the go live process.
Once application changes are live, user feedback is provided at the governance committee level and products are continuously improved to meet users needs, always following the above Software Development Lifecycle.
Subscribe to:
Post Comments (Atom)
2 comments:
Nice overview Dr. Halamka.
#3 is interesting to me. Being in an infrastructure team, I see System Requirements Definition often overlooked or put off until just before project go-live and testing. This can be dangerous as long lead times can occur with purchases and configuration of infrastructure products required to make the project "go." Infrastructure, like business owners, developers and analysts, are really stakeholders as well and, in my opinion, should be involved as such ... earlier in the project. While I know it's pretty difficult to understand what your infrastructure requirements are before design decisions have been made, I think the two decisions should go hand-in-hand, thus reducing the risk that the infrastructure can't handle the new system and long, expensive, unplanned-for upgrades have to be made. My two cents as an infrastructure employee.
I am impressed by this process. The large public HIT company I work for who shall not be named would do well to follow such a process. Often it feels to me as though are developers are way out of touch with the needs of our clients.
Post a Comment