1. Managing Information Technology 6th Edition
CHAPTER 10 METHODOLOGIES 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
Definition
Feasibility Analysis
Requirements Definition
Construction
System Design
System Building
System Testing
Implementation
Installation
Operations
Maintenance

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 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
User acceptance testing
Ensures that the system performs reliably and does what it is supposed to do in the user environment
Documentation
Major mechanism of communication among members of the project team

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