Systems Development Life Cycles

Systems

A collection of interrelated parts that form a whole

The collection has some purpose

A change in any part can lead to a change in other part(s)

Systems Development Life Cycle

The process of determining how a system can support business needs, designing the system, building it, and delivering it to users

Stages:

1. Planning

2. Analysis

3. Design

4. Implementation

Planning

• Understanding why a system should be developed and creating plan for how it will be developed and delivered

• Often involves a feasibility analysis – technical feasibility, economic feasibility and organisational feasibility - how much revenue is this going to bring in

• Working out the resources required and capacity to deliver; making a business case

cost-benefit analysis and outputs

Cost-Benefit Analysis

• Part of stage 1 economic feasibility

• Development costs (one-time costs)

• Operational costs (ongoing costs)

• Tangible benefits (e.g., revenue) 

• Intangible benefits (predicted benefits, that may be harder to quantify)

Outputs

• Goals for new system

• Definition of project’s scope

• Assessment of feasibility

• Initial work plan

Analysis

Understanding who will use the system, what the system will do, and where/when it will be used

1. Understand the existing situation

2. Identify improvements

3. Define requirements

Problem Analysis

• Breaking a whole into its parts to understand the parts’ functions and inter-relationships - 

• May involve rich pictures; images that attempt to capture everything that is relevant to a complex situation or system

  • Mental tool to understand a scenario

  • Useful for discussing with other people – can cut across jargon, etc.

  • Helpful for identifying stakeholders

  • Suitable for any domain

Requirements Determination

• Changes high level strategic objectives into more precise statements of what a system should do

• Requirements are simply statements of what the system should do and characteristics the system should have

Requirements Gathering

Getting more insight into the requirements for the system by gathering data from users

PACT Questions

• People – what are the intended users’ characteristics and skills?

• Activities – how is the activity currently carried out? Why? What can be improved?

• Context – what is the environment of the activity?

• Technology – what tools are being used currently? How might new developments be used

People

• Language

• Levels of skill and expertise

• Cognitive characteristics – attention, perception, memory

• Physical characteristics – physical abilities, accessibility

• Emotions – satisfaction, frustration, things being aesthetically pleasing

• Infrequent vs. frequent users

Activities

• Goals, tasks and actions

• Frequent or infrequent tasks?

• Well-defined or vague goals

• Continuous or interrupted?

• Individual or cooperative?

• Time requirements (e.g., how fast a response is needed)

• Error tolerance

Context

• Physical environment 

• Social environment

• Organisational context

• When and where activities happen

Technology

• Input – data, commands

• Output 

• Communications (between people, between devices, speed, etc.)

• Size of screen 

• Networked?

Design

System design is the determination of the overall system architecture that will satisfy the system’s essential requirements

• How will the system operate; deciding how to build it

• Involves design of architecture and interface, development of database and file specifications

• Output: system specification

User Interface Design

• Defines how users will interact with the system and what kind of inputs and outputs the system accepts and produces

• Navigation mechanisms: how user gives instructions to the system (e.g., buttons, menus) 

• Input mechanisms: how the system captures information (e.g., forms)

• Output mechanism: how the system provides information to the user (e.g., reports)

Implementation

• Actually building the system

• Testing the system

• System construction, installation and support plan (maintainability)

• Sometimes maintenance is identified as a separate phase 

  • Not just about maintaining existing functionality; may often involve building new functionality

Types of Testing

• Unit testing – testing of each unit or program module separately

• Integration testing – checking that things that should work together do so without error

• Acceptance testing – does the system meet requirements

• User testing - system tested with users

Waterfall Development Advantages

• Requirements identified at the start; limited changes to requirements as project goes on

• Well suited to systems that have high security needs

• Clear deliverables

• Easy to arrange tasks as thing progress one phase at a time

Waterfall Development

• Time consuming

• Inflexible/not dynamic

• No working software until end stage

• Doesn’t adjust to changing requirements

• Difficult to measure progress within stages

• High overheads

Rapid Application Development (RAD)

An alternative approach to waterfall 

Examples include:

• Iterative development

• System prototyping

• Throwaway prototyping

• Agile – e.g., XP, Scrum

Agile - RAD

• Feature oriented not activity oriented

• Rapid development and delivery

• Work in small iterations

• Deliver in each iteration

• Review and adapt

• Make changes 

Advantages of RAD

• Cheaper and easier to make changes during process

• Flexible

• Requirements can change and be more adaptive

• Often useful when users struggle to articulate requirements

• Get user feedback earlier

• Quicker delivery of working software

Disadvantages of RAD

• Can be more challenging to integrate at the end

• Planning can be difficult

• Can be harder to manage

• Less control

• Can be difficult to sc