TP-SystemsDesign1

Diploma of Software Development –

Subject:

Systems Design 1

Developer:

Allan Tadich

Contact Details:

Phone: (W) 9215 7011

Email: [email protected]

Time Frame:

36 hours – 2 hours per week for 18 weeks

References:

1. Systems Analysis and Design: 4th Edition – Shelly, Cashman and Rosenblatt – Course Technology: Thompson Learning

2. Essentials of IT: General or Software Applications – Hamilton, Olekalns, Rogers, Sutton and Wilson – Eastern House (specifically for ICAITS031B)

3. Business Information Processing – Kypridemos and Veliotos - CITB404 – Eastern House

4. Systems Development Analysis, Feasibility and Implementation - CITB408/9/10 - Eastern House

5. Modern Systems Analysis & Design: 2nd Edition – Hoofer, George and Valacich – Addison-Wesley

6. Toolbox - Systems Analysis & Design http://toolbox.vetonline.vic.edu.au/

7. Systems Analysis and Design: 4th Edition – Kendall and Kendall – Prentice Hall

Competencies:

ICAITB059B Develop detailed technical design

ICAITT077C Develop detailed test plan

Diploma of MM (Integration) – Systems Design Version 1 Feb 05 AT

mailto:[email protected]

http://toolbox.vetonline.vic.edu.au/

Subject Overview:

Ensure the client business requirements are developed as a pre-requisite to designing the new/additional system.

Pre-requisites:

Nil

Assessment:

1. Assignment – 40%2. Class presentation – 20%3. Exam – 40%

Students must be deemed competent in each assessment item to receive a graded result.

Sequence of Topics:

Time Topic Reference Comments6hrs Specify context of business need or

problem:

1.3 The business need is fully understood by project team and client.

1.2 Methods for gathering and collecting information are ensured to be cost effective and relevant, both to the project and client environment.

1.3 System boundaries, scope and methodologies to be used are determined.

Students should have the textbook by week 3 and we can therefore start looking at the textbook

Information from lesson plans provided by Allan Tadich and from Chapter 1 of the Shelly & Cashman textbook (5th edition).

The aim here is to provide students with a background to systems analysis by initially considering the organization and its features, functions, etc.

6hrs Specify interested parties:

2.1 People (especially the owner, sponsor and those that will contribute to defining the requirements and using the system), and roles of client users are identified.

2.2 The physical requirements of the system are identified taking into account current system functionality, geography, environment, client user and cost

Chapter 1 – Systems Analysis and Design : Shelly, Cashman and Rosenblatt


constraints. systems, user productivity systems & information system integration

2.3 Case studies

These are a list of the relevant headings from the textbook. Materials i.e. worksheets, student notes etc. will be developed in due course.

2hrs Strategic plans.Use as intro only.

SCR(5) 2, Analysing the business case.

SCR(4) 2.2.

<overlaps material covered in Client Needs Analysis >

Strategic plans.Use as intro only.

2hrs Problem and solution statements.Practical activity to get students to focus on identifying the problem.

key terms: problem scope, problem domain.

[P] determine the problem for: Programmer's

toolbox 1 Programmer's

toolbox 5 (start)

Programmer's toolbox 8 (start)

Problem and solution statements.Practical activity to get students to focus on identifying the problem.

key terms: problem scope, problem domain.

4hrs SDLC methodologies (overview):

traditional, waterfall prototype RAD JAD

Focus on design and construction.

SCR(5) 1, Intro to Systems analysis and design.

Brief intro to: modelling prototyping CASE structured

analysis OO analysis SDLC –

Waterfall and interactive development guidelines

SDLC methodologies (overview):

traditional, waterfall

prototype RAD JAD

Focus on design and construction.


SCR(5) 3, Requirements modeling

JAD and RAD

SCR(4) 1.14 – .21Brief intro to: modelling, prototyping, CASE, JAD and RAD, structured analysis, OO analysis, SDLC – Waterfall and interactive development guidelines

[P] SCR(5) 3, Personal Trainer Inc case study. Determine requirements.

[P] Continue with toolbox problems. [P] Roach's Restaurant problem statement and solution. Students can determine if solution solves the problem and comment on the interface.

2hrs SDLC methodologies (detailed): traditional prototype RAD JAD

Examine the methodologies described in SCR.

There are many other methodologies described in textbooks and on the web.

In many textbooks, the traditional SDLC

SCR(5) 5, Development strategies

select relevant sections

[P] SCR(5) 5, Personal Trainer Inc case study.

SCR(4)6.2 –.9 evaluating alternatives, 6.16

SDLC methodologies (detailed): traditional prototype RAD JAD

Examine the methodologies described in SCR.


has 7 phases: Problem Definition, Feasibility, Analysis, Design, Development, Implementation and Maintenance.

completion of analysis, 6.17 transition to design, 6.18 - .20 Prototyping (incl advantages and disadvantages), 6.25 overview of design, 3.3 - .4 Joint Application Development

[P] SCR(4) Look at Ridgeway Company case study 3.45 q1 (determine requirements) and q2 (scalability issues) only. This case study selected because it is complete - others are all in parts.

SCR(4). Toolkit 4. 4.1 - .5 Rapid

Application Development

There are many other methodologies described in textbooks and on the web.

In many textbooks, the traditional SDLC has 7 phases: Problem Definition, Feasibility, Analysis, Design, Development, Implementation and Maintenance.

[P] Follow links to OO Tips web site. Investigate "Extreme Programming", "Pair programming" and "To diagram or not to diagram".

[P] SCR(5) 3,4,5, Personal Trainer Inc case study. Work in teams: Try to sketch out an initial (rough) design. Which development


technique would you use and why?

[P] SCR(4) Continue Ridgeway Company case study example.

2hrs Other methodologiesSpiralIterative

Examine methodologies described in UML(R). Compare with those in described in SCR.

UML(R) 1.1, Lifecycle models. Waterfall, spiral, incremental-iterative.

UML(R) 1.2, Understand the unified modelling process. Rational Unified Process phases: inception, elaboration, construction and transition.

Larman –

timeboxing – complete development cycle in 2 to 6 weeks.

Selected pages or slides from OOSAD

Other methodologiesSpiralIterative

Examine methodologies described in UML(R). Compare with those in described in SCR.

2hrs Comparison of life cycles

Look at advantages and disadvantages of each life cycle. Determine the situations where a particular life cycle should be used.

B407 – text has a comparison of traditional SDLC and prototyping. Available on CIT server as

Comparison of life cycles

Look at advantages and disadvantages of each life cycle.


SDLC_Comparison.doc.

[P] Discuss advantages and disadvantages of each approach in relation to a given case study.Possible case studies: SCR(5)

Personal Trainer Inc

SCR(4) Ridgeway Country Club

Determine the situations where a particular life cycle should be used.

4hrs Develop a detailed test plan Classroom based activity

Feedback session to clients

2hrs Gather requirements:

4.1 Questionnaires are issued and participation in workshops and interviews has occurred as per the requirements plan.

4.2 Collected data is evaluated and collation of the requirements is started.

4.3 Any gaps in knowledge or other requirements issues relevant to obtaining a satisfactory resolution are followed up.

4.4 Views and requirements of key client users are identified and documented.Case studies

These are a list of the relevant headings from the textbook. Materials i.e. worksheets, student notes etc. will be developed in due course.

Chapter 3 – Systems Analysis and Design : Shelly, Cashman and Rosenblatt

4 Hours Student presentations:1. Students will in-groups of two present

the findings of their group assignment.3 Hours Exam:


Elements:

Element Performance Criteria CommentsICAITAD041A1. Specify context

of business need or problem

1. The business need is fully understood by project team and client

2. Methods for gathering and collecting information are ensured to be cost effective and relevant, both to the project and client environment

3. System boundaries, scope and methodologies to be used are determined

2. Specify interested parties

1. People (especially the owner, sponsor and those that will contribute to defining the requirements and using the system), and roles of client users are identified

2. The physical requirements of the system are identified taking into account current system functionality, geography, environment, client user and cost constraints

3. Plan the requirements phase

1. Most appropriate way to obtain requirements information is decided on

2. Any questionnaires or material needed for workshops and interviews are developed and trialed

3. A workable and extensible administration system to cope with incoming data is prepared

4. An extensible Data Dictionary to be used throughout the project is prepared.

5. Commitment and timing is agreed on by users and managers impacted by the plan.

4. Gather requirements

1. Questionnaires are issued and participation in workshops and interviews has occurred as per the requirements plan.

2. Collected data is evaluated and collation of the requirements is started

3. Any gaps in knowledge or other requirements issues relevant to obtaining a satisfactory resolution are followed up

4. Views and requirements of key client users are identified and documented

5. Carry out preliminary analysis of information

1. All functional areas included by the project brief are covered in the analysis and meet the client’s stated business expectations

2. All views and requirements are compared for commonalties in line with project brief

6. Resolve conflicts and develop consensus

1. Conflicting information is investigated and a single position is developed

2. The identified position is circulated for discussion with key client users according to agreed project scope

3. Consensus is gained with key client users subject to project brief and cost constraints


ICAITAD042A1. Confirm client

expectations and needs

1. Information is cross-checked and verified as relevant to project brief using appropriate techniques to confirm needs

2. Cost effective, relevant and reliable methods are used to present requirements to client users in order that they may confirm requirements

3. The identified needs are submitted to higher authority for confirmation from key decision makers in the company

2. Confirm that information is consistent and complete

1. Information is checked to cover functional, quality and added-value requirements, fits within any constraints and fully covers the project proposal/brief

2. Latent assumptions are explored and detailed according to project requirements

3. Consistency and coherence of the elicitation process is confirmed through the internal reviews/walk throughs

3. Verify that overall process is integrated, ensure remote users and any distributed requirements are covered

1. All techniques used to elicit and to validate information are verified and found to be consistent and compatible

2. Relevant details only are contained in requirements model and the elicitation process is confirmed through requirements model

3. Details of function usage by business unit including entity, volumes and function frequency are obtained

4. Matrix/relationship of business units to geographic locations is confirmed

4. Specify organisation specific issues

1. Functions where complexity, function dependency or usage require special attention are identified

2. Transition issues relating to user competence levels, organisation structure and existing systems are identified and recorded

3. Organisation specific issues are documented and reported to higher authorities and/ or technical specialists

4. The scope of the requirements are reported to higher authorities for sign off

ICAITAD043A1. Confirm that

proposed solution is the best reasonable fit

1. Analysis of client requirements has occurred and is confirmed

2. Solutions most useful to client needs are considered by each key client user

3. Proposed solution are accepted by key decision makers

4. Analysis and recommendations are reviewed with management according to company requirements

2. Develop high level alternative scenarios

1. Future business process requirements are compared and analysed with current requirements

2. Alternative work scenarios are performed for each


work to analyse the principal inputs/outputs; expected improvements/impacts; revenue/cost benefits; risks, negatives, down-sides; physical requirements of each system

3. Alternatives are fully examined against budget constraints and are dismissed after careful consideration

4. Model of preferred scenario is prepared3. Prepare and

publish feasibility report

1. Reasons for change are established and scope and function of proposed system are detailed

2. Alternative scenarios are described, assumptions are articulated and 1 (or 2) preferences are presented

3. Project constraints and impact statement eg. Personnel/budget are described

4. Cost benefit analysis is prepared in accordance with organisation standards and project requirements

5. Plan is produced that describes project schedule, timeframe and cost constraints

6. Summary is presented to higher authorities / or client for project approval

ICAIYS031B1. Analyse client

support issues 1. Logged requests are answered in accordance with

organisation guidelines2. Client support issues are investigated and

documented in accordance with organisation guidelines

3. Previous logs are checked for similar problem by same or other client

2. Provide advice on software

1. Client requirements are confirmed2. Advice is determined and provided or client is

referred for further technical assistance3. Advice is provided to client to overcome software

problem in line with organisation guidelines4. Manuals and help documentation are provided to

client5. Group or one to one instruction is provided, as

required6. Upgrade requirements or new software

requirements are documented and recommendations are referred to supervisor/management

3. Provide advice on hardware

1. Client requirements are obtained from documentation

2. Advice is provided to client to overcome hardware problem in line with organisation guidelines

3. Manuals and help documentation are provided to client

4. Group or one to one instruction are provided , as required


5. Further requirements are documented , such as new equipment requirements, and refer recommendations to supervisor/management

4. Provide advice on network

1. Client requirements are obtained from documentation

2. Advice and support is provided to client to overcome network problem in line with organisation guidelines

3. Manuals and help documentation are provided to client

4. Group or one to one instruction is provided , as required

5. Further requirements are documented and recommendations are referred to supervisor/management

5. Obtain client feedback

1. Client evaluation and feedback are obtained to ensure client requirements are met

2. Function is performed by client unassisted according to instruction


TP-SystemsDesign1

Documents

Transcript of TP-SystemsDesign1