Customer’s Explanation

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