0% found this document useful (0 votes)
16 views1 page

A4 - 1

The document outlines standards for systems development life cycle (SDLC) processes including documentation of SDLC methodology, management and controls, testing standards, change control approval, documentation and emergency procedures.

Uploaded by

saqib hussain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
16 views1 page

A4 - 1

The document outlines standards for systems development life cycle (SDLC) processes including documentation of SDLC methodology, management and controls, testing standards, change control approval, documentation and emergency procedures.

Uploaded by

saqib hussain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Following are the standards which we are going to follow for the development of new

projects

· Systems Development Life Cycle (SDLC) Standards and Procedures

· SDLC Management and Controls

· SDLC Documentation

· Testing Standards

· Change Control Approval

· Change Control Documentation

· Emergency Change Control Procedures

Introduction:

Systems development is the process of defining, designing, testing, and implementing a


new software application or program. It could include the internal development of
customized systems, the creation of database systems, or the acquisition of third party
developed software. Written standards and procedures must guide all information
systems processing functions. The organization’s management must define and
implement standards and adopt an appropriate system development life cycle
methodology governing the process of developing, acquiring, implementing, and
maintaining computerized information systems and related technology.

Systems Development Life Cycle (SDLC) Standards and Procedures

Establish written standards and procedures for systems development and maintenance
for the systems to be developed, acquired, implemented, and maintained. Review SDLC
methodology to ensure that its provisions reflect current generally accepted techniques
and procedures.

Reason: SDLC documented standards and procedures ensure a consistent approach


and controls are maintained throughout a systems or application development process.

SDLC Management and Controls

Ensure adequate SDLC management processes and controls exist. Essential


management processes and controls over the system development (project) process
include:

• Appropriate strategic planning for projects within the IT short- and long-term plans,
including authorization and reporting requirements from senior management to the
board;

• Periodic reporting to the board on project status and target completion;

• Requirements for internal audit involvement in mission critical projects; and,

• Requirements for security officer/team involvement regarding security controls.

Reason: Appropriate management processes and controls over the systems


development process ensures efficient use of resources and minimizes risk(s) within
systems development and programming activities. A general systems development or
project management framework defines the scope and boundaries of managing
projects, as well as the SDLC or project management methodology to be adopted and
applied. Automated project planning, monitoring, and production software aids help
control and facilitate the systems development process. Periodic reporting to senior
management and the board as well as auditor and security officer involvement enables
controls to be considered during the development process prior to implementation into
production.

SDLC Documentation

Develop and maintain a well-documented SDLC for all system and application
development processes. At a minimum, the SDLC documentation will include:

• Project initiation (planning);

• Requirements definition (analysis);

• System design;

• System development;

• Testing;

• Implementation and support;

Reason: Minimum SDLC standards should ensure that project development is


sufficiently controlled to ensure the integrity of the system and IT infrastructure. The
development process may differ depending on the method used (prototyping, rapid
application development, waterfall, etc.). The process should be flexible while providing
maintenance of system integrity and internal controls.

Testing Standards

Document testing standards and procedures. Standard testing procedures include:

• A documented test plan;

• Types of tests to be used (e.g., unit, parallel, user test, regression);

• A restriction of the use of live files in testing to prevent destruction or alteration of live
data;

• Simulated error conditions to ensure that the program effectively handles all
situations; and

• Independent verification, documentation, and retention of test results.

Reason: Testing standards and procedures must be documented to ensure consistency


and data integrity during the testing process. The testing phase is designed to prove
the reliability of the application or system. Testing is performed in an isolated
environment to ensure that new programs do not adversely impact existing production
systems. Testing ensures that data will be processed correctly and reliable output will
be produced in the desired format.

Change Control Approval

Document standards for managing changes (Change Control) to an existing information


systems infrastructure. The Change Control process includes:

• Specification of change;

• Approval for access to source code;

• Programmer completion of change;

• Request and approval to move source code into the test environment;

• Completion of acceptance testing by business unit owner;

• Request and approval for compilation and move to production; and

• Determination and acceptance of overall and specific security impact.

Reason: Change management procedures must be documented and followed in order to


minimize the likelihood of system disruption, unauthorized alterations, and errors to the
existing IT infrastructure.

Change Control Documentation

Document the process for modifying information systems programs. Change Control
documentation includes:

• Change request date;

• Person(s) requesting;

• Change request approval;

• Change request approval and acceptance (Management and business users);

• Documentation revision date;

• Quality assurance approval;

• Final business unit owner acceptance and approval; and

• Date moved into production.

Reason: Change control documentation is necessary to ensure management and users


are aware of changes being made to the existing IT infrastructure. Documentation is
also necessary to ensure appropriate segregation of duties between production,
application, and operation staff.

Emergency Change Control Procedures

Document and control Emergency Program Changes. Control procedures include:

• Approval by supervisory personnel;

• Review of changes by a knowledgeable supervisor if the source code is changed;

• A form used to identify the change, indicate the reason(s) for the emergency change,
identify who made the change, record the date the change was made, and document
the authorization signature(s); and

• Completion of normal management procedures after the emergency change is made.

Reason: Occasionally the need for program change arises that must bypass normal
change procedures. Such a change might be required to restore production processing.
These immediate (emergency) changes are usually called patches, quick fixes, program
temporary fixes, or temporary program changes. The use of such techniques should be
strictly controlled to prevent unauthorized changes and to ensure that approved
changes are made correctly.

If we receive any change request or WRICEF we will follow these standards.

1. Change requests should be prioritized based on their impact on the system and the
business.

2. Change requests should be well-documented, including a clear description of the


problem, the proposed solution, and any relevant information such as test results or
user feedback.

3. Change requests should be reviewed and approved by relevant stakeholders before


they are implemented.

4. Changes to the software should be tracked and managed using a version control
system to ensure that changes can be easily rolled back if necessary.

5. Changes should be thoroughly tested before they are deployed to production to


ensure that they do not introduce new bugs or negatively impact the system's
performance.

6. There should be a clear communication plan to inform stakeholders of the progress of


change request and its implementation.

7. The name of the person or team requesting the change and their contact information.

8. Signature or approval from appropriate parties, such as project managers,


development leads, and stakeholders.

9. Identification of the resources required to implement the change.

10. Impact analysis, including any potential risks or drawbacks of the proposed change.

11. Change requests are typically reviewed and approved by a designated group or
individual before being implemented.

These standards help ensure that changes to software systems are well-planned,
coordinated, and thoroughly evaluated before being implemented.

For the change request we will follow the below mentioned steps.

You might also like