1 / 24

Finalizing Scope (functions/level of automation)

Finalizing Scope (functions/level of automation). Finalizing scope in terms of functions and level of automation for each function overlaps with and requires information from: Defining target deployment environment Defining implementation alternatives e.g., build vs. buy

feng
Download Presentation

Finalizing Scope (functions/level of automation)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Finalizing Scope (functions/level of automation) • Finalizing scope in terms of functions and level of automation for each function overlaps with and requires information from: • Defining target deployment environment • Defining implementation alternatives • e.g., build vs. buy • General Approach for including/excluding functions: • Functions deemed mandatory are in scope. • Include as many important functions as budget and schedule allow • Desirable features: delay to later ‘release’ of system • Strategic plan: • Often, genesis of a new system is organization’s strategic plan • Functions that align with strategic plan typically get included in scope

  2. Finalizing Scope (functions/level of automation) • Need to revisit feasibility analysis. Now have much more information to work with. • Economic feasibility • What set of functions give us an optimal return on investment? • What set of functions can we afford? • Schedule and resource feasibility • What can be implemented in time available? • What can be implemented given human and other resources? • Technological feasibility • What can be practically implemented given state of technology and organizations knowledge and experience? • Operational, organizational, and cultural feasibility • What can our organization handle/accept? • How much change is required?

  3. Application Deployment Environment • What is the technical environment in which system will be implemented? • Deployment environment consists primarily of: • Hardware • Networks • System software • Development software • Development methodology and tools • Technical requirements define constraints regarding deployment environment • Organization’s current environment/standards typically drive deployment options

  4. Range of Application Types • Stand-alone applications on mini- and personal computers • Online interactive applications • Distributed applications • Web-based applications

  5. Hardware, System Software, and Networks • Computers range from handheld to super computers • Operating systems range from Windows to Unix • Database management systems range from Oracle to SQL Server to IBM DB2 • Software components and standards range from Java 2 Enterprise (J2EE) to Microsoft .NET • Web servers range from IIS to Apache

  6. Deployment Environment Characteristics to Consider • Compatibility with technical requirements: • Volume of transactions, location of users, etc. • Compatibility among hardware and system software • Required interfaces to external systems • Conformity with IT strategic plan and architecture plans • Cost and schedule

  7. Development Tools • Development environment – programming languages, CASE tools, and other software used to develop application software • Java and Visual Studio .NET are examples • Application deployment environment decisions limit development tool choices • Operating system environment • Database management system (DBMS) • Distributed software standard

  8. Development and System Software Environments • Consists of standards and tools used in an organization to develop systems • Important considerations • Language environment and expertise • Java, C, etc, • Existing CASE tools and methodologies • RUP and Rose, Information Engineering • Required interfaces to other systems • Operating system environment • Unix, Linux, OS390, NT • Database management system environment • Oracle, DB2, SQL Server

  9. Choosing Implementation Alternatives • Many variations on obtaining a system • Facilities management solutions • Packaged, turnkey, ERP software systems • Custom software development • In-house development

  10. Implementation Alternatives ASPs Salesforce. com MySAP.com ERP SAP PeopleSoft Off the shelf packages Simply Accounting We build, consultants build or blended approach

  11. IdentifyingCriteria for Selection • Comparisons difficult • Different proposed systems have strengths in different areas • Need a consistent framework for comparison of alternatives • Criteria • Weights • Scores • Three areas to consider • General requirements • Functional requirements • Technical requirements

  12. Evaluation Framework Weight – importance of criteria vs other criteria Alternatives considered Evaluation Criteria Total 49 Total 42 Score * Weight Score

  13. Evaluation Framework (Expanded)

  14. General Requirements • General requirements include considerations that are important but not directly associated with the computer system itself. • Related to feasibility assessment – alternative must be feasible to be chosen • General requirements examples: • Performance record of the provider • Level of technical support from the provider • Warranties and support services (from outside vendor) • Availability of experienced staff • Development cost • Expected value of benefits • Length of time (schedule) until deployment • Requirements for internal expertise • Organizational impacts (retraining, skill levels)

  15. Technical Requirements • Constraints under which system must operate • Defined by technical requirements identified during information gathering • Categories: • Performance (response time/throughput, etc) • Security and Control • User interface (ease of use, etc.) • Service (number/location of users to be supported) • Operating environment • etc.

  16. Functional Requirements • Need to evaluate alternatives based on how well they meet functional requirements. • Use expanded event table

  17. Evaluating Functional Requirements

  18. Evaluating Technical Requirements

  19. Making the Selection • After rating alternatives, choice can be made • Scores are tabulated and compared

  20. Systems Analysis and Design in a Changing World, 5th Edition Partial Matrix of General Requirements Figure 8-7

  21. Systems Analysis and Design in a Changing World, 5th Edition Partial Matrix of Functional Requirements Figure 8-8

  22. Systems Analysis and Design in a Changing World, 5th Edition Partial Matrix of Technical Requirements‏ Figure 8-9

  23. Contracting with Vendors • Generate a Request for Proposal

  24. Presenting Results and Making Decisions • Compile, organize, and present the alternatives and critical issues in an easy-to-understand but complete manner • Final choice generally made by executive steering committee • Format of documentation and presentation style varies with organization

More Related