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