1. System Analysis and Design Rabie A. Ramadan, PhD http://rabieramadan.org 3 5/4/2011

2. Your Project During the Semester 2 - 2 Step 1: Since you are here at Future University, Define the needed projects for the University and asses their feasibility. Write a complete proposal by the next week in a doc file I will asses your proposals and approve one

3. Plan B 1 - 3 Student Web Site Auto registration Auto timetable Generator E-mail System Quiz Generator E-learning System ……

4. Questions to answer 1 - 4 Which development methodology to use ? What are the criteria for selecting your methodology ? Name the team and their roles ? What are the values of the project (tangible and intangible)? Who is the sponsor of the project ? Did you get the committee approval ?

5. Questions to answer 1 - 5 Is it a new system ? If yes, answer the following questions? Define the problem Establish system objectives Identify the USERS Establish functional scope What are the project issues and constraints ?

6. Questions to answer 1 - 6 What is the technical feasibility of the project ? Do we have the capability to develop the system? Does the necessary tech exist? Can it be acquired? Does the proposed equipment have the right capacity for the data? Does the propose have the right: response time, interface, Can the system be expanded? Are the accuracy, reliability, ease of use, ease of access, security ok?

7. Identify Costs and Benefits 1 - 7 CostsBenefits Tangible Intangible ************ ************

8. Organizational feasibility 1 - 8 Is there support/resistance; from or by who? Are current business methods acceptable? Have the user's will be involved? Will the system cause harm?

9. Remember 1 - 9

10. Work and Meta-work 1 - 10 Work is what we do to deliver elements of the project: design, coding, testing, etc. Meta-work, “work about the work”, is the organization and management of the tasks and deliverables to maximize the effectiveness of the work itself. Meta-Meta work: process definition … design of the meta-work of all your projects (process and procedures).

11. Project Manager: Role Slide 11 Responsible for “When” Not responsible for understanding every detail of implementation dependencies PM needs to engage all team members to extract dependencies and possibilities spine PM needs serious “spine” to get straight answers to “how long?”

12. Nomenclature – I Slide 12 Resource: anything with a cost … People, conference rooms, machines, test labs, customers (for testing) Once you get going, resources become fixed. Negotiate early! Most of what you manage are People.

13. Your turn Slide 13 What are the main resources for your project?

14. Nomenclature - II Slide 14 Task Task: an activity that results in a specific deliverable – should be verifiable Each task needs an estimated effort, for each resource assigned to the task. Start with “large grain”, then break down to consistent sizes (measured in days, for example).

15. Your turn Slide 15 What are the main tasks for your project?

16. Estimates of Effort Slide 16 Effort vs. Duration Effort: how long it takes in “abstract” Duration, how long it takes with discounts for meetings, travel, dentists, etc. Be consistent across the entire team, or be specific about the “overhead” rates you apply.. “Uncertainly” can overwhelm the value of an estimate. Be clear with staff as to quality of estimates.

17. Your turn Slide 17 Put a schedule for each task you defined ?

18. Nomenclature – III Slide 18 Tasks are aligned using dependencies … For each task, what other tasks must be accomplished to enable the work. This will require some digging with the individual developers and designers.

19. Nomenclature - IV Slide 19 Milestone: a clearly definable & measurable state that has meaning and importance to the team encapsulates functionality, denotes a specific deliverable Must be verifiable!

20. Verifiable Milestones Slide 20 “SMART” Specific Measurable Aligned Realistic Time-based

21. Your turn Slide 21 What are the mail stones of the project ?

22. Critical Path Slide 22 The set of tasks and milestones that determine the earliest delivery of the project. Map tasks and their dependencies in a tool, and the critical path falls out.

23. More on Milestones Slide 23 Tasks can be hard to manage in detail: omissions, complications.. Build a schedule with excellent Milestones, and manage your team to hit the milestones. Celebrate & acknowledge major milestones.

24. Slack Slide 24 Free slack: The amount of time that a task can be delayed without delaying its successor tasks. Once you lay out the critical path, slack is your friend. Zero slack … everything is on the critical path. Too much slack … not tight enough, or dependencies are not exposed.

25. Drive the Project Slide 25 Often, it is the PM that pushes Gets commitments to delivery (public testimony) Schedules meetings, publishes meeting notes and tasks Do not attend meetings without an agenda. Do not let a meeting end without a summary and next steps. Communication of the expectation makes it happen

26. Before the Project … Slide 26 Develop a Shared Vision Earliest “Discovery”: identifies what system does and for whom Get senior management to respond with scope estimates

27. Discovery & Scope Slide 27 Senior leadership drives project as it is conceived. Keep them involved. Constraints on project (cost, schedule) are documented up front.

28. Bottom-up Scheduling Slide 28 Use a structured breakdown to identify components and interfaces Data Flow Diagram (DFD) is a good source (be consistent) Use experienced developers to estimate effort for each component or interface Early estimates are low quality: iterate The toolset changes everything …

29. Bottom-up Scheduling Slide 29 Each component needs requirements, design, spec, implementation and testing … include it all Assign / allocate resources Look for trouble … Overbooking, gaps, availability

30. Function Point Approach Slide 30 Method to develop estimates of time and resources needed

31. Good Estimates … Slide 31 Reliable estimates can be accomplished by senior engineers when: Platform exists: incremental additions Tool-set well understood and stable Nothing too new or radical

32. Bad Estimates … Slide 32 Estimates get funky when: New tools or language New application area (no established models) New team working together Process is not respected by leadership (scope creep).

33. Risks … Slide 33 Identify risk areas, unknowns: Technology, Skill gaps Resource commitment/focus Use early phases to mitigate risk Prototypes Consultants (with care)

34. Your turn Slide 34 What are the risks of your project?

35. Contingency Planning Slide 35 PM is responsible for leading contingency planning … get team to walk through “plan B”. When risk / uncertainly is high on any particular component. For all elements on the Critical Path.

36. Break the critical path Slide 36 Create mechanisms to reduce dependencies Sample data to drive processes XML is a useful tool for these tricks. Assign more resources … ?

37. A Holy Trinity Slide 37 Do your best to set a plan and allocate your resources. Assuming that you have done a credible job. Additional features require additional testing

38. “Brooks’ Law” Slide 38 From “The Mythical Man-month”, a classic in Software Engineering “Adding resources to a late project only makes it later.” Thus the demands on tracking resources and adjusting early, to compensate while there is still hope.

39. Telling Bad News Slide 39 You have got to do it … Blame is rarely needed: Focus on how, and what next? There is always time to punish later Forest and trees: sometimes its not as bad as it seems. The earlier, the better.

40. Key Definitions 4 - 40 The As-Is system is the current system and may or may not be computerized. The To-Be system is the new system that is based on updated requirements. The System Proposal is the key deliverable from the Analysis Phase.

41. Key Ideas 4 - 41 The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them -- or decide a new system isn’t needed. The System Proposal is presented to the approval committee via a system walk-through. Systems analysis incorporates initial systems design. Requirements determination is the single most critical step of the entire SDLC.

42. REQUIREMENTS DETERMINATION 4 - 42

43. What is a Requirement ? 4 - 43 A statement of what the system must do A statement of characteristics the system must have Focus is on business user needs during analysis phase Requirements will change over time as project moves from analysis to design to implementation

44. Requirement Types 4 - 44 Functional Requirements A process the system hast to perform Information the system must contain Nonfunctional Requirements Behavioral properties the system must have Operational Performance Security Cultural and political

45. Documenting Requirements 4 - 45 Requirements definition report Text document listing requirements in outline forming Priorities may be included Key purpose is to define the project scope: what is and is not to be included.

46. Basic Process of Analysis (Determining Requirements) 4 - 46 Understand the “As-Is” system Identify improvement opportunities Develop the “To-Be” system concept Techniques vary in amount of change BPA – small change BPI – moderate change BPR – significant change Additional information gathering techniques are needed as well

47. Determining Requirements 4 - 47 Participation by business users is essential Three techniques help users discover their needs for the new system: Business Process Automation (BPA) - small change Business Process Improvement (BPI) - moderate change Business Process Reengineering (BPR)- significant change

48. Business Process Automation 4 - 48 Goal: Efficiency for users

49. Identifying Improvements in As-Is Systems 4 - 49 Problem Analysis Ask users to identify problems and solutions Improvements tend to be small and incremental Rarely finds improvements with significant business value Root Cause Analysis Challenge assumptions about why problem exists Trace symptoms to their causes to discover the “real” problem

50. Root Cause Analysis Example 4 - 50

51. Business Process Improvement 4 - 51 Goal: Efficiency and effectiveness for users

52. Duration Analysis 4 - 52 Calculate time needed for each process step Calculate time needed for overall process Compare the two – a large difference indicates a badly fragmented process Potential solutions: Process integration – change the process to use fewer people, each with broader responsibilities Parallelization – change the process so that individual step are performed simultaneously

53. Activity-Based Costing 4 - 53 Calculate cost of each process step Consider both direct and indirect costs Identify most costly steps and focus improvement efforts on them

54. Benchmarking 4 - 54 Studying how other organizations perform the same business process Informal benchmarking Common for customer-facing processes Interact with other business’ processes as if you are a customer

55. Business Process Reengineering 4 - 55 Goal: Radical redesign of business processes

56. Outcome Analysis 4 - 56 Consider desirable outcomes from customers’ perspective Consider what the organization could enable the customer to do

57. Technology Analysis 4 - 57 Analysts list important and interesting technologies Managers list important and interesting technologies The group identifies how each might be applied to the business and how the business might benefit

58. Activity Elimination 4 - 58 Identify what would happen if each organizational activity were eliminated Use “force-fit” to test all possibilities

59. Your Turn 4 - 59 How do you know whether to use business process automation, business process improvement, or business process reengineering? Provide one example.

60. REQUIREMENTS-GATHERING TECHNIQUES 4 - 60

61. Interviews 4 - 61 Most commonly used technique Basic steps: Selecting Interviewees Designing Interview Questions Preparing for the Interview Conducting the Interview Post-Interview Follow-up

62. Selecting Interviewees 4 - 62 Based on information needs Best to get different perspectives Managers Users Ideally, all key stakeholders Keep organizational politics in mind

63. Types of Questions 4 - 63 Types of Questions Examples Closed-Ended Questions* How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions* What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions* Why? * Can you give me an example? * Can you explain that in a bit more detail?

64. Organizing Interview Questions 4 - 64 Unstructured interview useful early in information gathering Goal is broad, roughly defined information Structured interview useful later in process Goal is very specific information

65. Structuring the Interview 4 - 65 High Level: Very General Medium-Level: Moderately Specific Low-Level: Very Specific TOP DOWN BOTTOM UP EXAMPLES?

66. Interview Preparation Steps 4 - 66 Prepare general interview plan List of question Anticipated answers and follow-ups Confirm areas of knowledge Set priorities in case of time shortage Prepare the interviewee Schedule Inform of reason for interview Inform of areas of discussion

67. Conducting the Interview 4 - 67 Appear professional and unbiased Record all information Check on organizational policy regarding tape recording Be sure you understand all issues and terms Separate facts from opinions Give interviewee time to ask questions Be sure to thank the interviewee End on time

68. Conducting the Interview Practical Tips 4 - 68 Take time to build relationship Pay attention Summarize key points Be brief Be honest Watch body language

69. Post-Interview Follow-Up 4 - 69 Prepare interview notes Prepare interview report Have interviewee review and confirm interview report Look for gaps and new questions

70. Your Turn 4 - 70 Based on the previous tips, work in two groups to conduct an interview. Prepare questions and try to interview the other party. Exchange your rules

71. Your Assignment 4 - 71 Prepare interview notes Prepare interview report Have interviewee review and confirm interview report Look for gaps and new questions Do this for at least 5 people ?

72. Joint Application Development (JAD) 4 - 72

73. Joint Application Development 4 - 73 A structured group process focused on determining requirements Involves project team, users, and management working together May reduce scope creep by 50% Very useful technique

74. JAD Participants 4 - 74 Facilitator Trained in JAD techniques Sets agenda and guides group processes Scribe(s) Record content of JAD sessions Users and managers from business area with broad and detailed knowledge

75. JAD Sessions 4 - 75 Time commitment – ½ day to several weeks Strong management support is needed to release key participants from their usual responsibilities Careful planning is essential e-JAD can help alleviate some problems inherent with groups

76. JAD Meeting Room 4 - 76 JPEG Figure 5-5 Goes Here