1 / 69

Customer’s Explanation

Customer’s Explanation. Proj. Ldr’s understanding. Analyst’s Design. Programmer’s effort. Business Consultant’s description. Billing. What the customer really needed !!. Software Engineering.

osric
Télécharger la présentation

Customer’s Explanation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Customer’s Explanation Proj. Ldr’s understanding

  2. Analyst’s Design Programmer’s effort

  3. Business Consultant’s description Billing

  4. What the customer really needed !!

  5. Software Engineering • The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines. • The application (and study) of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software - i.e., Application of engineering to software

  6. SSAD • An organizational process used to develop and maintain computer-based information systems

  7. Characteristics of Software • Developed or engineered - not manufactured • Does not wear out • Deteriorates - why?

  8. Failure Rate for Hardware Failure Rate Time

  9. Ideal Failure Rate for software Failure Rate Time

  10. Actual Failure Rate for software Failure Rate Time

  11. Software Myths • We have state of the art equipment and software tools. We can produce a quality product Takes a lot more to produce quality software. Good processes and techniques more important • If we fall behind schedule, we can add more programmers and catch up Adding more people to a late project makes it “later.” • General statement of objectives sufficient to start programming Poor definition major cause of failed efforts • Software is flexible - change is easy Can cause major upheaval

  12. Software Myths • Job is done once program is written and it works The sooner you start writing code, the longer it will take to complete • Only deliverable for a successful project is a working program Program only a part. Documents and data just as important Recognition of software realities is the first step towards effective software development

  13. Objectives • Describe the life cycle of a specific systems analysis and design project, including the purpose and deliverables of each step. • List the important skills required of a systems analyst in conducting a systems analysis and design project. • Explain the purpose of adopting a standard methodology for systems development in an organization. • Discuss the roles of individuals who work on a systems project. • Explain the differences between the analysis, design, and implementation phases of a systems development project. • Describe the purpose of basic documentation produced during a systems development project

  14. Case

  15. Systems Design The process of planning a new business system, or one to replace / complement an existing system • Existing system must be thoroughly understood • Determine how computers can best be used

  16. Systems Analysis • The process of gathering and interpreting fact, diagnosing problems and using the information to recommend improvements • NOT • Determining what should be computerized and how • Determining what changes are to be made: change should be consequence, not intent

  17. System Development Life Cycle(SDLC)

  18. SDLC Model A framework that describes the activities performed at each stage of a software development project

  19. SDLC Predictive Life cycle • Waterfall • Spiral • Prototyping • Incremental Build • RAD Adaptive Software Development • XP • Scrum

  20. Waterfall Model Requirement functions, behaviour, performance, interfaces Design data structure, software arch., algorithms Implementation Source code, db, documentation Testing Installation • One step at a time • No going back Maintenance

  21. Waterfall Model Strengths • Easy to understand, easy to use • Structure to inexperienced staff • Milestones well understood • Good for management control

  22. Waterfall Model Weaknesses • Requirements must be known upfront • Phase deliverables frozen – no flexibility • False impression of progress possible • Integration is one big bang at the end • Little opportunity for preview

  23. Waterfall Model When to use • Requirements are well known • Product definition is stable • Technology is understood

  24. Structured Evolutionary Prototyping Prototype User evaluation Refine prototype User satisfied? NO YES Finish

  25. Structured Evolutionary Prototyping Strengths • System requirements “seen” as they are being gathered • Developers learn from customers • A more accurate end product • Unexpected requirements met • Flexible design and development • Steady, visible signs of progress

  26. Structured Evolutionary Prototyping Weaknesses • “Code-and-fix” / “quick-and-dirty” • Maintainability may be overlooked • Feature / Scope creep

  27. Structured Evolutionary Prototyping When to use • Requirements unstable • First stage of waterfall model • Develop user interfaces • Short-lived demonstrations • New, original development

  28. Spiral Model • Define the problem in detail • Create a preliminary design • Construct first prototype • Construct second prototype • Risk Analysis (strengths, weaknesses, risks) • Define requirements • Plan and design 2nd prototype • Construct 2nd prototype

  29. Spiral Model • Project may be scrapped at this point • Cost overruns • Operating cost miscalculations • Other factors • Repeat process till full satisfaction

  30. Spiral Model Advantages • High amount of risk analysis • Software produced early • Easier to cope with changes • Good for large, expensive projects

  31. Spiral Model Disadvantages • Risk analysis requires expertise • Costly model to use • Estimates of cost and schedule harder at start of the project

  32. Agile Models Scrum • Iterative, incremental model • Requirements can change • “Team” activity important • Sprint • Unit of activity (one week to one month) • Completed product

  33. Agile Models Scrum Roles • Product Owner • Development Team • (3 - 9, cross-functional) • Scrum Master

  34. Agile Models Scrum Events • Sprint Planning Meeting • At the start of sprint cycle • Eight hours • Identify quantum of work to be done • Daily Scrum Meeting • 15 minutes • What was done yesterday • Plans for today • Any problems

  35. Agile Models Scrum Events • Sprint Review Meeting • At the end of sprint cycle • Four hours • Demo to stakeholders • Incomplete work not demonstrated • Sprint Retrospective Meeting • Three hours • What went wrong, what was right • Process improvements

  36. Agile Models Pitfalls • Lack of sponsor support • Insufficient training • Product Owner Role is not properly filled • Teams not focused • Excessive Preparation/Planning • Problem-Solving in the Daily Scrum

  37. Agile Models Pitfalls • Assigning Tasks • ScrumMaster as a contributor • Lacking test automation • Allowing technical debt to buildup • Attempting to take on too much in a sprint • Fixed time, resources, scope and quality

  38. People

  39. System Analyst Role • Liaison between IT professionals and the business professionals (end users) • Recommend solutions • Coordinate development • Need not be involved in actual development

  40. System Analyst Tasks • Integration of new technical requirements with existing processes and skill sets • Plan system flow • Interact with users and document requirements • Write technical requirements • Compare software against metrics • Cost, flexibility, ease of use, functionality …

  41. System Analyst Tasks • Interact with designers to understand software limitations • Help programmers ex: provide flow charts, use cases, database design • Perform system testing • Deploy the completed system • Contribute to user manuals

  42. System Analyst Skills • Knowledge of IT • General business knowledge • General problem-solving skills • Interpersonal communication skills • Good interpersonal relations skills • Flexibility and adaptability • Character and ethics

  43. User All those interacting with the system • Hands-on user • Direct interaction through equipment • Indirect end-user • Uses information/reports but does not operate system • User Manager • Has organizational responsibility for control of system activities • Senior Management

  44. Tools of System Development

  45. Requirements Determination • Requirements anticipation • Foreseeing characteristics • Based on experience • Bias/shortcuts could creep in • Requirements Investigation • System study • Use of fact-finding, data flow analysis • Requirements Specification • Describe the system • What requirements to be met • Strategies for fulfilling requirements

  46. Types of Requirements • User Transaction Requirements • User Decision Requirements • Organization-wide requirements

  47. Fact-finding • User Transaction Requirements • User Decision Requirements • Organization-wide requirements • Interviews • Questionnaires • Observation

  48. Decision Tree Invoice properly priced Payment Valid PO Invoice not properly priced Reject Invoice properly priced Payment Invoice signed Auth. available Invoice not properly priced Reject No valid PO Auth. not available Reject Payment Invoice properly priced Valid PO Invoice not properly priced Reject Items received Reject No valid PO Invoice not signed Reject Items not received

  49. Structured English • Based on structured logic • Simple English statements such as add, multiply, move, and so on • Appropriate decisions are not complex

  50. Structured English Do until all invoices are processed IF invoice is signed ELSE IF item was not accepted Reject END IF IF valid PO prepared ELSE IF auth. not received Reject invoice END IF IF invoice properly priced ELSE Reject invoice END IF END IF END DO

More Related