System Devlopmet And Change Management Flashcards
Describes the policy, procedures, and resources deployed to govern change in an organization. Can be initiated within the organization, or circumstances outside of the organization have compelled us to change.
Change management
Selecting and acquiring new IT resources is an area where risk exists in the change management process, examples of risks here include:
Lack of expertise
Lack of formal selection and application process
Software/hardware vulnerability and incompatibility
Integration risks exist under change management and examples of this risk include:
Resistance of adoption Lack of management support Lack of stakeholder support Resource concerns Business disruption Lack of system integration Compliance risk
Outsourcing risks exist under change management, examples of these risks include:
Lack of organizational knowledge
Uncertainty of the third party’s knowledge and management
Failure of the third party to deliver
Lack of security
Lack of quality
Unexpected costs
Lack of key performance indicators (KPIs)
Controls are implemented to decrease the inherent selection & acquisition risks, integration risks, and outsourcing risks. What are some example of controls that could be implemented to reduce these risks?
Policies and procedures Emergency change policies Standardized change requests Impact assessment Authorization Separation of duties Conversion controls (minimize data conversion errors) Reversion access Pre-implementation testing Post-implementation testing Ongoing monitoring
The system development life cycle guides an organization through seven steps:
Plan Analyze Design Develop Test Deploy Maintain
The waterfall model is used with the system development life cycle to
Guide different teams of employees performing separate tasks in sequence with each team beginning work from the prewritten authoritative agreement from the preceding team.
Drawbacks: requires a lot of time; benefits aren’t realized until process is complete; no customer input; change is difficult to manage; employees may be idle before beginning or after completing their step in the process.
How does the plunge or big band method of deployment work?
The entire new system is immediately delivered to users (lowest cost and highest risk)
How does the ramped conversion / rolling conversion method of deployment work?
Portions of the new system replace corresponding parts of the old system (above average cost, below average risk)
How does the A/B Testing (Pilot) deployment method work?
A few users get the new system while old systems are still in use with other users. After successful deployment to the few users, the new system is deployed to remaining users. (Average cost and average risk)
How does the Blue/Green or Shadow method of deployment work?
The new system is fully deployed in parallel with the old system while a routing layer directs progressively more duplicated traffic to the new system (highest cost, lowest risk)
To help address issues developed with the waterfall method, this system was developed to use cross-functional teams each dedicated to particular functions that are small enough to tackle in short periods of time:
Agile method
When working through the system development lifecycle, risks are expected. Some examples of risks that arise are:
Resource risk Scheduling risk Technical risk Project management risk User resistance risk
Outdated technology or systems already in service
Legacy systems
A lot of risks surround maintaining a legacy system rather than implementing a new system, examples of these risks include:
Security vulnerability
Lack of vendor support
Compatibility issues
Lack of efficiency and effectiveness
A company can mitigate some of the risks legacy systems create, some examples of mitigating these risks include:
Isolate the legacy system from other systems
Hardening (turning off unnecessary features of the legacy system to reduce exposure)
Virtual patches(applied at the network level before reaching the legacy)
Monitoring
Examples of testing strategies to use for new system development:
Unit testing - testing the smallest level of code or software program
Integration testing - testing the combination of two or more units of a code or program
System testing - testing the system as a whole once all parts are combined
Acceptance testing - testing to see if the system works for users as intended
Some tests that go into system tests (testing a system as a whole after parts have been combined) include:
Functional test - validate real business scenarios
Black box testing - focus only on the end user’s perspective
White box testing - focus only on the design/code perspective
Grey box testing - combines both black and white box testing
Exploratory tests
Performance testing - run time/speed of software
Recovery testing
Security testing
Regression test - determine if new features break functionality
Stress testing
Sanity testing - logic working as designed
A type of acceptance test where the initial version of the completed software is tested by the customer under the supervision of the developer at the developer’s site
Alpha test
A type of acceptance test where the later version of the complete software is tested by the customer at their own site without the developer present
Beta test
