Elisha,
Thanks for your thoughtful review. Here are responses to your questions:
“How does this standard relate to the Virtual Classroom standard or any other Standards and SLAs that will involve application administration, acquisition, and/or development?”
To the extent that application management is involved, the Application Development and Support Standard would apply. We will work hard internally to ensure that avoidable inconsistencies are eliminated and instead cross-reference standards appropriately. We would appreciate your help in identifying these. If there is an area that is more rigid in another standard, it is appropriate to follow the more rigid requirement.
“Is there a size of application and/or level of application exposure that triggers formal adherence to a Development Life Cycle? Are there specific templates or forms required?”
In general, the development life cycle will benefit any development effort and should be observed; however, it is appropriate to exercise judgement on the effort expended to meet the minimums relative to the size and impact of the application. We will include this language in a revision.
“I know the standard says that development philosophies are excluded from the scope, but the outlined process indicates a level of linear formality commonly associated with waterfall development rather than agile approaches. that’s not to say that agile methods should not follow the same life cycle, it’s more a question of what level of formality is expected.”
The diagram appears linear because it is showing the various phases and we thought it easiest to explain this linearly, but the standard is not prescriptive on the approach taken.
“Under Operation and Maintenance, I agree that at least two-weeks’ notice is preferable when outages are involved. However, there should also be a process for handling an Emergency Request for Change. Perhaps Change Management should be referenced.”
Good point. We have internal processes for change management and will look at whether this could be an institutional standard in the future.
“Disposition or disposal: end user input is always good. How does this provision apply in the case of product end of life or end of support?”
I agree that these situations should still allow for end user input with the appropriate understanding of constraints. We will adjust the language.
“Is there a central repository for the minimum artifacts related to the Application Development Lifecycle? Is there an audit process? How will departments be able to proactively tell if their artifacts are meeting the standard?”
There is not currently. The SLA could follow the format we are using here for SLAs on the Discuss.UNM site, there are templates available for project management artifacts, etc. These templates are guides but are not a required format for others to use. We will look to ensure we have links to templates where available.
“Under upgrades, large systems are used continuously, which makes this provision unattainable: ‘Upgrade or refresh hardware and software during breaks in the semester or business cycle, or when an Application is offline so end-users are not negatively impacted.’ Change management processes and minimal disruption principles are encouraged in those instances.”
We will note this as you indicate. Great catch!
“An emergency request for change process should apply here, too.”
We will note this as well.