SDLC_Intro.ppt
- 1. INTRODUCTION TO SYSTEM DEVELOPMENT LIFE CYCLES
- 2. WHAT IS AN INFORMATION SYSTEM (IS)? Hardware, software, data, people, and procedures that work together to produce quality information SystemβSet of components that interact to achieve common goal Businesses use many types of systems
- 3. WHAT ARE THE PHASES OF THE SYSTEM DEVELOPMENT CYCLE? Phase 1. Planning Phase 2. Analysis Phase 3. Design Phase 4. Implementation Phase 5. Support ο§ Review project requests ο§ Prioritize project requests ο§ Allocate resources ο§ Identify project development team ο§ Conduct preliminary investigation ο§ Perform detailed analysis activities: Study current system Determine user requirements Recommend solution ο§ Acquire hardware and software, if necessary ο§ Develop details of system ο§ Develop programs, if necessary ο§ Install and test new system ο§ Train users ο§ Convert to new system ο§ Conduct post-implementation system review ο§ Identify errors and enhancements ο§ Monitor system performance
- 4. WHO PARTICIPATES IN THE SDLC?
- 5. WHAT IS A SYSTEMS ANALYST? Responsible for designing and developing information system Liaison between users and IT professionals
- 6. WHAT IS THE PROJECT TEAM? Consists of users, systems analyst, and other IT professionals Formed to work on project from beginning to end Project leaderβone member of the team who manages and controls project budget and schedule
- 7. WHAT IS FEASIBILITY? Measure of how suitable system development will be to the company Operational feasibility Schedule feasibility Four feasibility tests: Technical feasibility Economic feasibility (also called cost/benefit feasibility)
- 8. WHAT IS DOCUMENTATION? Includes reports, diagrams, programs, and other deliverables Collection and summarization of data and information
- 9. WHY CREATE (OR MODIFY) AN INFORMATION SYSTEM? Competition can lead to change To improve existing system Outside group may mandate change To correct problem in existing system
- 10. WHAT IS A REQUEST FOR SYSTEM SERVICES? ο Formal request for new or modified information system ο§ Also called project request
- 11. PLANNING PHASE Begins when steering committee receives project request Steering committeeβ decision-making body for the company Function of committee: Review and approve project requests Allocate resources Form project development team for each approved project Prioritize project requests
- 12. ANALYSIS PHASE Conduct preliminary investigation, also called feasibility study Perform detailed analysis
- 13. PRELIMINARY INVESTIGATION ο Determine exact nature of problem or improvement and whether it is worth pursuing ο§ Findings are presented in feasibility report, also known as a feasibility study
- 14. DETAILED ANALYSIS Sometimes called logical design 2. Determine userβs wants, needs, and requirements 3. Recommend solution 1. Study how current system works
- 15. SYSTEM PROPOSAL Presented to steering committee, which decides how system will be developed Assesses feasibility of each alternative solution Recommends the most feasible solution for the project
- 16. IDENTIFY POSSIBLE SOLUTIONS Buy packaged softwareβprewritten software available for purchase Outsourceβhave outside source develop software Write own custom softwareβsoftware developed at userβs request Vertical market softwareβdesigned for particular industry Horizontal market softwareβmeets needs of many companies
- 17. DESIGN PHASE Acquire hardware and software Develop all details of new or modified information system
- 18. Visit vendorsβ stores ACQUISITION What is needed to acquire new hardware and software? ο Identify all hardware and software requirements of new or modified system Surf Web Read print and online trade journals, newspapers, and magazines Talk with other systems analysts
- 19. HOW TO TEST SOFTWARE PRODUCTS? ο References from vendor ο Talk to current users of product ο Product demonstrations ο Trial version of software ο Benchmark test measures performance
- 20. DETAILED DESIGN Includes several activities Database design Input and output design Program design Detailed design specifications for components in proposed solution
- 21. PROTOTYPING TOOLS/METHODS: MOCKUP ο Sample of input or output that contains actual data
- 22. PROTOTYPING TOOLS/METHODS: PROTOTYPE Working model of proposed system Beginning a prototype too early may lead to problems
- 23. PROTOTYPING TOOLS/METHODS: CASE ο CASE (Computer-Aided Software Engineering) tools support activities of the SDLC
- 24. Convert to new system IMPLEMENTATION PHASE ο Purpose is to construct, or build, new or modified system and then deliver it to users Train users Install and test new system Develop programs
- 25. TESTING Three kinds of tests performed by system developers: Verifies application works with other applications Systems test Integration Test Unit Test Verifies each individual program works by itself Verifies all programs in application work together
- 26. TRAINING ο Showing users exactly how they will use new hardware and software in system
- 27. SUPPORT PHASE Conduct post-implementation system reviewβmeeting to find out if information system is performing according to expectations Identify errors Identify enhancements Monitor system performance ο Providing ongoing assistance after the system is implemented
- 28. FEASIBILITY ο’ Every organization which performs system development, or has it done for them, needs a way to choose which projects are worth the effort ο’ Feasibility study is a common approach to make such decisions thoughtfully ο’ Basis for feasibility study is generally the problems and opportunities analysis
- 29. PROBLEMS & OPPORTUNITIES ο’ We can look for problems and opportunities in many parts of our organization, and the existing systems which are supported ο Track maintenance costs for existing systems ο Measure existing processes to determine their cost, and compare to industry standards ο Monitor availability of support for existing system components ο Look for signs of unhappy employees
- 30. ο Check quality of work products (outputs) ο Listen to customers, vendors, and suppliers ο’ Both complaints and suggestions ο Measure customer satisfaction ο Monitor competitorβs offerings and plans ο Monitor changes in technology which could help ο Donβt forget obvious measures of success, like sales, profit, or number of contracts awarded PROBLEMS & OPPORTUNITIES
- 31. PROJECT SELECTION ο’ Selection of projects is based on many factors β cost, urgency, the systems affected, etc. ο’ From the organizationβs perspective, choosing projects is kind of like shopping ο Thereβs generally a limited amount of funds and people available to work on the possible projects, and management needs to choose which projects to support
- 32. ο’ There are five typical requirements for a project to be supported ο Management support for the project ο Appropriate timing of commitment to the project ο Relevance to helping meet organizational goals ο Project must be practical and feasible ο Project must be worthwhile compared to other possible expenditures ο’ Are we getting enough βbang for our buck?β PROJECT SELECTION
- 33. PROJECT OBJECTIVES ο’ Based on the problems and opportunities identified for a project, we can set objectives for the project ο These not only help the feasibility study which follows, but set goals against which we can later test the system ο’ Objectives should not only address the type of improvement sought, but set a desired level of improvement
- 34. ο’ Examples of objectives might include ο Improve customer satisfaction 10% within 1 year ο Reduce the response time for customer complaints by 15% ο Get a new feature to market before competitors ο Reduce error rate for data entry from 2% to 0.5% ο Improve sales to new customers by 5% ο Reduce voluntary employee turnover by 10% PROJECT OBJECTIVES
- 35. FEASIBILITY ANALYSIS ο’ Feasibility consists of several types we want to assess for each candidate project ο Technical feasibility ο’ Can the project be done with existing technology? ο’ Are people available to use the technologies needed? ο Economic feasibility ο’ How much does the system cost to develop? Maintain? How long will it be usable? ο’ Some add schedule feasibility β how long will it take to create the system?
- 36. ο Operational feasibility ο’ What impact will the new system have on how we do business? Will there be changes to where or how processes are performed? ο’ Will there be changes to employee skills needed? Changes to employee training? ο’ Are existing users amenable to a new system? ο’ These types of feasibility can be measured for each project, and compared to determine which is most feasible FEASIBILITY ANALYSIS
- 37. ο’ Like voting or buying a car, feasibility analysis is rarely completely logical or quantifiable ο’ Many other issues can also affect it ο Political climate ο State of the US and/or global economy ο Preferences of the decision makers β favored vendors, technologies, types of projects, etc. FEASIBILITY ANALYSIS
- 38. PLANNING ACTIVITIES ο’ To help structure development activities, we use a life cycle model to identify the major sets of activities, called life cycle phases ο’ There are many kinds of life cycle models ο The Waterfall model is the oldest, and uses phases like Requirements Analysis, High Level Design, Low Level Design, Coding, and Testing ο The Rational Unified Process has Inception, Elaboration, Construction, and Transition phases
- 39. ο’ Each life cycle phase is broken down into more and more specific activities, until the time needed for each activity can be reliably estimated ο’ Then the tasks are put into a Gantt chart or Pert chart to show when they occur relative to each other ο Tasks might occur sequentially, have to start or end together, or wait for some other tasks to be completed PLANNING VIA THE SDLC
- 40. ο Tasks for a project often include the acts of creating specific documents or work products, approving things or making decisions; such as ο’ βPrepare system test planβ ο’ βApprove system releaseβ ο’ βConduct user satisfaction surveyβ ο’ βApprove system requirements specificationβ ο’ So the life cycle model provides guidance on the types of activities needed, but the tasks provide authority for people to do them PLANNING VIA THE SDLC
- 41. WATERFALL MODEL
- 42. FEATURES OF A WATERFALL MODEL ο’ A waterfall model is easy to follow. ο’ It can be implemented for any size project. ο’ Every stage has to be done separately at the right time so you cannot jump stages. ο’ Documentation is produced at every stage of a waterfall model allowing people to understand what has been done. ο’ Testing is done at every stage.
- 43. ADVANTAGES OF A WATERFALL MODEL ο’ Easy to understand, easy to use ο’ Provides structure to inexperienced staff ο’ Milestones are well understood ο’ Sets requirements stability ο’ Good for management control (plan, staff, track) ο’ Works well when quality is more important than cost or schedule
- 44. DISADVANTAGES OF A WATERFALL MODEL ο’ All requirements must be known up front ο’ Deliverables created for each phase are considered frozen β inhibits flexibility ο’ Can give a false impression of progress ο’ Does not reflect problem-solving nature of software development β iterations of phases ο’ Integration is one big bang at the end ο’ Little opportunity for customer to preview the system (until it may be too late)
- 45. WHEN TO USE THE WATERFALL MODEL ο’ Requirements are very well known ο’ Product definition is stable ο’ Technology is understood ο’ New version of an existing product ο’ Porting an existing product to a new platform.
- 46. AGILE SDLCS ο’ Speed up or bypass one or more life cycle phases ο’ Usually less formal and reduced scope ο’ Used for time-critical applications ο’ Used in organizations that employ disciplined methods
- 47. AGILE MANIFESTO
- 48. SOME AGILE METHODS ο’ Adaptive Software Development (ASD) ο’ Feature Driven Development (FDD) ο’ Crystal Clear ο’ Dynamic Software Development Method (DSDM) ο’ Rapid Application Development (RAD) ο’ Scrum ο’ Extreme Programming (XP) ο’ Rational Unify Process (RUP)
- 49. EXTREME PROGRAMMING - XP For small-to-medium-sized teams developing software with vague or rapidly changing requirements Coding is the key activity throughout a software project ο’ Communication among teammates is done with code ο’ Life cycle and behavior of complex objects defined in test cases β again in code
- 50. XP PRACTICES (1-6) 1. Planning game β determine scope of the next release by combining business priorities and technical estimates 2. Small releases β put a simple system into production, then release new versions in very short cycle 3. Metaphor β all development is guided by a simple shared story of how the whole system works 4. Simple design β system is designed as simply as possible (extra complexity removed as soon as found) 5. Testing β programmers continuously write unit tests; customers write tests for features 6. Refactoring β programmers continuously restructure the system without changing its behavior to remove duplication and simplify
- 51. XP Practices (7 β 12) 7. Pair-programming -- all production code is written with two programmers at one machine 8. Collective ownership β anyone can change any code anywhere in the system at any time. 9. Continuous integration β integrate and build the system many times a day β every time a task is completed. 10. 40-hour week β work no more than 40 hours a week as a rule 11. On-site customer β a user is on the team and available full-time to answer questions 12. Coding standards β programmers write all code in accordance with rules emphasizing communication through the code
- 52. XP is βextremeβ because Commonsense practices taken to extreme levels ο’ If code reviews are good, review code all the time (pair programming) ο’ If testing is good, everybody will test all the time ο’ If simplicity is good, keep the system in the simplest design that supports its current functionality. (simplest thing that works) ο’ If design is good, everybody will design daily (refactoring) ο’ If architecture is important, everybody will work at defining and refining the architecture (metaphor) ο’ If integration testing is important, build and integrate test several times a day (continuous integration) ο’ If short iterations are good, make iterations really, really short (hours rather than weeks)
- 53. SUMMARY ο’ This has been a (very) quick tour through the life cycle of a system. ο’ You will have to doβto some extentβall of these activities for your project.