System Analysis and Design
Rabie A. Ramadan, PhDhttp://rabieramadan.org
3
5/4/2011
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
Plan B
1 - 3
Student Web Site • Auto registration
• Auto timetable Generator
• E-mail System
• Quiz Generator
• E-learning System
……
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 ?
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 ?
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?
Identify Costs and Benefits
1 - 7
Costs Benefits
Tangible
Intangible
***
***
***
***
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?
Remember
1 - 9
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).
Project Manager: Role
Slide 11
Responsible for “When”• Not responsible for understanding every detail of
implementation
• PM needs to engage all team members to extract dependenciesdependencies and possibilities
• PM needs serious “spinespine” to get straight answers to “how long?”
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.
Your turn
Slide 13
What are the main resources for your project?
Nomenclature - II
Slide 14
TaskTask: 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).
Your turn
Slide 15
What are the main tasks for your project?
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.
Your turn
Slide 17
Put a schedule for each task you defined ?
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.
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!
Verifiable Milestones
Slide 20
“SMART” • Specific
• Measurable
• Aligned
• Realistic
• Time-based
Your turn
Slide 21
What are the mail stones of the project ?
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.
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.
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.
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
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
Discovery & Scope
Slide 27
Senior leadership drives project as it is conceived. Keep them involved.
Constraints on project (cost, schedule) are documented up front.
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 …
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
Function Point Approach
Slide 30
Method to develop estimates of time and resources needed
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
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).
Risks …
Slide 33
Identify risk areas, unknowns:• Technology, Skill gaps
• Resource commitment/focus
Use early phases to mitigate risk• Prototypes
• Consultants (with care)
Your turn
Slide 34
What are the risks of your project?
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.
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 … ?
A Holy Trinity
Slide 37
Features
Quality Schedule
Resources
•Do your best to set a plan and allocate your resources.•Assuming that you have done a credible job.•Additional features require additional testing
“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.
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.
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.
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.
REQUIREMENTS DETERMINATION
4 - 42
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
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
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.
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
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
Business Process Automation
4 - 48
Goal:
Efficiency for users
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
Root Cause Analysis Example
4 - 50
Business Process Improvement
4 - 51
Goal:
Efficiency and
effectivenessfor users
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
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
Benchmarking
4 - 54
Studying how other organizations perform the same business process
Informal benchmarkingCommon for customer-facing processes
Interact with other business’ processes as if you are a customer
Business Process Reengineering
4 - 55
Goal:
Radical redesign of
business processes
Outcome Analysis
4 - 56
Consider desirable outcomes from customers’ perspective
Consider what the organization could enable the customer to do
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
Activity Elimination
4 - 58
Identify what would happen if each organizational activity were eliminated
Use “force-fit” to test all possibilities
Your Turn
4 - 59
How do you know whether to use business process automation, business process improvement, or business process reengineering?
Provide one example.
REQUIREMENTS-GATHERING TECHNIQUES
4 - 60
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
Selecting Interviewees
4 - 62
Based on information needs
Best to get different perspectives• Managers
• Users
• Ideally, all key stakeholders
Keep organizational politics in mind
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?
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
Structuring the Interview
4 - 65
High Level:Very General
Medium-Level:Moderately
Specific
Low-Level:Very Specific
TOP DOWN
BOTTOM UP
EXAMPLES?
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
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
Conducting the InterviewPractical Tips
4 - 68
Take time to build relationship Pay attention Summarize key points Be brief Be honest Watch body language
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
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
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 ?
Joint Application Development (JAD)
4 - 72
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
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
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
JAD Meeting Room
4 - 76
JPEG Figure 5-5 Goes Here