MIS 330 Final Review
Maintenance & Operations
- Operations - Maintenance - Disposal - Upgrades
Systems Development Life Cycle
- Planning - Analysis - Design - Implementation - Maintenance & Operations
Planning
- Project Authorization - Scope - Budget - Schedule - Requirements Gathering
Evidence You Need to Provide
- Tangible - Tangible and Intangible - Intangible Evidence needed
Quantification Evaluation Steps (1/6)
*Step 1: Understand the client's business environment*
Quantification Evaluation Steps (2/6)
*Step 2: Determine and Quantify the AS-IS (current) process*
Quantification Evaluation Steps (3/6)
*Step 3: Determine a case for change & Quantify an estimated TO-BE (new/better) process*
Quantification Evaluation Steps (4/6)
*Step 4: Receive Approval; Then Design, Develop, Implement (and Test!) the TO-BE process*
Quantification Evaluation Steps (5/6)
*Step 5: Determine & Quantify the impact (hopefully positive) of the new (TO-BE) process* - Take the same measurement and document
Quantification Evaluation Steps (6/6)
*Step 6: Compare the AS-IS with the TO-BE process, and see if there is POSITIVE change*
Design
- Architecture - User Interface - Administration Interface - Use Case Walkthroughs - Improvement
Implementation
- Development - Testing - Training - Transition - Observation
Analysis
-Requirements Analysis - Process Modeling & Use Cases - Quantification - Process Improvement - Requirements IV & V & Determination - Risk & Response - Feasibility Determination
Project Management Areas
1. Scope 2. Schedule 3. Cost 4. Quality 5. Risk 6. Communications 7. Human Resources 8. Procurement 9. Stakeholder - The Project Manager plays the role of Integrator for these 9 areas
Build or Buy Decision
o Would you build: ▪ Accounting Software? Payroll Software? Timecard Software? Inventory Tracking Software? CRM? Job Tracking? o Things to consider: ▪ How much will the software be used ▪ When will the software be needed to be used ▪ How will the business / market change over time? ▪ Does the business expect to grow or shrink ▪ Do you have a dedicated team to support the software? ▪ Are needs vs wants considered?
Testing Methods
➢ *Black Box:* testing method in which the internal structure, design, and implementation of the system/software being tested is not known to the tester. May also be referred to as Behavioral Testing. ➢ *White Box:* testing method in which the internal structure, design, and implementation of the system/software being tested is known to the tester. May also be referred to as Clear Box, Open Box, Glass Box, or Transparent Box Testing. ➢ *Gray Box:* testing method in which a combination of Black Box and White Box Testing methods are utilized.
Business Process Projects
➢ *Business Process Automation (BPA)* o Taking manual tasks / paper-based systems and processes and using technology to make them more electronically efficient o Example: creating web forms and automated email workflows to replace old paper forms that were emailed around ➢ *Business Process Improvement (BPI)* o Utilizing technology systems to enhance efficiency of business processes. This may include BPA activity, but on a larger scale. o Integration of new systems into the organization o May yield new business operation rules / culture ➢ *Business Process Reengineering (BPR)* o Throw away the old process and let's build a new one o Many times used to get rid of legacy processes and technologies
Risk- Risk Response Relationship
➢ *Challenge - A constraint you must operate within, or one that impacts your available actions* o We only have $500K to complete a project that is estimated to cost $650K o Our product must be PCI/DSS compliant o We must abide by GDPR ➢ Risk - The probability and impact of something occurring (usually negative in our context) o We may not be able to complete the project due to budget constraints o We may deliver a poor-quality product given our budget constraint o We may be fined if we do not comply with xyz ➢ *Risk Response - How we can reduce the probability and or impact of the risk* o Deploy security controls o Purchase insurance o Do something else / pursue a different avenue
Architecture Design Basics
➢ *Connections / Network Mediums* o Connect the different network devices together, and carry the data from one point to another o Guided/Wired ▪ Ethernet ▪ Coaxial ▪ Fiber o Unguided/Wireless ▪ Radio waves; microwaves; infrared ▪ Wireless Access Points (WAP): These allow you to connect to WiFi networks so that you can access the Internet ▪ Cell Towers
Requirements Gathering: Elicitation Methods
➢ *Document Analysis* o Gather, read through, and analyze current documents in the organization o Policy, Procedures, Guidelines, Standards, Org Charts, etc. o Current vs. previous versions ➢ *Strengths* o Can be very detailed o Can allow you to understand the environment better o Can give you a history of the problems and successes ➢ *Weaknesses* o Very time consuming o Documentation most likely out of date o Can very undetailed
Risk Response (Positive Risk)
➢ *Enhance (instead of Mitigate)* o Strategize ways to increase the probability of the risk/opportunity o Examples ▪ Your company has a contract with the TSA dealing with security checkpoints. With the COVID-19 pandemic, there is discussion between TSA and your company's leadership to rollout thermal imagery and health screenings to detect potential health risks. This is to grow the current business within TSA for your company. ➢ *Exploit (instead of Avoid)* o Strategize ways to ensure the risk happens so benefits are yielded o Examples ▪ Apple builds into its iPhone updates additional features that are amazing for the users, except it also slows down the phone. This captivates the users in the new product's usability, so it also builds a stream of recurring purchases of newer iPhone models
TO-BE Process Flowchart
➢ Can use a process flowchart to show the TO-BE Process o Needs to show inputs and outputs of the process o Needs to show who is involved o Needs to show decision points o Should highlight the changes & improvements ▪ Use a positive color ➢ Compare this to the AS-IS Process (Why is the TO-BE so good?) ➢ Address both positive and negative changes o Increase/Decrease in expenses o Increase/Decrease in profit o Increase/Decrease in time for tasks o Etc.
Requirements Gathering: Elicitation Methods
➢ *Interviews* o Select individuals / groups o Categorize: Executives, Supervisors, Users, Clients, Customers, etc. o Prepare & Don't waste time o Take notes during & After o Send a summary after (optional) ➢ *Strengths* o Interviewee can respond in an open format o Interviewer can ask for clarification and note interviewee's body language o Interview Questions can be adapted to different individuals / groups ➢*Weaknesses* o Very time consuming o Location and time may be an issue o Interviewer and interviewee may not be comfortable with each other
Architecture Design Basics
➢ *Locations* o Datacenter o Offices o Field Employees o Telework Employees o Traveling Employees ➢ *Cloud Services* o Connected to your architecture logically o Data not stored/processed at your location ➢ *Third Party Solutions* o Integrated into your network physically o Data may not be stored/processed at your location ➢ *Labels*
Project Management Methodology
➢ *Methodology: a formalized approach to implementing a process or framework* o Derived from various sources ➢ Choosing a methodology can be based on your o Project o Organization o Client o Preference o Previous Experience ➢ Waterfall & Agile
Business Preparation
➢ *Migration Styles* o Direct Migration: The new system instantly replaces the old o Parallel Migration: For a time both old and new systems are used. The old is abandoned when the new is proven fully capable. ➢ *Migration Locations* o Pilot Migration: One or more locations are migrated to work out bugs before extending to other locations o Phased Migration: Locations are migrated in sets o Simultaneous Migration: All locations are migrated at the same time ➢ *Migration Modules* o Whole system migration: All modules migrated in one step o Modular Migration: When modules are loosely associated, they can be migrated one at a time
Requirements Gathering: Elicitation Methods
➢ *Observations* o Watch users perform the activities to learn about the current process / system o Used when the data collected is questionable or needs to be verified o Good to utilize when complex processes are involved where problems may be hard to identify or explain ➢ *Strengths* o Can see exactly the step-by-step activities o Gathered data is firsthand, so it's reliable o Inexpensive compared to interviews ➢ *Weaknesses* o Users may perform the activity differently when being observed o Like interviews, scheduling may become an issue o Activities may vary depending on the day, time, request, etc. o Observations may be interrupted (which may be a good thing too) o Observers interpretations may be wrong
Types of Tests
➢ *Regression Testing:* done to verify that a change in the system/software (whether it is updated code or a new component) does not impact the existing functionality of the product. Ensures the product continues to work as intended with new functionality, bug fixes, security patches, or other changes in the existing feature. ➢ *Security Testing:* determines if the system/software has the proper mitigation controls so that users (legitimate or illegitimate) do not perform operations (intentional or unintentional) that violate confidentiality, integrity, and or availability of that system/software and the data that resides. ➢ *Software Testing:* determines if the software operates as intended, focuses on how the code is written, if it's efficient, if there's a security vulnerability, etc. o Manual ▪ Code Reviews: Developer and a teammate review line by line o Automatic ▪ Static: Testing software reviews and flags common mistakes ▪ Dynamic: Code is executed and testing software reviews and flags common issues and anomalies
Risks
➢ *Risk is the probability and impact of loss or danger* ➢ *Risk can be positive or negative, but when discussing in terms of project and security, usually negative* ➢ Risk can come from internal and external forces o Internal: Policies, Processes, Resources, etc. o External: Laws, Industry Standards, Partners, Nature, etc. ➢ There is always risk when conducting business operations and ventures o Conducting a cost/benefit analysis is necessary to determine which risks are worth taking ➢ There are many forms of risks o Business & Technical ➢ Determining the risk ahead of time allows us to understand the situation better. ➢ New risks will appear as time goes on
Architecture Design Basics
➢ *Servers* o Any device that requests or transfers data to a client o Examples: Database & Web ➢ *Client Devices / End Nodes* o Any end device that requests or transfers data to a server o Examples: Laptops, Tablets, & Mobile Phones ➢ Switches o A device that connects other devices to each other and allows for data transmission. It is used for LAN transmission ➢ *Routers* o A device that connects other devices to each other and allows for data transmission. It is used for WAN transmission ➢ *Firewalls* o filters traffic going into and out of a network
Agile Management Methodology
➢ *Strengths* o Can handle requirement changes very well o Users get a usable component/prototype quickly and consistently o Allows for immediate feedback from the client o Fail quickly ➢ *Weaknesses* o Hard to know the budget upfront o Process learning curve may slow down the project o Users have an incomplete system for a time o Fail quickly ➢ Good for what type of projects? o Software Projects o Projects where requirements unclear or are always changing o Example: Application Development
Requirements Gathering: Elicitation Methods
➢ *Surveys & Questionnaires* o Allows you to send out questions to a larger audience, and hopefully get more feedback o Respondents complete these on their own time... or not o Questions can be closed-ended (fixed-format) or open-ended (free-format) ▪ Closed-ended questions are easier to tabulate ➢* Strengths* o Most questions can be answered quickly, so it's easy for respondents o Inexpensive o Anonymity o Can analyze and view a large amount of data quickly ➢ *Weaknesses* o Response rate may be low o Incomplete questions may skew data results o Can't be as specific or detailed as Interviews, can't ask feedback, and can't clarify any questions o Hard to tailor to individuals, but maybe to groups with some effort
Risk Responses (Negative Risk)
➢ *Transfer* o It is more cost effective to share the risk with a third party o Examples ▪ Insurance - car, home, rental, etc. ➢ *Avoid* o The cost of dealing with the risk is too high, so we abandon the effort, and choose a different path o Different than ignoring risk o Examples ▪ Backing out of a project due to lack of stability with a Prime Contractor ▪ Abandoning a plan to enter the spaceship market because of the barrier to entry
Types of Tests
➢ *Unit Testing: individual components of software/system are tested. Purpose is to validate that each component (unit) performs as designed.* o Unit is the smallest testable part of any system/software. ➢ *Integration Testing: individual components are combined (integrated) and tested as a group. Purpose is to expose faults in the interaction between the connections of the components.* ➢ *System Testing: when all components have been combined and then tested as a whole. Purpose is to evaluate the software/system's compliance with the specified technical requirements.* Unit Testing -> Integration Testing -> System Testing -> Acceptance Testing
Types of Tests
➢ *Usability Testing:* determining if the representative users can perform tasks that are required of the system/software. Key metrics here include o Duration of tasks, completion of tasks, ease of use, and at times - satisfaction of use ➢ *Reliability Testing:* defined as the probability of failure-free software operation (does its intended purpose) for a specified period of time in a particular environment. ➢ *Performance Testing:* determining the speed, responsiveness, capacity, and stability of a system/software when in operation. Many times used to find bottlenecks, lags, and other efficiency issues within a system o Metrics here include throughput (data that can be processed), memory, response time (or latency), bandwidth (volume of data being moved), etc. ➢ *Stress Testing:* determines the system on its robustness and error handling under extremely heavy load conditions. Primarily used to tests beyond the normal operating point and evaluates how the system works under those extreme conditions. It can be used to determine the limit at which the system/software breaks. Sometimes called Endurance Testing. o Tesla vehicle roofs and solar roofs are good examples here
Data Model
➢ A formal way of representing the data that are used and created by a business system ➢ Shows the people, places and things about which data is captured and the relationships among them. ➢ Logical data model shows the organization of data without indicating how it is stored, created, or manipulated ➢ Physical data model shows how the data will actually be stored in databases or files. ➢ Can use ERDs or Flowcharts to model
Processes
➢ A series of steps taken to accomplish a task / achieve a goal ➢ Will usually require some type of input, and will produce some type of output ➢ Formalized / Uniformed work ➢ Measurable
Types of Tests
➢ Acceptance Testing: the fully integrated system/software is tested for approval by users and the business. Purpose is to evaluate the system/software's compliance with the business requirements and assess whether it has met the criteria for delivery. o Alpha Testing (Internal Acceptance Testing) ▪ Performed by members of the organization that developed the software but who are not directly involved in the project o Beta Testing (User Acceptance Testing) ▪ Performed by the end users of the software. They can be the customers themselves or the clients' customers. ▪ Not all users / customers are selected for Beta Testing - usually a small group(s)
TO-BE Process Flowchart
➢ Add the necessary requirements / acceptance criteria's ➢ Add the industry/external requirements such as industry compliance, new regulations, etc. if approved o Security Controls o Privacy & new legal rules o Mandatory / Must-have features ➢ Maybe even suggest the "nice to have" features ➢ Get the executives / approvers to support your project o They have the money o They have the power / influence o They can help drive the change ▪ Before, during, & after implementation o They can influence organizational culture
Virtualization
➢ Allows for operation of multiple operating systems running on one physical machine o Virtual Machines (VMs) o Depending on the RAM and Processor of the physical machine, two VMs can be on one host, or two hundred VMs can be on one host ➢ Example: Allows a user to run Windows 10 on a Mac ➢ How cloud computing works/scales ➢ Hypervisor: allows for VMs to talk to the Host, and vice versa ➢ Security implications
Documentations
➢ Allows you and others to understand the system's innerworkings, making it easier to troubleshoot later ➢ System Documentation: allows software developers to remember/understand how the system works - usually for troubleshooting, maintaining, and upgrading later ➢ User Documentation: Allows users to understand what they need to do when interacting with the system ➢ Documentation is important to keep current and can be stored online or offline o Updated as the system is updated during the operations & maintenance phase
Quantification Results
➢ Analyze the data ➢ Does the TO-BE process result in one or more of the following?: o Improved Revenue o Reduced Expenses ▪ Including cost of the new process o Improved Net Income ➢ Did you solve the problem? How does it compare to the estimate? Calculate actual ROI ➢ Showing the differences between the AS-IS and TO-BE processes with quantification (time and or money (both is better)) will allow executive management to make an informed decision ➢ Quantification can make or break your project proposal
Post Implementation
➢ Assess the project (Lessons Learned) o Analyze what was done well o Discover what project activities need improvement in the future ➢ Project Team Review o Team reflections o Focus on improvement not penalties o Team leader summarizes and distributes lessons learned ➢ *System Review* o Operations vs Expected Behavior
Compelling Case for Change
➢ Based on the organization's current situation, your proposed solutions, and the potential benefits of implementing your TO-BE process - explain/show why they should approve / fund your project o Can be a simple statement (3 Bullet Points) o Can be visual of some sort o Etc. ➢ This is your final statement and reasoning on why the project needs to be funded and approved ➢ Usually a combination of: o This is the problem o This is how we can solve the problem (TO-BE process & selected proposed solution) o The quantification of the TO-BE process is saving us money and time by x amount
Build or Buy?
➢ Build Pros o Custom to your organization's needs o Your engineers will know the ins and outs of the solution o Can turn into a sellable product ➢ Build Cons o Expensive and time consuming (RDT&E) o Internal Support may be lacking (organization needs to be able to support it) ▪ Build engineers leave in the future o Can you integrate with other COTS products? Customization may be harder than you think o Did you build security into it?
Impact of a Process Change
➢ Business Level o What is the defined value of the change? o How can that value be promoted? o What are the benefits for each person involved? o How to gain buy-in from all stakeholders o Are value measurements in place?
Implementation Management Responsibilities
➢ Change Management Planning o Develop strategies to motivate adoption ▪ Informational - aims to convince adopters that change is better ▪ Political - uses organizational power to motivate change ▪ Potential adopters generally are • 20-30% Ready adopters • 20-30% Resistant adopters • 40-60% Reluctant adopters o Strategies should focus on supporting and encouraging ready adopters and helping them win over the reluctant adopters. o 'Ignore' the resistant adopters
Identifying Improvements
➢ Characteristics of processes that can be improved: o Inefficient, time consuming o Repeatable and predictable o Prone to errors, high rate of errors o Simple decision structure o Collection, processing, and presenting data o Handling large volumes of data/information o Older technology or technology silos
Technical Risks
➢ Confidentiality o Protection of the data from unauthorized disclosure and people ➢ Integrity o Correctness and modification of the data ➢ Availability o Uptime of the system, solution, and process ➢ Processing o Data, calculations, power, etc. ➢ Storage o Volume and location ➢ Others
Business Preparation
➢ Contingency Plan / Plan B / Backup Plan ➢ What do we do if things go very wrong during conversion? o Technical glitches may occur during the transition o Is the old system still available? o If not, how do we keep the business running? o Can manual procedures be used for a short time? ➢ Be prepared for the worst-case scenario! o Think about the consequences of being unable to operate normally...lost sales, unhappy customers... could we stay afloat?
Requirements Analysis
➢ Create Business / Use Cases o Allows us to express and clarify the requirements o It defines the expected interaction between the user and the solution o Describes the different activities needed to be handled by the solution ▪ Approval / Smooth vs. Rejection / Issues o Inputs of the solution o Processes within the solution o Outputs of the solution o Identify use case triggers (activity initiation of the use case) ➢ Understanding step-by-step activities needed to be handled by the solution o Different organizations point of views o Different users point of views o Front-end vs. back-end ➢ Business / Use Cases can later be used as Test Scripts to verify system functionalities & goals
Turnover
➢ Customer Sign off o Serves as formal delivery of the solution o Includes ▪ Summary of what is being provided ▪ Turnover Documents ▪ Formal Customer Acceptance ➢ Who to turnover to? o Depends, usually to the client if external o To the Operations Team if internal
Why is Data Modeling Crucial?
➢ Data is a resource to be shared by as many processes as possible. ➢ Data organization must be flexible and adaptable to unanticipated business requirements - and that is the purpose of data modeling. ➢ Data models are much smaller than process models and are constructed more rapidly. ➢ Constructing the data model helps analysts and users quickly reach consensus on business terminology and rules.
Identify Areas of Concerns
➢ Describe why it's an area of concern (why should we care / why is it a problem?) o Repetitive? o Duplicated? o Bottleneck? o Error prone? o Obsolete? o Unnecessary? o More complicated/complex than necessary? o Slow? o Too many components/systems? o Does it effect other areas of the business?
Project Proposal Scheduling
➢ Different than your project management Gantt chart o Project has not been approved yet o Not a WBS style Gantt chart ➢ Showing the executives what the high-level plan is from beginning to end (estimate) ➢We show no sub-tasks or specific dates... because we don't know them ➢ No real resources tied to each activity
Architecture Design Purpose
➢ Documentation for organization's technology infrastructure layout & components ➢ TO-BE process' technology solution location and integration in the organization's infrastructure ➢ Shows hardware and software specifications ➢ Shows locations ➢ Shows connections & communications ➢ Shows other components like cloud service providers & third-party connections ➢ Allows engineers to understand the organization's infrastructure ➢ Allows auditors to review the organization's infrastructure
Turnover
➢ Documentation o Gather all documentation needed to keep your solution operation should a catastrophic error occur. o This is your legacy ➢ What to be included o HW/SW/Environment ▪ Anything needed to duplicate the solution environment (The Specs!) o Design Documents ▪ Architecture & User Interface o Source code/Customization ▪ What changed? The integration codes o Documents Vendor & training Manuals ▪ Purchase, License, & Maintenance Agreements ▪ Everything o Points of Contact ▪ Sales Representative, Vendor Help Desk, Maintenance Support, Project Team Representative
Quantification Evaluation Steps (1/6)
➢ Ensure Accuracy ➢ Measure and Verify Everything ➢ Assume nothing from the client without verifying and measuring yourself ➢ Building blocks for the business case ➢ Case for change must be comprehensive and supported by overwhelming facts ➢ Define a Quantification methodology
Project Proposal/Selection
➢ Feasibility Analysis within the Project Proposal o Technical Feasibility ▪ Can we build or integrate this solution? o Economic feasibility ▪ Should we do this? ▪ How much does it cost and how much will our return on investment be? o Organizational Feasibility ▪ Will it be used?
Third Party Solution Integration
➢ Solutions that are physically at your location o Point of Sales Systems o Kiosks o Scanners ➢ Solutions that are not physically at your location are most likely Cloud-based o Cloud Service Providers are Third-Party, but you don't need to do physical integration
Acceptance Criteria Examples
➢ Feature-based o Solution must be able to _____ o Software must be compatible with both MAC & Windows Operating systems o Solution can track inventory AND operate as the Point of Sale system o Solution is compatible with Oracle 12c o Solution has automatic email features o Solution comes with Training Option ▪ Training option is less than $10K total (Range-Based) ➢ Range-based: o Solution costs less than $50K to acquire and integrate into the organization o Solution can handle up to 500 users at a time o Maintenance costs of the solution is less than $5K a year o Solution can be integrated within 3 months ➢ Should have a combination of Feature and Range Based Criteria
Business Risks
➢ Financial Risks o Budget and funding related ➢ Time Risks o Schedule related ➢ People Risks o Staff & team related ➢ Resource Risks o Materials and technology availability, capability, and applicability related ➢ Business Cultural Risks o Acceptance by the organization related ➢ Sustainment Risks o Related to the operation and maintenance of the new solution and process
Architecture Design Specifications
➢ Hardware ➢ Software (versioning) ➢ Speed ➢ Capacity ➢ Security ➢ Storage ➢ Portability ➢ Reliability ➢ Maintainability ➢ Customization
Implementation Management Responsibilities
➢ Human Resource & Communication Management o More people does not always mean quicker delivery or better results ▪ More than the "right" amount of people can actually slow down the project ▪ Communications becomes more difficult as more people become part of the team ▪ Be carful about hiring cheap personnel to accomplish tasks • Too many entry level folks may cause quality issues as well as project schedule delays o Know who / which team is working on which unit to avoid double work ➢ Configuration Control Management o Source code libraries (GitHub) o Updates and other changes to code are tracked and approved o Ensures product documentation in happening and complete o Avoids surprises down the road
Project Constraints
➢ If triple constraint is well balanced, you will have a quality solution Quality - Scope (Features, Functionality) - Time (Schedule) - Cost (Resources, Budget)
Implementation
➢ Implementation is the development of the system's design, testing it, and putting it into the production environment successfully. This also includes administrative functions (nontechnical) such as training, procedure rework, and document turnover. ➢ Project Managers will play a large integration role during this phase o Development, Testing, Training, & Transition ➢ Can happen in parallel ➢ Implementation management responsibilities
Flow Chart Best Practices
➢ In this class, I let you do what is best for your project. But here are some basic starting points ➢ Boxes: Represent a Noun like Patient, Customer, Database, etc. OR a Process like Submit Report ➢ Lines: Represent Data Flow to get from one noun/process to the next ➢ Diamonds: Represent Decision Points ➢ Circler Boxes: Represent Starting & Ending Points ➢ You can also use images ➢ Keep it simple: No sentences / Paragraphs
Proposed Technical Solutions
➢ In this class, we don't just worry about the process. We are here to apply technology solutions to business processes ➢ Usually, we want to present three potential technical solutions that can be implemented in the TO-BE process, to improve the AS-IS process ➢ The requirements gathered at the beginning are needed to produce an "Acceptance Criteria" for your client/customer/organization o Acceptance Criteria are those requirements that need to be met for the new solution to be accepted/implemented ▪ Can be a combination of requirements o This is usually done in teams and interacting with the product owner and executives o Of course, this is an iterative process to better understand what is necessary and wanted
Agile Management Methodology
➢ Iterative in nature ➢ Emphasizes getting product/solution in the hands of clients quickly ➢ Promotes client interaction for feedback and requirement updates
Waterfall Management Methodology
➢ Linear in nature ➢ Doesn't build in re-design, or handling of requirement changes well ➢ Don't get a product that you can interact with until near the end 1. Analysis 2. Design 3. Implementation 4. Testing 5. Deployment 6. Release & Maintenance
Architecture Design Basics
➢ Local Area Network (LAN) o A network that spans a small geographical area o A floor, building, or even campus ➢ *Wide Area Network (WAN)* o A network that spans a large geographical area o Two or more LANs connected together will make a WAN o A company network, and ISP's network, the Internet ➢ *Internet* o Public WAN to share information around the world ➢ Intranet o A network using Internet technologies to share information within an organization ➢ *Extranet* o A network using Internet technologies to share information between organizations o Open only those invited users outside the organization
Business Process Projects
➢ Most project's goals will be to improve a component(s) within the business process ➢ Business Process Management (BPM): methodology used to continuously monitor and improve end-to-end business processes o Internal or cross-departmental o Increase efficiency in hopes to save time and money, as well as increase revenue and market share o 3 different ways to enhance current business processes: ▪ *Business Process Automation (BPA)* ▪ *Business Process Improvement (BPI)* ▪ *Business Process Reengineering (BPR)*
Processes
➢ Necessary o Formalizes operations o Measures time and resources o Sets performance goals o Predictably reproduces the desired outcomes o Easier Knowledge Transfer/ Training ➢ People, Process, & Technology o People manage and operate within the process o Software formalizes a process based on policy developed by people o The process offloads repeated tasks to technology o Technology separates out the expected from the unexpected when used in a process o People work on improving the process by utilizing technology
Identify Areas of Concerns
➢ Note areas on the AS-IS Process flowchart where the problems/inefficiencies exist ➢ Part of the process or the whole process? ➢ Different / Troublesome color o Boxed o Circled o Highlighted o Shaded
The Testing Questions
➢ Who o Participants in the testing o Alpha vs Beta (for example) ➢ What o Components of the system o Use Case → Test Case (Action & Expectations) ➢ When o Certain types tests will be started and completed o Timeline noted in Gantt chart ➢ Where o Location to be conducted (from and at) ➢ How o Types of tests o Test Methods
TO-BE Process Flowchart
➢ Now that we have noted the current process and highlighted the areas that need improvement, we need to show that we have a solution (or solutions) that can fix the current process ➢ Why? o You need to show the executives / approvers there is a way to become better ▪ Showing what can be done o You need to show the new process will not negatively effect the organization's other processes o Pointing out a solution for the problem is better than just pointing out a problem o To get funding for the project
Project Proposal/Selection
➢ Our Group Project is a Project Proposal ➢ Proposal is used to show the feasibility and benefits of investing in and undertaking a project o Feasibility Analysis o "Planning the SDLC Execution" o Cost / Benefit Analysis ➢ Project Sponsor o Supports & Funds the Project ➢ Committee may be required to approve the project as well ➢ Proposal must be convincing to show the current problems, and how the project will be a benefit that the organization needs to invest in o Problem, Potential Solution, Quantified Estimated Benefits, Risks & Responses, Design, & Implementation plans o Projects are implemented because of a business need
Retesting
➢ Procedure for reporting bugs to developers ➢ Plan to re-test after bug fixes ➢ Identify who to perform retest ➢ How long should you retest ➢ What is the criteria for declaring "System Ready"
Post Implementation
➢ Provide support o Assistance in using the system o Types of System Support ▪ On-demand training at time of user need ▪ Online support • Frequently asked questions (FAQ) ▪ Help desk • Level 1 Support - Broad knowledge • Unresolved issues passed to Level 2 Support - specialists in the application system ➢ Provide maintenance o Repair or fix discovered bugs or errors o Add minor enhancements to provide added value ➢ Many projects will receive Change Requests after the solution has been implemented 'successfully' o Sources of Change Requests ▪ Problem reports from the operations group ▪ Requests for enhancements from users ▪ Requests from other systems development projects ▪ Change requests from senior management
Quantification of the Benefits/ TO-Be Process
➢ Quantification Numbers o Time o Money o Tangible and intangible o Should include all metrics from your AS-IS Process o Can include additional metrics that are not currently being measure (create new Key Performance Indicators (KPIs)) ➢ The TO-BE metrics can show a positive or negative change o Justify why there are negative changes if there are any o EX: To generate more revenue, you will most likely increase your R&D or operating costs ➢ You will need to show the difference between the AS-IS and TO-BE process to prove that it is worth investing in the implementation of the TO-BE process
Quantification Evaluation Steps (2/6)
➢ Quantification of the problems in the current system/process ➢ Some examples of problems o Revenue Loss & Low Sales o Lost Customers o Employee Morale o Inefficient / Time-consuming Processes o High Costs o Theft o Lost/Misplaced/Over-ordered/Incorrect Inventory o Too many / too expensive staff o Limited Growth o Low Customer Satisfaction
Requirements Gathering
➢ Requirement: what the users and organization need the solution to have and do ➢ Requirements come from many different sources o Business o Users o Clients / Customer o Regulations & Standards o Best Practices ➢ Requirements can be needs or wants; that should be noted ➢ Requirements should be noted for analysis ➢ Iterative Process
Requirements Determination
➢ Requirements need to be verified and validated o Verified = You go and check to see if these are in fact the requirements, and that they are properly stated o Validated = Approved by a Manager, Director, or Executive ➢ Requirements need to be documented o Scope o Statement of Work o Contract / Agreement ➢ These will later become the Acceptance Criteria o We'll have a dedicated lecture on Acceptance Criteria (Lecture 4)
Risks
➢ Risk Register: list of all identified risks for monitoring ➢ Risk Management o Risk Assessment: process of identifying assets, threats, and vulnerabilities o Risk Analysis: process of valuating the potential risks ▪ Cost Benefit Analysis o Risk Response: determining how to react to the risks so that we can continue with business ➢ *Secondary Risk: a new risk that is introduced as a result of a risk response* ➢ *Residual Risk: the risk amount left over after a risk response* ➢ *Total Risk: the amount of risk before any risk response is implemented* o Usually calculated as: Threats * vulnerability * asset value
Monitoring Risk
➢ Risk level changes as the environment evolves ➢ As time goes on, risk can increase, decrease, become newly realized, or even become obsolete ➢ Monitoring risk is an important function is risk management - whether we are discussing project management, cyber management, etc. ➢ Update the risk register while monitoring risk, including residual and secondary risks
Project Constraints
➢ Scope o *Scope Creep - doing more than is stated in the statement of work (SOW), initiated from the client's side o Gold Plating - doing more than is stated in the SOW, initiated from the project team* ➢ *Budget / Cost* o Managerial Funds - money that can be used to address unforeseen issues ➢ *Schedule* o Start & End Date o Slack - extra time built into the schedule to account for any unforeseen or unpredictable issues ➢ *Triple Constraint* o If one of these is effected, it will effect the other constraints as well o If Scope is increase, then budget and schedule will need to be increase o If budget is cut, maybe scope also needs to be cut, and if scope is cut, then most likely time to complete will be shorten
Defining the AS-IS Process
➢ Show a flow chart o Individual Steps o What tasks performed o What are the inputs and outputs o Who performs each o How long does the task take to perform o Where are decisions made o Who makes the decisions ➢ What may cause the process not to be followed? ➢ Once AS-IS Process is Defined, it must also be described in detail
Quantification of the Benefits/ TO-BE Process
➢ Since you haven't built the TO-BE Process yet, this will need to be an estimate that is reasonable/achievable o Don't overpromise o Solve the issue o Better to under promise and over deliver - but make sure the promise is sufficient ➢ To do this, you will need: o To do research on tools/solutions that are available o Reach out to everyday users/contributors of the process to see if they have ideas/goals o How are your competitors doing compared to you? o Determine the organization and executives' mission and goals
Implementation Management Responsibilities
➢ Stakeholder Management o Updates on implementation o Informational updates o Training updates ➢ Procurement Management o Purchasing what the developers need, and in time (not too early either) ▪ Money doesn't come all at once into your account (may be obligated in intervals) o Quality product when procuring o Takes a lot of time ▪ Licensing ▪ Legal ▪ Contracts ▪ Finance
Waterfall Management Methodology
➢ Strengths o Requirements are identified and verified before development (Clear Requirements) o No moving targets because requirements are set o Easier to budget ➢ Weaknesses o Visible product isn't seen/touched until near the end o Requirement changes can't be implemented cheaply o Client interaction and feedback are not emphasized ➢ Good for what type of projects? o Short Term Projects o Projects where requirements are clearly known and not likely to change o Example: Construction
Quantification Evaluation Steps (3/6)
➢ TO-BE Process Quantification Options (1/3) ➢ Lowering Costs o Focused on Expenses & Materials such as Inventory, Salaries, & Operating Expenses o Easiest to manage and measure o Directly affects the "bottom line" o What is necessary vs what is extra o What cannot be controlled o Is the most tangible
Quantification Evaluation Steps (3/6)
➢ TO-BE Process Quantification Options (2/3) ➢ Saving Time o Focuses on Internal Business Processes such as communication, operations, development & Manufacturing o Update inefficient processes o Generate more reliable data o Faster communication o Requires training and ramp-up o Less tangible o Harder to convert to dollar amount
Quantification Evaluation Steps (3/6)
➢ TO-BE Process Quantification Options (3/3) ➢ Increasing Sales o Focused on Products and Services such as Delivery, Marketing, & Support o Increase products or services being sold o Delivery efficiencies & improvement o Marketing o Customer Satisfaction & Support ▪ Most difficult to measure ▪ Intangible
Process Modeling
➢ Takes into consideration more than just how the data flows from input to output ➢ Considers users, customers, decision makers, technologies involved, and more o The Business Operations as a whole ➢ Can use a flowchart to model
Gathering the Evidence
➢ Tangible Problems/Solutions - Directly Measurable o Revenue / Sales o Salaries o Bills o Other Operating Expenses ➢ Less Tangible Problems/Solutions - Still Measurable o Workflow Processes o Labor Hours ➢ Intangible Problems/Solutions - Indirectly Measured [Requires Research & Support!] o Customer Satisfaction o Impact of a New Web Page o Employee Productivity o Reduced Risk of Fraud
Impact of a Process Change
➢ Technology Level o Are current hardware assets adequate? o Can current data be converted? o Does significant data need to be collected? o Any workstation, network, cloud considerations? ➢ Personnel Level o How significant is the change to the staff? o What's the pain to performance ratio? o Software or interface changes? o Similarity to the current process? o Is there a paradigm change? o Is there reluctance or apprehension? o How trainable is the staff?
Testing
➢ Testing allows us to check a variety of different categories (such as quality, performance, security, usability, etc.) based on the acceptance criteria (requirements) of the system before implementing it for official use in the organization ➢ Many times, you will not be able to test everything due to time, budget, and or other constraints ➢ Different types of tests exists
Quantification Evaluation Steps (3/6)
➢ The message we need to be able to convey to the executives ➢ The AS-IS process is slow/inefficient/expensive and needs to change before it gets worse (case for change) ➢ The TO-BE process is faster/more efficient/cheaper and will better the business, and possibly provide improvements to other processes ➢ TO-BE Process Quantification Options o Lowering Costs o Saving Time o Increasing Sales
Implementation Management Responsibilites
➢ The sponsor is the businessperson who initiated the request for the new system ➢ The change agent is the person(s) who lead the change effort ➢ The potential adopter(s) are the people who will be effected by the change. ➢ Understanding Resistance to Change o Even changes that benefit an organization do not necessarily benefit each individual o Adapting to new work processes requires effort, for which there may be no additional compensation ➢ No system will be successfully adopted unless management policies support its adoption.
Risk Response (Negative Risk)
➢ There are four ways to respond to risk o Never ignore the identified risk ➢ *Mitigate* o Invest in reducing the probability and or the impact of the risk being realized o Examples ▪ Implement security controls to mitigate the risk of a cyber intrusion ▪ Locking and arming your car so that you reduce the likelihood of car theft ➢ *Accept* o The cost of mitigating the risk is greater than if the risk is realized o Different than ignoring risk o Examples ▪ Driving a car even though you could get into an accident... and get injured or die ▪ Not worrying about your participation grade because it is only 5% of your final grade (not this class)
Risk Response (Positive Risk)
➢ There are four ways to respond to risk o You will want to escalate these positive risks for awareness and approval ➢ *Accept* o No negative impact to the project, but there may be positive impact; should monitor o Examples ▪ Extra credit will require you to do more work, and it will possibly increase your grade. But if you get the extra credit wrong, you won't get marked down ➢ *Share (instead of Transfer)* o Great opportunity may exist, but going in alone may not yield as much of the benefit; so things like partnerships can provide mutual benefits on the opportunity o Examples ▪ You can potentially win a $500M contract if your company had additional cyber capabilities. So your company teams up with a cyber company in a contractual partnership to bid the $500M.
Proposed Technical Solutions
➢ There are many ways to show and describe your proposed technical solutions to your client ➢ Table Matrix may be one of the most common o On the left are the acceptance criteria o On the top are the proposed solutions o In the middle cells show if the proposed solutions meet the acceptance criteria o You should highlight the solution that ends up "on top" ➢ There are others you can use as well, just make sure you show: o The capabilities of each system compared to the client's acceptance criteria o The system that is your first recommendation, and why o Clarity
Transition/Deployment
➢ There are two aspects / activities that need to be considered during migrations o Technical activities ▪ Installing/Upgrading New Hardware and Software ▪ Converting Data o Organizational activities ▪ Training users on the new systems (and a lot of times the differences) ▪ Motivating employees to use the new system because it's great ➢ Three categories of preparation o Business Preparation ▪ Migration strategy ▪ Contingency plans o Technology Preparation ▪ Hardware & software capabilities ▪ Data conversion/transfer o People Preparation ▪ Policies, adoption, & training
High Level Gantt Chart
➢ Timeline: use ranges ➢ Swim lanes I need you to have: o Planning & Requirements Determination o Design o Development o Testing o Training o Transition ➢ Only include what you need for your project, and what is in your proposal ➢ Include high level activities ➢ Can add milestones o Indicates important dates or goals on the Gantt chart (diamond or triangle) ➢ The Gantt I made is for guidance on how it looks - not based on any accurate projects
Current Process Model (AS-IS Process)
➢ To determine how an organization currently operates, you will need to do Requirements Gathering and Analysis ➢ Flowchart out the step-by-step operations ➢ This is called the AS-IS process ➢ Highlight points of concerns here, where we will need to produce improvement suggestions
Transition/ Deployment
➢ Transitioning from one system to another involves changing the culture norms and habits ➢ It involves what management refers to as Unfreeze - Reform - Refreeze o Unfreeze refers to loosening the current habits and culture of the current business users o Reform refers to introducing the new and exciting processes and culture to current and new users o Refreeze refers to making the new processes and culture the new norm through policies, practices, and repetition o Our Business Processes: ▪ AS-IS Process is what we want to Unfreeze ▪ Reform is the Transition from the old system to the new system ▪ TO-BE Process is what we will want to Refreeze ➢ Transitioning from an old system to a new system is generally referred to as a Migration
Requirements -> Acceptance Criteria
➢ Using the requirements that were finalized from the Requirements Determination stage o Scope / SOW of the contract/agreement o Acceptance criteria must be met for the client to accept your solution/deliverable ➢ Affects Everything: the TO-BE process, TO-BE quantification, Proposed Technical Solutions, User Interface, Architectural Design, and more. ➢ Specific & Measurable o Acceptance criteria are either met or not ▪ Yes or No Determination ▪ Can be feature based or range based ➢ If acceptance criteria is not met when the solution is delivered.... o Client may not accept the solution - money back? o Client may request you complete the solution to the agreed upon scope (acceptance criteria) - on your dime o Legal Action
Cloud Computing
➢ Using, storing data, processing data, etc. on somebody else's computer ➢ Cloud Service Providers (CSPs) ➢ Cloud is a Datacenter in various locations o Don't necessarily know where that computer is located ➢ Cheaper ➢ Organizational Maintenance & Scalability ➢ Better Security? ➢ Do you own the data? Or do the CSPs? o Cloud Lock-in ➢ Who is responsible for the data?
Training
➢ We conduct training to show all affected users how they perform their part of the system/solution and how the new system/solution fits into their existing processes ➢ Conducting good training is the key to the solution being adopted and accepted o New systems usually require new skills; train current employees up on those new skills!
Build or Buy?
➢ What technology solution do you believe can solve your organization's issue? ➢ Does the solution currently exist? o Can we buy it? o Can we customize it? o How expensive is it? o How easy is it to use? o How is there customer service? ➢ Is it something we need to need to build? o Do we have the capability to do so? ▪ Time, money, ability, etc.
Proposed Technical Solutions
➢ What technology solution do you believe can solve your organization's issue? ➢ Does the solution currently exist? o Can we buy it? o Can we customize it? o How expensive is it? o How easy is it to use? o How is there customer service? ➢ Is it something we need to need to build? o Do we have the capability to do so? ▪ Time, money, ability, etc.
Impact of a Process Change
➢ When software is introduced: o Should the software change to suit the business? o Should the business change to suit the software? ➢ What is considered when making this decision? o Impact to the operation o Customization abilities of the software o Long term technological implications o Effort vs. reward
Cloud Computing
➢ When we don't use cloud computing, we call it "On-Premise" or "On-Prem" ➢ *Software as a Service (SaaS)* o Most common o No maintenance of software, the CSP takes care of everything! o Log in and use o Examples: Office 365, Cisco WebEx, Concur, Salesforce, Dropbox, Google Apps ➢ Platform as a Service (PaaS) o CSP give you an environment with the desired operating systems o You load your own applications o Many developers like this environment o Examples: Google App Engine, AWS Elastic Beanstalk, Windows Azure, Apache Stratos ➢ *Infrastructure as a Service (IaaS)* o CSP give you the hardware capabilities o You're responsible for the operating system and applications o Examples: Amazon Web Services, Microsoft Azure, Google Compute Engine, Rackspace ➢ *Anything as a Service (XaaS)* o Analytics, Security, Identity, Disaster Recovery, Communication, Network, etc.
The Training Questions
➢ Who o Affected users that need it o Groups o Customers vs employees vs trainers, vs managers ➢ What o Components, activities, tasks, technical, etc. ➢ When o Certain users will be trained first o Timeline noted in Gantt chart ➢ Where o Location - Online vs In-Person ➢ How o Training Materials o Methods - Scheduled vs. On-Demand, hands-on vs lecture, etc.
The Transition/ Deployment Questions
➢ Who o Will be affected by the transition o Will perform the transition ➢ What o Will part of the transition ➢ When o Will this happen o Reflected in the Gantt chart ➢ Where o Will this happen o Locations affected ➢ How o Transition & migration strategies
The Development Questions
➢ Who o Will be building and integrating the system o Application programmers, web designer, analysts, database developers, network engineers, etc. ➢ What o Needs to be developed - features & deliverables o Order the components need to be developed ➢ When o Certain components will be started and completed o Timeline noted in Gantt chart ➢ Where o Development will take place o Offsite / onsite ➢ How o Agile / Waterfall o Programming language & teams