Presentation on theme: "Management Information Systems: Solving Business Problems with"— Presentation transcript:
1 ManagementInformationSystems:Solving BusinessProblems withInformation TechnologyPart One:Business OperationsChapter Four:Security, Privacy, andAnonymityProf. Gerald V. PostProf. David L. Anderson
2 The Growth of Electronic Commerce Business-to-BusinessIncludes up and down stream transactions that can enhance channel coordination and customer relationshipsBusiness-to-ConsumerEncompasses all interaction between the customer and the organizationOpen MarketspaceConnects business, partner, and consumer
3 Web-Based Commerce Model Manufacturer/SupplierCustomersDirectMarketspaceBusiness-to-BusinessBusiness-to-ConsumerIntermediary
4 Operating Effectively in the Business-to-Consumer Boundary Leverage Firm’s Logistical SystemPrice and Manage Online TransactionsOptimize Communication to Key Consumer MarketsAchieve Excellence through Service
5 Develop Business Partnerships Establish Business-to-Business Relationships to Sell Competitively to CustomersStrengthen the Value ChainProvide Value through CommunicationOptimize Business-to-Business Service
6 Virtual Interconnectivity Sell in a Virtual WorldStay Real or Become VirtualCommunicate with a CommunityProvide Value-Add Services in the Marketspace
7 Opportunities and Threats of End-Run Strategies Odd Person OutEstablish Place in Value ChainCompare Information in a Virtual WorldOptimize the Service Offering Across Partner Organizations
8 Managerial Issues for Security TechnicalSocietalEconomicLegalBehavioralOrganizational/Managerial
9 Managerial Issues for Security TechnicalHow will Security be Implemented?What protocols will be the standards of future electronic commerce?What are the future technologies used to “wire” people and households?
10 Managerial Issues for Security SocietalHow will the privacy of individuals be protected?How will consumer data be used?Will consumer data be misused?How do user perceptions of issues reflect reality?
11 Managerial Issues for Security EconomicHow will electronic and physical markets differ?Will economic theories succeed as instantaneous access to information emerges?What will be the price of information?
12 Managerial Issues for Security LegalShould governments continue to subsidize the internet?How will real world laws apply to the legality of virtual sites?Who is liable for information accuracy?
13 Managerial Issues for Security BehavioralHow satisfied will users be with virtual experiences compared to those in the real world?How will a sense of community and social needs be represented through E-Commerce?What are the characteristics of early adopters of E-Commerce?
14 Managerial Issues for Security Organizational/ManagerialWhat are the differences between managing an E-commerce business and a more traditional one?How will the organization of the firm change as E-commerce becomes more prevalent?What products lend themselves to success with E-Commerce?
15 Managerial Issues for Security TechnicalSocietalEconomicLegalBehavioralOrganizational/Managerial
16 Strategic Security Leverage Paradigm ChangetheGameChangetheGameCompetitivePositionCompetitivePositionNature of Conflict;Terms ofCompetitionStrategicLeverageObjectivesStrategiesTactics
17 Systems Development Lifecycle Obsolete SolutionProblem to be SolvedPlanningNew, Related Problem or RequirementAnalysisSupportNew implementation Alternative or RequirementImplementationError (bug)ProblemUnderstandingandSolutionRequirementsImplementedSolutionDesignImplementationAcceptableSolutionStatement
18 Systems Planning Elements PeopleUsers, Management, Information SpecialistsDataHow it is captured, used, and storedActivitiesAutomated and ManualBusiness and Information ApplicationsNetworksWhere data is stored and processedHow data is exchanged between different locationsTechnologyhardware and software used
19 Electronic Commerce Building Block SystemsOwnersSystemsUsersSystemsDesignersSystemsBuilders
20 Differentiation versus Cost Leadership DifferentiatedPlayerSustainablePremiumTechnologyCurveCostLeaderMinimum orMarket-RequiredQualityQuality
21 Is Cost Leadership Sustainable? DifferentiatedPlayerSustainablePremiumNewTechnologyCurveOldTechnologyCurveCostLeaderMinimum orMarket-RequiredQualityQuality
27 Barriers to Information Security Sources Economies of ScaleEconomies of ScopeProduct DifferentiationCapital RequirementsCost DisadvantagesIndependent of SizeDistribution Channel AccessGovernment Policy
28 Four Generic Approaches LoseWinWin/WinWin/Lose orCooperative EquilibriumWinLoseWin/Lose orCooperativeEquilibriumLose/Lose
29 Lose/Lose Structure Defines the Industry War Total Industry Profits are Very Low, Zero, or NegativeIndustry Revenues are Declining, or, at best, steadyProduct Technology is at or past its peak
30 Win/Win Total Industry Revenues and Profits are Growing Rapidly Numerous Players of All SizesProducts and Services are not Standardized
31 Win/LoseTotal Industry Revenues and/or Profits are Constant or are Growing very SlowlySignificant Economies of Scale in Production, Distribution, and/or PromotionNumber of Firms Participating in the Industry is Limited and StableIndividual Participants have, or can obtain, Information Regarding the Relative Positions of the Players
32 Structure Defines the Terms of Competition Wasting Resourcesgeneric advertising rather than focusing on specific market segmentsPrecipitating Unwanted WarfareCausing a full-scale price war when only brand repositioning was necessaryFailing to Anticipate and Adapt to ChangesFollowing historical patternsUnderspending on Advertising
33 Structure Defines Maneuver Standard or Dominant Product EmergesDistribution Channels Limit Firm’s Ability to Determine which Channels to SelectTarget and Market Niches Become More Difficult to DefendSubstitutes Limit Price Increases which Requires Increase in Advertising Expenditure
34 Two Levels of Planning Systems Planning Systems Project Planning Gives Managers, Users, and Information Systems Personnel ProjectsEstablishes what should be doneSets a budget for the total cost of these projectsSystems Project PlanningSetting a plan for the development of each specific systems project
35 Systems Professional Skills Systems PlanningForm project team after proposed systems project is cleared for developmentSystems AnalysisBusiness Systems Analysts knowledgeable in businessGeneral Systems DesignBusiness Systems AnalystsSystems Evaluation and SelectionDetailed Systems DesignWide Range of Systems and Technical DesignersSystems ImplementationSystems analysts, programmers, and special technicians
36 Effective Leadership Style Autocratic StyleCrisis-Style ManagementUsed to Correct Major Problem, such as Schedule SlippageDemocratic StyleTeam-oriented LeadershipGives each team member the freedom to achieve goals which he/she helped setLaissez-Faire StyleHighly-motivated, Highly-Skilled Team MembersPeople who work best alone
37 Project Management Skills PlanningStates what should be doneEstimates how long it will takeEstimates what it will costLeadingAdapts to dynamics of enterprise and deals with setbacksGuides and induces people to perform at maximum abilitiesControllingMonitors Progress Reports and Documented DeliverablesCompares Plans with ActualsOrganizingStaffs a Systems Project TeamBrings together users, managers, and team members
38 CASE/Frameworks Computer-Aided Systems and Software Engineering Increase Productivity of Systems ProfessionalsImprove the Quality of Systems ProducedImprove Software Maintenance Issue
39 CASE/Frameworks Includes: workstations central repository numerous modeling toolsproject managementSystems Development Life Cycle SupportPrototyping ApplicationsSoftware Design Features
40 Central Repository for Models Models Derived from Modeling ToolsProject Management ElementsDocumented DeliverablesScreen Prototypes and Report DesignsSoftware Code from Automatic Code GeneratorModule and Object Libraries of Reusable CodeReverse Engineering, Reengineering, and Restructuring Features
41 Software Maintenance Reverse Engineering Extract original design from spaghetti-like, undocumented code to make maintenance change requestAbstract meaningful design specifications that can be used by maintenance programmers to perform maintenance tasksReengineeringExamination and changing of a system to reconstitute it in form and functionalityReimplementationRestructuringRestructures code into standard control constructssequence, selection, repetition
42 Data DesignDefine all the entities to be dealt with and the relationships between themTransform the conceptual design into logical design wherein all the views are combined and all the resulting data elements are defined and the data structure is syntactically and semantically determinedNormalize this logical design for mathematically minimized redundancy and maximized integrityTransform this logical design to a physical design where the underlying RDBMS, hardware, and use patterns are taken into accountDevelop the SQL DDL code specific to each RDBMS vendor’s product is generated
43 Business Rules For Data Basic selection of what data elements are of interest, what are their characteristics (data type and acceptable range - also called syntactic structure)How they are related to, or dependent on, each other in a business sense (key, foreign key and referential constraint rule - also called the semantic structure)Data Integrity Rules
44 Advantages of Data Analysis “slice and dice” dynamic query supportstandard high-level access language (SQL)minimum data redundancyself-protecting data integrityno insert, delete and update anomalies
45 Relational ModelThe Relational Model for data design is the foundation of the relational database and the industry that produces the “engines” that run them.It puts data design (and data modeling) on a formal, mathematical footing.
46 Relationship Typesa). One-to-one (1:1): means that an occurrence if one OT uniquely determines an occurrence of other OT - and vice-versab). One-to-many (1:n): means that an occurrence of one OT determines an occurrence of the other OT - but not vice-versac). Many-to-many (n:m):means that an occurrence of one OT can be related to many occurrences of other OT - and vice-versa
47 Data RationalizationIdentification of data synonyms and homonyms across multiple and disparate data sources and the creation of a map that points back to their original sources.
48 Data Access Gatewaysits between end users (usually in PC networks) and a legacy databaseaccepts data read requests (expressed as SQL statements)converts the requests to legacy access method instructionsprovides the resulting data to the usersdata flow is one-way read-only.
49 Structured Data Analysis the functions or activities which are to be handled by the systemthe external entities which interact with the systemthe logical data stores, andthe data flows among all the the aboveData flow diagrams (DFD) are used to diagrammatically describe the elements.
50 Entity Relationship Diagrams (ERDs) A method of documenting and visualizing a conceptual data model.
51 Normalization The process based on the business rules for data a set of data elements (attributes) are arranged in a mathematically minimum set of tables (relations), within which all the attributes are dependent on a primary key attribute (the key).
52 Normalization ModelThe SA/Normalization method is based on the use of decomposition rules, which enable one to decompose tables/relations.Database design starts with flat tables/relations, each of which is created out of a data stores in the DFDs and then decomposed into the normal form relations. No conceptual schema of the enterprise is created to express the semantics of its information structure.The SA/IA method is based on the use of grouping rules which map simple relationships in the binary-relationship data model onto normal form relationships.The relational model and the normalization method have been criticized for being too detailed to use at the initial design stage, and for lacking a semantic structure for making unambiguous choices in modeling the enterprise.The IA method incorporates a semantic model of the enterprise which captures its essential semantic features from which the normal form relations are derived.
53 Conversion into Normalized Record Types For every data flow which either enters or emanates from a data store (in the leaf level DFDs), the integral data elements are identifiedFor every data store, a list of the data elements which are entering and emanating are drawn upThe dependencies among all the data elements are analyzed, and the normalization rules are applied in steps so that at every step a given relation is split into more “simple” relationsEvery relation has a key which consists of one or more data elementsEvery non-key data element functionally depends on that entire key and not on part of itNo non-key data element depends on any other non-key data element in the relation (there are no transitive dependencies)
54 Conversion into Normalized Record Types Enter exams dates & roomsList of Exams detailsD1Exams FileDetails of ExamsDetails of Examsfor lecturerfor studentsNotify LecturesNotify Students
55 De-Normalization The process of selectively combining two or more normalized tables into one, ordecomposing one normalized table into two or more
56 Part Description for Model for General Motors “Part #123 that is supplied by GM was assembled on bus 456 on May 28, 1996” is decomposed into the following elementary sentences:a). A part... is supplied by a manufacturer...b). A part... was assembled on a bus...c). The assembly [part*bus] was performed on a date...
57 Part Distribution Model for General Motors Part (p#)Manufacturer (name)Supplier ofSupplied of
58 Relationship Typesa). One-to-one (1:1): means that an occurrence if one OT uniquely determines an occurrence of other OT - and vice-versab). One-to-many (1:n): means that an occurrence of one OT determines an occurrence of the other OT - but not vice-versac). Many-to-many (n:m):means that an occurrence of one OT can be related to many occurrences of other OT - and vice-versa
59 GM Parts Assembly Distribution Model Bus(License #)Manu-facturer (name)Part (p#)SupplierDate (Calc. date)Date of Assembly
60 Data WarehouseAn intermediate, read-only store (usually based in a purchased RDBMS product) and the programs that manage it.Contains recent and summarized data extracted from across some or all of the legacy data systemsPresents a subject-based view
61 Functional Dependency Mathematical term for the key relationship (using rational terminology) between data elements. A data element (attribute) that is functionally dependent on another data element (the key) will always exist in a relation (table) such that a unique value for the key will always “determine” or “locate” or “define a unique value of” the dependent.
62 MetadataData about data that is generally extracted from an existing system or created for a new system and stored in a design repository for developers to use in maintaining or extending the system during its lifecycleMetadata refers to the table, attribute, and key definitions contained in the catalog of a relational database. It can also mean the business rules for data designed for a new design, or the business rules for data thought to be enforced in a legacy system (semantic data structure, sometimes called meta-data, or meta2 data).The actual syntactic and semantic data structure (not just what the documentation might say), including a complete synonym and homonym map, plus the business rules for data that are actually being enforced in the legacy system.
63 Business Administration Graduate School ofBusiness AdministrationLoyola University