Your SlideShare is downloading. ×
0
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...
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

McGraw-Hill/Irwin ©2008 The McGraw-Hill Companies, All Rights ...

3,098

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
3,098
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
154
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. CHAPTER 11 SYSTEMS DEVELOPMENT
  • 2. DEVLOPING SOFTWARE <ul><li>Software that is built correctly can transform/be adapted as the organization and its business transforms </li></ul><ul><li>Software that effectively meets employee needs will help an organization become more productive and enhance decision making </li></ul><ul><li>Software that does not meet employee needs may have a damaging effect on productivity and can even cause a business to fail </li></ul>
  • 3. DEVELOPING SOFTWARE <ul><li>As organizations’ reliance on software grows, so do the business-related consequences of software successes and failures including: </li></ul><ul><ul><li>Increase or decrease in revenue </li></ul></ul><ul><ul><li>Repair or damage to brand reputation </li></ul></ul><ul><ul><li>Prevent or incur liabilities </li></ul></ul><ul><ul><li>Increase or decrease productivity </li></ul></ul>
  • 4. The Systems Development Life Cycle (SDLC) <ul><li>Large, complex IT systems take teams of architects, analysts, developers, testers, and users many years to create </li></ul><ul><li>The systems development life cycle is the foundation for many systems development methodologies </li></ul><ul><ul><li>Systems development life cycle – the overall process for developing information systems from planning and analysis through implementation and maintenance </li></ul></ul>
  • 5. SDLC
  • 6. PHASE 1: PLANNING <ul><li>Planning phase – involves establishing a high-level plan of the intended project and determining project goals </li></ul><ul><li>Primary planning activities include </li></ul><ul><ul><li>Identify and select the system for development </li></ul></ul><ul><ul><li>Assess project feasibility </li></ul></ul><ul><ul><li>Develop the project plan </li></ul></ul>
  • 7. Planning 1: Identify and Select the System for Development <ul><li>Organizations use different forms of evaluation criteria to determine which systems to develop </li></ul><ul><ul><li>Critical success factor (CSF) – a factor that is critical to an organization’s success </li></ul></ul>
  • 8. Planning 1: Identify and Select the System for Development
  • 9. Planning 2: Assess Project Feasibility <ul><li>Feasibility study – determines if the proposed solution is feasible and achievable from a financial, technical, and organizational standpoint </li></ul><ul><li>Different types of feasibility studies </li></ul><ul><ul><li>Economic feasibility study </li></ul></ul><ul><ul><li>Operational feasibility study </li></ul></ul><ul><ul><li>Technical feasibility study </li></ul></ul><ul><ul><li>Schedule feasibility study </li></ul></ul><ul><ul><li>Legal and contractual feasibility study </li></ul></ul>
  • 10. Planning 3:Develop the Project Plan <ul><li>Developing the project plan is a difficult and important activity </li></ul><ul><li>The project plan is the guiding force behind on-time delivery of a complete and successful system </li></ul><ul><li>Continuous updating of the project plan must be performed during every subsequent phase during the SDLC </li></ul>
  • 11. PHASE 2: ANALYSIS <ul><li>Analysis phase – involves analyzing end-user business requirements and refining project goals into defined functions and operations of the intended system </li></ul><ul><li>Primary analysis activities include: </li></ul><ul><ul><li>Gather business requirements </li></ul></ul><ul><ul><li>Create process diagrams </li></ul></ul><ul><ul><li>Perform a buy vs. build analysis </li></ul></ul>
  • 12. Analysis 1: Gather Business Requirements <ul><li>Business requirements – the detailed set of business requests that the system must meet in order to be successful </li></ul><ul><li>Different ways to gather business requirements </li></ul><ul><ul><li>Joint application development (JAD) session – where employees meet to define or review the business requirements for the system </li></ul></ul><ul><ul><li>Interviews </li></ul></ul><ul><ul><li>Questionnaires </li></ul></ul><ul><ul><li>Observations </li></ul></ul><ul><ul><li>Review business documents </li></ul></ul>
  • 13. Analysis 1: Gather Business Requirements <ul><li>The system users review the requirements definition document and determine if they will sign-off on the business requirements </li></ul><ul><ul><li>Requirements definition document – contains the final set of business requirements, prioritized in order of business importance </li></ul></ul><ul><ul><li>Sign-off – the system users’ actual signatures indicating they approve all of the business requirements </li></ul></ul>
  • 14. Analysis 2: Create Process Diagrams <ul><li>Process modeling – graphically representing the processes that capture, manipulate, store, and distribute information between a system and its environment </li></ul><ul><li>Common process modeling diagrams include </li></ul><ul><ul><li>Data flow diagrams (DFD) – illustrate the movement of information between external entities and the processes and data stores within the system </li></ul></ul><ul><ul><li>Computer-aided software engineering (CASE) tools –automate systems analysis, design, and development </li></ul></ul>
  • 15. Analysis 2: Create Process Diagrams <ul><li>Sample data flow diagram </li></ul>
  • 16. Analysis 3: Perform a Buy vs. Build Analysis <ul><li>An organization faces two primary choices when deciding to develop an information system </li></ul><ul><ul><li>Buy the information system from a vendor </li></ul></ul><ul><ul><ul><li>Commercial off-the shelf (COTS) – software package or solution that is purchased to support one or more business functions and information systems </li></ul></ul></ul><ul><ul><ul><li>SCM, CRM, and ERP solutions are typically COTS </li></ul></ul></ul><ul><ul><li>Build the information system itself </li></ul></ul>
  • 17. Analysis 3: Perform a Buy vs. Build Analysis <ul><li>Organizations must consider the following when making a buy vs. build decision: </li></ul><ul><ul><li>Are there any currently available products that fit the needs? </li></ul></ul><ul><ul><li>Are there features that are not available and important enough to warrant the expense of in-house development? </li></ul></ul><ul><ul><li>Can the organization customize or modify an existing COTS to fit its needs? </li></ul></ul><ul><ul><li>Is there a justification to purchase or develop based on the acquisition cost? </li></ul></ul>
  • 18. Analysis 3: Perform a Buy vs. Build Analysis <ul><li>Three key factors an organization should also consider when contemplating the buy vs. build decision </li></ul><ul><ul><li>Time to market </li></ul></ul><ul><ul><li>Availability of corporate resources </li></ul></ul><ul><ul><li>Corporate core competencies </li></ul></ul>
  • 19. PHASE 3: DESIGN <ul><li>Design phase – involves describing the desired features and operations of the system including screen layouts, business rules, process diagrams, pseudo code, and other documentation </li></ul><ul><li>Primary design activities include: </li></ul><ul><ul><li>Design the IT infrastructure </li></ul></ul><ul><ul><li>Design system models </li></ul></ul>
  • 20. Design 1: Design the IT Infrastructure <ul><li>Sample IT infrastructure </li></ul>
  • 21. Design 2: Design System Models <ul><li>Modeling – the activity of drawing a graphical representation of a design </li></ul><ul><li>Different modeling types include: </li></ul><ul><ul><li>Graphical user interface (GUI) screen design </li></ul></ul><ul><ul><li>Data models </li></ul></ul><ul><ul><ul><li>Entity relationship diagram (ERD) </li></ul></ul></ul>
  • 22. Design 2: Design System Models <ul><li>Sample entity relationship diagram (ERD) </li></ul>
  • 23. PHASE 4: DEVELOPMENT <ul><li>Development phase – involves taking all of the detailed design documents from the design phase and transforming them into the actual system </li></ul><ul><li>Primary development activities include: </li></ul><ul><ul><li>Develop the IT infrastructure </li></ul></ul><ul><ul><li>Develop the database and programs </li></ul></ul>
  • 24. Development 1: Develop the IT Infrastructure based on the design
  • 25. Development 2: Develop the database & programs based on the Models from the Design Phase
  • 26. PHASE 5: TESTING <ul><li>Testing phase – involves bringing all the project pieces together into a special testing environment to test for errors, bugs, and interoperability, in order to verify that the system meets all the business requirements defined in the analysis phase </li></ul><ul><li>Primary testing activities include: </li></ul><ul><ul><li>Write the test conditions </li></ul></ul><ul><ul><li>Perform the system testing </li></ul></ul>
  • 27. Testing 1: Write the Test Conditions <ul><li>Test conditions – the detailed steps the system must perform along with the expected results of each step </li></ul>
  • 28. Testing 2: Perform the System Testing <ul><li>Types of testing: </li></ul><ul><ul><li>Unit testing – tests each unit of code upon completion to determine errors in that unit </li></ul></ul><ul><ul><li>Application (or system) testing – verifies that all units of code work together and that the total system satisfies all functional and operational requirements </li></ul></ul><ul><ul><li>Integration testing – exposes faults in the integration of software components or units with other systems </li></ul></ul>
  • 29. Testing 2: Perform the System Testing <ul><li>Different types of testing, cont. </li></ul><ul><ul><li>Regression testing – determines if a functional improvement or repair to the system has affected the other functional aspects of the SW </li></ul></ul><ul><ul><li>User acceptance testing (UAT) – determines whether a system satisfies its acceptance criteria, enabling the customer to decide whether or not to accept the system </li></ul></ul><ul><ul><li>Documentation testing – verifies instruction guides are helpful and accurate </li></ul></ul><ul><ul><li>Backup and recovery testing – tests the ability of an application to be restarted after failure </li></ul></ul>
  • 30. PHASE 6: IMPLEMENTATION <ul><li>Implementation phase – involves placing the system into production so users can begin to perform actual business operations with the system </li></ul><ul><li>Primary implementation activities include: </li></ul><ul><ul><li>Write detailed user documentation </li></ul></ul><ul><ul><li>Provide training for the system users </li></ul></ul><ul><ul><li>Determine implementation method </li></ul></ul>
  • 31. Implementation 1: Write Detailed User Documentation <ul><li>System users require User documentation – highlights how to use the system </li></ul>
  • 32. Implementation 2: Provide Training for the System Users <ul><li>Organizations must provide training for system users </li></ul><ul><li>Two popular types include: </li></ul><ul><ul><li>Online training – conducted over the Internet or from a CD-ROM </li></ul></ul><ul><ul><li>Workshop training – set in a classroom-type environment and led by an instructor </li></ul></ul>
  • 33. Implementation 3: Determine Implementation Method <ul><li>Four primary implementation methods </li></ul><ul><ul><li>Parallel implementation </li></ul></ul><ul><ul><li>Plunge implementation </li></ul></ul><ul><ul><li>Pilot implementation </li></ul></ul><ul><ul><li>Phased implementation </li></ul></ul>
  • 34. PHASE 7: MAINTENANCE <ul><li>Maintenance phase – involves performing changes, corrections, additions, and upgrades to ensure the system continues to meet the business goals </li></ul><ul><li>Primary maintenance activities include: </li></ul><ul><ul><li>Provide a help desk to support the system users </li></ul></ul><ul><ul><li>Perform system maintenance </li></ul></ul><ul><ul><li>Provide an environment to support system changes </li></ul></ul>
  • 35. Maintenance 1: Provide a Help Desk to Support System Users <ul><li>Internal system users have a phone number for the help desk they call whenever they have issues or questions about the system </li></ul><ul><ul><li>Help desk – a group of people who respond to internal system user questions </li></ul></ul><ul><li>Providing a help desk is an excellent way to provide comprehensive support for new system users </li></ul>
  • 36. Maintenance 2: Perform System Maintenance/Changes <ul><li>Maintenance – fixing or enhancing an information system </li></ul><ul><li>Different types of maintenance include: </li></ul><ul><ul><li>Corrective maintenance </li></ul></ul><ul><ul><li>Adaptive maintenance </li></ul></ul><ul><ul><li>Perfective maintenance </li></ul></ul><ul><ul><li>Preventative maintenance </li></ul></ul>
  • 37. Maintenance 3: Support System Changes <ul><li>An organization must modify its systems to support the business environment </li></ul><ul><li>It typically accomplishes this through change management systems and change control boards </li></ul><ul><ul><li>Change management system – a collection of procedures to document a change request and define the steps necessary to consider the change based on the expected impact of the change </li></ul></ul><ul><ul><li>Change control board (CCB) – responsible for approving or rejecting all change requests </li></ul></ul>
  • 38. Alternative Software Development Methodologies <ul><li>There are a number of different software development methodologies including: </li></ul><ul><ul><li>Waterfall </li></ul></ul><ul><ul><li>Rapid application development (RAD) </li></ul></ul><ul><ul><li>Extreme programming </li></ul></ul><ul><ul><li>Agile </li></ul></ul>
  • 39. Waterfall Methodology <ul><li>Waterfall methodology – a sequential, activity-based process in which each phase in the SDLC is performed sequentially from planning through implementation and maintenance </li></ul>
  • 40.  
  • 41. Rapid Application Development Methodology (RAD) <ul><li>Rapid application development methodology (RAD) – emphasizes extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the systems development process </li></ul><ul><li>The prototype is an essential part of the analysis phase when using a RAD methodology </li></ul><ul><ul><li>Prototype – a smaller-scale representation or working model of the users’ requirements or a proposed design for an information system </li></ul></ul>
  • 42. Rapid Application Development Methodology (RAD)
  • 43. Extreme Programming Methodology (XP) <ul><li>Extreme programming (XP) methodology – breaks a project into tiny phases; developers cannot continue on to the next phase until the first phase is complete </li></ul>
  • 44. Agile Methodology <ul><li>Agile methodology – a form of XP, aims for customer satisfaction through early and continuous delivery of useful software components </li></ul><ul><ul><li>Agile is similar to XP but with less focus on team coding and more on limiting project scope </li></ul></ul><ul><ul><li>An agile project sets a minimum number of requirements and turns them into a deliverable product </li></ul></ul>
  • 45. DEVELOPING SUCCESSFUL SOFTWARE <ul><li>Primary principles for successful software development include: </li></ul><ul><ul><li>Slash the budget </li></ul></ul><ul><ul><li>If it doesn’t work, kill it </li></ul></ul><ul><ul><li>Keep requirements to a minimum – watch out for: </li></ul></ul><ul><ul><ul><li>Scope creep- the scope of the project increases </li></ul></ul></ul><ul><ul><ul><li>Feature creep – extra features are added </li></ul></ul></ul><ul><ul><li>Test and deliver frequently </li></ul></ul><ul><ul><li>Assign non-IT executives to software projects </li></ul></ul>
  • 46. SOFTWARE PROBLEMS ARE BUSINESS PROBLEMS <ul><li>Primary reasons for project failure include </li></ul><ul><ul><li>Unclear or missing business requirements </li></ul></ul><ul><ul><li>Skipping SDLC phases </li></ul></ul><ul><ul><li>Failure to manage project scope –allowing: </li></ul></ul><ul><ul><ul><li>Scope creep – occurs when the scope increases </li></ul></ul></ul><ul><ul><ul><li>Feature creep – occurs when extra features are added </li></ul></ul></ul><ul><ul><li>Failure to manage project plan </li></ul></ul><ul><ul><li>Changing technology </li></ul></ul>
  • 47. SOFTWARE PROBLEMS ARE BUSINESS PROBLEMS <ul><li>Find errors early: the later in the SDLC an error is found - the more expensive it is to fix </li></ul>
  • 48. <ul><li>http://www.updatexp.com/we-share-your-pain.html </li></ul>

×