Information Management and Auditing

System Development

IS AUDITOR:

From an IS auditor perspective, a well-defined system development approach has the following advantages:  Influence is significantly increased when there are formal procedures and guidelines specified for each distinct development phase.  He can review and report independently regarding adherence of planned objectives.  He can identify selected parts of the system and technicalities associated with them.  He can evaluate the methods and techniques applied in system development.

TRADITIONAL SYSTEM DEVELOPMENT: (Water-fall Method)
Traditional approach to system development is based on systematic, sequential approach to software development. It has the following SIX phases:

Problems: Following are certain problems associated with this sequential approach to system development:  Unanticipated events.  Difficulty in obtaining explicit requirement set at once.  User patience is required – time delay.  Changing business environment. 1: FEASIBILITY

1

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

The feasibility study is basically the test of the proposed system in the light of its workability, meeting user’s requirements, effective use of resources, and the cost effectiveness. The goal of feasibility study is to evaluate alternative systems and to propose the most feasible and desirable system for development. It provides the justification to proceed with next steps. Following items are addresses in a typical feasibility study:  Implementation time frame.  Optimum risk-based solution.  Existing system’s ability to cope the problem.  Vendor product.  Approximate development cost.  Strategic workability of solution. DEVELOP VS. ACQUIRE: Following factors would determine the choice between in-house development or purchasing a pre-developed system:  Required date.  Cost.  Resources required.  System compatibility.  IT infrastructure compatibility.  Future change requirements.

Determine the strategic benefits of implementing the system either in productivity gains or in future cost avoidance, identify and quantify the cost savings of a new system and estimate a payback schedule for costs incurred in implementing the system. RFP contents: The feasibility study should contain documentation that supports the decision to acquire the software. A project team with participation by technical support staff and key users should be created to write a Request for Proposal (RFP). The RFP should be sent to a variety of vendors to determine which of their products offers the best solution at the most cost-effective price. The RFP should include areas such as:  Product Versus System Requirements  Customer References

2

Prepared by: Muhammad Umar Munir

Information Management and Auditing     Vendor Viability/Financial Stability Availability of Complete and Reliable Documentation Vendor Support Source Code Availability

System Development

2: REQUIREMENTS Define the problem or need that requires resolution and the major requirements of the solution system. This can be either a customized approach or vendor-supplied software package which would entail following a defined and documented acquisition process. In either case, the user needs to be actively involved. It entails identifying and specifying business requirements of proposed system. It explains:  System functionality.  User interaction.  Operating conditions.  Information criteria. Following tasks are performed in order to analyze requirements:  Consulting stakeholder to identify expectations.  Analysing requirements.  The way in which system should interact with its environment.  Recording requirements in a structured format.  Verifying requirements. (Completeness, accuracy, consistent, realistic, modifiable etc.)  Resolving conflicts between stakeholders.  Resolving conflicts between requirements and available resources. 3: DESIGN/SELECTION Based on requirements defined, system and sub-system establish specifications which generally include both program and database specifications, and create a security test plan. Establish a formal change control process to prevent the controlled entry of new requirements into the development process. 4: DEVELOPMENT/CONFIGURATION Use the design specifications to begin programming and formalizing supporting operational processes of the system. Various levels of testing also occur in this space to verify and validate what has been developed. 5: IMPLEMENTATION The actual operation of the new information system is established, with final user acceptance testing conducted in this environment. The system may also go through a certification and accreditation process to assess the effectiveness of the business application in mitigating risks to an appropriate level and providing management accountability over the effectiveness of the system in meeting its intended objectives and in establishing an appropriate level of internal control. 6: POST-IMPLEMENTATION Following the successful implementation of a new or extensively modified system, it is beneficial to verify that the system has been properly designed, developed and that proper controls have been built into the system. As such, a post implementation review should meet the following objectives: Assess the adequacy of the system  Does the system meet user requirements and management’s objectives?  Have access controls been adequately defined and implemented?  Evaluate the projected cost benefits or Return On Investment (ROI) measurements.

3

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

 Develop recommendations that address the system’s inadequacies and deficiencies.  Develop a plan for implementing the recommendations.

RISKS:
a) Inadequate SDLC: There are many potential risks that can be realized when poor or inadequate SDLC methodologies are utilized. The first and most devastating is that the end result of the process or the new system does not meet the users’ business needs, user requirements and expectations. The business requirements that were to be addressed by the new system are still unfulfilled and the process has been a waste of resources. Even if the system is implemented it will most likely be under-utilized and not maintained, making it obsolete in a short period of time. b) Poor methodology: Systems designed utilizing a poor SDLC methodology will often exceed the limits of the financial resources set aside for the project and may be completed late, if ever. An inadequate SDLC methodology can promote poor management or mismanagement of the project. Other risks associated with a poor methodology could position the organization at a competitive disadvantage or result in incompatibility with existing systems, missed business opportunities, reduced IS credibility and unmotivated employees. c) Other risks: The IS auditor should be aware that merely following an adequately designed SDLC methodology does not ensure the successful completion of a development project. The IS auditor should review other aspects of systems development, such as user involvement and senior management support, in addition to compliance with the organization’s SDLC.

ROLES AND RESPONSIBILITIES:
Following are various roles and responsibilities in project/system development:  Senior Management: Senior Management commits to the project and approves the necessary resources to complete the project. This commitment from senior management helps ensure involvement by those needed to complete the project.  User Management: User Management assumes ownership of the project and resulting system, allocates qualified representatives to the team, and actively participates in… o System requirements definition. o Acceptance testing. o User training. User management should review and approve system deliverables as they are defined and accomplished.  Project Steering Committee: Project Steering Committee provides overall direction and ensures appropriate representation of affected parties. The project steering committee is ultimately responsible for all costs and timetables.  Project Sponsor: Project sponsor Provides funding for the project. It works closely with the project manager to define success measurement for the project. It is crucial that success is translated to measurable and quantifiable terms. Data and application ownership are assigned to a project sponsor. A project sponsor is typically the senior manager in charge of the primary business function the application will support.  Systems Development Management: Systems Development Management Provides technical support for hardware and software environments by developing, installing and operating the requested system. Provides assurance that the system is compatible with the organization’s computing environment

4

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

and strategic direction. It assumes operating support and maintenance activities after installation. Project Manager: Project Manager provides overall direction, ensures appropriate representation of affected departments, ensures project adheres to local standards and that deliverables are a quality product, resolves inter-departmental conflicts, monitors and controls costs and project timetable. This person can be an actual end user or a member of the systems development team. Systems Development Project Team: Systems Development Project Team Completes assigned tasks, communicates effectively with users by actively involving them in the development process, works according to local standards, advises project manager of necessary project plan deviations. User Project Team: User Project Team Completes assigned tasks, communicates effectively with the systems developers by actively involving themselves in the development process, works according to local standards, advises project manager of expected and actual project plan deviations. Security Officer: Security Officer ensures that system design adheres to corporate security policies, consults on appropriate security measures that should be incorporated into the system, tests system security prior to implementation, receives adequate training on any new security systems, procedures or security responsibilities after implementation. Quality Assurance: This function should review results and deliverables within each phase and at the end of each phase confirm compliance with requirements. The points where reviews occur depend on the Systems Development Life Cycle (SDLC) methodology used, structure and magnitude of the system and impact of potential deviations.

ALTERNATIVE SOFTWARE DEVELOPMENT STRATEGIES:
Data-Oriented System Development (DOSD) focuses on and recognizes the need for management and staff to have access to data to facilitate and support decisions. Users need and want data so they can derive information from it. Inherent in DOSD systems is the development of an accessible database of information that will provide the basis for ad hoc reporting. Object-Oriented System Development (OOSD) is the process of solution specification and modeling. This process defines how to implement functionality defined by the analysis. OOSD is usually divided into two levels: the first, abstract design, adds solution characteristics to the analysis models but is still largely independent of development tool specifics; the second, physical design, is a more detailed level which looks at the specifics of the development environment and incorporates those features or constraints into the design. Component-based Development. Component-based development can be regarded as an outgrowth of object-oriented development. Component-based development means assembling applications from cooperating packages of executable software that make their services available through defined interfaces (i.e., enabling pieces of programs, called objects, to communicate with one another regardless of what programming language they were written in or what operating system they’re running). Prototyping, also known as heuristic development, is the process of creating a system through controlled trial and error. It is a method, primarily using faster development tools such as 4GLs, that allows a user to see a high level view of the workings of the proposed system within a short period of time. Rapid Application Development (RAD) is a methodology that enables organizations to develop strategically important systems faster while reducing development costs and maintaining quality. This is achieved by using a series of proven application development techniques, within a well-defined methodology. These techniques include the use of:  Small, well-trained development teams

5

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

 Evolutionary prototypes  Integrated power tools that support modeling, prototyping and component re-usability  A central repository  Interactive requirements and design workshops  Rigid limits on development time frames Re-engineering is a process of updating an existing system by extracting and reusing design and program components. This process is used to support major changes in the ways an organization operates. A number of tools are now available to support this. Reverse Engineering is the process of taking apart an application or a software application or a product, in order to see how it functions and to use that information to develop a similar system. This process can be carried out in several ways:  De-compiling object or executable code into source code and using it to analyze the program  Utilizing the reverse-engineered application as a black box and unveiling its functionality using test data The major advantages of reverse engineering are:  Faster development and reduced SDLC duration  Creation of an improved system using the reverse-engineered application drawbacks

IS MAINTENANCE:
Whether systems are vendor supplied or internally developed, change in inevitable due to changing business and technological circumstances. Defined: IS maintenance refers to the process of managing change to application systems and at the same time maintaining the integrity of source and executable codes. CHANGE MANAGEMENT: The change process is just like system development which should appropriately authorized, documented, tested, and approved by management. The process begins with authorizing. Change requests are initiated from end users, operational staff, and system development maintenance staff through formal correspondence. Appropriateness and likely effects of the changes are to be considered. The request would contain the following information:  Requestor’s name.  Date.  Description of anticipated effects.  Request description.  Reason.  Justification etc. All change request and related information should be maintained by the system maintenance staff as a part of system’s permanent documentation. Programmers should not have write, modify, or delete access to production data. DEPLOYING CHANGES: After the end user is satisfied with the system test results and the adequacy of the system documentation, approval should be gained from user management. User approval could be documented on the original change request or in some other fashion (memo or e-mail); however, evidence which verifies that user approval has been granted should be retained by the system maintenance staff. DOCUMENTATION:

6

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

To ensure the effective utilization and future maintenance of a system, it is important that all relevant system documentation be updated. Due to tight time constraints and limited resources, thorough updates to documentation are often neglected. Documentation requiring revision may consist of program and/or system flowcharts, program narratives, data dictionaries, entity-relationship models, Data Flow Diagrams (DFDs), operator run books and end-user procedural manuals. TESTING PROGRAM CHANGES: In evaluating whether program changes are adequate the IS auditor should ensure that controls are in place to protect production application programs from unauthorized changes. EMERGENCY CHANGES: There may be times when emergency changes are required to resolve system problems and enable critical processing to continue. Procedures should exist to ensure emergency fixes can be performed without compromising the integrity of the system. Typically, it requires special login IDs and passwords to programmer that grant access to production data during emergency. DEPLOYING CHANGES BACK INTO PRODUCTION: Once user management has approved the change, the modified programs can be moved into the production environment. A group that is independent of computer programming should perform the migration of programs from test to production. Groups such as computer operations, quality assurance or a designated change control group should perform this function. To ensure that only authorized individuals have the ability to migrate programs into production, proper access restrictions must be in place. Such restrictions can be implemented through the use of operating system security or an external security package. CHANGE EXPOSURES (UNAUTHORIZED CHANGES) Unauthorized change could occur due to the following reasons:  Programmer has access to production libraries.  Responsible user is unaware of the change.  No formal change request was initiated.  Change was unauthorized.  Improper review of programming code was made.  Committed fraud - programmer put extra code for personal benefit.  Change received from vendor was not properly tested.

CONFIGURATION MANAGEMENT:

Since software is subject to ongoing change, configuration management is important (both during development and afterwards). In configuration management system, change requests must formally be documented and approved by a change control group. Additionally, careful control is exercised in each stage of maintenance process. For audit purpose, this software provides important evidence of managerial commitment to careful control over maintenance process. Configuration management involves procedures throughout the software lifecycle to identify, define, and baseline software items in the system, forming basis for problem and release management. Important terms:  Configuration items – these are the items that are likely to be changed (programs, documents, and data).  Checking in – it is the process of moving an item to the controlled environment.

7

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

Once the item to be changed is identified, it is moved to the configuration management team for safekeeping and reference numbering. Following tasks are performed by a maintainer: a) Developing configuration management plan. b) Baselining the code and associated documents. c) Analysing and the report on the result of configuration control. d) Developing report providing configuration status information. e) Developing release procedures. f) Performing configuration control activities. g) Updating the configuration status.

RELEASE MANAGEMENT:

It is the process of making software available to users. A release consists of new or changed software required.

TYPES OF RELEASE: There are three types of releases: a) Major: It is a significant change or addition of a new functionality. It supersedes all preceding minor changes. Large organizations have typically developed timetables for major releases. b) Minor: It contains small enhancements and fixes and supersedes all previous emergency fixes. These are the fixes that cannot be deferred until next major release. They require lesser time than major releases do. c) Emergency: It involves correction of small number of known problems. They are required as quickly as possible to prevent downtime of critical functions. PLANNING A RELEASE:  Gaining consensus on the release’s contents.  Agreeing on release terms.  Producing high-level release schedule.  Agreeing roles and responsibilities.  Developing quality plans.  Planning acceptance of support groups.

LIBRARY CONTROL SOFTWARE:

Library Control Software should be used to separate test from production libraries in either a mainframe or client/server environment. The major objective of library software is to ensure that all program changes have been authorized. The minimum control necessary is authorization of the changes to the production library, which requires an authorization procedure between the test and production libraries. Authorization controls should be applied to both test and production libraries.

PROJECT MANAGEMENT:
Timebox Management Timebox management is an emerging and highly regarded project management technique for defining and deploying software deliverables within a relatively short, but absolute and unchangeable, amount of time and with limited resources. In applying this technique, a balance has to be established between software quality and getting the job done within the timebox.

8

Prepared by: Muhammad Umar Munir

Information Management and Auditing

System Development

Budgets and Schedules The system development project is analyzed with a view of estimating the amount of effort that will be required to carry out each task. Individual tasks may consume both human effort and machine time. The estimates for each task should contain many elements. Critical Path Methodology (CPM) All project management techniques compute what is called a critical path. A critical path is one whose sum of activity time is longer than that for any other path through the network. This path is important because, if everything goes according to schedule, its length gives the shortest possible completion time of the overall project. GANTT Charts They can be constructed to aid in scheduling the activities (tasks) needed to complete a project. The charts show when an activity should begin and when it should end. Program Evaluation Review Technique (PERT) PERT is a network management technique that assumes that the project is a collection of activities or tasks. The activities can be started and stopped independently of each other (in contrast to a sequential flow of processing) or have precedent relationships. Precedence relationships preclude the start of certain activities until others are complete (e.g. surfacing a road must be preceded by the laying of the roadbed).

9

Prepared by: Muhammad Umar Munir

Sign up to vote on this title
UsefulNot useful