Systems Methodologies for Software Development

JOURNAL #FIVE [SYD701]

Systems Methodologies for Software Development

A system is a broad term applied across many fields including information technology. For instance, a business is considered a system that contains several often disparate units or departments that deploy procedures, these procedures work together for a common goal or purpose. The elements of a system are defined by a boundary that separates it from its environment. Like a business system, software systems intend to receive input from outside the boundary, which then processes and changes the data before sending the output back into the environment.

Information systems capture and manage data that has a tangible benefit to organisations, employees, partners, suppliers and customers. As a result, they are essential to ensure businesses remain competitive. Commonly used information systems include transaction processing systems, managerial or executive information systems, decision support systems, communication and collaboration systems and automation systems. An ability to clearly define and understand what makes an information system should help software developers design and build applications that meet user and stakeholder requirements, both on time and within budget. Despite this, the failure rate in this field remains high.

Experienced users of information systems will have encountered software applications that haven’t been up to the job. Often, this requires procedures and processes outside of the technology system to bridge the functionality gap. The problem is not uncommon, particularly where systems are sold as a ‘one size fits all’, suitable for several business processes but achieve none to any great degree. Users are left operating these systems differently across departments and even within business units to perform separate tasks. So why is this so common?

A Methodology for Software Development

Many factors might collectively explain these failed systems, complexity is likely to play a role plus communication failures and a lack of requirements understanding. These can be attributed to a lack of defined methodology throughout the system development life cycle (SDLC). The early days of software development emphasised programming talent and ability. There was a desire to create a working application to overcome the existing technological limitations such as hardware and the processing power of available memory capacity. The experience of programmers became the dominant methodology. The results were inevitable, inappropriate designs that failed to meet user requirements. As discussed in the critical analysis of the failures of TSB bank, a lack of communication played a significant role in the implementation failures.

It became clear that a methodology for software development was necessary, the objectives were clear:

1. Address the growing appreciation of the importance of the analysis and design process of the SDLC
2. Move away from separate solutions to problems and produce more integration in information systems to handle increasing organisational complexity
3. Produce an accepted methodology accounting for the increasing appreciation for the benefits a framework could bring

As a result, the SDLC needed to evolve to include phases, procedures, tasks, rules, techniques, guidelines, documentation, training programs and tools. The early prevailing methodology comprised several sequential stages that included approaches that are still used today, these include feasibility studies, analysis and design, systems investigation, implementation, review and ongoing maintenance. The approach aided communication between business users and software developers, it ensured adequate training and controls that were implemented through the phases of the SDLC to meet delivery requirements, mitigate unexpected costs and avoid missing deadlines.

This early approach, now referred to as the Waterfall approach, was not without its limitations. Primarily, its inflexibility made changes and change management costly and difficult to achieve, it created documentation problems because users could not test the system as it was developed and finally, there was an overemphasis to digitalise existing business systems. Although developing a mythology for system development was a step forward, there was clear room for improvement.

Methods & Tools

Deploying the correct methodology for a software development project will inform and justify the methods & tools used to find solutions for problems. Methods can be qualitative, such as interviewing stakeholders and users, and quantitative, collecting data to create workable knowledge to identify and optimise trends and patterns and quantifying processes and products for improvement.

Given the complexity of software development, the industry has recognised the importance of qualitative methods for communication between technical and non-technical users to better meet and ultimately solve management and business issues. A quantitative approach alone will often fail given the typically small sample size. This is not helped by the difficulty organisations have when attempting to define and quantify the business in a non-qualitative manner. A result of a qualitative approach will be a deeper understanding of the complexity of the business system and the human interaction and behaviour in the environment.

Avison, D., & Fitzgerald, G. (2006). Methodologies for Developing Information Systems: A Historical Perspective. https://doi.org/10.1007/978-0-387-34732-5_3

Methods and methodology - Dr Deborah Gabriel. (2011, May 13). https://deborahgabriel.com/2011/05/13/methods-and-methodology/

padakuu.com. (n.d.). What is System and its concepts - characteristics and types of system - PadaKuu.com. Www.Padakuu.Com. Retrieved April 24, 2022, from https://padakuu.com/system-definition-and-concepts-characteristics-and-types-of-system-2-article

Top 5 Key Differences Between Methods and Methodology. (2021, July 1). Enago Academy. https://www.enago.com/academy/difference-methods-and-methodology/

Dybå, T., Prikladnicki, R., Rönkkö, K., Seaman, C., & Sillito, J. (2011). Qualitative research in software engineering. Empirical Software Engineering, 16(4), 425–429. [https://doi.org/10.1007/s10664-011-9163-y](https://doi.org/10.1007/s10664-011-9163-y] (https://doi.org/10.1007/s10664-011-9163-y](https://doi.org/10.1007/s10664-011-9163-y)

Quantitative methods in Software Engineering. (n.d.). Retrieved April 24, 2022, from https://gousios.org/courses/ml4se/2018/quant-se.html