Reply To: Application Development and Support Standard

#692
darruti
Participant

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.