Systems Analysis and Design Unit 1. LO1 Understand the different systems life cycles Assessment criteria AC1.1 Evaluate the different systems life cycle.

Systems Analysis and Design

Unit 1

• LO1 Understand the different systems life cycles • Assessment criteria

• AC1.1 Evaluate the different systems life cycle models• AC1.2 Discuss the importance of following a procedural/staged life cycle in

a systems investigation

• Learning objectives • After studying this unit, you should be able to:

• Understand the different SDLC phases • Understand the different systems life cycle models• Identify the different systems life cycle models• Evaluate the different systems life cycle models • Explain the importance of following a procedural/staged life cycle

Information systems analysis and design • Information systems analysis and design focus on the interaction

between related entities while developing an effective information technology solution.• There is no one single methodology that will ensure success during

information systems development, however, • using tools and techniques available to us will enhance our chances

of successfully completing a systems development project.

• Example • A library is in need of a system that will keep track of all books that

are currently booked out as well as who booked them out. • Another example is organisations that often purchase off-the-shelf

software. Such software, however, cannot always be customised or does not necessarily fit the needs of the organisation fully.

Components of information systems

• Information systems consist of the following components:

• Application software • Hardware software• System software • Documentation and training material • System roles and responsibilities • System controls • System users

• One of the aims of information systems development is to assist understanding the software engineering process .• This process leads to the creation of information systems.

Definition and characteristics of systems

• As stated previously, no one system can perform all functionality required by an organisation. • Organisations make use of various types of information

system in different departments. • For example, a system that keeps track of student results is separate

from a system that manages lecturer payroll.

• A system involves components and business procedures that are related in some way, and, which, when they work together, reach a designed outcome (Valacich [et al.], 2011:3).

• There are nine characteristics of a system, namely: 1. System components/sub-systems:

• parts that, when put together, will make up a system.

2. Inter-related system components: • the level to which the components rely on each other or on other parts

of a system.

3. System boundaries: • a system is developed to satisfy a set of requirements that meet a

specific organisational need. • Each system has limitations, known as ‘system boundaries’. • Simply put, to identify system boundaries, one must look at what should

be included in a system and what belongs outside such. • Everything inside a system will have to be planned, designed and

developed.

4. System purpose: • the main goal/function that a system will perform.

5. System environment: • a system exists within a specific environment; this refers to everything

external to a system that could interact with it.

6. System interface: • the point of contact where a system meets its environment; an interface

can also occur between sub-systems.

7. System constraints: • any limitation that a system might have in terms of capacity, speed or

functionality.

8. System input: • a system takes input from its environment to function.

9. System output: • a system provides output from received input and returns such to its

environment; this marks that a system is achieving its purpose.

Decomposition

• Decomposition entails breaking a system up into smaller, more manageable components that may constitute a system by itself. • These broken down systems are referred to as ‘sub-systems’. • The main reason for performing decomposition is to focus on

particular parts of a system. • Decomposition allows a systems analyst to do the following:

• Break a system into smaller, more manageable sub-systems • Focus the attention on one specific area in a system • Focus on a part of a system that is relevant to a specific group of users • Build sub-systems independently from one another

Modularity

• Modularity is the result of decomposition; it refers to the divided system pieces (modules) that exist. • For example, looking at the components of the MP3 player, we can

see how decomposition makes it easy to understand an overall system.

Coupling

• Coupling means that sub-systems are dependent on each other. • If one sub-system should fail, the others will also fail or have difficulty

functioning properly. • For example, without a battery, the MP3 player will not function at

all; without a hard drive sub-system, the MP3 player will switch on but will not be able to store any music.

Cohesion

• Cohesion refers to the extent to which a sub-system will perform a single function. • For example, storing music on a hard drive refers to a single function.

The systems development life cycle (SDLC)

• The SDLC forms the basis for any information systems development project. • The four main phases of the SDLC will be discussed in detail in the

sections to follow.

• In order to remain competitive, a business must keep its systems up to date. • The SDLC refers to a process of understanding exactly how an

information system will be able to support the requirements of an organisation. • As each system is developed, it progresses through the specific life

cycle. • A life cycle refers to the time from the beginning of a systems

project to the implementation and maintenance of such. • This includes the time that the system will be operational as well as

the time needed to develop and implement such. • How the different phases/levels relate to one another depends on

which life cycle model is used. • Each model will employ phases, even if they are called something

different; some models might even combine phases to occur simultaneously or add additional phases to ensure that a system’s outcomes are met.

Phase 1: systems planning and selection

• The systems planning and selection phase begins with a formal request to the Information Technology (IT) Department that describes a problem or desired change that an organisation might need. • This request is called a ‘systems request’. • A systems request can originate from any department within an organisation and

may be very significant or small. • The main questions answered during this phase are why a system should be built

and how the team will go about building such. • The purpose of this phase is to perform a preliminary investigation to identify the

nature and scope of the problem or requested change. • A very important part of this investigation is to perform a systems feasibility

study. • Another important process is to perform a SWOT analysis: the purpose of a

SWOT analysis is to determine the strengths (S), weaknesses (W), opportunities (O) and threats (T) of a proposed system.

Phase 2: systems analysis

• The purpose of the systems analysis phase is to draw and build logical models of the proposed system. • It is concerned with discovering what the new system should be able

to do. (Requirements specification)• At the end of this phase, a systems analyst should propose

alternative replacement systems for the given request, outlining the requirements, costs and benefits.

Phase 3: systems design

• The purpose of the systems design phase is to create a draft of the system that will satisfy all of the documented requirements given by an organisation for the new system. • During this stage, data designs, user interfaces, input and output

designs and systems architecture are identified and created. • It is essential that the first three phases of the SDLC are understood

and correct before the construction of a system can begin.

Phase 4: systems implementation and operation

• The system is now constructed according to the systems design specifications. • It is important that each section is checked to verify that it meets the

requirements as identified previously. • Regardless of the approach being used, the method is the same:

programs are written, tested and documented. • At the end of this phase, the system is ready for use. • The final preparations include converting current organisational data

to the new system’s files, training users and performing the change over to the new system.

SDLC phases Products

1. Systems planning and

selection

Priorities for systems and projects Architecture for data, networks, hardware and information

systems management Detailed work plans for selected projects Specifications of systems scope Systems justification or business case

2. Systems analysis

Description of current systems General recommendations on how to fix, enhance or

replace current systems Explanations of alternative systems and justification for

chosen alternatives Acquisition plans for new technology

3. Systems design Detailed specifications of all systems elements

4. Systems

implementation andoperation

Coding Documentation Training procedures and support capabilities New versions or releases of software with associated

updates to documentation, training and support

Waterfall Model

• The Waterfall Model is a traditional methodology based on a series of steps that should be addressed in sequence when building information systems. • The order of the steps is predefined with a review at the end of each

step. • The model requires that each step be completed before moving on to

the next step.• Where the requirements have been well defined and the

development methods well understood, the Waterfall Model allows for forecasting project completion times.

• Advantages• Easy to understand, easy to use• Provides structure to inexperienced staff• Milestones are well understood• Sets requirements stability• Good for management control (plan, staff, track)• Works well when quality is more important than cost or schedule

Quality

TimeCost

• Disadvantages• All requirements must be known upfront• Deliverables created for each phase are considered frozen – inhibits flexibility• Can give a false impression of progress• Does not reflect problem-solving nature of software development – iterations

of phases• Integration is one big bang at the end• Little opportunity for customer to preview the system

• When to use the waterfall model:• Requirements are very well known• Product definition is stable• Technology is understood• New version of an existing product• Porting an existing product to a new platform

Prototyping

• Prototyping is a strategy related to information systems development, in which a scaled-down system or portion of a system is created in a short time, tested and improved upon in several steps. • A prototype is an initial version of a system that is developed quickly

to test the effectiveness of the overall design being used to solve a particular problem.

Analysis

Design

Modeling

Testing

• Advantages:• Customers can “see” the system requirements as they are being gathered• Developers learn from customers • A more accurate end product• Unexpected requirements accommodated• Allows for flexible design and development• Steady, visible signs of progress produced• Interaction with the prototype stimulates awareness of additional needed

functionality

• Disadvantages• Tendency to abandon structured program development for “code-and-fix”

development• Bad reputation for “quick-and-dirty” methods• Overall maintainability may be overlooked• The customer may want the prototype delivered• Process may continue forever (scope creep)

• When to use the prototyping model• Requirements are unstable or have to be clarified • As the requirements clarification stage of a waterfall model• Develop user interfaces• Short-lived demonstrations • New, original development• With the analysis and design portions of object-oriented development

Spiral Model

• The Spiral Model is a non-linear model; it contains features from both the Waterfall Model and prototyping. • It adds a new element called ‘risk analysis’. • The Spiral Model goes through all of its stages many times before a

system is released.

• Advantages• Provides early indication of insurmountable risks, without much cost• Users see the system early because of rapid prototyping tools• Critical high-risk functions are developed first• The design does not have to be perfect • Users can be closely tied to all life cycle steps• Early and frequent feedback from users• Cumulative costs assessed frequently

• Disadvantages• Time spent for evaluating risks too large for small or low-risk projects• Time spent planning, resetting objectives, doing risk analysis and prototyping

may be excessive• The model is complex • Risk assessment expertise is required• Spiral may continue indefinitely• Developers must be reassigned during non-development phase activities• May be hard to define objective, verifiable milestones that indicate readiness

to proceed through the next iteration

When to use the spiral model• When creation of a prototype is appropriate• When costs and risk evaluation are important• For medium to high-risk projects• Long-term project commitment unwise because of potential changes to

economic priorities• Users are unsure of their needs• Requirements are complex• New product line • Significant changes are expected

Joint application development (JAD)

• JAD is a structured process, in which users, managers and systems analysts work together for several days in a series of intensive meetings to specify or review systems requirements.

Rapid application development (RAD)

• RAD is a team-based technique that is used to speed up the systems development process. • It produces a working system, which is very similar to prototyping.• The fundamental principle of RAD is to delay producing detailed

systems design documents until user requirements are understood.

• Requirements planning phase (a workshop utilising structured discussion of business problems)• User description phase – automated tools capture information from

users• Construction phase – productivity tools, such as code generators,

screen generators, etc. inside a time-box (“Do until done”)• Cutover phase -- installation of the system, user acceptance testing

and user training

• Advantages • Reduced cycle time and improved productivity with fewer people means

lower costs• Time-box approach mitigates cost and schedule risk• Customer involved throughout the complete cycle minimises risk of not

achieving customer satisfaction and business needs• Focus moves from documentation to code (WYSIWYG).• Uses modeling concepts to capture information about business, data, and

processes

• Disadvantages• Accelerated development process must give quick responses to the user• Risk of never achieving closure • Hard to use with legacy systems• Requires a system that can be modularized• Developers and customers must be committed to rapid-fire activities in an

abbreviated time frame

• When to use RAD• Reasonably well-known requirements• User involved throughout the life cycle• Project can be time-boxed • Functionality delivered in increments• High performance not required• Low technical risks • System can be modularised

Test your knowledge

• Toolbox activities • Individual exercise 1• Group exercise 1• Research task 1

• Textbook activities • Chapter 1: match the terms and definitions • Chapter 1: review questions • Chapter 1: Pine Valley Furniture case study

Test your knowledge

1. List and briefly explain the four phases of the SDLC. Draw a diagram to illustrate the phases.

2. Identify the components of an information system. 3. Briefly describe the nine characteristics of a system. 4. Define decomposition, modularity, coupling and cohesion. 5. Differentiate between the different life cycle models.

Activity

Activity