Sylnovie Merchant, Ph.D. MIS 210 Fall 2004


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

  1. 1. Lecture 2: SDLC Methodologies Project Initiation and Planning Requirements Analysis MIS 210 Information Systems I
  2. 2. Systems Development Life Cycle (SDLC)
  3. 3. Systems Development <ul><li>What is a system? </li></ul><ul><li>A collection of related components that interact to perform a task in order to accomplish a goal </li></ul><ul><li>Systems development (systems analysis and </li></ul><ul><li>design) is the process of creating systems, </li></ul><ul><li>developing them, and maintaining or enhancing </li></ul><ul><li>them. </li></ul>
  4. 4. Characteristics of Software <ul><li>Software is developed, not manufactured </li></ul><ul><li>Software does not “wear out” </li></ul><ul><ul><li>although it can become obsolete </li></ul></ul>
  5. 5. Today’s Software Development Environment <ul><li>Failures </li></ul><ul><li>Productivity gap </li></ul><ul><li>Backlogs </li></ul><ul><li>Maintenance bound </li></ul>
  6. 6. Alleviating the Problems in Systems Development <ul><li>Elimination of the causes of system failure lie in </li></ul><ul><li>1. the application of methodologies </li></ul><ul><li>2. modeling tools </li></ul><ul><li>3. techniques </li></ul><ul><li>4. project management techniques </li></ul><ul><li>to design and build IS that not only meet the needs of the </li></ul><ul><li>users, but also are delivered on time and within budget </li></ul>
  7. 7. Principles of Successful Systems Development <ul><li>Get the user involved </li></ul><ul><li>Use a problem-solving approach </li></ul><ul><li>Establish phases and activities </li></ul><ul><li>Establish standards for development and documentation </li></ul><ul><li>Justify systems as capital investments </li></ul><ul><li>Don't be afraid to cancel or revise scope </li></ul><ul><li>Divide and conquer </li></ul><ul><li>Design systems for growth and change </li></ul><ul><li>Proper planning and project management </li></ul>
  8. 8. Some Key Terms ... <ul><li>Systems development life cycle (SDLC) : the life of a project, from concept through implementation </li></ul><ul><li>Methodology : a comprehensive and detailed version of an entire SDLC </li></ul><ul><li>Technique : an approach that applies specific tools and rules to complete one or more phases of the methodology </li></ul><ul><li>Modeling tools : specific tools used to apply techniques </li></ul><ul><li>Project management techniques : tools used to help plan, schedule, and control a project </li></ul>
  9. 9. Tools <ul><li>Software support that helps create models or other project components </li></ul><ul><li>From simple drawing programs to complex CASE tools </li></ul>
  10. 10. Some Tools <ul><li>Project management applications </li></ul><ul><li>Drawing/graphics applications </li></ul><ul><li>Word processing/text editor </li></ul><ul><li>Computer-aided system engineering (CASE) tools </li></ul><ul><li>Integrated development environment (IDF) </li></ul><ul><li>Database management applications </li></ul><ul><li>Reverse-engineering tool </li></ul><ul><li>Code generators </li></ul>
  11. 11. Techniques <ul><li>Collection of guidelines that help the analyst complete a system development activity or task </li></ul><ul><li>Step-by-step instructions </li></ul><ul><li>General advice </li></ul>
  12. 12. Some Techniques <ul><li>Strategic planning </li></ul><ul><li>Project management </li></ul><ul><li>User interviewing </li></ul><ul><li>Data-modeling </li></ul><ul><li>Relational database design </li></ul>
  13. 13. Systems Development Lifecycle (SDLC) <ul><li>Three major activities </li></ul><ul><ul><li>Analysis: understanding business needs </li></ul></ul><ul><ul><li>Design: conceptualizing computer-system solution </li></ul></ul><ul><ul><li>Implementation: construction, testing, and installation </li></ul></ul><ul><li>Two additional phases </li></ul><ul><ul><li>Project planning </li></ul></ul><ul><ul><li>Support </li></ul></ul>
  14. 14. The SDLC <ul><li>1. Planning </li></ul><ul><ul><li>a. Project identification and selection </li></ul></ul><ul><ul><li>b. Project initiation and planning </li></ul></ul><ul><li>2. Analysis </li></ul><ul><ul><li>a. Determine system requirements (WHAT users need) </li></ul></ul><ul><ul><li>b. Modeling possible solutions (HOW to satisfy user needs) </li></ul></ul><ul><li>3. Design </li></ul><ul><ul><li>a. logical design </li></ul></ul><ul><ul><li>b. physical design </li></ul></ul><ul><li>4. Implementation </li></ul><ul><li>5. Maintenance / support </li></ul>Frontend Backend A D I
  15. 15. SDLC Concepts <ul><li>All projects use some variation of the SDLC </li></ul><ul><li>SDLC is more than phases </li></ul><ul><ul><li>Principles of management </li></ul></ul><ul><ul><li>Planning and control </li></ul></ul><ul><ul><li>Organization and scheduling </li></ul></ul><ul><ul><li>Problem solving </li></ul></ul>
  16. 16. Major Attributes of the Life Cycle <ul><li>The project -- </li></ul><ul><ul><li>Moves systematically through phases where each phase has a standard set of outputs </li></ul></ul><ul><ul><li>Produces project deliverables </li></ul></ul><ul><ul><li>Uses deliverables in implementation </li></ul></ul><ul><ul><li>Results in actual information system </li></ul></ul><ul><ul><li>Uses gradual refinement </li></ul></ul>
  17. 17. Project Phases <ul><li>Planning (Why build the system? How should the team go about building it?) </li></ul><ul><li>Analysis (Who uses system, what will it do, where and when will the system be used?) </li></ul><ul><li>Design (How will the system work?) </li></ul><ul><li>Implementation (System delivery) </li></ul>
  18. 18. <ul><li>Identifying business value </li></ul><ul><li>Analyze feasibility </li></ul><ul><li>Develop work plan </li></ul><ul><li>Staff the project </li></ul><ul><li>Control and direct project </li></ul>Planning
  19. 19. <ul><li>Design selection </li></ul><ul><li>Architecture design </li></ul><ul><li>Interface design </li></ul><ul><li>Data storage design </li></ul><ul><li>Program design </li></ul>Design
  20. 20. <ul><li>Construction </li></ul><ul><ul><li>Program building </li></ul></ul><ul><ul><li>Program and system testing </li></ul></ul><ul><li>Installation </li></ul><ul><ul><li>Conversion strategy </li></ul></ul><ul><ul><li>Training plan </li></ul></ul><ul><ul><li>Support plan </li></ul></ul>Implementation
  21. 21. Support Phase <ul><li>Objective: Keep system running productively following initial installation </li></ul><ul><ul><li>End-user support </li></ul></ul><ul><ul><ul><li>Help desks </li></ul></ul></ul><ul><ul><ul><li>Training programs </li></ul></ul></ul><ul><ul><li>Maintaining and enhancing computer system </li></ul></ul><ul><ul><ul><li>Enhancements </li></ul></ul></ul><ul><ul><ul><li>Upgrades </li></ul></ul></ul><ul><ul><ul><li>Maintenance </li></ul></ul></ul>
  22. 22. Methodologies
  23. 23. Common Development Methodologies and Techniques <ul><li>Code & fix model </li></ul><ul><li>Structured development </li></ul><ul><li>Prototyping </li></ul><ul><li>Rapid application development </li></ul><ul><li>Object-oriented development </li></ul>
  24. 24. Code and Fix It Model <ul><li>An early technique </li></ul><ul><li>The developer, in the following order: </li></ul><ul><ul><li>codes </li></ul></ul><ul><ul><li>thinks about requirements </li></ul></ul><ul><ul><li>fixes the code </li></ul></ul><ul><ul><li>continues this process until... </li></ul></ul>
  25. 25. Structured Development <ul><li>Based on the principles of: </li></ul><ul><ul><li>modularization </li></ul></ul><ul><ul><li>top-down decomposition </li></ul></ul><ul><ul><li>process driven </li></ul></ul><ul><li>Structured programming </li></ul><ul><li>Structured design </li></ul><ul><li>Structured analysis </li></ul>
  26. 26. Systems Development Life Cycle Waterfall Model Project Identification and Selection Project Initiation and Planning Analysis Logical Design Physical Design Implementation Maintenance
  27. 27. Waterfall Model <ul><li>Problems </li></ul><ul><ul><li>dependent on documents, particularly in completing the requirements and design phases </li></ul></ul><ul><ul><li>tendency to hide poorly understood requirements with elaborate specifications </li></ul></ul>
  28. 28. Advantages of Structured Development <ul><li>Been used successfully for over 30 years </li></ul><ul><li>Provides a clear framework that defines and divides important activities </li></ul><ul><li>Can be applied to both small and large projects </li></ul><ul><li>Division of labor is easier to facilitate </li></ul>
  29. 29. Limitations of Structured Development <ul><li>Specification problems </li></ul><ul><ul><li>assumes that development is a sequential process </li></ul></ul><ul><li>Changing requirements </li></ul><ul><ul><li>requirements specified at the beginning </li></ul></ul><ul><ul><li>assumption that requirements will not change </li></ul></ul><ul><li>Conceptualization and visualization </li></ul><ul><ul><li>document led methodology </li></ul></ul><ul><ul><li>volume of documentation can be huge </li></ul></ul><ul><li>Inaccuracy </li></ul><ul><ul><li>there is only downward trend </li></ul></ul>
  30. 30. Prototyping <ul><li>Principle : a user can tell you better what they DON'T want than what they DO want </li></ul><ul><li>Expendable (throw-away) prototyping: </li></ul><ul><ul><li>discarded after use </li></ul></ul><ul><ul><li>used to support the analysis and design phases </li></ul></ul><ul><li>Evolutionary prototyping: </li></ul><ul><ul><li>prototype evolves into the final system </li></ul></ul><ul><ul><li>is it a methodology? </li></ul></ul>
  31. 31. Advantages <ul><li>Speed </li></ul><ul><li>Easier for end-users to learn </li></ul><ul><li>System changes discovered earlier </li></ul><ul><li>End-user involvement (ownership) </li></ul><ul><ul><li>increased user satisfaction </li></ul></ul><ul><ul><li>increased user acceptance </li></ul></ul><ul><li>User-analyst communication </li></ul><ul><li>Early problem detection </li></ul><ul><ul><li>reduced development time </li></ul></ul><ul><ul><li>reduced maintenance </li></ul></ul>
  32. 32. Disadvantages <ul><li>Poor documentation </li></ul><ul><li>Hard to control/manage </li></ul><ul><li>(Unrealistic) User expectations </li></ul><ul><ul><li>time for final system </li></ul></ul><ul><ul><li>final system differences </li></ul></ul><ul><ul><ul><li>reduced analysis </li></ul></ul></ul>
  33. 33. Rapid Application Development (RAD) <ul><li>Logistical approach to systems design </li></ul><ul><li>Combines </li></ul><ul><ul><li>integrated CASE tools </li></ul></ul><ul><ul><li>information engineering methodologies </li></ul></ul><ul><ul><li>management techniques </li></ul></ul><ul><li>Speeds up Systems Development by as much as 20 times </li></ul><ul><li>Critics consider it incomplete life cycle </li></ul>
  34. 34. Object-Oriented (OO) Development <ul><li>A fundamentally new way of thinking about developing systems </li></ul><ul><li>Object-oriented : means that we organize software as a collection of discrete objects that incorporate both data and behavior </li></ul><ul><li>Object-oriented development : an approach to systems development that proposes the use of objects in the building of new systems and the rebuilding of old ones </li></ul>
  35. 35. Advantages of OO <ul><li>Faster development </li></ul><ul><li>Higher quality </li></ul><ul><li>Easier maintenance </li></ul><ul><li>Increased scalability </li></ul><ul><li>Better information structure </li></ul><ul><li>Increased adaptability </li></ul><ul><li>Increased modeling power </li></ul><ul><li>Supports complexity </li></ul>Reuse
  36. 36. Disadvantages of OO <ul><li>Maturity of technology </li></ul><ul><li>Need for standards </li></ul><ul><li>Lack of database technology </li></ul><ul><li>Lack of reusable software </li></ul><ul><li>Lack of metrics </li></ul><ul><li>Speed of execution </li></ul><ul><li>Availability of qualified personnel </li></ul><ul><li>Cost of conversion </li></ul>
  37. 37. Project Initiation and Planning
  38. 38. Project Initiation and Planning <ul><li>Long-term information systems strategic plan (top-down) </li></ul><ul><li>Department managers or process managers (bottom-up) </li></ul><ul><li>Response to outside forces </li></ul><ul><ul><li>Legislative changes </li></ul></ul><ul><ul><li>Market forces </li></ul></ul><ul><ul><li>Competition </li></ul></ul>
  39. 39. Confirming Project Feasibility <ul><li>Economic </li></ul><ul><li>Organizational and cultural </li></ul><ul><li>Technological </li></ul><ul><li>Schedule </li></ul><ul><li>Resource </li></ul>
  40. 40. Intangibles in Economic Feasibility <ul><li>Costs and benefits cannot always be measured </li></ul><ul><li>Examples </li></ul><ul><ul><li>Increased levels of service </li></ul></ul><ul><ul><li>Survival </li></ul></ul><ul><ul><li>Lost customers or sales </li></ul></ul>
  41. 41. Organizational and Cultural Feasibility <ul><li>Each company has own culture </li></ul><ul><li>New system must fit into culture </li></ul><ul><li>Evaluate related issues for potential risks </li></ul>
  42. 42. Technological Feasibility <ul><li>Does system stretch state-of-the-art? </li></ul><ul><li>Does expertise exist in-house for development? </li></ul><ul><li>Does a third party need to be involved? </li></ul>
  43. 43. Schedule Feasibility <ul><li>Can project be completed on time? </li></ul><ul><li>Risk of schedule slipping </li></ul><ul><li>Assumptions and estimates </li></ul>
  44. 44. Resource Feasibility <ul><li>Team member availability </li></ul><ul><li>Team skill levels </li></ul><ul><li>Equipment </li></ul><ul><li>Support staff </li></ul><ul><li>Physical facilities </li></ul>
  45. 45. Developing Project Schedule <ul><li>Task: smallest piece of work </li></ul><ul><li>Activity: group of tasks </li></ul><ul><li>Phase: group of activities </li></ul><ul><li>Schedule process </li></ul><ul><ul><li>List all tasks for each SDLC activity </li></ul></ul><ul><ul><li>Estimate sizes of each task </li></ul></ul><ul><ul><li>Determine task sequence </li></ul></ul><ul><ul><li>Schedule tasks </li></ul></ul>
  46. 46. Project Staffing <ul><li>Develop resource plan for the project </li></ul><ul><li>Identify and request specific technical staff </li></ul><ul><li>Identify and request specific user staff </li></ul><ul><li>Organize the project team into work groups </li></ul><ul><li>Conduct preliminary training and team building exercises </li></ul>
  47. 47. Launching Project <ul><li>Oversight committee is finalized and meets to give go-ahead </li></ul><ul><li>Formal announcement made </li></ul><ul><li>Key question, “Are we ready to start?” </li></ul>
  48. 48. Focusing the Investigation <ul><li>Most system problems occur in complex tasks that have high user impact </li></ul><ul><li>Application complexity </li></ul><ul><li>User impact </li></ul>
  49. 49. Requirements Analysis
  50. 50. Analysis <ul><li>A. Determine system requirements </li></ul><ul><li>B. Structure requirements </li></ul><ul><ul><li>1. Process modeling </li></ul></ul><ul><ul><li>2. Logic modeling </li></ul></ul><ul><ul><li>3. Data modeling </li></ul></ul><ul><li>C. Select best alternative </li></ul>
  51. 51. Requirements Analysis Goals <ul><li>Fully describe the current system </li></ul><ul><ul><li>Study and analyze the current system (gather and study facts) </li></ul></ul><ul><li>Determine the ideal information system </li></ul><ul><li>Identify resource constraints </li></ul><ul><li>Define and prioritize requirements </li></ul><ul><li>Inspire user confidence/ownership </li></ul>
  52. 52. Study & Analyze Current System <ul><li>Gather information on what the system should do from as many sources as possible </li></ul><ul><li>Concentrate on WHAT is needed, not HOW to do it </li></ul><ul><li>“Don’t try to fix it unless you understand it” </li></ul><ul><li>Major problem: analyst not understanding user needs </li></ul>
  53. 53. Study & Analyze Current System <ul><li>-- Activities -- </li></ul><ul><li>1. Learn about current system (gather facts) </li></ul><ul><li>2. Model current system </li></ul><ul><li>3. Analyze problems/opportunities (study facts) </li></ul><ul><li>4. Establish new system objectives </li></ul>
  54. 54. Study & Analyze Current System -- Output -- 1. Complete statement of user environment 2. Models of current system 3. List of major problems/causes/effects 4. System objectives
  55. 55. Learn About Current System (gather facts) <ul><li>Gather information from: </li></ul><ul><ul><li>Current information system: </li></ul></ul><ul><ul><ul><li>a current IS may exist </li></ul></ul></ul><ul><ul><li>External sources: </li></ul></ul><ul><ul><ul><li>reviewing other IS outside the organization can reveal practical ideas and techniques </li></ul></ul></ul><ul><ul><li>Internal sources: </li></ul></ul><ul><ul><ul><li>single most important source of facts is the user </li></ul></ul></ul><ul><ul><ul><li>existing paper work or documents is also a good source </li></ul></ul></ul>
  56. 56. Tactics <ul><li>Listen - don’t lecture </li></ul><ul><li>Don’t pre-solve problem </li></ul><ul><li>Compare stories </li></ul><ul><li>Look for reluctant responses </li></ul><ul><li>Observe your effects on system </li></ul><ul><li>Avoid politics ( head nodding ) </li></ul><ul><li>Expect hard, boring work </li></ul>
  57. 57. Fact-finding Methods <ul><li>Research and site visits </li></ul><ul><li>Existing documentation </li></ul><ul><li>Observation </li></ul><ul><li>Questionnaires </li></ul><ul><li>Interviews </li></ul>
  58. 58. Observation <ul><li>Not for long periods of time </li></ul><ul><ul><li>will change what your measuring </li></ul></ul><ul><li>Vary observation periods </li></ul><ul><li>Take only minimal, preplanned notes </li></ul><ul><li>Coordinate visit beforehand </li></ul><ul><li>Beware of Selective Perception!!! </li></ul>
  59. 59. Questionnaires -- Types -- <ul><li>Open-ended (free format) </li></ul><ul><li>Closed-ended (fixed format) </li></ul><ul><ul><li>multiple choice </li></ul></ul><ul><ul><li>rating </li></ul></ul><ul><ul><li>ranking </li></ul></ul><ul><ul><li>single fact </li></ul></ul>
  60. 60. Questionnaire Development <ul><li>1. Determine what facts need to be collected </li></ul><ul><li>2. Determine whether free- or fixed-format is best. Usually, a combination is used. </li></ul><ul><li>3. Write the questions. Examine them carefully. Make sure the questions don't reflect your personal biases. </li></ul><ul><li>4. Test the questions on a small sample of respondents. Modify those questions that respondents had problems with. </li></ul><ul><li>5. Duplicate and distribute the questionnaire. </li></ul>
  61. 61. Questionnaires - the Good and the Bad <ul><li>Advantages </li></ul><ul><ul><li>Can be quickly answered. </li></ul></ul><ul><ul><li>Cheap for gathering data from a large number of users. </li></ul></ul><ul><ul><li>Allow users to maintain anonymity. </li></ul></ul><ul><ul><li>Responses can be tabulated and analyzed quickly. </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Number of respondents is often low. </li></ul></ul><ul><ul><li>No guarantee that the user will answer all the questions. </li></ul></ul><ul><ul><li>Inflexible - voluntary information is stifled. </li></ul></ul><ul><ul><li>Elimination of body cues. </li></ul></ul><ul><ul><li>No immediate opportunity to clarify an answer. </li></ul></ul><ul><ul><li>Good questionnaires are difficult to prepare. </li></ul></ul>
  62. 62. Interviews <ul><li>Types of Interviews </li></ul><ul><ul><li>1. Unstructured </li></ul></ul><ul><ul><li>2. Structured </li></ul></ul><ul><li>Types of Questions </li></ul><ul><ul><li>1. Open-ended </li></ul></ul><ul><ul><li>2. Closed-ended </li></ul></ul><ul><li>Focus of Questions </li></ul><ul><ul><li>1. Decision analysis </li></ul></ul><ul><ul><li>2. Data analysis </li></ul></ul>
  63. 63. How to Conduct an Interview <ul><li>1. Select interviewees. Learn as much as you can about interviewee. </li></ul><ul><li>2. Make an appointment - never 'drop by' </li></ul><ul><li>3. Limit the interview to between 1/2 hour and 1 hour </li></ul><ul><li>4. Clear it with the interviewee's supervisor </li></ul><ul><li>5. Conduct the interview in a private location </li></ul><ul><li>6. Prepare for the interview: provide an interview agenda </li></ul><ul><li>7. Conduct the interview: opening, body, conclusion </li></ul><ul><li>8. Follow-up </li></ul>
  64. 64. Interviewing Tips <ul><li>Watch the time </li></ul><ul><li>Don’t look at watch </li></ul><ul><li>No leading questions </li></ul><ul><li>Listen </li></ul><ul><li>No body language </li></ul>
  65. 65. <ul><li>Make the user feel important </li></ul><ul><li>Be courteous and professional </li></ul><ul><li>Don’t take exhaustive notes </li></ul><ul><li>Use structured questions </li></ul><ul><li>Don’t ask users to remember details </li></ul><ul><li>Avoid gang interviews </li></ul>More Interviewing Tips
  66. 66. Interviews - the Good and the Bad <ul><li>Advantages </li></ul><ul><ul><li>Users are actively involved </li></ul></ul><ul><ul><li>SA can probe for more feedback from user </li></ul></ul><ul><ul><li>SA can reword questions for each interviewee </li></ul></ul><ul><ul><li>Body cues </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Very time consuming, thus very costly </li></ul></ul><ul><ul><li>Success of the interview is dependent on the SA's human relations skills </li></ul></ul><ul><ul><li>Interviewing may be impractical due to location of interviewees </li></ul></ul>
  67. 67. Overall Strategy for Fact Finding <ul><li>1. Learn all you can from existing documents </li></ul><ul><li>2. If appropriate, observe the system in action </li></ul><ul><li>3. Conduct interviews </li></ul><ul><li>4. Use questionnaires to clear up things you don't fully understand </li></ul><ul><li>5. Follow-up </li></ul>
  68. 68. Some Questions That Must be Answered <ul><li>What are the inputs to this system? </li></ul><ul><li>What are the outputs of this system? </li></ul><ul><li>What is the business process (i.e., how is data processed)? </li></ul><ul><li>Who are the direct end-users? </li></ul><ul><li>How will the users feel about this system? </li></ul><ul><li>Who developed the existing system? </li></ul>
  69. 69. Analyze Problems / Opportunities (study facts) <ul><li>Study and analyze the &quot;current&quot; system </li></ul><ul><li>Problem analysis is difficult. </li></ul><ul><ul><li>We often try to solve problems without analyzing them. </li></ul></ul><ul><ul><li>We try to state the problem in terms of a solution. </li></ul></ul><ul><li>Use the PIECES framework to frame your investigation of the problems, opportunities, and requirements </li></ul><ul><ul><li>P erformance analysis </li></ul></ul><ul><ul><li>I nformation and data analysis </li></ul></ul><ul><ul><li>E conomic analysis </li></ul></ul><ul><ul><li>C ontrol and security analysis </li></ul></ul><ul><ul><li>E fficiency analysis </li></ul></ul><ul><ul><li>S ervice analysis </li></ul></ul>
  70. 70. Requirements Analysis Document <ul><li>Parts </li></ul><ul><ul><li>How analysis was conducted </li></ul></ul><ul><ul><ul><li>credibility </li></ul></ul></ul><ul><ul><ul><li>restarts </li></ul></ul></ul><ul><ul><li>User requirements </li></ul></ul><ul><ul><li>System constraints </li></ul></ul><ul><ul><li>Realistic System Objectives </li></ul></ul><ul><ul><li>Documentation </li></ul></ul>
  71. 71. User Requirements <ul><li>User system objectives (unedited) </li></ul><ul><li>Reports (type/frequency) </li></ul><ul><li>User training needs </li></ul><ul><li>Effect of system on various users </li></ul><ul><ul><li>Organization Chart </li></ul></ul>