Also there are little changes in Chapter - 2 . But major part is only deletions .
Documented policy and procedures;
Following are the additions :
Chapter 2 – SDLC
Agile Methodologies
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;
© Simplicity;
© Self-organizing teams; and
© Regular adaptation to changing circumstances.
Strengths
© 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.
Weaknesses
© 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.
No comments:
Post a Comment