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.