Also there are little changes in Chapter - 2 . But major part is only deletions .
Following are the additions :
Chapter 2 – SDLC
Basic Principles :
Following are the key principles of this methodology:
© Customer satisfaction by rapid delivery of useful software;
© Welcome changing requirements, even late in development;
© Working software is delivered frequently (weeks rather than months);
© Sustainable development, able to maintain a constant pace;
© Close, daily co-operation between business people and developers;
© Face-to-face conversation is the best form of communication (co-location);
© Projects are built around motivated individuals, who should be trusted;
© Continuous attention to technical excellence and good design;
© Self-organizing teams; and
© Regular adaptation to changing circumstances.
© Able to respond to the changing requirements. ( i.e., Adaptability)
© Investment in time and efforts are saved.
© Guesswork is eliminated. ( Due to face to face communication and continuous inputs from customer representative)
© The documentation is crisp (decisive) and to the point to save time.
© The end result is the high quality software in least possible time duration and satisfied customer.
© Difficult to assess the efforts required at the beginning of the SDLC in case of big projects.
© Lack of emphasis on necessary designing and documentation.
© Agile increases potential threats to business continuity and knowledge transfer since verbal communication with the customer is emphasized rather than on documentation.
© Agile requires more re-work because of the lack of long-term planning and the lightweight approach to architecture.
© The project can easily get taken off track if the customer representative is not clear about the final outcome that they want.
© Senior programmers are capable of taking the kind of decisions required during the development process. Hence, it has no place for newly appointed programmers, unless combined with experienced resources. ( i.e., Experienced programmers are required)
Auditors’ Role In SDLC ( Amendment)
The audit of systems under development can have three main objectives:
ü To provide an opinion on the efficiency, effectiveness, and economy of project management;
ü To assess
© the extent to which the system being developed provides for adequate audit trails and controls to ensure the integrity of data processed and stored; and
© the controls being provided for the management of the system's operation.
1. For the first objective to achieve,
· Auditor will have to attend project and steering committee meetings and examine project control documentation and conducting interviews.
· This is to ensure what project control standards are to be complied with, (such as a formal systems development process) and determining the extent to which compliance is being achieved.
2. For addressing second objective,
· Auditor has to examine system documentation, such as functional specifications, to arrive at an opinion on controls.
· Auditor's opinion will be based on the degree to which the system satisfies the general control objectives that any Information Technology system should meet.
· A list of such objectives should be provided to the auditee.
3. The same is true for the third objective, viz. system's operational controls.
· Auditor should provide the a list of the standard controls, over such operational concerns as response time, CPU usage, and random access space availability, that the auditor has used as assessment criteria.
4. Auditor may adopt a rating system such as on scale of 1 to 10 in order to give rating to the various phases of SDLC.
5. After deriving such a rating for all the phases, the auditor can form his/her overall opinion about the SDLC phases.
6. In order to audit technical work products (such as database design or physical design), auditor may opt to include a technical expert to seek his/her opinion on the technical aspects of SDLC.
7. However, auditor will have to give control objectives, directives and in general validate the opinion expressed by technical experts.
Some of the control considerations for an auditor are:
Documented policy and procedures;
Established Project team with all infrastructure and facilities ;
Developers/ IT managers are trained on the procedures ;
Appropriate approvals are being taken at identified mile-stones;
Development is carried over as per standards, functional specifications;
Separate test environment for development/ test/ production / test plans;
Design norms and naming conventions are as per standards and are adhered to;
Business owners testing and approval before system going live;
Version control on programs;
Source Code is properly secured;
Adequate audit trails are provided in system; and
Appropriateness of methodologies selected.
8. Further, Post-Implementation Review (PIR) is performed to determine whether the system adequately meets earlier identified business requirements and needs (in feasibility studies or Requirements Specifications).
9. Auditors should be able to determine if the expected benefits of the new system were realized and whether users are satisfied with the new system.
10. In PIR, auditors need to review which of the SDLC phases have not met desired objectives and whether any corrective actions were taken.
11. If there are differences between expectations and actual results, auditors need to determine the reasons for the same. E.g. it could be due to incomplete user requirements. Such reasons can help auditors to evaluate the current situation and offer guidelines for future projects.
Master Checklist ( Amendment)
The process objectives are:
· To ensure an appropriate acquisition and / or development of information systems including software, and
· To maintain the information systems in an appropriate manner.