BISM3222 Final Exam Summary (Midterm is also covered) PDF

Preview

Summary

Download BISM3222 Final Exam Summary (Midterm is also covered) PDF

Description

BISM3222 Final Exam Review

Lecture 1: Application vs. Information Systems: a. Application is a software program that executes on a computing device to carry out a specific set of functions b. Information Systems is a set of interrelated components that collects, process, stores and provides as output of the information needed to complete the business task. System Analysis and System Design concepts: a. System Analysis enables a person to understand and specify what an information system should accomplish b. System Design enables a person to define and describe in detail the information system that solves the need. What makes a good analyst? 1. 2. 3. 4. 5.

Problem Solver – extract root issues, understand ways to solve the problem Understands business, technology and people Curious yet focused Comfortable with iteratively opening up and shutting out (explore – exploit) Most important: Ability to convey why something is important to you and everyone in your organization 6. A reminder! Project Management: What is it? It is a controlled process of initiating, planning, executing and closing down the project a. How to approach Project Management in general: i. Both structure and perspective are necessary ii. An outstanding musician cannot become so unless they have both the technical tools and the ability to improvise. (means that a good Project Manager should be able to perform well both technically and improvise certain aspects if necessary). iii. Closely related to management concept of “ambidexterity” (a state of having to be able to adapt to both the good and bad side of the conditions). iv. Understand the situation first, then ‘grab the tools’ when needed. (know when to use different methodologies in different situations).

b. Simplified process of Project Management: i. Understand BHAG ii. Known and understand core values iii. Real world event iv. Recall appropriate tools needed v. Act upon it vi. Assess outcome vii. Repeat from step 1 c. In times of crisis (increasingly in the case), BHAG’s and core values should be relied upon.

Lecture 2: Approaches to Information Systems Development (ISD): a. Waterfall Approach: i. What is it? 1. One of the first developed and often associated with SDLC 2. Assume phases can be completed sequentially with no overlap or iteration 3. Once one phase is completed, there’s no going back 4. Driven by initial documentation 5. Relatively linear sequential design ii. Stages of Waterfall Approach Development: 1. Requirement Gathering and Analysis: possible requirements of the system to be developed 2. System Design: helps in specifying hardware and system requirements and helps in defining the overall system architecture 3. Implementation: the system is first developed into small programs called units, and then integrated to the next phase. Each unit is developed and tested for its functionality, called User Testing. 4. Integration and Testing: all the units developed in the implementation phase are integrated into a system after testing of each unit. 5. Deployment of System: the final product is then deployed in the customer environment or released into the market.

6. Maintenance: to fix issues that might occur in the final product and enhance the product so better versions will be released. iii. Advantages: 1. Model is simple and easy to understand 2. It is easy to manage due to rigidity of model – since each phase has specific deliverables and a review process 3. Phases do not overlap, processes will be completed one by one 4. Works for smaller scale of project where requirements were fully understood at the initial development. iv. Disadvantages: 1. Once the application is on testing stage, it is very difficult to go back and change things up. 2. No working software up until late during the life cycle of the development. 3. High amount of risks and uncertainties. 4. Not a good model for complex and object-oriented projects. 5. Poor model for long and ongoing projects 6. Not suitable for projects that require a lot of sudden changes

b. Agile Approach: i. What is it? 1. Describe approaches to software development emphasizing incremental delivery, collaboration and continual learning. 2. A development process that revolves around iteration and modularity 3. Focuses on reducing risk 4. Focus on people and interaction; processes are not really important 5. Requirements and solutions evolve through the collaborative effort of teams 6. Iterative and team-based approach to development ii. Stages: 1. Requirements: define the requirements for iteration based on the product backlog, sprint backlog, customer and stakeholder feedback 2. Development: Design and develop software based on defined requirements

3. Testing: QA(Quality Assurance) testing, internal and external testing, documentation development 4. Delivery: integrate and deliver the working iteration into production 5. Feedback: accept customer and stakeholder feedbacks and work it into the requirements of the next iteration iii. Advantages: 1. Development is more user-focused, likely a result of more and frequent direction from the customer 2. High degree of collaboration between the client and the project team, providing more opportunities for the team to truly understand the client’s vision. 3. Improves quality of product, as the project’s broken down into manageable units, team can focus on a high-quality development, testing and collaboration. 4. The customer/client has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development of the project. 5. Suitable for complex and object-oriented projects 6. Agile could start with working on a simple product and could be built upon in successive iterations. 7. Approaches: a. SCRUM: i. Focus on constant movement ii. Lightweight process framework for Agile development (set of practices that must be followed in order to for a process to be consistent with the framework) iii. Process is kept as small as possible, and as focused as possible, again, to produce a highquality product. b. Crystal Methods: focus on people and interactions; processes don’t really matter c. Dynamic Systems Development Model: iterative, incremental approach, largely based on Rapid Application Development (RAD). ‘Do it badly for the first time’. d. Extreme Programming: the usage of pair programming that aims to produce higher quality of a product to satisfy the responsiveness of changeable customer’s values upon the product. e. Feature Driven: concern with scalability but also maintains creativity. Basically creates features for the product, has bits from both XP and Scrum. f. Joint Application Development: focuses on business problem over tech details. It involves a

client or an end user in the design and development of the application. g. Lean Development: 80/20 Rule: 80% of effects come from 20% of causes and 80% of results come from 20% of efforts. Lecture 3,4,5,6: Requirements and Types of Requirements: Requirements: a. What is it? It remember typically how a customer knows exactly what they want. User/customer doesn’t know what they want until they see it, yet you must meet the previous requirements (Use Design Sprint approach, it really helps both the user and developer both understand what the customer really wants) b. Stages: i. Gather Detailed Information: interviews, questionnaires, business processes interviews ii. Define Requirements: modeling both functional and non-functional requirements iii. Prioritize Requirements: essential and important vs. nice to have iv. Develop UI Dialogs: flow of interaction between user and the system v. Evaluate Requirements w/ users: feedback, user involvement in adapting to changes

Types of Requirements: 1. System Requirements: both functional and non-functional requirements 2. Functional Requirements: business uses, functions the users carry out 3. Non-functional requirements: goals, feedback loops, generativity, psychological (??) 4. Usability Requirements: documented expectations and specifications designed to ensure that the product is easy to use 5. Reliability Requirements: part of the non-functional requirement 6. Performance Requirements: creating specific and measurable performance of the product that should again meet the initial requirements. 7. Security Requirements: to ensure the product is safe and secure enough to interact with

Design Sprint compliments Agile Software Development 1. Adapting rapidly on initial requirements 2. Ensure cultivation and modularization through simplicity (focus on component => loose coupling) 3. Takes out guesswork or attempts to rationalize guesswork by actually doing what more prescriptive methods attempt to predict (an attempt to predict something)

4. 5. 6. 7.

Nearly foolproof and very high demand in industry Stops groupthink (increases autonomy, creativity, and teamwork) Follows bottom up approach to ideas and solutions Focuses on fluid thinking, how to structure in some way, lots of drawing (no software needed yet at this stage)

Design Sprint Day 1: a. Expert Interviews: a.Interview as many people as possible: when they are talking about their problems write as many HMWs as possible. Don’t focus on the solutions just yet, focus on uncovering the challenges. b. Arrange, categorize and prioritize HMWs: which one is more important than the others c. Determine the long-term project goals (BHAG) d. Determine Sprint Questions: a. Think of all the ways the goal might not be achieved or what would stop the process b.Votes on most important questions c. Write down goal and top 3 questions to answer (later on) e. Create a user story map: a.What is it? A rough user journey based on the sprint questions, small specific goals also based on the sprint questions. Activities leading to the sprint goals. b.Take prioritized HMWs c. Has key activities/interactions between user and developer d.Smaller specific goals based on sprint questions e.Lightning Demos (sources of inspiration) f. Map Targeting i. Prioritized HMWs (the ones that were voted as most important) and place them on the relevant parts of the system (the map) where the challenges arise ii. There might be three to four clusters after the process, since we can’t target the whole map, focus on the most important parts. g. Lightning Demos (sources of inspiration) h. 4 Parts Sketching: a.What is it? Go from a blank state to something simple b.Note taking: i. Take notes from all the previous steps ii. Add sources of inspirations iii. Come up with small ‘inkling’ ideas c. Sketching: i. Take all previous brainstormed notes and turn them into something more tangible, such as drawings. Use pencil and eraser first! d.Crazy 8’s: i. Sketch random thoughts, could be the iteration of the same idea over and over again e.Create Final Concept

i. has to be self-explanatory!! ii. Must be unique iii. Might be adopted from the adaptation of the sources of inspiration Day 2: f. Heat Map: i. Voting on the best final concept ii. Vote on the things that you personally think are good solutions iii. Without fucking discussions! g.Presenting a Concept  moderator goes from concept to concept and presents each of their interpretation of what they’re essentially reading back to the team.  presenting the final concepts. Maksud dari concepts yg mereka sudah pilih itu apa aja sih? After presenting, is there anything that they need to add in order to make the audience understands what the concept really means? Moderator then take notes of what each of the team member is currently presenting. Team member gives feedback (reasoning why they choose to present that concept). h.Do straw poll: i. Everyone gets one vote ii. Look around the concepts remind themselves of the sprint goal, map, the target questions, etc. iii. Decide which one iv. Reason why v. Place votes simultaneously i. Do Decider Voting: i. Decider makes final decision about which direction the team is going to go ii. Deciding could be both on 2 solutions or parts of solutions combined together iii. Discuss with team members j. Storyboard: i. What is it? Storyboard is about combining the concept/concepts that were chosen previously with what the team came up in the user test flow, into one consistent story that the team will be able to take and turn it into prototype. ii. Screen-by-screen walkthrough of what the prototype is going to look like iii. Doesn’t have to be high fidelity iv. Includes user test flow!! (form of post its) v. Use user test flow to help the creation of the storyboards vi. User test flow  draw the timelines written by each of the team member, and then the Decider then choose which one fits the best user test flow for the storyboard and then curate the user storyboard using pencil first (back to the idea of how Design Sprint compliments Agile development) vii. Most important aspect of a storyboard  idea that designer could come to the storyboard and can determine the flow without

having to think and ask the other designers on how might the storyboard means.

k.Prototype i. Approaches to find testers for Design Sprint Prototype: i. Social Media Ads ii. Online Forums: such as Quora or Reddit iii. Existing Customers: there might be some open lines of communication with users who are already giving feedback to the current product or service iv. Friends and Family l. User testing: i. Testing Concepts: i. Testing: process of examining a concept, subsystem or system to determine its operational characteristics whether it contains any defects ii. Test case: a formal description of a starting state, one or more events to which the software must respond, and expected response/ending state a. Characteristics: i. Defined based on well understood functional and non-functional requirements ii. Must test all normal and exception situations iii. Test data: a set of starting states and events used to test a module, group of modules or the entire system ii. Testing Stages: i. Spare about 40-60minutes to interview a person ii. Choose an isolated space to do the interview iii. Before you begin with the interview, identify areas that you would like to focus on more iv. Record the interviews transcript or have someone else take notes for you: i. Take notes of the comments they are giving about different features /aspects of your prototype ii. Take note of any usability and possibilities of pain points where they appear to be having trouble v. Cluster the notes from each test: look for similarities in the feedback from all the users vi. Aggregate insights: starts writing down the main repeated feedback as bullet points under each aspect which was tested vii. Start answering the sprint questions that will lead you towards a clearer picture of possible next steps iii. Types of Testing: i. Unit Testing: software components must perform to the defined requirements and specifications when tested in isolation.

i. More specific types of unit testing: a. Black Box testing: tester focuses whether the unit meets the requirements stated in the program’s specifications b. White Box testing: looking inside the codes itself, tester may discover errors or assumptions not immediately obvious to someone treating the unit as a black box ii. Integration Testing: software components that perform correctly in isolation must also perform correctly when executed in combination with other components. They must communicate correctly with each other in the system. i. More specific types of integration testing: 1. User Interface Testing: tests each interface function 2. User Scenario Testing: tester tests each use scenario 3. Data Flow Testing: tests each process when the system performs data processing whether it’s correct to the result 4. System Interface Testing: tests the exchange data with other systems iii. System and Stress Testing: A system and subsystem must meet both the functional and non-functional requirements. i. More specific types of system testing: 1. Requirements Testing: tests whether original business requirements are met 2. Usability testing: tests how convenient the system is to use 3. Security Testing: tests disaster recovery and unauthorized access (how secure the system is) 4. Performance Testing: examine the ability to perform under high loads 5. Documentation Testing: tests the accuracy of the documentation iv. User Acceptance Testing: software must not only operate correctly but must also satisfy the business need and meet all users’ ‘ease of use’ and ‘completeness’ requirements. i. More specific types of Acceptance Testing: 1. Alpha Testing: conducted by users make sure they accept the system

2. Beta Testing: uses real data, not test data to monitor the systems for errors or useful improvements. One of the most important testing(s) is the integration testing, core process of integration testing is implementation.

User Stories & Use Cases User Stories: are short, simple descriptions of a feature told from the perspective of a person who desires the new capability, usually a user or customer of the system. There are several big features, being broken down into several detailed steps on how to achieve those big features. Use Cases: List of actions or event steps typically defining the interactions between role and a system to achieve a goal. Lecture 7 Architecture and Deployment Definitions Architecture: what your system is composed of Deployment: Getting the system to work properly and correctly according to the requirements Object-oriented Paradigm vs. Functional Paradigm Object-oriented: What is it? It is a programming paradigm based on the concept of ‘objects’, which are data structures that contain data, in the form of fields; often known as attributes; and code, in the form of procedures, often known as methods. Separation of data and code is not there, as using object-oriented paradigm means that the codes in the computer program are not loosely-coupled. How you model your data and your code, is basically the same thing. Characteristics: a. Older; easy to understand b. Takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them c. Objects are defined by their states and behaviors the object can perform Advantages: a. Code modularity for easy troubleshooting and debugging processes b. Reuse of code through inheritance c. Flexibility through polymorphism

d. Effective problem solving e. For easy troubleshooting and debugging processes Functional Paradigm: What is it? Is a programming paradigm, a style of building a structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoid changing-state and mutable data. Characteristics: a. Is a non-linear process b. Newer and more complex to understand c. More demand for skills than supply Advantages: a. Good for performing lots of different operations on data that has a fixed, known amount of variation b. Programs are written in higher-level language, easy to comprehend c. Debugging is easier d. Testing is easier, and pure functions lend themselves well to techniques like propertybased testing Object-oriented paradigm sees the world as objects with static characteristics, and everything else proceed from there, Functional paradigm sees the world as a problem based on what you are trying to do, and everything else proceeds from there. Separation of Data and Behaviour in Functional Paradigm Functional Paradigm: a. b. c. d.

Data and behavior are distinctively different things and should be kept for clarity Objects are used but are not the basis of design or development Data is needed to test algorithms only, not to be a part of them Advantages: a. Timeliness: when is data value known b. Structure: single data time set according to a single coordination c. Locality: Data are stored in a limited number of places, easier to manage d. More documentation available widely for people to use e. Separations of concern: i. Data is needed to test algorithms only, not to be a part of them ii. A concern is a set of information that affects the code of a computer program iii. Could be achieved by encapsulating information inside ...