6/29/ Professor Lili Saghafi

Transcription

1 6/29/ Professor Lili Saghafi

2 MANAGING INFORMATION TECHNOLOGY Lecture 9 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT By : Prof. Lili Saghafi 1-2

3 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT Large firms purchase software packages whenever feasible, but development of custom software still highly important Custom methodology also used by software companies who develop products for many different buyers Approaches for developing custom applications: - Traditional Systems Development Life Cycle (SDLC) - Prototyping - Rapid Application Development (RAD) - Agile Development 9-3

4 SYSTEMS DEVELOPMENT LIFE CYCLE Systems development life cycle (SDLC) - Highly structured process for developing customized applications - Requires a lot of documentation and formal reviews at end of each major step - Output from one step = input to next step (Waterfall model) SDLC Waterfall 9-4

5 9-5

6 SYSTEMS DEVELOPMENT LIFE CYCLE SDLC Waterfall: 8 Steps in 3 phases or 5 phases Figure

7 SYSTEMS DEVELOPMENT LIFE CYCLE Typical SDLC project costs by Steps in 3 Phases 9-7

8 Definition Phase SDLC DEFINITION PHASE Feasibility Analysis (3 types) 1. Technical 2. Operational 3. Economic 4. Schedule 9-8

9 SDLC DEFINITION PHASE Technical Feasibility Primary responsibility of the IS analyst Based on: - Knowledge of current and emerging technological solutions - IT expertise of in-house personnel -Anticipated infrastructure needed to both develop and support the proposed system 9-9

10 SDLC DEFINITION PHASE Operational Feasibility Primary responsibility of the business manager Entails assessing the degree to which a proposed system addresses the business issues that gave rise to the idea for a new information system Economic Feasibility Business managers and IS analysts work together to prepare a cost/benefit analysis IS analyst responsible for establishing the developmental costs for the project Schedule feasibility 9-10

11 Feasibility analysis SDLC DEFINITION PHASE Typical Deliverable:10-20 page document: - Executive overview and recommendations -Description of what system would do and how it would operate - Analysis of costs and benefits - Development plan 9-11

12 SDLC DEFINITION PHASE Requirements Definition Focuses on processes, data flows, and data interrelationships rather than a specific physical implementation Requirements are gathered by: 1. Interviewing individuals or work groups 2. Reviewing documents 3. Observing employees doing their jobs 4. Questionnaire 5. Survey 9-12

13 SDLC DEFINITION PHASE Requirements Definition Deliverable = systems requirements document: 1. Detailed descriptions of inputs and outputs, processes used to convert input data to outputs 2. Formal diagrams and output layouts 3. Revised cost/benefit analysis 4. Revised plan for remainder of project Approved by business managers before next phase begins 9-13

14 SDLC CONSTRUCTION PHASE Construction Phase Begins only after the systems requirements document from the Definition phase is approved Three steps: - System design - System building - System testing 9-14

15 SDLC CONSTRUCTION PHASE System Design Includes: - Deciding what hardware and software to use - Designing structure and content of databases - Defining programs and their interrelationships Critical step for quality system: 9-15

16 System Design SDLC CONSTRUCTION PHASE Deliverable: detailed design document -Models, such as diagrams of system s physical structure - Descriptions of databases -Detailed specification for each program in the system -Plan for the remaining steps of the Construction phase 9-16

17 System Building SDLC CONSTRUCTION PHASE Includes: - Producing the computer programs -Developing or enhancing the databases and files to be used by the system - Procuring new hardware and support software Documentation is a major mechanism of communicating among members of the project team 9-17

18 SDLC CONSTRUCTION PHASE System Testing by IS specialists Time-intensive step (if executed well) -Each module of code is tested - Modules are assembled into subsystems and tested -Subsystems are combined and entire system is integration tested 9-18

19 SDLC CONSTRUCTION PHASE System Testing by Users User Acceptance Testing: Ensures that the system performs reliably and does what it is supposed to do in the user environment Who might participate in User Testing? 9-19

20 SDLC IMPLEMENTATION PHASE Implementation Phase Success of this phase is highly dependent upon business manager involvement - Installation - Operations - Maintenance 9-20

21 Installation Includes: SDLC IMPLEMENTATION PHASE - Building files and databases -Converting relevant data from one or more old systems to the new system - Training system users Installations that involve converting data from an old system to a new one can be as difficult to implement as systems to automate totally new functions or processes 9-21

22 SDLC IMPLEMENTATION PHASE Installation Four Approaches to Convert from an old System: Parallel: organization operates old system in parallel with new system until new system is working sufficiently Pilot: new system is introduced to only one part of the organization first Phased: new system is implemented one component at a time Cutover: old system is totally abandoned as soon as the new system is implemented Fig

23 Operations SDLC IMPLEMENTATION PHASE New application that is operational is referred to as in production mode Project team is disbanded at this time or shortly thereafter Requires two types of documentation -Systemdocumentation for IS specialists who operate and maintain the system - User documentation for those who use the system 9-23

24 Maintenance SDLC IMPLEMENTATION PHASE The process of making changes to a system after it has been put into production mode Reasons for maintenance Correct errors in the system Adapt the system to changes in the business environment Enhance or improve the system beyond the original system requirements 9-24

25 Maintenance SDLC IMPLEMENTATION PHASE In the past, maintenance step has incurred about 80% of total costs over a system s life In the 1990s, systems development resources heavily devoted to system maintenance versus new system development: -75% to run and maintain existing systems -35% to build/buy new systems 9-25

26 Maintenance SDLC IMPLEMENTATION PHASE Common Problems: - Documentation may not be updated when changes to the system are made, causing problems for future maintenance - Changes to one part of the system may have an unanticipated effect on other parts of the system (i.e.,a ripple effect ) - Programmers generally prefer new development, not maintenance, so work may go to least experienced programmers 9-26

27 SDLC IMPLEMENTATION PHASE Maintenance Business managers need to be aware that: - Maintenance can introduce new errors into the system - If IT resources not available, there may be long delays before a requested system change is worked on, creating gaps in system performance and the needs of an organization 9-27

28 SYSTEMS DEVELOPMENT LIFE CYCLE The SDLC project team Usually a temporary team for specific project Includes appropriate representatives from business units, as well as IS personnel Led by project manager - Usually from IS, but can be from business unit (or both) - Responsible for success of project: delivering quality system on time and within budget 9-28

29 SYSTEMS DEVELOPMENT LIFE CYCLE Three project characteristics associated with successful outcomes: 1. Manageable project size 2. Accurate requirements definition Cost of corrections increases as development life cycle advances 3. Executive sponsorship 9-29

30 Challenge in System Development 1. Data and Data conversion 2. Managing expectations 3. Managing changes / Change management 9-30

31 SYSTEMS DEVELOPMENT LIFE CYCLE Advantages and Disadvantages 9-31

32 Prototyping PROTOTYPING METHODOLOGY Is a type of evolutionary development process: enables creation of system (or part of system) quickly, then system is revised after initial trial(s) by user(s) Takes advantage of fourth generation procedural languages and relational database management systems Can be used as a complete alternative to the SDLC or within an SDLC process 9-32

33 PROTOTYPING METHODOLOGY Examples of Prototyping goals: First-of-a-series a completely operational prototype used as a pilot Selected features only some essential features included in prototype, more added later 9-33

34 PROTOTYPING METHODOLOGY The Prototyping Steps: 9-34

35 Project Team: PROTOTYPING METHODOLOGY IS team members who can quickly build systems using advanced tools Business users committed to working closely with IS developers to try out and refine prototype 9-35

36 Advantages: PROTOTYPING METHODOLOGY Only basic requirements needed at front end Used to develop systems that radically change how work is done, so users can evaluate Allows firms to explore use of new technology Working system available for testing more quickly Less strong top-down commitment needed at front end Costs and benefits can be derived after experience with initial prototype Initial user acceptance likely to be higher 9-36

37 Disadvantages: PROTOTYPING METHODOLOGY End prototype may lack security and control features needed for the final system May not undergo rigorous testing Final documentation may be less complete More difficult to manage user expectations 9-37

38 PROTOTYPING METHODOLOGY Prototyping within an SDLC Definition Phase 1. To help users define system requirements such as input and output screens 9-38

39 PROTOTYPING METHODOLOGY Prototyping within an SDLC Definition Phase 2. Used for a pilot implementation of a working prototype before Construction using SDLC approach 9-39

40 RAPID APPLICATION DEVELOPMENT (RAD) RAPID APPLICATION DEVELOPMENT (RAD) Hybrid methodology: combines aspects of SDLC and prototyping Goal = produce a system more quickly than an SDLC alone 9-40

41 RAPID APPLICATION DEVELOPMENT (RAD) A common RAD technique is: JOINT APPPLICATION DEVELOPMENT (JAD) Team of users and IS specialists engage in an intense and structured process in order to minimize total time required for gathering information from multiple participants 9-41

42 RAPID APPLICATION DEVELOPMENT (RAD) 9-42

43 CASE TOOLS Computer Aided Software Engineering (CASE) Any software tool used to automate one or more steps of a software development methodology 9-43

44 AGILE DEVELOPMENT Alternative methodology for smaller projects Based on four key values: 1. -Simplicity 2. - Communication 3. -Feedback 4. -Courage AGILE Manifesto 9-44

45 9-45

46 AGILE DEVELOPMENT extreme programming (XP) - Programmers write code in pairs - Use simple design and frequent testing - Three program design characteristics: 1. System must communicate everything you want to communicate 2. System must contain no duplicate code 3. System should have the fewest number of components as possible 9-46

47 AGILE DEVELOPMENT Scrum, The Scrum methodology marks a departure from waterfall development. Well-orchestrated movement of project updates between team members - Similar to the coordination in a rugby scrum - Emphasizes: - Independent project teams - Coordination and communication between and within teams - Iterative and continuous monitoring of work - Highly efficient work methods Approach utilizes: - Daily Scrum meeting -Scrum of Scrum meeting - Sprint planning meeting - Sprint review meeting - Scrum uses the real-world progress of a project not a best guess or uninformed forecast to plan and schedule releases Rugby Scrum 9-47

48 9-48

49 9-49

50 9-50

51 9-51

52 9-52

53 9-53

54 9-54

55 9-55

56 9-56

57 Agile Scrum 9-57

58 SOURCING SOFTWARE PROJECTS Outsourcing is an alternative for: Computer and Network Operations Application Development (and Maintenance) Onshore outsourcing: contracting with companies within the same country or region Offshore outsourcing: contracting with companies not within the same country or region - Special risks include: language and cultural barriers, risk of piracy of intellectual property - Best alternative for application development outsourcing when system requirements are well defined and remain stable 9-58

59 SOURCING SOFTWARE PROJECTS Potential Advantages of Application Outsourcing in General - Makes use of technical expertise not available in-house -Temporarily expands capacity of IS workforce to complete projects more quickly - Frees up internal IS resources to work on strategic or proprietary projects Potential Advantages of Offshore Outsourcing in General - Lower labor costs and 24/7 availability 9-59

60 SOURCING SOFTWARE PROJECTS Outsourcing Applications: some best practices - Manage expectations, not staff - Take explicit actions to integrate the offsite workers - Communicate frequently - Use a project management office - Begin small - Use secure and redundant communication links - Hire legal expertise for offshore contracts 9-60

61 USER APPLICATION DEVELOPMENT (UAD) Application development by non-is professionals has grown rapidly with the introduction of user tools (hardware and software) During the 1970s most IS managers did not expect PCs to be used in a corporate setting - Many PCs were purchased by business managers without the IS organization s involvement - The primary motivator was a new type of PC application: spreadsheet programs Over time, small applications using database software (such as Microsoft Access) also were commonly developed by end users 9-61

62 USER APPLICATION DEVELOPMENT (UAD) Advantages of UAD - Users do not have to explain their information requirements to an analyst from an IS unit who is not familiar with the business context - Users do not have to wait for IS resources to be assigned to work on their application project -Business managers have more control over the development costs and timelines 9-62

63 USER APPLICATION DEVELOPMENT (UAD) Disadvantages of UAD -Less attention typically given by user developer to application controls (security, data quality) - Loss of opportunities for application integration - User developed applications are more likely to reinvent functionality found in other applications and opportunities to share data across applications are missed. -Increased operational risks due to a job change of the user developer 9-63

64 . COMMON DATA QUALITY PROBLEMS IN SPREADSHEETS Mechanical errors Logic errors Omission errors Qualitative errors Typing errors, pointing errors or other simple slips Have a high chance of being caught Incorrect formulas due to choosing the wrong algorithm or creating the wrong formula to implement the algorithm Eureka errors refer to easy-toproof errors Cassandra errors are difficult-toproof Things left out of the model that should be there These are difficult errors to detect Flaws that do not produce immediate quantitative errors, but can lead to quantitative errors later 9-64

65 MAGNITUDE OF SPREADSHEET ERRORS Fidelity's Magellan Fund example "During the estimating process, a tax accountant is required to transcribe the net realized gain or loss from the fund's financial records (which were correct at all times) to a separate spreadsheet, where additional calculations are performed. The error occurred when the accountant omitted the minus sign on a net capital loss of $1.3 billion and incorrectly treated it as a net capital gain on this separate spreadsheet. This meant that the dividend estimate spreadsheet was off by $2.6 billion... -J. Gary Burkhead 9-65

66 USER APPLICATON DEVELOPMENT (UAD) The Sarbanes-Oxley Act (SOX) has created additional quality concerns and organizational risks: Spreadsheets and applications that use financial information are subject to audit and must be protected by the proper controls 9-66

67 PRE-ASSESING THE POTENTIAL UAD RISKS Three types of risk factors should be considered when deciding whether an application should be user-developed or developed by an IS professional: 9-67

68 GUIDELINES FOR USER DEVELOPERS Use a development methodology appropriate to the application, based on three application characteristics: 1. Scope ( personal, work unit) 2. Size 3. Complexity of the business problem 9-68

69 GUIDELINES FOR USER DEVELOPERS Askimportant questions during the Definition and Construction phases, such as these: 9-69

70 GUIDELINES FOR USER DEVELOPERS Avoid two common problems: 1. Not doing enough testing - Thorough testing should take extensive time and effort 2. Not providing sufficient documentation -Multi-user applications especially need relatively detailed documentation 9-70

71 GUIDELINES FOR USER DEVELOPERS Some lessons from other user developers: - Stay in touch with end users throughout the project - The prototyping methodology is useful but development is still time consuming - Intricate, hard-to-find bugs often show up at end of development - Managing user expectations is crucial 9-71

72 Microsoft Visio 2013 tutorial 9-72

73 Thank you Any Question? 6/29/ Professor Lili Saghafi

74 6/29/2014 Professor Lili Saghafi