How to improve your IT. Part 11 – Applications Development

A series of posts on how to improve the performance of your IT

The Best practice IT Standard is comprised of:

A thoroughly documented and tailored where appropriate, development lifecycle methodology. (Systems Development Lifecycles-SDLC) with associated how-to guidelines and procedures.
A vendor supported, integrated applications development toolset.
Development and test databases refreshed daily.
As the applications portfolio is usually a mix of packaged solutions and in-house developments, both require thorough documentation, especially legacy applications.
Development work like enhancements requires rigorous functional gap analysis and review of business processes before work is undertaken.
The use of scripts is minimised as they tend to organically grow which makes them problematic and requiring manual intervention to run.

What is the approach to testing?
Does the testing approach cover people (numbers and skills), capacity, software and tools, overall technical environment, processes (e.g., function test, performance and load test, problem reporting, management and fixing), and the user functions?
Does testing cover off usability, reliability, functionality, and performance versus the documented requirements.
How is testing planned and documented?
How are test statements planned and documented?
Do test plans include component tests, integration test, regression tests, system test and acceptance test.
How are acceptance criteria for the system deliverables defined?

What format do the conversion strategies take?
Are conversion rules, programs and final data file definitions defined?
How is the original environment described?
What if any conversion tools are in use?
Are conversion and integrated acceptance test plans defined?
How is the clean-up of converted data defined?
How is a newly converted system compared with the original to assess identical results?
What data integrity issues exist?

Create an end-to-end testing process including the use of test harnesses, scripts and conditions.
Review the use of and management of development and testing environments.
Review recent application failures (unusable to users), assess cause and ensure mitigations been put in place.
Introduce a Rule of ‘fix a problem once’.
Split DBAs into Systems and Applications.
Locate application DBAs with developers.
Create any necessary umbrella processes that involve inter-team workflows including hand-off points and deliverables.
Pending how often conversions are undertaken, consider creating a conversions process that includes sub-contractors.
Determine extent of data integrity issues and how to resolve.
Define and agree a test environment.
investigate QA toolsets.
Determine further works required and scope out.
Breakdown the scope of works to task level, ready for loading into the change management project schedule.

Is that applications development methodologies are guiding all development activities, there are five primary types:

The waterfall model: - this is the classic SDLC model, with a sequential process that has goals for each applications development phase. The waterfall model simplifies task scheduling, because it is linear with no iterative or overlapping tasks.
Rapid application development (RAD): - based on the approach that solutions can be developed more quickly using development workshops to collect system requirements. Makes use of prototyping and reiterative design testing.
Joint application development (JAD): - this model involves the client or end-user in the design and construction of an application through a series of collaborative workshops.
Prototyping: - in this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.
Synchronize-and-stabilize: - this approach calls for different development teams working in parallel on different parts of an application. Requires regular synchronization of code.

How often are development databases refreshed from production databases?
Are the methodologies in use tailored?
What methodology how-to guidelines exists?
Are there matching Work Breakdown Schedule templates in use?
What is project delivery performance like (timely delivery of all software developed by (and subcontractors) to defined acceptance criteria (i.e. on schedule, within budget, with required function, with required performance and to the specified quality)?
Is there an agreed and documented procedure for interfacing with subcontractors?
How are subcontractors advised of in-house development standards?
Are regular performance reviews of progress including monitoring actual versus plan on a task and effort basis conducted with sub-contractors?
Is Quality Assurance involved in code inspections?
Is there a clear and unambiguous view of the overall application architecture and, is this conveyed to subcontractors?
Is a close and continual liaison with the technical architect maintained to ensure that all matters potentially affecting system capacity and performance are communicated and understood?
How are applications security requirements managed?

Review software licenses.
Risk analysis of in-use methodologies.
Assess methodologies fit for purpose.
Document in-house methodologies and customisations to packaged methodologies.
Determine further works required and scope out.
Breakdown the scope of works to task level, ready for loading into the change management project schedule.