Consider your school, how do you know that the life cycle was developed specifically for the university. How do we know it meets our needs? at least 2500 words ..
SYSTEMS DEVELOPMENT LIFECYCLE
The systems development life cycle is a project management technique that divides complex projects into smaller, more easily managed segments or phases. Segmenting projects allows managers to verify the successful completion of project phases before allocating resources to subsequent phases.
Software development projects typically include initiation, planning, design, development, testing, implementation, and maintenance phases. However, the phases may be divided differently depending on the organization involved. For example, initial project activities might be designated as request, requirements-definition, and planning phases, or initiation, concept-development, and planning phases. End users of the system under development should be involved in reviewing the output of each phase to ensure the system is being built to deliver the needed functionality.
Note: Examiners should focus their assessments of development, acquisition, and maintenance activities on the effectiveness of an organization’s project management techniques. Reviews should be centered on ensuring the depth, quality, and sophistication of a project management technique are commensurate with the characteristics and risks of the project under review.
INITIATION PHASE
Careful oversight is required to ensure projects support strategic business objectives and resources are effectively implemented into an organization's enterprise architecture. The initiation phase begins when an opportunity to add, improve, or correct a system is identified and formally requested through the presentation of a business case. The business case should, at a minimum, describe a proposal’s purpose, identify expected benefits, and explain how the proposed system supports one of the organization’s business strategies. The business case should also identify alternative solutions and detail as many informational, functional, and network requirements as possible.
The presentation of a business case provides a point for managers to reject a proposal before they allocate resources to a formal feasibility study. When evaluating software development requests (and during subsequent feasibility and design analysis), management should consider input from all affected parties. Management should also closely evaluate the necessity of each requested functional requirement. A single software feature approved during the initiation phase can require several design documents and hundreds of lines of code. It can also increase testing, documentation, and support requirements. Therefore, the initial rejection of unnecessary features can significantly reduce the resources required to complete a project.
If provisional approval to initiate a project is obtained, the request documentation serves as a starting point to conduct a more thorough feasibility study. Completing a feasibility study requires management to verify the accuracy of the preliminary assumptions and identify resource requirements in greater detail.
Primary issues organizations should consider when compiling feasibility study support documentation include:
Business Considerations:
Strategic business and technology goals and objectives;
Expected benefits measured against the value of current technology;
Potential organizational changes regarding facilities or the addition/reduction of end users, technicians, or managers;
Budget, scheduling, or personnel constraints; and
Potential business, regulatory, or legal issues that could impact the feasibility of the project.
Functional Requirements:
End-user functional requirements;
Internal control and information security requirements;
Operating, database, and backup system requirements (type, capacity, performance);
Connectivity requirements (stand-alone, Local Area Network, Wide Area Network, external);
Network support requirements (number of potential users; type, volume, and frequency of data transfers); and
Interface requirements (internal or external applications).
Project Factors:
Project management methodology;
Risk management methodology;
Estimated completion dates of projects and major project phases; and
Estimated costs of projects and major project phases.
Cost/Benefit Analysis:
Expected useful life of the proposed product;
Alternative solutions (buy vs. build);
Nonrecurring project costs (personnel, hardware, software, and overhead);
Recurring operational costs (personnel, maintenance, telecommunications, and overhead);
Tangible benefits (increased revenues, decreased costs, return-on-investments); and
Intangible benefits (improved public opinions or more useful information).
The feasibility support documentation should be compiled and submitted for senior management or board study. The feasibility study document should provide an overview of the proposed project and identify expected costs and benefits in terms of economic, technical, and operational feasibility. The document should also describe alternative solutions and include a recommendation for approval or rejection. The document should be reviewed and signed off on by all affected parties. If approved, management should use the feasibility study and support documentation to begin the planning phase.
PLANNING PHASE
The planning phase is the most critical step in completing development, acquisition, and maintenance projects. Careful planning, particularly in the early stages of a project, is necessary to coordinate activities and manage project risks effectively. The depth and formality of project plans should be commensurate with the characteristics and risks of a given project.
Project plans refine the information gathered during the initiation phase by further identifying the specific activities and resources required to complete a project. A critical part of a project manager’s job is to coordinate discussions between user, audit, security, design, development, and network personnel to identify and document as many functional, security, and network requirements as possible.
Primary items organizations should address in formal project plans include:
Project Overview – Project overviews provide an outline of the project plan. Overviews should identify the project, project sponsors, and project managers; and should describe project goals, background information, and development strategies.
Roles and Responsibilities – Project plans should define the primary responsibilities of key personnel, including project sponsors, managers, and team members. Additionally, project plans should identify the responsibilities of third-party vendors and internal audit, security, and network personnel.
Communication – Defined communication techniques enhance project efficiencies. Therefore, management should establish procedures for gathering and disseminating information. Standard report forms, defined reporting requirements, and established meeting schedules facilitate project communications.
Management should establish acceptance criteria for each project phase. Management should also establish appropriate review and approval procedures to ensure project teams complete all phase requirements before moving into subsequent phases.
Defined Deliverables – Clearly defined expectations are a prerequisite for successfully completing projects. Representatives from all departments involved in, or affected by, a project should assist in defining realistic project objectives, accurate informational, functional, and interface requirements, and objective acceptance criteria.
Control Requirements – An essential part of the planning process involves designing and building automated control and security features into applications. Identifying all required features and exactly where they should be placed is not always possible during initial project phases. However, management should consider security and control issues throughout a project’s life cycle and include those features in applications as soon as possible during a project’s life cycle.
Risk Management – Managing risks is an important part of the project planning process. Organizations should establish procedures to ensure managers appropriately assess, monitor, and manage internal and external risks throughout a project’s life cycle. The procedures should include risk acceptance, mitigation, and/or transfer strategies.
External risks include issues such as vendor failures, regulatory changes, and natural disasters. Internal risks include items that affect budgets, such as inaccurate cost forecasting or changing functional requirements; scheduling difficulties, such as unexpected personnel changes or inaccurate development assumptions; and work flow challenges, such as weak communication or inexperienced project managers
Change Management – Personnel often request the addition or modification of functional requirements during software development projects. Although the addition or modification of requirements may be appropriate, standards should be in place to control changes in order to minimize disruptions to the development process. Project managers should establish cut-off dates after which they defer requested changes to subsequent versions. Additionally, representatives from the same departments involved in establishing requirements should be involved in evaluating and approving proposed changes. Large, complex, or mission-critical projects should include formal change management procedures.
Standards – Project plans should reference applicable standards relating to project oversight activities, system controls, and quality assurance. Oversight standards should address project methodology selections, approval authorities, and risk management procedures. System controls standards should address functional, security, and automated-control requirements. Quality assurance standards should address the validity of project assumptions, adherence to project standards, and testing of a product’s overall performance. Management should review, approve, and document deviations from established standards.
Documentation – Project plans should identify the type and level of documentation personnel must produce during each project phase. For instance, personnel should document project objectives, system requirements, and development strategies during the initiation phase. The documentation should be revised as needed throughout the project. For example, preliminary user, operator, and maintenance manuals created during the design phase should be revised during the development and testing phases, and finalized during the implementation phase.
Scheduling – Management should identify and schedule major project phases and the tasks to be completed within each phase. Due to the uncertainties involved with estimating project requirements, management should build flexibility into project schedules. However, the amount of flexibility built into schedules should decline as projects progress and requirements become more defined.
Budget – Managers should develop initial budget estimations of overall project costs so they can determine if projects are feasible. Managers should monitor the budgets throughout a project and adjust them if needed; however, they should retain a baseline budget for post-project analysis. In addition to budgeting personnel expenses and outsourced activities, it is important to include the costs associated with project overhead such as office space, hardware, and software used during the project.
Testing – Management should develop testing plans that identify testing requirements and schedule testing procedures throughout the initial phases of a project. End users, designers, developers, and system technicians may be involved in the testing process.
Staff Development – Management should develop training plans that identify training requirements and schedule training procedures to ensure employees are able to use and maintain an application after implementation.
DESIGN PHASE
The design phase involves converting the informational, functional, and network requirements identified during the initiation and planning phases into unified design specifications that developers use to script programs during the development phase. Program designs are constructed in various ways. Using a top-down approach, designers first identify and link major program components and interfaces, then expand design layouts as they identify and link smaller subsystems and connections. Using a bottom-up approach, designers first identify and link minor program components and interfaces, then expand design layouts as they identify and link larger systems and connections.
Contemporary design techniques often use prototyping tools that build mock-up designs of items such as application screens, database layouts, and system architectures. End users, designers, developers, database managers, and network administrators should review and refine the prototyped designs in an iterative process until they agree on an acceptable design. Audit, security, and quality assurance personnel should be involved in the review and approval process.
Management should be particularly diligent when using prototyping tools to develop automated controls. Prototyping can enhance an organization’s ability to design, test, and establish controls. However, employees may be inclined to resist adding additional controls, even though they are needed, after the initial designs are established.
Designers should carefully document completed designs. Detailed documentation enhances a programmer’s ability to develop programs and modify them after they are placed in production. The documentation also helps management ensure final programs are consistent with original goals and specifications.
Organizations should create initial testing, conversion, implementation, and training plans during the design phase. Additionally, they should draft user, operator, and maintenance manuals.
DEVELOPMENT PHASE
The development phase involves converting design specifications into executable programs. Effective development standards include requirements that programmers and other project participants discuss design specifications before programming begins. The procedures help ensure programmers clearly understand program designs and functional requirements.
Programmers use various techniques to develop computer programs. The large transaction-oriented programs associated with financial institutions have traditionally been developed using procedural programming techniques. Procedural programming involves the line-by-line scripting of logical instructions that are combined to form a program.
Primary procedural programming activities include the creation and testing of source code and the refinement and finalization of test plans. Typically, individual programmers write and review (desk test) program modules or components, which are small routines that perform a particular task within an application. Completed components are integrated with other components and reviewed, often by a group of programmers, to ensure the components properly interact. The process continues as component groups are progressively integrated and as interfaces between component groups and other systems are tested.
Advancements in programming techniques include the concept of "object-oriented programming." Object-oriented programming centers on the development of reusable program routines (modules) and the classification of data types (numbers, letters, dollars, etc.) and data structures (records, files, tables, etc.). Linking pre-scripted module objects to predefined data-class objects reduces development times and makes programs easier to modify. Refer to the "Software Development Techniques" section for additional information on object-oriented programming.
Organizations should complete testing plans during the development phase. Additionally, they should update conversion, implementation, and training plans and user, operator, and maintenance manuals.
Development Standards
Development standards should be in place to address the responsibilities of application and system programmers. Application programmers are responsible for developing and maintaining end-user applications. System programmers are responsible for developing and maintaining internal and open-source operating system programs that link application programs to system software and subsequently to hardware. Managers should thoroughly understand development and production environments to ensure they appropriately assign programmer responsibilities.
Development standards should prohibit a programmer's access to data, programs, utilities, and systems outside their individual responsibilities. Library controls can be used to manage access to, and the movement of programs between, development, testing, and production environments. Management should also establish standards requiring programmers to document completed programs and test results thoroughly. Appropriate documentation enhances a programmer's ability to correct programming errors and modify production programs.
Coding standards, which address issues such as the selection of programming languages and tools, the layout or format of scripted code, and the naming conventions of code routines and program libraries, are outside the scope of this document. However, standardized, yet flexible, coding standards enhance an organization’s ability to decrease coding defects and increase the security, reliability, and maintainability of application programs. Examiners should evaluate an organization’s coding standards and related code review procedures.
TESTING PHASE
The testing phase requires organizations to complete various tests to ensure the accuracy of programmed code, the inclusion of expected functionality, and the interoperability of applications and other network components. Thorough testing is critical to ensuring systems meet organizational and end-user requirements.
If organizations use effective project management techniques, they will complete test plans while developing applications, prior to entering the testing phase. Weak project management techniques or demands to complete projects quickly may pressure organizations to develop test plans at the start of the testing phase. Test plans created during initial project phases enhance an organization’s ability to create detailed tests. The use of detailed test plans significantly increases the likelihood that testers will identify weaknesses before products are implemented.
Testing groups are comprised of technicians and end users who are responsible for assembling and loading representative test data into a testing environment. The groups typically perform tests in stages, either from a top-down or bottom-up approach. A bottom-up approach tests smaller components first and progressively adds and tests additional components and systems. A top-down approach first tests major components and connections and progressively tests smaller components and connections. The progression and definitions of completed tests vary between organizations.
Bottom-up tests often begin with functional (requirements based) testing. Functional tests should ensure that expected functional, security, and internal control features are present and operating properly. Testers then complete integration and end-to-end testing to ensure application and system components interact properly. Users then conduct acceptance tests to ensure systems meet defined acceptance criteria.
Testers often identify program defects or weaknesses during the testing process. Procedures should be in place to ensure programmers correct defects quickly and document all corrections or modifications. Correcting problems quickly increases testing efficiencies by decreasing testers’ downtime. It also ensures a programmer does not waste time trying to debug a portion of a program without defects that is not working because another programmer has not debugged a defective linked routine. Documenting corrections and modifications is necessary to maintain the integrity of the overall program documentation.
Organizations should review and complete user, operator, and maintenance manuals during the testing phase. Additionally, they should finalize conversion, implementation, and training plans.
IMPLEMENTATION PHASE
The implementation phase involves installing approved applications into production environments. Primary tasks include announcing the implementation schedule, training end users, and installing the product. Additionally, organizations should input and verify data, configure and test system and security parameters, and conduct post-implementation reviews. Management should circulate implementation schedules to all affected parties and should notify users of any implementation responsibilities.
After organizations install a product, pre-existing data is manually input or electronically transferred to a new system. Verifying the accuracy of the input data and security configurations is a critical part of the implementation process. Organizations often run a new system in parallel with an old system until they verify the accuracy and reliability of the new system. Employees should document any programming, procedural, or configuration changes made during the verification process.
PROJECT EVALUATION
Management should conduct post-implementation reviews at the end of a project to validate the completion of project objectives and assess project management activities. Management should interview all personnel actively involved in the operational use of a product and document and address any identified problems.
Management should analyze the effectiveness of project management activities by comparing, among other things, planned and actual costs, benefits, and development times. They should document the results and present them to senior management. Senior management should be informed of any operational or project management deficiencies.
MAINTENANCE PHASE
The maintenance phase involves making changes to hardware, software, and documentation to support its operational effectiveness. It includes making changes to improve a system’s performance, correct problems, enhance security, or address user requirements. To ensure modifications do not disrupt operations or degrade a system’s performance or security, organizations should establish appropriate change management standards and procedures.
Change management (sometimes referred to as configuration management) involves establishing baseline versions of products, services, and procedures and ensuring all changes are approved, documented, and disseminated. Change controls should address all aspects of an organization’s technology environment including software programs, hardware and software configurations, operational standards and procedures, and project management activities. Management should establish change controls that address major, routine, and emergency software modifications and software patches.
Major modifications involve significant changes to a system’s functionality. Management should implement major modifications using a well-structured process, such as an SDLC methodology.
Routine changes are not as complex as major modifications and can usually be implemented in the normal course of business. Routine change controls should include procedures for requesting, evaluating, approving, testing, installing, and documenting software modifications.
Emergency changes may address an issue that would normally be considered routine, however, because of security concerns or processing problems, the changes must be made quickly. Emergency change controls should include the same procedures as routine change controls. Management should establish abbreviated request, evaluation, and approval procedures to ensure they can implement changes quickly. Detailed evaluations and documentation of emergency changes should be completed as soon as possible after changes are implemented. Management should test routine and, whenever possible, emergency changes prior to implementation and quickly notify affected parties of all changes. If management is unable to thoroughly test emergency modifications before installation, it is critical that they appropriately backup files and programs and have established back-out procedures in place.
Software patches are similar in complexity to routine modifications. This document uses the term "patch" to describe program modifications involving externally developed software packages. However, organizations with in-house programming may also refer to routine software modifications as patches. Patch management programs should address procedures for evaluating, approving, testing, installing, and documenting software modifications. However, a critical part of the patch management process involves maintaining an awareness of external vulnerabilities and available patches.
Maintaining accurate, up-to-date hardware and software inventories is a critical part of all change management processes. Management should carefully document all modifications to ensure accurate system inventories.
DISPOSAL PHASE
The disposal phase involves the orderly removal of surplus or obsolete hardware, software, or data. Primary tasks include the transfer, archiving, or destruction of data records. Management should transfer data from production systems in a planned and controlled manner that includes appropriate backup and testing procedures. Organizations should maintain archived data in accordance with applicable record retention requirements. It should also archive system documentation in case it becomes necessary to reinstall a system into production. Management should destroy data by overwriting old information or degaussing (demagnetizing) disks and tapes.
How do you know that the life cycle was developed specifically for the university. How do we know it meets our needs?
We, students of the University, can be able to say that the life cycle is being developed for the school itself since part of USEP goal is to produce globally competitive and morally upright graduates and to develop a strong Research, Development, and Extension culture with competent human resource and responsive and relevant researches that are adopted and utilized for development , which means we are part of the life cycle and that life cycle is our development and product. University mostly lack something that students are discouraged because it seems that the school usually can not provide them all the convenience they needed and hard at their part to agree on the new propose system. For sure, for those in the positions when they are being involved and trained well, I think this things will never be a problem for them. Though there are some difficulties with the part of the university to shift with other new system that they find much harder to use than the latter, still both system's purpose is for the betterment and progress of the school as well as the students. And even there are certain issues like that arises,still, I may say that the school serve me with some the things that I need such as in keeping my records secure and updated.
From the views and opinions I stated above, I therefore concluded that the systems development life cycle existed and will remain part of the school's life cycle for the reason that the steps being considered here is very helpful and efficient tool for the universities development and students progress.
SYSTEMS DEVELOPMENT LIFECYCLE
The systems development life cycle is a project management technique that divides complex projects into smaller, more easily managed segments or phases. Segmenting projects allows managers to verify the successful completion of project phases before allocating resources to subsequent phases.
Software development projects typically include initiation, planning, design, development, testing, implementation, and maintenance phases. However, the phases may be divided differently depending on the organization involved. For example, initial project activities might be designated as request, requirements-definition, and planning phases, or initiation, concept-development, and planning phases. End users of the system under development should be involved in reviewing the output of each phase to ensure the system is being built to deliver the needed functionality.
Note: Examiners should focus their assessments of development, acquisition, and maintenance activities on the effectiveness of an organization’s project management techniques. Reviews should be centered on ensuring the depth, quality, and sophistication of a project management technique are commensurate with the characteristics and risks of the project under review.
INITIATION PHASE
Careful oversight is required to ensure projects support strategic business objectives and resources are effectively implemented into an organization's enterprise architecture. The initiation phase begins when an opportunity to add, improve, or correct a system is identified and formally requested through the presentation of a business case. The business case should, at a minimum, describe a proposal’s purpose, identify expected benefits, and explain how the proposed system supports one of the organization’s business strategies. The business case should also identify alternative solutions and detail as many informational, functional, and network requirements as possible.
The presentation of a business case provides a point for managers to reject a proposal before they allocate resources to a formal feasibility study. When evaluating software development requests (and during subsequent feasibility and design analysis), management should consider input from all affected parties. Management should also closely evaluate the necessity of each requested functional requirement. A single software feature approved during the initiation phase can require several design documents and hundreds of lines of code. It can also increase testing, documentation, and support requirements. Therefore, the initial rejection of unnecessary features can significantly reduce the resources required to complete a project.
If provisional approval to initiate a project is obtained, the request documentation serves as a starting point to conduct a more thorough feasibility study. Completing a feasibility study requires management to verify the accuracy of the preliminary assumptions and identify resource requirements in greater detail.
Primary issues organizations should consider when compiling feasibility study support documentation include:
Business Considerations:
Strategic business and technology goals and objectives;
Expected benefits measured against the value of current technology;
Potential organizational changes regarding facilities or the addition/reduction of end users, technicians, or managers;
Budget, scheduling, or personnel constraints; and
Potential business, regulatory, or legal issues that could impact the feasibility of the project.
Functional Requirements:
End-user functional requirements;
Internal control and information security requirements;
Operating, database, and backup system requirements (type, capacity, performance);
Connectivity requirements (stand-alone, Local Area Network, Wide Area Network, external);
Network support requirements (number of potential users; type, volume, and frequency of data transfers); and
Interface requirements (internal or external applications).
Project Factors:
Project management methodology;
Risk management methodology;
Estimated completion dates of projects and major project phases; and
Estimated costs of projects and major project phases.
Cost/Benefit Analysis:
Expected useful life of the proposed product;
Alternative solutions (buy vs. build);
Nonrecurring project costs (personnel, hardware, software, and overhead);
Recurring operational costs (personnel, maintenance, telecommunications, and overhead);
Tangible benefits (increased revenues, decreased costs, return-on-investments); and
Intangible benefits (improved public opinions or more useful information).
The feasibility support documentation should be compiled and submitted for senior management or board study. The feasibility study document should provide an overview of the proposed project and identify expected costs and benefits in terms of economic, technical, and operational feasibility. The document should also describe alternative solutions and include a recommendation for approval or rejection. The document should be reviewed and signed off on by all affected parties. If approved, management should use the feasibility study and support documentation to begin the planning phase.
PLANNING PHASE
The planning phase is the most critical step in completing development, acquisition, and maintenance projects. Careful planning, particularly in the early stages of a project, is necessary to coordinate activities and manage project risks effectively. The depth and formality of project plans should be commensurate with the characteristics and risks of a given project.
Project plans refine the information gathered during the initiation phase by further identifying the specific activities and resources required to complete a project. A critical part of a project manager’s job is to coordinate discussions between user, audit, security, design, development, and network personnel to identify and document as many functional, security, and network requirements as possible.
Primary items organizations should address in formal project plans include:
Project Overview – Project overviews provide an outline of the project plan. Overviews should identify the project, project sponsors, and project managers; and should describe project goals, background information, and development strategies.
Roles and Responsibilities – Project plans should define the primary responsibilities of key personnel, including project sponsors, managers, and team members. Additionally, project plans should identify the responsibilities of third-party vendors and internal audit, security, and network personnel.
Communication – Defined communication techniques enhance project efficiencies. Therefore, management should establish procedures for gathering and disseminating information. Standard report forms, defined reporting requirements, and established meeting schedules facilitate project communications.
Management should establish acceptance criteria for each project phase. Management should also establish appropriate review and approval procedures to ensure project teams complete all phase requirements before moving into subsequent phases.
Defined Deliverables – Clearly defined expectations are a prerequisite for successfully completing projects. Representatives from all departments involved in, or affected by, a project should assist in defining realistic project objectives, accurate informational, functional, and interface requirements, and objective acceptance criteria.
Control Requirements – An essential part of the planning process involves designing and building automated control and security features into applications. Identifying all required features and exactly where they should be placed is not always possible during initial project phases. However, management should consider security and control issues throughout a project’s life cycle and include those features in applications as soon as possible during a project’s life cycle.
Risk Management – Managing risks is an important part of the project planning process. Organizations should establish procedures to ensure managers appropriately assess, monitor, and manage internal and external risks throughout a project’s life cycle. The procedures should include risk acceptance, mitigation, and/or transfer strategies.
External risks include issues such as vendor failures, regulatory changes, and natural disasters. Internal risks include items that affect budgets, such as inaccurate cost forecasting or changing functional requirements; scheduling difficulties, such as unexpected personnel changes or inaccurate development assumptions; and work flow challenges, such as weak communication or inexperienced project managers
Change Management – Personnel often request the addition or modification of functional requirements during software development projects. Although the addition or modification of requirements may be appropriate, standards should be in place to control changes in order to minimize disruptions to the development process. Project managers should establish cut-off dates after which they defer requested changes to subsequent versions. Additionally, representatives from the same departments involved in establishing requirements should be involved in evaluating and approving proposed changes. Large, complex, or mission-critical projects should include formal change management procedures.
Standards – Project plans should reference applicable standards relating to project oversight activities, system controls, and quality assurance. Oversight standards should address project methodology selections, approval authorities, and risk management procedures. System controls standards should address functional, security, and automated-control requirements. Quality assurance standards should address the validity of project assumptions, adherence to project standards, and testing of a product’s overall performance. Management should review, approve, and document deviations from established standards.
Documentation – Project plans should identify the type and level of documentation personnel must produce during each project phase. For instance, personnel should document project objectives, system requirements, and development strategies during the initiation phase. The documentation should be revised as needed throughout the project. For example, preliminary user, operator, and maintenance manuals created during the design phase should be revised during the development and testing phases, and finalized during the implementation phase.
Scheduling – Management should identify and schedule major project phases and the tasks to be completed within each phase. Due to the uncertainties involved with estimating project requirements, management should build flexibility into project schedules. However, the amount of flexibility built into schedules should decline as projects progress and requirements become more defined.
Budget – Managers should develop initial budget estimations of overall project costs so they can determine if projects are feasible. Managers should monitor the budgets throughout a project and adjust them if needed; however, they should retain a baseline budget for post-project analysis. In addition to budgeting personnel expenses and outsourced activities, it is important to include the costs associated with project overhead such as office space, hardware, and software used during the project.
Testing – Management should develop testing plans that identify testing requirements and schedule testing procedures throughout the initial phases of a project. End users, designers, developers, and system technicians may be involved in the testing process.
Staff Development – Management should develop training plans that identify training requirements and schedule training procedures to ensure employees are able to use and maintain an application after implementation.
DESIGN PHASE
The design phase involves converting the informational, functional, and network requirements identified during the initiation and planning phases into unified design specifications that developers use to script programs during the development phase. Program designs are constructed in various ways. Using a top-down approach, designers first identify and link major program components and interfaces, then expand design layouts as they identify and link smaller subsystems and connections. Using a bottom-up approach, designers first identify and link minor program components and interfaces, then expand design layouts as they identify and link larger systems and connections.
Contemporary design techniques often use prototyping tools that build mock-up designs of items such as application screens, database layouts, and system architectures. End users, designers, developers, database managers, and network administrators should review and refine the prototyped designs in an iterative process until they agree on an acceptable design. Audit, security, and quality assurance personnel should be involved in the review and approval process.
Management should be particularly diligent when using prototyping tools to develop automated controls. Prototyping can enhance an organization’s ability to design, test, and establish controls. However, employees may be inclined to resist adding additional controls, even though they are needed, after the initial designs are established.
Designers should carefully document completed designs. Detailed documentation enhances a programmer’s ability to develop programs and modify them after they are placed in production. The documentation also helps management ensure final programs are consistent with original goals and specifications.
Organizations should create initial testing, conversion, implementation, and training plans during the design phase. Additionally, they should draft user, operator, and maintenance manuals.
DEVELOPMENT PHASE
The development phase involves converting design specifications into executable programs. Effective development standards include requirements that programmers and other project participants discuss design specifications before programming begins. The procedures help ensure programmers clearly understand program designs and functional requirements.
Programmers use various techniques to develop computer programs. The large transaction-oriented programs associated with financial institutions have traditionally been developed using procedural programming techniques. Procedural programming involves the line-by-line scripting of logical instructions that are combined to form a program.
Primary procedural programming activities include the creation and testing of source code and the refinement and finalization of test plans. Typically, individual programmers write and review (desk test) program modules or components, which are small routines that perform a particular task within an application. Completed components are integrated with other components and reviewed, often by a group of programmers, to ensure the components properly interact. The process continues as component groups are progressively integrated and as interfaces between component groups and other systems are tested.
Advancements in programming techniques include the concept of "object-oriented programming." Object-oriented programming centers on the development of reusable program routines (modules) and the classification of data types (numbers, letters, dollars, etc.) and data structures (records, files, tables, etc.). Linking pre-scripted module objects to predefined data-class objects reduces development times and makes programs easier to modify. Refer to the "Software Development Techniques" section for additional information on object-oriented programming.
Organizations should complete testing plans during the development phase. Additionally, they should update conversion, implementation, and training plans and user, operator, and maintenance manuals.
Development Standards
Development standards should be in place to address the responsibilities of application and system programmers. Application programmers are responsible for developing and maintaining end-user applications. System programmers are responsible for developing and maintaining internal and open-source operating system programs that link application programs to system software and subsequently to hardware. Managers should thoroughly understand development and production environments to ensure they appropriately assign programmer responsibilities.
Development standards should prohibit a programmer's access to data, programs, utilities, and systems outside their individual responsibilities. Library controls can be used to manage access to, and the movement of programs between, development, testing, and production environments. Management should also establish standards requiring programmers to document completed programs and test results thoroughly. Appropriate documentation enhances a programmer's ability to correct programming errors and modify production programs.
Coding standards, which address issues such as the selection of programming languages and tools, the layout or format of scripted code, and the naming conventions of code routines and program libraries, are outside the scope of this document. However, standardized, yet flexible, coding standards enhance an organization’s ability to decrease coding defects and increase the security, reliability, and maintainability of application programs. Examiners should evaluate an organization’s coding standards and related code review procedures.
TESTING PHASE
The testing phase requires organizations to complete various tests to ensure the accuracy of programmed code, the inclusion of expected functionality, and the interoperability of applications and other network components. Thorough testing is critical to ensuring systems meet organizational and end-user requirements.
If organizations use effective project management techniques, they will complete test plans while developing applications, prior to entering the testing phase. Weak project management techniques or demands to complete projects quickly may pressure organizations to develop test plans at the start of the testing phase. Test plans created during initial project phases enhance an organization’s ability to create detailed tests. The use of detailed test plans significantly increases the likelihood that testers will identify weaknesses before products are implemented.
Testing groups are comprised of technicians and end users who are responsible for assembling and loading representative test data into a testing environment. The groups typically perform tests in stages, either from a top-down or bottom-up approach. A bottom-up approach tests smaller components first and progressively adds and tests additional components and systems. A top-down approach first tests major components and connections and progressively tests smaller components and connections. The progression and definitions of completed tests vary between organizations.
Bottom-up tests often begin with functional (requirements based) testing. Functional tests should ensure that expected functional, security, and internal control features are present and operating properly. Testers then complete integration and end-to-end testing to ensure application and system components interact properly. Users then conduct acceptance tests to ensure systems meet defined acceptance criteria.
Testers often identify program defects or weaknesses during the testing process. Procedures should be in place to ensure programmers correct defects quickly and document all corrections or modifications. Correcting problems quickly increases testing efficiencies by decreasing testers’ downtime. It also ensures a programmer does not waste time trying to debug a portion of a program without defects that is not working because another programmer has not debugged a defective linked routine. Documenting corrections and modifications is necessary to maintain the integrity of the overall program documentation.
Organizations should review and complete user, operator, and maintenance manuals during the testing phase. Additionally, they should finalize conversion, implementation, and training plans.
IMPLEMENTATION PHASE
The implementation phase involves installing approved applications into production environments. Primary tasks include announcing the implementation schedule, training end users, and installing the product. Additionally, organizations should input and verify data, configure and test system and security parameters, and conduct post-implementation reviews. Management should circulate implementation schedules to all affected parties and should notify users of any implementation responsibilities.
After organizations install a product, pre-existing data is manually input or electronically transferred to a new system. Verifying the accuracy of the input data and security configurations is a critical part of the implementation process. Organizations often run a new system in parallel with an old system until they verify the accuracy and reliability of the new system. Employees should document any programming, procedural, or configuration changes made during the verification process.
PROJECT EVALUATION
Management should conduct post-implementation reviews at the end of a project to validate the completion of project objectives and assess project management activities. Management should interview all personnel actively involved in the operational use of a product and document and address any identified problems.
Management should analyze the effectiveness of project management activities by comparing, among other things, planned and actual costs, benefits, and development times. They should document the results and present them to senior management. Senior management should be informed of any operational or project management deficiencies.
MAINTENANCE PHASE
The maintenance phase involves making changes to hardware, software, and documentation to support its operational effectiveness. It includes making changes to improve a system’s performance, correct problems, enhance security, or address user requirements. To ensure modifications do not disrupt operations or degrade a system’s performance or security, organizations should establish appropriate change management standards and procedures.
Change management (sometimes referred to as configuration management) involves establishing baseline versions of products, services, and procedures and ensuring all changes are approved, documented, and disseminated. Change controls should address all aspects of an organization’s technology environment including software programs, hardware and software configurations, operational standards and procedures, and project management activities. Management should establish change controls that address major, routine, and emergency software modifications and software patches.
Major modifications involve significant changes to a system’s functionality. Management should implement major modifications using a well-structured process, such as an SDLC methodology.
Routine changes are not as complex as major modifications and can usually be implemented in the normal course of business. Routine change controls should include procedures for requesting, evaluating, approving, testing, installing, and documenting software modifications.
Emergency changes may address an issue that would normally be considered routine, however, because of security concerns or processing problems, the changes must be made quickly. Emergency change controls should include the same procedures as routine change controls. Management should establish abbreviated request, evaluation, and approval procedures to ensure they can implement changes quickly. Detailed evaluations and documentation of emergency changes should be completed as soon as possible after changes are implemented. Management should test routine and, whenever possible, emergency changes prior to implementation and quickly notify affected parties of all changes. If management is unable to thoroughly test emergency modifications before installation, it is critical that they appropriately backup files and programs and have established back-out procedures in place.
Software patches are similar in complexity to routine modifications. This document uses the term "patch" to describe program modifications involving externally developed software packages. However, organizations with in-house programming may also refer to routine software modifications as patches. Patch management programs should address procedures for evaluating, approving, testing, installing, and documenting software modifications. However, a critical part of the patch management process involves maintaining an awareness of external vulnerabilities and available patches.
Maintaining accurate, up-to-date hardware and software inventories is a critical part of all change management processes. Management should carefully document all modifications to ensure accurate system inventories.
DISPOSAL PHASE
The disposal phase involves the orderly removal of surplus or obsolete hardware, software, or data. Primary tasks include the transfer, archiving, or destruction of data records. Management should transfer data from production systems in a planned and controlled manner that includes appropriate backup and testing procedures. Organizations should maintain archived data in accordance with applicable record retention requirements. It should also archive system documentation in case it becomes necessary to reinstall a system into production. Management should destroy data by overwriting old information or degaussing (demagnetizing) disks and tapes.
How do you know that the life cycle was developed specifically for the university. How do we know it meets our needs?
We, students of the University, can be able to say that the life cycle is being developed for the school itself since part of USEP goal is to produce globally competitive and morally upright graduates and to develop a strong Research, Development, and Extension culture with competent human resource and responsive and relevant researches that are adopted and utilized for development , which means we are part of the life cycle and that life cycle is our development and product. University mostly lack something that students are discouraged because it seems that the school usually can not provide them all the convenience they needed and hard at their part to agree on the new propose system. For sure, for those in the positions when they are being involved and trained well, I think this things will never be a problem for them. Though there are some difficulties with the part of the university to shift with other new system that they find much harder to use than the latter, still both system's purpose is for the betterment and progress of the school as well as the students. And even there are certain issues like that arises,still, I may say that the school serve me with some the things that I need such as in keeping my records secure and updated.
From the views and opinions I stated above, I therefore concluded that the systems development life cycle existed and will remain part of the school's life cycle for the reason that the steps being considered here is very helpful and efficient tool for the universities development and students progress.
