Your SlideShare is downloading. ×
Sylnovie Merchant, Ph.D. MIS 210 Fall 2004
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Sylnovie Merchant, Ph.D. MIS 210 Fall 2004

508
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
508
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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