System Development and Change Management Flashcards
What is change management?
the policies, procedures, and resources employed to govern change in an organization; these changes may be initiated from within the organization or imposed from sources outside the organization, but they will usually have an impact on IT infrastructure and governance no matter the source
a robust change management process is a key component for successfully ensuring that an organization can keep up with changing needs without losing the ability to operate or achieve its strategic objectives
Fact: a key component of change management is identifying the potential risks that could arise as a result of the change; these risks are present in all steps of change from acquisition to implementation and can affect existing systems, processes, and employees
selecting and acquiring new IT resources is a fundamental area in which risks exist in the change management process; examples of selection and acquisition risks include: lack of expertise, lack of formal selection and acquisition process, and software/hardware vulnerability and incompatibility
once the software has been selected and acquired, it must be integrated into existed systems and processes; examples of integration risks include: user resistance, lack of management support, lack of stakeholder support, resource concerns, business disruption, lack of system integration, and compliance risk
when planning a significant IT change or system upgrade, some organizations choose to outsource the change management process; examples of outsourcing risks include: lack of organizational knowledge, uncertainty of the third party’s knowledge and management, failure of the third party delivering, lack of security, lack of quality, unexpected costs, and lack of key performance indicators (KPI)
Fact: once all risks in the change management process have been identified, controls are designed to minimize the possibility that the inherent risks will cause business disruptions or negatively impact IT systems
change management controls that should be considered when implementing new systems include the following: policies and procedures, emergency change policies, standardized change requests, impact assessments, authorization, separation of duties, conversion controls, reversion access, pre-implementation testing, post-implementation testing, and ongoing monitoring
organizations may acquire a new system or choose to develop a new system in-house; both processes have their own risks and concerns but still follow the general systems development life cycle (SDLC)
What is the Waterfall Model?
the systems development life cycle provides a model for organizations to create, modify, or acquire information systems to meet the needs of organizations and their users; the SDLC guides an organization through seven key steps: plan, analyze, design, develop, test, deploy, and maintain
the waterfall model is characterized by different teams of employees performing separate tasks in sequence, with each team beginning work from the prewritten authoritative agreement of the preceding team and then ending work when the business requirements for the team have been met; the project then passes to the next team
Deeper dive into the 7 key steps of the waterfall model
plan - during the planning phase, the organization evaluates the need for a new or improved information system
analyze - during the analysis phase, information is gathered from all vital stakeholders to comprehensively compile and analyze all the needs of the end users to establish specific and detailed goals to be accomplished by the project; this will enable the project team to have a clear understanding of the system requirements
design - using the information gathered during the planning and analysis phases, the project team will then start designing the system to meet the agreed-upon user needs; the design phase can be subdivided into 3 parts: conceptual design (broad translation of business requirements into technical requirements), logical design (hardware and software specifications), and physical design (more granular platform and product specifications)
develop - the technical implementation plan created in prior phases is executed in the development step
test - the system is checked for adherence to the business requirements in the testing step
deploy - after the system has been fully vetted and tested, the organization will choose and document an implementation strategy to deliver the system to end users; there are several methods available for deployment that depend on available time, cost, and the cost of failure to the business:
plunge or big bang = the entire new system is immediately delivered to all users and customers (lowest cost, highest risk)
ramped (rolling, phased) conversion = portions of the new system replace corresponding parts of the old system, one piece at a time (above-average cost, below-average risk)
A/B testing (pilot, canary) = a subset of users gets the new system while the old system is still in use and assigned to current and new users or customers; after successful deployment to the subset of users, the new system is deployed to the remaining users (average cost, average risk)
blue/green (or other pair of colors) or shadow = the new system is fully deployed in parallel with the old system; a routing layer directs progressively more duplicated traffic to the new system; once the new system is handling all the traffic, the old system is deactivated (highest cost, lowest risk)
maintain - ongoing adjustments and improvements occur during the maintenance stage, which begins as soon as deployment is complete
What is the Agile Method?
the agile framework was created to address issues with the waterfall model; agile is characterized by cross-functional teams, each dedicated to particular functions or improvements of a system drawn from a prioritized list of the customer’s remaining needs for the system
frequent, short meetings are required, and features are kept small enough to be accomplished by teams during each spring (usually two weeks) before the team moves on to the next feature; communications between teams, within teams, and with customers is crucial in an agile environment as the priority list and project backlog constantly change
Fact: when going through the systems development life cycle, an organization will face many risks
these risks can be paramount for the project because they can cause delays, inefficiencies, and wasted resources; these risks are: resource risk, scheduling risk, technical risk, project management risk, and user resistance risk
What are legacy systems?
outdated technology or systems already in service (sometimes the first system ever established) within an organization; maintaining legacy systems is still common at many organizations due to a number of factors, such as comfort with existing systems and unwillingness to pay for upgrades; however, the benefits of maintaining a legacy system vs phasing it out and replacing it usually do not outweigh the risks of keeping the system
reasons for persistence of legacy systems: costs, time, user resistance, features and customization, and risk of information loss
risks of legacy systems: security vulnerability, lack of vendor support, compatibility issues, and ack of efficiency and effectiveness
mitigating risks of legacy systems: isolating the system, hardening, virtual patches, and monitoring
Fact: establishing an ongoing testing plan for information technology is necessary to discover any problem or functional issues; testing should involve the acquired software, any developed software, and the change management process
due to the complex nature of systems development, a need exists for a variety of types of systems testing; an effective testing strategy includes automated, manual, and exploratory tests to efficiently reduce risk and optimize the release of a system at different stages of its development; the testing process works from the smallest units of the stem to eventual full system testing by end users; this sequence is typically as follows:
step 1: unit testing - testing the smallest level of code or software program
step 2: integration testing - testing the combination of two or more units of code or a program
step 3: system testing - testing the system as a whole once all parts have been combined
step 4: acceptance testing - testing to see if the system works for users as intended and meets all requirements
What are system tests?
they evaluate the system as a whole; once all components are integrated, the application as a whole is tested rigorously to determine whether it meets the functional and technical specifications in addition to any specified quality standards; the application is tested in an environment that is very close to the production environment in which the application will be deployed; system testing enables quality assurance (QA) processes and personnel to test, verify, and validate the business requirements as well as the application architecture; this type of testing on many forms including:
functional tests - focus on testing the functions performed by the system; realistic business scenarios are run though the system to validate that they are working effectively and efficiently
black-box testing - there is little information about how the product is designed; instead of focusing on design, testers focus on the end user’s perspective by evaluating interfaces and features in the same manner as an end user
white-box testing - involves evaluating a system from a design perspective, with a focus on code and its design improvement as opposed to testing functionality
gray-box testing - combines both black-box and white-box testing techniques; while evaluating user interfaces, the tester has access to source code but does not analyze it; when the tester evaluates the design of the system, that person focuses on the logical structure of the program instead of functionality
exploratory tests - are utilized for the less-common or exception-based situations with no specified test cases
performance testing - designed to test the run-time (speed) performance of software when processing the required workload
recovery testing - checks the system’s ability to recover from failures
security testing - verifies that system protection mechanisms prevent improper penetration or data alteration and validate that authorized access levels function properly
regression tests - rerun previous test cases within the entire application after new features or functionalities have been incorporated; this is to determine whether the new features caused any breaks or modifications to functionality
stress testing - the program is checked to see how well it deals with abnormal and/or extreme resource demands (quantity, frequency, or volume)
sanity testing - exercises the logical reasoning and behavior of the software to determine whether system logic is functioning as designed
What are acceptance tests?
they determine whether the software works correctly for the intended user in the normal work environment; this is arguably the most important type of testing, as it is conducted by a QA team that gauges whether the application meets the intended specifications and satisfies the client’s requirements; the QA team has a set of prewritten scenarios and test cases that are used to test the application
alpha test - the initial version of the completed software is tested by the customer under the supervision of the developer at the developer’s site
beta test - the later version of the compete software is tested by the customer at their own site without the developer being present
T/F: testing of the change management process and controls generally occur both within the organization (compliance, management review, and internal audit) and outside the organization (regulators and external auditors)
True
