Managing Information Technology 6 th Edition

1. Managing Information Technology6th Edition CHAPTER 10METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT

2. Methodologies for Custom Software Development • Although firms are likely to purchase software packages whenever they can, the development of custom software is still highly important and in demand • Different approaches to developing customized applications • Traditional Systems Development Life Cycle (SDLC) • Evolutionary Prototyping • Rapid Application Development (RAD) • Agile Development

3. SYSTEMS DEVELOPMENT LIFE CYCLE The SDLC steps • Highly structured process for developing customized applications • Most often requires a lot of documentation • Outputs from one step inputs to next • Often referred to as the “waterfall” model • Key characteristic is extensive formal reviews at the end of each major step

4. SYSTEMS DEVELOPMENT LIFE CYCLE The SDLC Waterfall

5. SYSTEMS DEVELOPMENT LIFE CYCLE The SDLC steps • Extensive up-front time spent determining requirements to avoid expensive changes later

6. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase • The first phase of the SDLC is the definition phase • This phase contains two steps: • Feasibility analysis • Requirements definition

7. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase – Feasibility analysis • Three types of feasibility are assessed • Technical • 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

8. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase – Feasibility analysis • Three types of feasibility are assessed (cont’d) • Operational • 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

9. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase – Feasibility analysis • Three types of feasibility are assessed (cont’d) • Economic • Business managers and IS analysts work together to prepare a cost/benefit analysis • IS analyst responsible for establishing the developmental costs for the project

10. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase – Feasibility analysis • Deliverable is a 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

11. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase – Requirements Definition • Focuses on processes, data flows, and data interrelationships rather than a specific physical implementation • Requirements are gathered by: • Interviewing individuals or groups • Reviewing documents • Observing employees doing their jobs

12. SYSTEMS DEVELOPMENT LIFE CYCLE Definition phase – Requirements Definition • Deliverable is a system requirements document: • Detailed descriptions of inputs and outputs, processes used to convert input data to outputs • Formal diagrams and output layouts • Revised cost/benefit analysis • Revised plan for remainder of project

13. SYSTEMS DEVELOPMENT LIFE CYCLE Construction phase • The second major phase of the SDLC is the construction phase • This starts after the systems requirements document from the definition phase is approved • The phase contains three steps: • System design • System building • System testing

14. SYSTEMS DEVELOPMENT LIFE CYCLE Construction phase – System design • Includes: • Deciding what hardware and software to use • Designing structure and content of databases • Defining programs and their interrelationships • Good design is critical for the quality of the system

15. SYSTEMS DEVELOPMENT LIFE CYCLE Construction phase – System design • Deliverable is a 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

16. SYSTEMS DEVELOPMENT LIFE CYCLE Construction phase – System building • Includes: • Producing the computer programs • Developing or enhancing the databases and files to be used by the system • Procuring new hardware and support software

17. SYSTEMS DEVELOPMENT LIFE CYCLE Construction phase – System testing • Might require as much time as writing the code for the system • Involves testing by IS specialists, then user testing • Multiple steps: • Each module of code is tested • Modules are assembled into subsystems and tested • Subsystems are combined and entire system is integration tested

18. SYSTEMS DEVELOPMENT LIFE CYCLE Construction phase – System testing

19. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase • The final phase of the SDLC is the implementation phase • The success of this phase is dependent upon business managers • The three steps in this phase are: • Installation • Operations • Maintenance

20. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Installation • Includes: • Building files and databases • Converting relevant data from one or more old systems to the new system • Training system’s end users

21. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Installation • Conversion from an old system to a new system can be difficult • Several transitioning strategies are commonly used to assist in this change: • 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

22. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Installation • Transitioning strategies (cont’d) • Phased: new system is implemented one component at a time • Cutover: old system is totally abandoned as soon as the new system is implemented

23. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Operations • New application begins operation in “production mode” • Project team is usually disbanded • Requires adequate documentation • System documentation for IS specialists who operate and maintain the system • User documentation for those who use the system

24. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Maintenance • 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 environment • Enhance or improve the system

25. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Maintenance • Maintenance makes up about 80% of total costs over a system’s life

26. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Maintenance • Problems with maintenance: • 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., ripple effect ) • Maintenance is considered low-status work by programmers, so typically only new programmers are assigned the job

27. SYSTEMS DEVELOPMENT LIFE CYCLE Implementation phase – Maintenance • Problems with maintenance (cont’d): • Maintenance may introduce new errors into the system • If resources are not available, business managers may suffer long delays before needed changes are made

28. SYSTEMS DEVELOPMENT LIFE CYCLE The SDLC project team • Usually temporary • Includes personnel from IS and business units • Has a project manager • Traditionally from IS • Can be from business unit • May be one from each • Responsible for success of project – delivering quality system on time and within budget

29. SYSTEMS DEVELOPMENT LIFE CYCLE Managing an SDLC project • Critical success factors: • Manageable project size • Accurate requirements definition • Executive sponsorship

30. SYSTEMS DEVELOPMENT LIFE CYCLE SDLC advantages and disadvantages

31. PROTOTYPING METHODOLOGY • Takes advantage of fourth generation procedural languages and relational database management systems • Enables creation of system (or part of system) more quickly, then revise after users have tried it • Is a type of evolutionary development process • Can be used as a complete alternative to the SDLC or within an SDLC process

32. PROTOTYPING METHODOLOGY • Prototype examples: • Input and output screens developed for users to test as part of requirements definition • “First-of-a-series” – a completely operational prototype used as a pilot • “Selected features” – only some essential features included in prototype, more added later

33. PROTOTYPING METHODOLOGY The prototyping steps

34. PROTOTYPING METHODOLOGY The prototyping project team • Representatives from IS and user management necessary • Need team members who can quickly build systems using advanced tools • Requires dedicated business user roles

35. PROTOTYPING METHODOLOGY Prototyping advantages and disadvantages • Advantages: • 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 higher

36. PROTOTYPING METHODOLOGY Prototyping advantages and disadvantages • Disadvantages: • End prototype often lacks security and control features • May not undergo as rigorous testing • Final documentation may be less complete • More difficult to manage user expectations

37. PROTOTYPING METHODOLOGY Prototyping within an SDLC process • Two ways in which prototyping is usually incorporated into an SDLC process: • Used in the Definition phase to help users define system requirements

38. PROTOTYPING METHODOLOGY Prototyping within an SDLC process • Two ways in which prototyping is usually incorporated into an SDLC process: • Includes a pilot implementation of a working prototype

39. NEWER APPROACHES Rapid applications development (RAD) • Hybrid methodology combines aspects of SDLC and prototyping • Goal is to produce a system in less than a year

40. NEWER APPROACHES Rapid applications development (RAD) • Advantages and disadvantages

41. NEWER APPROACHES Agile methodologies • Alternative methodology for smaller projects • Objective is to deliver software with very low defect rates • Based on four key values: • Simplicity • Communication • Feedback • Courage

42. NEWER APPROACHES Agile methodologies • eXtreme programming (XP) • Programmers write code in pairs • Use simple design and frequent testing • Three traits characterize the program design • System must communicate everything you want to communicate • System must contain no duplicate code • System should have the fewest number of components as possible

43. NEWER APPROACHES Agile methodologies • Scrum • Based on well-orchestrated movement 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

44. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF • Advantages of outsourcing: • Helps keep software development costs down • Make use of technical expertise not available in-house • Can hire capacity above baseline for current amount of development work • Frees up internal resources to work on more strategic or proprietary projects • Can often complete projects more quickly

45. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF • Onshore outsourcing: contracting with companies within the same country or region • Offshore outsourcing: contracting with companies not within the same country or region • Driven by price because labor costs are typically much lower • Risks include loss of some control, language and cultural barriers, and threats of piracy of intellectual property

46. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF • Offshore outsourcing is a good alternative when: • System requirements well-defined and remain stable • Time is of essence and 7x24 hour availability of resources a good idea • Cost of project important

47. MANAGING SOFTWARE PROJECTS USING OUTSOURCED STAFF • Guidelines for managing offsite outsourcer: • Manage expectations, not staff • Take explicit actions to integrate the offsite workers • Communicate frequently • Abandoning informal ways may result in increased rigor • Create a centralized project management office • Begin with pilot projects • Hire offshore legal expertise • Use secure and redundant communication links