Application Development and Support Standard

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.

Thanks for the input Gabe.  Responses below:

“The term Application needs to be defined.  What is the difference between a complex script or database package and an application? At what point does a body of code become an application?”

The script or database package would either be a standalone application or part of an application, depending on function.  Even in those instances, documentation, versioning and the various steps of SDLC should be considered to ensure support, stability and maintenance. 

“I am worried that the Scope of the Application Development and Support Standard inclusions and exclusions are going to be difficult to delineate.  The following have a high chance of overlapping:
Inclusion: ‘All architectural/supporting technologies (such as coding languages, database management systems, operating systems, frameworks, mark-up languages….) that scaffold the development environment. This includes the technical architecture or infrastructure, used to support the development and delivery of applications to end-users.’

Exclusion: ‘Specific technologies used to in any aspect of application development, such as servers, operating systems, compilers, backups, or network distribution software (iOS or Android, Java, Linux, Apache, Oracle, html, MySQL, php, for example).’

For example Linux, Apache, MySQL, and PHP would be a typical development environment for a web application. This typical environment includes one operating system, and one database management system which are listed in the supported technologies.  So overall, the scope here needs to be clarified with clear points of dileneation.”

Great point that it seems confusing and we will alter the verbiage to clarify.  What we are saying is this standard is not mandating a type of technology, operating system or technology to be used, but all the components of the environment from OS to the coding language should be considered as you architect, develop, document, support and backup.

“General  Guidelines
I do not recommend putting Guidelines in an SLA.  These should be a separate document since they are not actual requirements or be requirements.  All of these items are good things but it gives the impression that they are not mandatory or required or worse that they can be intentionally disregarded.”

Thanks, Gabe.  The potential for confusion is noted and we are working to ensure that requirements versus recommendations are clearly differentiated.

“SDLC 
Is this a requirement?  What if SDLC doesn’t make sense for the specific project?  This seems to be in conflict with these scope exclusions:
‘Specific development frameworks, software or team management approaches, such as Scrum or Team
Management Software.’ and
‘Specific approaches or industry standards used to ensure quality or process improvement, such as ISO
9000, Capability Maturity Model Integration or bodies of knowledge for software engineering or project
management.’”

SDLC is a requirement, but the chosen approach to SDLC is not prescriptive.

“Infrastructure, Equipment and Upgrades
Should this be a separate SLA? It is far from the Application Development in my opinion.  It is hard to tell if some of the items in this section are just definitions or requirements.”

These are included because they are critical decisions relative to application management and support.  

“Infrastructure includes a development instance and an operational instance or environment used for development/testing and production processing. This includes but is not limited to operating systems, security patches, compilers, firewalls, databases, test and production data management, among others.
Does the above mean all applications must have a development instance?  What about a local development environment, is that sufficient?  What are the requirements for a development instance? “

Yes, and a local development instance would generally be fine.  We will update the language.  Requirements are pretty basic – a place to develop and test before promoting and impacting production, with consideration to the backup and version control of the code within the development instance.

This is correct.