Systems Development Lifecycle (SDLC)

2. Systems Development Lifecycle (SDLC)

3. The Systems Development Lifecycle (SDLC) • Systems development life cycle (SDLC) • Provides overall framework for managing systems development process • Two main approaches to SDLC • Predictive approach– assumes project can be planned out in advance • Adaptive approach– more flexible, assumes project cannot be planned out in advance • All projects use some variation of SDLC

4. Choosing the Predictive vs. Adaptive Approach to the SDLC

5. Adaptive vs. Predictive approach for different types of IS • Transaction processing system • Customer relationship management system • Business intelligence and decision support system • Emergency response system • Mobile workforce support system • Healthcare system

6. Traditional Predictive Approach to the SDLC • Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project • Analysis – understand business needs and processing requirements • Design – define solution system based on requirements and analysis decisions • Implementation – construct, test, train users, and install new system • Support – keep system running and improve

7. Information System Development Phases

8. “Waterfall” Approach to the SDLC

9. Newer Adaptive Approaches to the SDLC • Based on spiral model • Project cycles through development activities over and over until project is complete • Prototype created by end of each cycle • Focuses on mitigating risk • Iteration – Work activities are repeated • Each iteration refines previous result • Approach assumes no one gets it right the first time • There are a series of mini projects for each iteration

10. The Spiral Life Cycle Model

11. Iteration of System Development Activities

12. Activities of Each SDLC Phase • Predictive or adaptive approach use SDLC • Activities of each “phase” are similar • Phases are not always sequential • Phases can overlap • Activities across phases can be done within an iteration

13. Activities of Planning Phase of SDLC • Define business problem and scope • Produce detailed project schedule • Confirm project feasibility • Staff the project (resource management) • Launch project  official announcement

14. Activities of Analysis Phase of SDLC • Gather information to learn problem domain • Define system requirements • Build prototypes for discovery of requirements • Prioritize requirements • Generate and evaluate alternatives • Review recommendations with management

15. Activities of Design Phase of SDLC • Design and integrate the network • Design the application architecture • Design the user interfaces • Design the system interfaces • Design and integrate the database • Prototype for design details • Design and integrate system controls

16. Activities of Implementation Phase of SDLC • Construct software components • Verify and test • Convert data • Train users and document the system • Install the system

17. Activities of Support Phase of SDLC • Maintain system • Small patches, repairs, and updates • Enhance system • Small upgrades or enhancements to expand system capabilities • Larger enhancements may require separate development project • Support users • Help desk and/or support team

18. System Analysis

19. The Activities of the Analysis Phase

20. Activities of the Analysis Phase and Their Key Questions

21. Fact finding • Who does it? Why? Who should? • What is done? Why? What should? • Where is it done? Why? Where should? • When is it done? Why? When should? • How is it done? Why? How should?

22. Zachman Framework for Enterprise Architecture

24. Business Process Reengineering • Questions basic assumptions for doing business and seeks to find a better way • Uses IT as BPR enabler • Systems analyst may discover opportunities for process improvement • Any project may include components of BPR

25. System Requirements • New system capabilities and constraints • Functional requirements • Activities system must perform (use cases) • Based on procedures and business functions • Documented in analysis models • Nonfunctional requirements • Technical environment or performance objectives • Usability, reliability, and security requirements

26. Stakeholders—The Source of System Requirements • People with interest in successful system implementation • Three primary groups of stakeholders • Users (use system) • Clients (pay for and own system) • Technical staff (ensure system operation)

27. Stakeholders Interested in New System Development

28. Techniques for Information Gathering • Original structured approach • Create model of existing system • Derive requirements from existing system model • Current approach • Identify logical requirements for new system • Balance the review of current business functions with new system requirements

29. Information Gathering and Model Building

30. Themes for Information-Gathering Questions

31. Fact-Finding Methods • Review existing reports, forms, and procedure descriptions • Interview and discuss processes with users • Observe and document business processes • Distribute and collect questionnaires • Conduct joint application design (JAD) sessions • Research vendor solutions • Requirement gathering though prototyping

32. Review Existing Reports, Forms, and Procedure Descriptions • External industry-wide professional organizations and trade publications • Existing business documents and procedure descriptions within organization • Identify business rules, discrepancies, and redundancies • Be cautious of outdated material • Obtain preliminary understanding of processes • Use as guidelines/visual cues to guide interviews

33. Conduct Interviews and Discussions with Users • Effective way to understand business functions and rules • Time consuming and resource expensive • May require multiple sessions to • Meet all users • Understand all processing requirements • Can meet with individuals or groups of users • List of detailed questions prepared

35. Preparation for Interview • Choose a setting with little distraction. • Explain the purpose of the interview. • Address terms of confidentiality. • Explain the format of the interview. • Indicate how long the interview usually takes. • Tell them how to get in touch with you later if they want to. • Ask them if they have any questions before you both get started with the interview. • Don't count on your memory to recall their answers. Ask for permission to record the interview or bring along someone to take notes.

36. Guidelines for Conducting an Interview • Ask one question at a time. • Attempt to remain as neutral as possible. • Encourage responses • Be careful about the appearance when note taking. • Provide transition between major topics • Don't lose control of the interview.

37. Distribute and Collect Questionnaires • Limited and specific information from a large number of stakeholders • Preliminary insight into business • Not well suited for gathering detailed information • Closed-ended questions direct person answering question • Open-ended questions encourage discussion and elaboration

39. Observe and Document Business Processes • Varies from office walkthroughs to performing actual tasks • Not necessary to observe all processes at same level of detail • May make users nervous, so use common sense • Can document workflows with UML activity diagrams

40. Research on vendor solutions • Many problems have been solved by other companies • Positive contributions of vendor solutions • Frequently provide new ideas • May be state of the art • Cheaper and less risky • Danger • May purchase solution before understanding problem

41. Joint Application Development • Joint Application Development (JAD) is a popular fact-finding technique that brings users into the development process as active participants • JAD was developed by Chuck Morris of IBM Raleigh and Tony Crawford of IBM Toronto in the late 1970’s

42. Why JAD • People who actually do a job have the best understanding of that job. • People who are trained in information technology have the best understanding of the possibilities of that technology. • Information systems and business processes rarely exist in isolation. People working in these related areas have valuable insight on the role of a system within a larger community. • The best information systems are designed when all of these groups work together on a project as equal partners.

43. Conduct Joint Application Design Sessions • Expedites investigation of system requirements • Seeks to compress fact-finding, modeling, policy formation, and verification activities into shorter time frame • Critical factor is to have all important stakeholders present

44. Joint Application Design Participants • Session leader trained in group dynamics and JAD group facilitation • Knowledgeable business and system users and policy makers • Technical staff representatives to handle • Computer and network configurations • Operating environments • Security issues • Project team members

45. Advantages and disadvantagesof JAD • JAD allows key users to participate effectively in the requirements modeling process. They are more likely to feel a sense of ownership in the results, and support for the new system. • When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system. • JAD may seem more expensive and can be cumbersome • A drawback of JAD is that it opens up a lot of scope for inter-personal conflict.

46. Requirement gathering through Prototyping • Preliminary working model of a larger, more complex system component • Discovery, design, evolving prototypes • Prototype should be • Operative • Working model to provide “look and feel” • Focused to accomplish single objective • Quick • Built and modified rapidly with CASE tools

47. Advantages of prototyping • May provide the proof of concept necessary to attract funding • Early visibility of the prototype gives users an idea of what the final system looks like • Encourages active participation among users and producer • Assists to identify any problems with the efficacy of earlier design, requirements analysis and coding activities • Helps to refine the potential risks associated with the delivery of the system being developed • Various aspects can be tested and quicker feedback can be got from the user • User interaction available in during development cycle of prototype

48. Disadvantages of prototyping • It is important to realize that by their very definition, prototypes will represent some compromise from the final production design. • Producer might produce a system inadequate for overall organization needs • User can get too involved whereas the program can not be to a high standard • Structure of system can be damaged since many changes could be made • Not suitable for large applications

49. Validating the Requirements • Make sure gathered information is correct • Structured walkthrough • Effective means of implementing quality control early in project • Verify and validate system requirements • Review of findings from investigation and of models based on findings

50. Preliminary investigation report • Introduction • System request summery • Preliminary investigation findings • Recommendations • Time and cost estimates • Expected benefits • http://oc.course.com/sc/sad7e/forms/02%20Preliminary%20Investigation%20Report.rtf