Business Analysis ITEC-630 Fall 2009

1. IntroductionProf. J. Alberto Espinosa Business Analysis ITEC-630 Fall 2009

2. 2

3. 3 Class Web Site Current versions of syllabus, class schedule, lecture notes, and homework assignments will be posted on the Blackboard class web site. Course Syllabus also available at:http://auapps.american.edu/~alberto/itec630/syllabus.html Class Schedule also available at:http://auapps.american.edu/~alberto/itec630/schedule.html All homework assignments, lecture slides, and other class materials will be available via the Class Schedule link above, and also via Blackboard Class announcements and grades will be available via Blackboard only

4. 4 “The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.” Source: International Institute of Business Analysis (iiBA)

5. 5

6. 6 Information Technology (IT) and Business

7. 7 = IT Infrastructure: the hardware, system software, telecommunications/networks and data storage supporting all business applications + Business Applications: software used to manage particular business functions or processes (e.g., accounting, supply chain management)

8. 8 An arrangement of people, business functions, processes, and IT which interact to collect, store and process, and store data to provide information to support business activities and decisions It is much more than just IT!!

9. 9

10. 10 3 bedrooms, dinning room, living room, kitchen, laundry room, 2-1/2 bathrooms Back patio, access from the kitchen 2-floors + basement 2-car attached garage w/extra room on top & driveway Landscaped front yard & small trees in the backyard 2 windows, one on each side of front door 2 windows on 2nd floor above with 1st floor windows 2 small windows above garage on extra room

11. 11

12. 12

13. 13

14. 14 SYSTEM DEVELOPMENT All the activities that go into producing and IS solution:  0. Vision Analysis Design Implementation Testing Conversion Production & Maintenance Degree of ceremony or formality? Depends on size, risk,

15. 15 A communication exercise between system users and system developers An analysis of the “problems” to be solved by an information system Developing an understanding of “the work” that the system needs to perform Developing an understanding of “what” the system needs to do Implication: Understanding the business problem is critical before offering solutions

16. 16 An analysis of the “solutions” to the problems identified during systems analysis Developing and understanding of “how” the system needs to do what was identified during systems analysis, per the “requirements specification” Implication: Can’t design a solution until you’ve analyzed the problem

17. 17 Selection, acquisition, production and assembly/integration of the necessary components of the system For systems that require software development, translating the conceptual design into specific software instructions to accomplish the work. Implications: Can’t purchase off-the-shelf software until you’ve until you’ve analyzed the requirements Can’t build an application until you’ve designed

18. 18 4. Testing Test Types: UNIT TESTING: Ensure that each part of the system work well individually SYSTEM TESTING: Ensure that all the parts work well together REGRESSION TESTING: Ensure that new software work well with the existing software ACCEPTANCE TESTING: By users and/or clients BLACK BOX TESTING: Testing if the system does what is supposed to, per requirements specifications, without inspecting the internals of the system CLEAR BOX TESTING: Inspecting and testing the internals of the system (opening the black box) Implication: Analysis artifacts (e.g., use cases) can be used for testing (e.g., acceptance and black box testing with “test cases”)

19. 19 5. Conversion (i.e., Installation) Important Conversion Issues: CONVERSION PLAN: Schedule for conversion DOCUMENTATION: Description of how system works USER TRAINING Conversion Methods: PARALLEL: Old & new run simultaneously DIRECT CUTOVER: Risky conversion to new system PILOT: Introduce first in one area, domain, location PHASED: Implement the system in stages Implication: Analysis artifacts (e.g., use cases) can be used to develop user manuals and other system documentation

20. 20 6. Production & Maintenance PRODUCTION:  Review by users & operators User support MAINTENANCE:  Upgrades Bug fixes Implication: Requirements are not static

21. 21 EFFORT DISTRIBUTION

22. 22 Systems Development Models

23. 23 System Development Life Cycle (SDLC)or the “Waterfall” Model (Linear Sequential)

24. 24 SDLC (“Waterfall”) Model Pros & Cons

25. 25 The Incremental Model(Linear Sequential)

26. 26 Incremental Model Pros & Cons

27. 27 The Spiral Model (Bohem)(Evolutionary)

28. 28 The Spiral Model

29. 29 Object-Oriented (OO) Analysis

30. 30 Standards

31. 31 Unified Modeling Language (UML)

32. 32 Important UML Models/Artifacts

33. 33 The Unified [System Development] Process (UP)

34. 34 Key Aspects of the UP

35. 35 Iterations, Disciplines & Workflows in the UP

36. 36 Development CaseFor this Course

37. 37 Important Things to Keep in Mind

38. 38

39. 39

40. 40 The New Way:Focus on Business Processes A process: Manner in which work is organized and coordinated to produce a product or service Some business processes take place within a function Some others cut across multiple business functions Concrete work flows of material, information, and knowledge Unique ways to coordinate work, information, and knowledge Example: processing a customer order

41. 41 A Process May Cut Across Multiple Departments

42. 42

43. p.43 EA Process (Armour et al 1999, TOGAF): -Can’t always architect from the ground up A very dynamic process -Change is difficult-Can’t always architect from the ground up A very dynamic process -Change is difficult

44. 44

45. 45 “The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.” Source: International Institute of Business Analysis (iiBA)

46. 46 Business analysts used to be called “systems analysts” Business analyst is the preferred title today in recognition of the fact that business strategies and system implementations need to be tightly aligned, so the analyst needs to thoroughly understand business goals, functions and processes, more than systems per se (CIO Magazine) A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems (iiBA) The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals (iiBA)

47. 47 Ability to develop a thorough understanding of: the requirements to solve a business problem, often with a system implementation how the proposed system or solution will interoperate or integrate with the existing systems and technology in which the new system will operate. how the proposed system or solution fits the existing enterprise architecture and business strategies the business problem from multiple perspectives: business, user, functional, quality of service, implementation, etc.

48. 48 See iiBA: http://download.theiiba.org/default.asp?fileid=26&categoryid=3 Enterprise analysis Requirements planning and management Requirements elicitation Requirements analysis Communication and documentation Solution assessment and validation

49. 49 Enterprise architecture: “The explicit description and documentation of the current and desired relationships among business and management processes and information technology.” – U.S. Office of Management and Budget, Circular A-130 The blueprint for creating enterprise-wide systems in alignment with business needs It involves preparing all diagram, models and descriptions of: all business processes, functions, information and technology infrastructure It often involves analyzing the current architecture, conducting gap analysis and developing a target architecture along with a transition plan The business analyst needs to understand the enterprise strategies, which provides “the context” in which enterprise analysis is conducted In modern, complex, dynamic and fast-paced business environments, the enterprise strategy and information technology are tightly aligned, but the strategy evolves rapidly, presenting substantial challenges for business analysts. In large complex organizations, senior business analysts are key participants in the strategic planning process.

50. 50 It involves: Identifying team roles: project manager, business analysts, developers, quality assurance analysts, trainers, application architects, data modeler, database analyst, infrastructure analyst, information architect, subject matter (functional) experts, etc. Identifying stakeholders (who will provide requirements information): executive sponsor, solution owner (client), end users, functional managers, investors, etc. Distribute responsibilities amongst business analysts and other team members and define coordination, team communication and knowledge sharing mechanisms and processes Define risk monitoring and management approach for each identified risk Define the requirements and system development method (e.g., traditional, object oriented, unified modeling language—UML, etc.) Define the requirements and system development process (e.g., system development life cycle, iterative, unified process—UP) Manage requirements change and scope: requirements creep is a big problem Define and collect project metrics and reporting mechanisms Other project planning and project management activities

51. 51 A “key” BA task – it provides the foundation for solutions to business needs – it helps develop a thorough understanding of the business process that will be automated and the essential needs of the system. It involves: Eliciting the these essential needs from stakeholders – dependent on the knowledge and willingness of stakeholders to share information “Trawl” for knowledge: business processes, baseline system, target system Methods: interviews, surveys, focus groups, requirements workshops, observations, prototyping, written documents, etc. Analyze all interfaces – human and external systems Document (i.e., record) all requirements identified (and the source) – requirements notes, cards, etc. Establish priorities and verification (measurement) parameters Beware of “scope creep”

52. 52 “The objective is to define and describe the characteristics of an acceptable solution to a business problem, so that the project team has a clear understanding of how to design and implement it” (iiBA) It involves: Developing analysis models and artifacts Can be textual or diagrams – beware of over-diagramming And “transitional artifacts” that connect the multiple models – e.g. CRUD and other matrices Methods: business process analysis, object-oriented (OO) analysis, structured analysis Requirements: functional, non-functional, project, assumptions, constraints, etc.

53. 53 The objective is to develop an accurate understanding of the business problem and clearly articulate the solution. It involves: Communication skills are critical – two ways: not only clearly articulating things verbally and in writing, but also listening effectively Selecting the appropriate models, artifacts and other requirements documents formats. Describing models and text artifacts clearly, accurately and concisely Key deliverable: “requirements specification” representing the BA’s “demonstrated understanding” of the business and processes that need to be handled by the system and its necessary capabilities. These specs will serve as the foundation for: effort estimation, budgeting, resource allocation, contractual terms, and implementation planning, etc. Preparing effective presentations for clients and stakeholders.

54. 54 Two key aspects: (1) evaluation if the proposed solution meets business needs (and the architecture analysis) and (2) if the solution was implemented correctly (per requirements) Evaluate proposed solution, it involves: Requirements reviews to evaluate if they are accurate, complete, clear, non-redundant, consistent (with architecture and business needs), feasible, correctly prioritized, etc. Obtaining signoff from clients and stakeholders – helps buy in and reduce “feature churn” Evaluate correct implementation, it involves: Working with Quality Assurance teams Mapping analysis artifacts to design artifacts Mapping implemented system features to requirements artifacts Black box testing of the system implemented – e.g., using test cases Evaluating non-functional requirements and technologies used Evaluating usability and interfaces (human and system)

55. 55 Course Content Business analysis overview (done) Requirements analysis Introduction to business process analysis Use case analysis – functional requirements Data/information analysis Project management issues