Systems Development

Systems Development
It refers to all activities that go into producing an information systems solution to an organizational problem or opportunity

Systems Development
IS/IT projects are generally risky or tend to fail because of High rate of technology changes High tendency for users to change requirements Misunderstanding of IS/IT deliverables and business outcomes Requirements determination tends to be dodgy Change associated with IS/IT projects are complex IS potentially change an organizations structure, culture, politics and work Most common reason for failure of large projects is due to organizational and political resistance to change. This is because they influence access to a key resource

Justification of IS/IT Projects

Justifying IS/IT projects involves
Matching the costs with benefits Identifying risks and plan to manage it

Categories of Cost of a new system

Cost Example

Equipment Cost

Installation Cost

Computer and peripherals Ancillary equipment The initial system Supplies (disk, tapes, paper etc) New buildings (if necessary) The computer room

Categories of Cost of a new system

Development Costs Cost measuring and Analyzing the existing system Cost of looking at the new system
software/ consultancy work System analysis Programming Change over cost
File conversion

Categories of Cost of a new system

Personnel Cost Staff training Staff recruitment Staff salaries and pension Redundancy payments Overheads

Categories of Cost of a new system

Operational Costs Consumable materials (tapes, disks, stationery etc) Maintenance Accommodation costs Power/Insurance/telephone Standby arrangements, in case the system breaks down

Benefits of a Proposed System

Savings because the old system will no longer be operated.
Savings may include
Savings in staff cost Savings in other operational cost such as consumable materials

Extra savings or revenue benefits because of the improvements or enhancements that the new system should bring
Possibly more sales revenue and so additional contribution Better stock control (with a new stock control system) and so fewer stock losses from obsolescence and deterioration Further savings in staff time, resulting perhaps in reduced future staff growth

Benefits of a Proposed System

Possibly, some one-off revenue benefits from the sale of equipment which the existing system uses, but which will no longer be required Intangible benefits
Greater customer satisfaction Improve staff morale from working with a better system Better decision, making it hard to quantify, but may result from better MIS, DSS or ESS

IS/IT Project Risks

Risk assessment involves the determination and evaluation of factors that are likely to hinder the delivery of the project Risks can be assessed by asking questions about the project definition, scope and viability
What business need is the project going to meet? Has the need and requirement well understood? Is the project feasible? Have you determined the alternatives?

IS/IT Project Risks

For each alternative have you assessed
Operational feasibility
Will it fit into the way things are done in the organization? Will it be accepted? Will it be abused?

Technical feasibility
Is it a proven technology? Is it compatible with the current systems? Do we have the technical support capacity? If not can we easily acquire it?

IS/IT Project Risks

Financial feasibility
Is the project financially sound?

Social feasibility
Will it adversely affect a section of the community Will it create social disharmony Will some people lose their jobs? Will it affect some peoples span of control in the organization?

 The assessment of technical feasibility is concerned with the technical performance criteria the system will have to meet to be accepted. For example:
The ability of the system to produce defined outputs in a given time scale. For example, to produce 120,000 examination certificates in two weeks. The ability of the system to provide minimum response times under certain conditions. For example, no more than a twosecond response time when accessing student information.

 The facility to input a large number of documents in a given time scale. For example, to enter the results for 200,000 students in four weeks. The facility to communicate data to distant locations. For example, to transfer examination results to a distant location. The facility to interface with other software already used by the organisation. For example, to allow data mining tools to be used on student information.

 Technical issues might include: (1) The technical issues concerning the scanned input of hand-written scripts into the computer system. Will it be possible to scan with sufficient quality to allow the marker to read the script on the screen? (2) If sufficient quality can be achieved in the scanning process, will it be possible to scan with sufficient speed at that quality to meet the marking process deadline?

 The technical issues concerning the security of transfer of scripts through the Internet and how the marker accesses the allocated scripts from his or her computer. What equipment will the marker need for this on-line access? For example, what size and quality of display unit will be required?

Operational and Social Feasibility

Operational and social feasibility is concerned with the organisational, social, human and political impact of the system. Amongst the issues considered are:
Likely job changes caused by the system and how these might affect the motivation of employees. The disturbance of established organisational structures within the company and trading relationships with suppliers.

 The expected skill requirements of users of the system and the implication of bridging any gaps in those skills. Any conflicts with how the organisation usually does business, the image it projects and the business ethics it wishes to adhere to.

Operational or social feasibility issues might include

Health and safety issues arising from on-line marking. The markers could potentially spend a long time looking at the screen and guidance will have to be given on equipment and work practice. The software skill levels of markers. Appropriate training will have to be given in the software application and supporting technology. The employment implications for staff at head office will also have to be considered. They have less involvement in the proposed system and so redundancies may be possible.

 Information systems development projects begin with some real or perceived needs The process Identify the problem or opportunity that we need to address( the purpose of the system) Identify the detailed requirements for the new system We identify the alternative ways to address the problem (different design alternative) and select the best We design the new system in detail We develop the system (i.e. coding and testing unit testing, system testing and integration testing) Implement the new system (i.e. install the system, train users, conduct testing unit testing, system testing, integration testing and acceptance testing; and identify appropriate changeover technique to adopt) and conduct file conversions (input/output files -- forms and reports, -menus, GUIs, etc). Operate and maintain

System Development Process

System Development Life Cycle (SDLC)

It is one formal process of developing information It is a series of recommended steps, or phases designed to reduce the risks of developing systems The actual number of steps and titles given to each step vary from organization to organization A step/phase has to be completed (with all deliverables produced and accepted) before the next one is started.

System Development Life Cycle (SDLC)

Putting it together: Software/systems development life cycle is an information system development methodology that partitions the systems development process into 6 stages/steps that must be completed sequentially with a formal division of labour between end-users and information systems specialists.

Phases of IS/IT projects

SLDC involves the following 6 steps/phases: 1. Requirements Definition 2. Systems Analysis 3. Systems Design 4. Systems Development/Acquisition 5. Installation & Deployment/Implementation 6. Post-Implementation Review

Stages/Phases Project definition Systems study/feasibility study Design Programming Installation & Implementation Post-implementation

End products Project proposal report System proposal report Design specifications Program code System performance tests Post-implementation audit report

Phases of IS/IT projects

Requirements Definition Phase Identifies the need for the software project Defines the problem Determines the objectives and scope for the project Identifies the constraints regarding:
Finance Technical issues Time Procedures, etc.

Phases of IS/IT projects

Analysis Phase Detailed requirements determination To ascertain and understand WHAT the system will do i.e. the purpose for which the system is needed Sifting through documents, polling users, conducting interviews Produce a Requirements specification document from users perspective

Phases of IS/IT projects

IS projects fail due to the following causes at this stage
Limited understanding of the business problem or opportunity Focus on technology requirement instead of business requirement Incomplete or unclear requirement

How to deal with these causes

Employ experience professionals
System analyst

Spend more time with the user or client to understand the need Use prototyping to solicit requirement and understanding

Systems Design Phase Deals with how to solve the problem or take advantage of the opportunity Involves conceptual/logical design and physical design Its the overall plan or model for that system. It includes:
Output design Input design User interface design Database Design Processing/logic design Training programs design Security design Conversion planning

Phases of IS/IT projects

Design tools are used e.g. UML, Flow charts, decision tables, system structure charts, etc. The outcome of this stage is a technical specification of the system and how it will be used

Phases of IS/IT projects

Systems Development/Build Phase This stage involves the creation or build of the system (i.e. Coding and testing --- unit testing, system testing and integration testing) For Software
It can be built in-house Purchased off the shelve Outsourced

Phases of IS/IT projects

Acquisition Strategies
Custom development (build from scratch) in-house Purchase software package (and customize it) Outsource development to third party

Phases of IS/IT projects

Custom Development PROS CONS

Advantages of in-house developed (or bespoke) software include: May meet organizations unique requirements. All business functions for the organization may be covered. User-friendly menus, forms, reports, combo boxes, online help, etc. Organizations need not buy middleware to bridge data interchange between two systems May perform many business functions well and to users satisfaction. Allows flexibility and creativity Consistent with existing technology and standards Builds technical skills and functional knowledge in-house

Disadvantages of in-house developed software include: Design work has to be accomplished from scratch Much testing is required and the testing period can be long More costly than application software packages. Programming and maintenance work have to done fully. Can be time consuming to develop.
Requires significant time and effort May require missing skills Risk of project failure

Phases of IS/IT projects

Packaged Software (Turnkey/off-the-shelf software):
Advantages of application software packages: They are pre-tested and proven before they are marketed; hence purchaser requires relatively shorter testing period. They are readily available for use. They are relatively cheaper than in-house developed software. They save time and cost for organizations that buy them. Most of their design work has been accomplished by the developers in advance. Vendors supply much of the ongoing maintenance and support They reduce the need for internal information systems resources Available for many common business needs

Disadvantages of application software packages are as follows.

They are not user friendly. Many business functions may not be covered. They require customization which could be very costly. They may not meet an organizations unique requirements. Organizations have to buy middleware to bridge data interchange between 2 systems Rarely a perfect fit with business needs

Phases of IS/IT projects

Outsourcing
Hiring an external vendor, developer, or service provider May reduce costs or add value Risks include possibly
Losing confidential information Losing control over future development Losing learning opportunities

Phases of IS/IT projects

Selecting Acquisition Strategy
Consider each of the following when deciding what strategy to use:
Business need In-house experience Project skills Project management Time frame

Selecting a System Acquisition Strategy

Systems Testing (Is part of Dev/Programming phase)

Phases of IS/IT projects

Testing of the computer system or product should always precede commissioning into service Testing procedures should clearly specified Users test the business scenarios Technical personnel test technical aspect The following 3 types of testing should be conducted:
Unit testing System testing Integration testing

 Unit Testing testing each program separately System Testing testing each module of the software, one after the other. Integration Testing testing all modules of the system a single go.

Phases of IS/IT projects

Deployment/Implementation Phase
Putting the system into production. This includes: installing the system, training users, re-testing the system, and file conversions adopting an appropriate changeover method.

 Testing (or re-testing)

The following 4 types of testing should be conducted during the Implementation phase of the project: Unit testing System testing Integration testing Acceptance testing All these types of testing require test plans.

 Unit Testing testing each program separately System Testing testing each module of the software, one after the other. Integration Testing testing all modules of the system a single go. Acceptance Testing provides the final certifications that the system is ready to be used in a production setting. When users and management are satisfied that the new system meets their requirements and standards, the system is formally accepted.

Changeover Methods Ways of introducing a system into production are:

Direct Changeover Parallel Run Pilot Run/Strategy Phased Implementation/Approach

Direct Changeover A complete changeover from old to new system on the cutover day Normally over a week end or a holiday period Least expensive of the strategies Ensures total commitment to making the new system work Its risky, as it has very little fallback option to the old system when serious problem occur

Phases of IS/IT projects

Parallel Run
It involves running the old and new system together for a specified period of time when the new system is functioning properly It provides opportunity to compare outputs from both systems Less risky, since the organization can fall on the old system whenever problem arise It is very expensive as efforts and resources need to be duplicated in running the two system

Phases of IS/IT projects

Pilot run
One department or other work site serves as a test site It is then replicated throughout the organization when the pilot is found to be working satisfactorily The full gains are not realizable as the new system is implemented in a limited area of the organization Not suitable for non branch situation, where the system cannot be replicated

Phases of IS/IT projects

Phased Implementation
Only parts of a new application or only a few departments, branch offices at a time are converted It allows gradual implementation process to take place within an organization Very suitable for implementing large and complex systems Minimizes the risk of implementation Requires effort in ensuring that the implemented parts are well integrated and function as a whole

Phases of IS/IT projects

Post-Deployment (Post-Implementation Review) Phase
Involves periodic (may be every 2 or 3 years) evaluation of the delivered system against planned requirements and objectives Making appropriate modifications to the system to conform to changes in the business organization: e.g. changes in organizational strategy, goals and objectives, etc.