How to improve your IT. Part 11 – Applications Development

IT
IT Applications Development

IT Applications Development

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

The Best practice IT Standard is comprised of:

  1. A thoroughly documented and tailored where appropriate, development lifecycle methodology. (Systems Development Lifecycles-SDLC) with associated how-to guidelines and procedures.

  2. A vendor supported, integrated applications development toolset.

  3. Development and test databases refreshed daily.

  4. As the applications portfolio is usually a mix of packaged solutions and in-house developments, both require thorough documentation, especially legacy applications.

  5. Development work like enhancements requires rigorous functional gap analysis and review of business processes before work is undertaken.

  6. The use of scripts is minimised as they tend to organically grow which makes them problematic and requiring manual intervention to run.

Performance Assessment

Testing

  1. What is the approach to testing?

  2. 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?

  3. Does testing cover off usability, reliability, functionality, and performance versus the documented requirements.

  4. How is testing planned and documented?

  5. How are test statements planned and documented?

  6. Do test plans include component tests, integration test, regression tests, system test and acceptance test.

  7. How are acceptance criteria for the system deliverables defined?

Quality Assurance

  1. What quality management tools and techniques are in use?

  2. How is quality assurance integrated with sub-contractors?

Conversion

  1. What format do the conversion strategies take?

  2. Are conversion rules, programs and final data file definitions defined?

  3. How is the original environment described?

  4. What if any conversion tools are in use?

  5. Are conversion and integrated acceptance test plans defined?

  6. How is the clean-up of converted data defined?

  7. How is a newly converted system compared with the original to assess identical results?

  8. What data integrity issues exist?

Sample Task list

  1. Create an end-to-end testing process including the use of test harnesses, scripts and conditions.

  2. Review the use of and management of development and testing environments.

  3. Review recent application failures (unusable to users), assess cause and ensure mitigations been put in place.

  4. Introduce a Rule of ‘fix a problem once’.

  5. Split DBAs into Systems and Applications.

  6. Locate application DBAs with developers.

  7. Create any necessary umbrella processes that involve inter-team workflows including hand-off points and deliverables.

  8. Pending how often conversions are undertaken, consider creating a conversions process that includes sub-contractors.

  9. Determine extent of data integrity issues and how to resolve.

  10. Define and agree a test environment.

  11. investigate QA toolsets.

  12. Determine further works required and scope out.

  13. Breakdown the scope of works to task level, ready for loading into the change management project schedule.

Methodologies

The Best practice IT Standard:

  1. 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.

Performance Assessment

  1. How often are development databases refreshed from production databases?

  2. Are the methodologies in use tailored?

  3. What methodology how-to guidelines exists?

  4. Are there matching Work Breakdown Schedule templates in use?

  5. 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)?

  6. Is there an agreed and documented procedure for interfacing with subcontractors?

  7. How are subcontractors advised of in-house development standards?

  8. Are regular performance reviews of progress including monitoring actual versus plan on a task and effort basis conducted with sub-contractors?

  9. Is Quality Assurance involved in code inspections?

  10. Is there a clear and unambiguous view of the overall application architecture and, is this conveyed to subcontractors?

  11. 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?

  12. How are applications security requirements managed?

Sample Task list

  1. Review software licenses.

  2. Risk analysis of in-use methodologies.

  3. Assess methodologies fit for purpose.

  4. Document in-house methodologies and customisations to packaged methodologies.

  5. Determine further works required and scope out.

  6. Breakdown the scope of works to task level, ready for loading into the change management project schedule.


You can share this post by using the buttons below

You can follow me on Facebook, Twitter, LinkedIn, Medium and Slideshare

Russell Futcher

Russell Futcher lives in Melbourne Australia as an IT/Business Change Management Consultant. He is a recognised High-Performance Management and Teams specialist, an author, researcher and blogger. His 40-year career to date has been focussed on Change Management where he has gained a hard-earned reputation for someone who takes on complex jobs and gets things done. Frank and direct, highly regarded by peers and customers alike, highly motivational and passionate about fixing problems, improving performance and developing management and team talent.

Russell has held senior management positions across the Insurance, Banking, Health, Transport, Retail, Superannuation, and Technology sectors in some of Australia’s largest corporations. Qualified in Business and Executive Coaching, Management Development and Training and Education, he is also the developer of the ‘Best Practice IT Standards’ and the ‘High-Performance Management and Teams’ management model, author of five management books and three courses.

An experienced electronic and print media presenter who spends much of his spare time doing research into Management and Team behavioural dynamics. His favourite subject he says is - people, stating that “Everyone is fascinating, and I just like everyone".

http://russellfutcher.com
Previous
Previous

High-Performance Teams - Reasons and Goals?

Next
Next

Part 18 – How to incrementally improve your Team - End of Series Summary