Presentation is loading. Please wait.

Presentation is loading. Please wait.

A U Introduction Prof. J. Alberto Espinosa Business Analysis & Data Design ITEC-630 Fall 2008.

Similar presentations


Presentation on theme: "A U Introduction Prof. J. Alberto Espinosa Business Analysis & Data Design ITEC-630 Fall 2008."— Presentation transcript:

1 A U Introduction Prof. J. Alberto Espinosa Business Analysis & Data Design ITEC-630 Fall 2008

2 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 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 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.edualberto@american.edu

5 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 http://auapps.american.edu/~alberto/itec630/syllabus.html Class Schedule also available at: http://auapps.american.edu/~alberto/itec630/schedule.html 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 6 Business Analysis

7 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 8 About the Business Analysis 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 9 Business Analysis Skills 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.

10 10 Business Data Design

11 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: o Discover data objects that need to be collected and their data elements o Design the most appropriate structure or schema for the data o Design the most appropriate relationships among data objects o 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 o 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 12 The Context of Business Analysis and Data Design: System Development Methods

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

14 14 What is an Information System (IS) for Business? 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!!

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

16 16 Information Technology (IT) and Business Business World Transactions Transaction Processing Business Applications IT Infrastructure Database Mainframes Information Decision Support Distributed Collaboration Enterprise Collaboration Financial Management etc. ERP, SCM, CRM, etc. Microcomputers (Local/Wide area) Networks Client Appl Server Appl Client/Server Computing Distributed Computing DB Ubiquitous Computing Security, Firewalls Inter-Networking (Internet, Intranets) Virtual Private Networks Routers ITEC 630

17 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 2 nd floor above with 1 st floor windows 2 small windows above garage on extra room

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

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

20 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 21 SYSTEM DEVELOPMENT All the activities that go into producing and IS solution: 0. Vision 1.Analysis 2.Design 3.Implementation 4.Testing 5.Conversion 6.Production & Maintenance Degree of ceremony or formality? Depends on size, risk, ITEC 630

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

23 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 ITEC 630

24 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 25 Why is requirements analysis so important? The cost of fixing and error in requirements is: Times largerIf discovered during 5Design 10Implementation 20Testing 100Operations Bohem, Barry R. 1981. Software engineering economics. Englewood Cliffs, N.J.: Prentice-Hall.

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

27 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 ITEC 630

28 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 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) ITEC 630 (Test Cases)

30 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 31 6. Production & Maintenance PRODUCTION: Review by users & operators User support MAINTENANCE: Upgrades Bug fixes

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

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

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

35 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 36 The Incremental Model (Linear Sequential) Analysis Design Programming Testing, etc. Core Product Analysis Design Programming Testing, etc. Analysis Design Programming Testing, etc. Increment 1 Increment 2 Etc. Integration + Regression Testing

37 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 38 The Prototyping Model (Evolutionary) Identify Requirements Develop Prototype Install and Use User satisfied ? No Feedback Refine Requirements Develop Full System Yes

39 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 40 The Spiral Model (Bohem) (Evolutionary) Planning Engineering (Analysis & Design) Construction (Implementation) Testing & Release (Conversion) Customer Communication & Evaluation (Business Requirements) Risk Analysis

41 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 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 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 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) notations See Object Mgt Group site: http://www.omg.org/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.2 For more info on UML and versions, see: http://www.kobryn.com/http://www.kobryn.com/

45 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 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/http://www.rational.com/

47 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 48 Iterations, Disciplines & Workflows in the UP Incep Elab 1 Elab 2 etc. Source: Larman book ch.2, p.21

49 49 Development Case For this Course DisciplineUP Artifact Incept I1 Elab E1..En Constr C1..Cn Trans T1..Tn Business ModelingDomain ModelS Analysis VisionSR Use Case ModelSR Supplementary SpecSR GlossarySR Design Design ModelSR SW Architecture DocS Data ModelSR Implementation Implementation ModelSRR SW Development PlanSRRR TestingTest ModelSR Dev EnvironmentDevelopment CaseSR S – Start; R – Refine

50 50 Important Things to Keep in Mind Ceremony or Formality: o High ceremony: lots of formal deliverables, meetings, etc. o 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 againClass Schedule Let’s look at the Final ProjectFinal Project


Download ppt "A U Introduction Prof. J. Alberto Espinosa Business Analysis & Data Design ITEC-630 Fall 2008."

Similar presentations


Ads by Google