Business Analysis & Data Design ITEC-630 Fall 2008

1. Business Analysis &Data DesignITEC-630 Fall 2008 IntroductionProf. J. Alberto Espinosa

2. Textbooks Required:Advanced Use Case Modeling Frank Armour and Granville Miller Addison Wesley, ISBN 0201615924 Optional but highly recommended:Modern Database Management, Hoffer, Prescott and McFadden, 8th edition, Prentice Hall, ISBN 0132212110

3. My Background • Started as New faculty at AU in Fall’02 • Previously at Carnegie Mellon University • PhD and MS in IS from Carnegie Mellon • Also, BS Mech Engineering & MBA • Over 18 years of working experience • Mostly implementing and managing systems • And in management • Specialty: systems implementation and database • Mostly in international/global contexts • Teach: MIS, Systems Analysis, Database • Research focus: • IT support for global & geographically distributed collaboration • Most recently: team coordination across time zones

4. Contact • Office: KSB 33 • Office Hours: Mo 1:30 – 5 PM Th 1:30 – 4 PM • Office Tel: 202-885-1958 • Fax: 202-885-1992 • E-mail: alberto@american.edu

5. 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

6. Business Analysis

7. What is business analysis? “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)

8. About the BusinessAnalysis Profession • 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)

9. Business Analysis Skills Ability to develop a thorough understanding of: • therequirementsto 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.

10. Business Data Design

11. About Business Data Design • Solutions to business problems often involve managing and processing business data into useful information • Important business data design skills – ability to: • Discover data objects that need to be collected and their data elements • Design the most appropriate structure or schema for the data • Design the most appropriate relationships among data objects • Describe the data accurately with appropriate models for implementation • Design Goals -- data collected: is consistent with the business requirements and enterprise architecture; is correct and accurate; has integrity, both within each data object and in how it relates to other objects; and has no redundancy that could cause inconsistent information • Discovering the queries necessary to support the creation, retrieval, and manipulation of data for the business application being implemented • There more than one paradigm for data design: relational database model, object oriented databases, object-relational, etc.

12. The Context of Business Analysis and Data Design:System Development Methods

13. = 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) What is Information Technology (IT) for Business?

14. An arrangement of people, business functions, processes, and IT that interact to collect, store and process, and store data to provide information to support business activities and processes – It is more than just IT!! What is an Information System (IS) for Business?

15. Information Systems IT for Business People,Processes& Business Functions IT Infrastructure(HW, System SW, database, telecom) BusinessApplications(ERP, CRM, SCM, Financial Appl, etc.) + + IS =Business Value !!

16. Business WorldTransactions ERP, SCM, CRM, etc. Decision SupportDistributed CollaborationEnterprise CollaborationFinancial Managementetc. Information BusinessApplications Transaction Processing ServerAppl Client Appl Microcomputers Mainframes Client/Server Computing ITInfrastructure Database DB DB Ubiquitous Computing Routers Security,Firewalls Distributed Computing (Local/Wide area) Networks Inter-Networking (Internet, Intranets)Virtual Private Networks ITEC630 Information Technology (IT) and Business

17. Requirements for a Cool House:(first meeting with the client: a very high level description of the house) • 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

18. A Cool House: A Sketch(a visual representation to discuss w/client)

19. A Cool House: A Scale Drawing(a more detailed representation to discuss w/client)

20. A Cool House: The Blueprints(very specific dimensions to discuss w/client and then give to builders for construction: i.e., communicating client requirements)

21. 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, ITEC630

22. 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 1. Analysis

23. Analysis Involves: Feasibility Analysis: • System concept, project blastoff • Technical, economical & operational feasibility Risk Analysis: • Identifying (technical, project & business) threats to the viability of the system and the probability that they materialize • Affected by system size, business impact, customer characteristics, software process maturity, development environment, technological complexities, development staff experience, etc. Requirements Analysis: Understanding the work that the system needs to do and, the qualities the system must have ITEC630

24. Requirements Analysis • Functional (Behavioral) Requirements – what the system needs to do: “The work” • Non-functional Requirements – the qualities of the system (e.g., speed, reliability, capacity) • Project requirements – costs, deliverables, deadlines • Described in the“System Requirements Specification”

25. Why is requirements analysis so important? Bohem, Barry R. 1981. Software engineering economics. Englewood Cliffs, N.J.: Prentice-Hall.

26. correct requirements wrong requirements design based on wrong requirements correct design wrong design code based on wrong requirements correct code code based on wrong designs wrong code Errors Propagate and Grow problem

27. 2. Design 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” ITEC 630: Business Data Design and Basic Introduction to Interface Design ITEC630

28. 3. Implementation 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.

29. 4. Testing Ensuring that the system performs as required 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 Methods: • 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) ITEC630 (Test Cases)

30. 5. Conversion (i.e., Installation) Important Issues: • CONVERSION PLAN:Schedule for conversion • DOCUMENTATION:Description of how system works • USER TRAINING Conversion Methods: • PARALLEL:Old & new run same problems. Give same results? • DIRECT CUTOVER:Risky conversion to new system • PILOT:Introduce into one area. Does it work? Yes: introduce into other area • PHASED:Implement the system in stages

31. 6. Production & Maintenance • PRODUCTION:Review by users & operators User support • MAINTENANCE: Upgrades Bug fixes

32. EFFORT DISTRIBUTION Systems Analysis & Design Maintenance Testing & Integration Implementation

33. Systems Development Models • Linear Sequential ModelsSystem development progresses in a straight line fashion • Evolutionary ModelsSystem development is done in iterations

34. Systems Analysis Design Testing and Conversion Production & Maintenance System Development Life Cycle (SDLC)or the “Waterfall” Model (Linear Sequential) Implementation

35. SDLC (“Waterfall”) Model Pros & Cons Pros: • Oldest and most widely used model • Life cycle concept is very useful • OK when requirements are certain and stable Cons: • Early errors detected late are very costly • Not very useful when requirements are uncertain • Many real projects rarely follow a sequential flow • Often difficult to know all requirements early on • Programmers have to wait until the whole design is finished

36. The Incremental Model(Linear Sequential) Core Product Analysis Design Integration +Regression Testing Programming Increment 1 Analysis Testing,etc. Design Programming Increment 2 Analysis Testing,etc. Design Etc. Programming Testing,etc.

37. Incremental Model Pros & Cons Pros: • Core functionality can be provided quickly • Increments can be planned to manage technical risks (e.g., increment, evaluate, increment, evaluate, etc.) Cons: • Takes a long time to finish entire system • Later increments may never get done

38. Identify Requirements Develop Prototype Install and Use Refine Requirements Develop Full System The Prototyping Model (Evolutionary) No Yes User satisfied ? Feedback

39. Prototyping Model Pros & Cons Pros: • Good when input/output requirements and user interface not clear initially • Good for development of “visible” parts of the system • Fosters communication with customers and users • Helps identify and refine requirements Cons: • False expectations: customer sees what appears to be a working product • Not good for “invisible” aspects of system • Early unfinished prototypes may perpetuate themselves

40. The Spiral Model (Bohem)(Evolutionary) Construction (Implementation) Testing & Release(Conversion) Engineering (Analysis & Design) Customer Communication & Evaluation(Business Requirements) RiskAnalysis Planning

41. The Spiral Model Pros: • Each loop allows the team to assess risks and adjust the plan • More realistic approach for large projects • Conceptually sound idea Cons: • Not many – the basic concept is widely adopted • Is the foundation for the Unified Process (UP)

42. Object-Oriented (OO) Analysis • Most prevalent software system development paradigm today • In which a system is conceptualized by discovering physical objects that the system needs to represent – e.g., customers, locations, students, classrooms, invoices, etc.) • And discovering their attributes (i.e., data elements – e.g., name, SSN, etc.) and behaviors (i.e., programs – e.g., place an order) • More on OO later in the course

43. Standards Standards are necessary when many people are involved in a system development effort. There are many types of standards, but two very important ones are standards about: (1) notation and (2) process • A notation (i.e., a language) is necessary to describe the system. Standard notations describe the symbols to use in models and other analysis artifacts. We will use the UML (Unified Modeling Language) • A process is necessary to define the sequence of activities that will be undertaken to gather requirements and then design and implement the system: We will use the UP (Unified Process)

44. Unified Modeling Language (UML) • UML a standard for notations and methods to express OOA/D • UML is the most widely adopted standard diagramming notation to describe systems today • Proposed by Booch, Jacobson & Rambaugh (the “Three Amigos”) to unify their individual (most widely used) notationsSee Object Mgt Group site: http://www.omg.org/ • Main purpose of the UML: communication!! • It is intended for OO Analysis and Design (OOA/D) • You can do OOA/D without UML using other notations • Similarly, you can use aspects of UML for non OOA/D • UML is up to version 2.0, textbook UML 1.3, MS Visio UML 1.2For more info on UML and versions, see: http://www.kobryn.com/

45. Important UML Models • Use Cases – a set of scenarios of system uses, each tied together by a common user goal • Activity Diagrams – diagrams that explain use case workflows (sometimes useful, but use case text is often preferred) • Class Diagrams – describes the types of objects in a system and the static relationships among them • Domain Model – like a class diagram (and/or other models), but it only shows noteworthy objects and elements, used to provide a conceptual skeleton view of the system • Interaction Diagrams – models that describe how groups of objects collaborate • Class-Responsibility-Collaboration (CRC) Cards – text version of interaction diagrams, not part of UML but often used with UML • State Diagrams – models that describe possible states of objects and how the object’s state changes with events (e.g., order status)

46. The Unified [System Development] Process (UP) • A system development process defines the activities undertaken to building, deploy, and maintain systems • UP: a popular SW development process used with OO methods • UP was also developed by the “Three Amigos” • UML and UP are independent – you can use UML without UP, or UP without UML, but they were both conceptualize to work together • Rational UP (RUP): a refinement of the UP formulated by the “Rational Corporation” now owned by IBM, widely adopted today.See: http://www.rational.com/

47. Key Aspects of the UP • Iterations: “timeboxed” – i.e., of fixed time length of 2-6 weeks – date slippage is discouraged – removing tasks or requirements from the iteration is preferred • Workshops: each iteration begins with at 1-2 day workshop to discuss the scope of the iteration and plan accordingly. • 4 Phases:inception, elaboration, construction and transition – this course deals with the inception and elaboration phases • Disciplines (originally called “workflows” until 2001): a set of related system development activities (e.g., analysis, design, etc. – note: these are considered “phases” in the Waterfall model) • Artifacts: working products such as code, database schemas, text documents, diagrams, models, etc. • Development Case: articulates upfront which artifacts (not all artifacts need to be employed) will be used in the particular development project

48. Iterations, Disciplines & Workflows in the UP Incep Elab 1 Elab 2 etc. Source: Larman book ch.2, p.21

49. Development CaseFor this Course S – Start; R – Refine

50. Important Things to Keep in Mind • Ceremony or Formality: • High ceremony: lots of formal deliverables, meetings, etc. • How much? it depends • The right process? it varies for each company • Requirements and Design = communication exercises • No need to use all diagrams or artifacts • No need to note everything, only what is noteworthy • Avoid overdoing requirements (i.e., analysis paralysis): keep it simple, but accurate Let’s look at the Class Schedule once again Let’s look at the Final Project