itec 2010a systems analysis and design i the analyst as project

1

ITEC 2010A

Lecture 3

2

Participants in a System Development Project

3

The Project Team

• Like a “surgical team” – each member of the team performs a specialized task critical to the whole

• Project team varies over duration of the project (as does project leadership)– During planning team consists of only a few members

(e.g. project manager and a couple of analysts)– During analysis phase the team adds systems analysts,

business analysts– During design other experts may come in with

technical expertise (e.g. database or network design)– During implementation, programmers and quality

control people are added

4

5

Project Management

• Project Manager – has primary responsibility for the functioning of the team

• Project Management – organizing and directing of other people to achieve a planned result within a predetermined schedule and budget

• Good manager:– Knows how to plan, execute the plan, anticipate

problems and adjust for variances• Client – person or group who funds the project• Oversight committee – reviews and direct the

project• User – the person or group who will use the

system

6

Tasks of a Project Manager

• Planning and Organization– Identify scope of the project– Develop a plan, with detailed task list and schedule

• Directing– Responsible for directing the execution of the project– Responsible for monitoring the project - make sure that

milestones (key events in a project) are met– Overall control of the project

• Plan and organize project• Define milestones and deliverables• Monitor progress• Allocate resources and determine roles• Define methodologies• Anticipate problems and manage staff

7

Project Initiation

• Projects may be initiated as part of the long-term strategic plan (top-down)– based on mission or objective statement come up with

some competitive business strategy- usually involves IT– E.G. Rocky Mountain Outfitters example – to be more

competitive wants to improve customer support – so moves towards Internet based re-development of systems

• Projects may proceed bottom up– To fill some immediate need that comes up

• Projects may also be initiated due to some outside force– E.g. change in tax structure may affect billing system

8

9

The Project Planning Phase

1. Defining the Problem• Review the business needs and benefits (a brief

paragraph)• Identify the expected capabilities of the new system

(define the scope of the project)• May involve developing a context diagram to explain

the scope of the project

10

11

12

Developing a Project Schedule1. Identify individual tasks for each activity

• Top-down or bottom-up approach

2. Estimate the size of each task (time and resources) – optimistic, pessimistic and expected times

3. Determine the sequence for the tasks4. Schedule the tasks• Charting methods (Appendix C)

– PERT/CPM (Project Evaluation and Review Technique/Critical Path Method) chart shows the relationships based on tasks or activities

• Defines tasks that can be done concurrently or not and critical path

– Gantt chart shows calendar information for each task as a bar chart

• Shows schedules well but not dependencies as well

13

14

15

PERT Chart

• Tasks represented by rectangles• Tasks on parallel paths can be done concurrently• Critical path – longest path of dependent tasks

– No allowable slack time on this path– Other paths can have slack time (time that can slip

without affecting the schedule)

16

Gantt Chart

• Tasks represented by vertical bars• Vertical tick marks are calendar days and weeks• Shows calendar information in a way that is easy• Bars may be colored or darkened to show

completed tasks• Vertical line indicates today’s date

17

18

Further Preparations

• Staffing the Project– Develop a resource plan– Identify and request technical staff– Identify and request specific user staff– Organize the project team into work groups– Conduct preliminary training and team-building

19

2. Confirming Project Feasibility– Economic feasibility – cost-benefit analysis– Organizational and cultural feasibility

• E.g. low level of computer literacy, fear of employment loss– Technological feasibility

• Proposed technological requirements and available expertise– Schedule feasibility

• How well can do in fixed time or deadline (e.g. Y2K projects)– Resource feasibility

• Availability of team, computer resources, support staff

• Economic Feasibility– The analysis to compare costs and benefits to see whether

the investment in the development of the system will be more beneficial than than costly

20

• Costs

– Development costs : salaries and wages, equipment and installation, software and licenses, consulting fees and payments to third parties, training, facilities, utilities and tools, support staff, travel and miscellaneous

– Sources of Ongoing Costs of Operations: connectivity, equipment maintenance, computer operations, programming support, amortization of equipment, training and ongoing assistance (help desk), supplies

21

• Benefits– Tangible benefits - examples

• Reducing staff (due to automation)• Maintaining constant staff• Decreasing operating expenses• Reducing error rates (due to automation)• Ensuring quicker processing and turnabout• Capturing lost discounts• Reducing bad accounts or bad credit losses• Reducing inventory or merchandise loss• Collecting accounts receivable more quickly• Capturing income lost due to “stock outs”• Reducing the cost of goods with volume discounts• Reducing paperwork costs

22

• Benefits– Intangible benefits – examples

• Increased customer satisfaction• Survival• Safety of a Patient • The need to develop in-house expertise

Note - also can have intangible costs for a project• reduced employee moral• lost productivity• lost customer or sales

23

Conducting the feasibility study

• Each category of cost is estimated• Salaries and wages are calculated based on

staffing requirements• Other costs such as equipment, software licenses,

training are also estimated• A summary of development costs and annual

operating costs is created• A summary of benefits is created• Net present value (NPV) – present value of

benefits and costs, is calculated for e.g. 5 year period

• Decision is made to proceed with project or not

24

25

Job Time Salary Total

Project Manager

12 months

90,000 90,000

System Analyst (3)

9 months 75,000 168,750

Programmers (6)

7 months 50,000 175,000

Network Designer

5 months 70,000 29,166

462,916

26

27

28

29

Some Terminology (see text – Appendix B)Net present value: The present value of dollar benefits and

costs for an investment such as a new system– since $100 received one year in the future is worth only $94.34,

using a discount rate of .06, the discount rate is used the calculation of Net present value (which equates future values to current values)

Payback period, or breakeven point: The time period at which the dollar benefits offset the dollar costs

Return on Investment (ROI): a measure of the percentage gain received from an investment such as a new system

ROI=(estimated time period Benefits – estimated time period costs) / estimated time period costsTangible benefits: Benefits that can be measured or

estimated in terms of dollars and that accrueIntangible benefits: Benefits that accrue but that cannot be

measured quantitatively or estimated accurately

30

Chapter 3 – Approaches to System Development

• System Development Methodology– Comprehensive guidelines to follow for completing

every activity in the system development life cycle, including specific models, tools and techniques

– May contain instructions about how to use models, tools and techniques

– We will examine a number of different methodologies for system development

31

• Models– Model: A representation of some important aspect of the real

world– Models used in system development include representations of

inputs, outputs, processes, data, objects, object interactions, locations, networks, and devices etc.

– Most models are graphical – diagrams and charts– Models of system components

• Flow chart• Data flow diagram (DFD)• Entity-relationship diagram (ERD)• Structure chart• Use case diagram• Class diagram• Sequence diagram

– Models to manage the development process• PERT chart• Gantt chart• Organizational hierarchy chart

32

• Tools– Tool: Supportive software that helps create models or

other components required in the project– Examples of tools

• Project management application• Drawing/graphics application• Word processor/text editor• Computer-aided system engineering (CASE) tools• Integrated development environment (IDE)• Database management application• Reverse-engineering tool• Code generator tool

33

• Techniques– Technique: a collection of guidelines that help the

analyst complete a system development activity or task– Examples of techniques

• Strategic planning techniques• Project management techniques• User interviewing techniques• Data-modeling techniques• Relational database design techniques• Structured analysis technique• Structured programming technique• Software-testing techniques (e.g. usability testing)• Object-oriented analysis and design techniques

34

35

Two Approaches to System Development

• the basis of virtually all methodologies• Approaches

– The structured approach• System development using structured programming,

structured analysis, and structured design techniques– Object-oriented approach

• An approach to systems development that views an information system as a collection of interacting objects that work together to accomplish tasks

36

The Structured Approach

• The structured approach is made up of:1. Structured programming2. Structured design3. Structured analysis

• Also known as SADT (Structured Analysis and Design Techniques)

• Before late 90’s you’d probably learn “structured programming” in your first programming course

• “structured analysis” evolved in the 1980’s (for stage prior to programming)

37

Structured Programming

• Structured program– A program or program module that has one beginning and

one ending, and each step in the program execution consists of one of the following

• Sequence (of program statements)• Decision (where one set of statements or another executes)• Repetition (of a set of statements)

– Related to concept of top-down programming• Division of complex problems into a hierarchy of smaller, (more

manageable) program modules• Top program “calls” lower-level modules• Lower level modules deal with lower-level detail• Makes programs much easier to write and understand• Module: collection of instructions to accomplish some logical

function or task (“modular programming”) – e.g. Procedures/functions in a programming language

38

39

40

Structured Design• Structured design

– A technique providing guidelines for deciding what the set of programs should be, what each program should accomplish, and how the programs should be organized into a hierarchy

– Related to (similar principles) as structured programming, but here looking at a larger level of how program modules themselves are organized

– Top-down approach again• start with highest level functions – top-level and break down

into lower level program modules (lower level details goes below)

– Use of a structure chart helps• A graphical model showing the hierarchy of program modules

produced in a structured design

41

42

Notes on structured design

• By breaking a complex problem down into sub-problems one can program very complex systems (e.g. space shuttle launch)– Can hand off modules to other teams (at other locations)– Specify what want to go as input to the module and what

want the module to return– The other team takes care of the details of their module(s)

43

Structured Analysis

• Structured analysis – a techniques to help define– What the system needs to do (processing requirements)– What data the system needs to store and use (data

requirements)– What inputs and outputs are needed– How the functions work together to accomplish tasks

• Key graphical model used – data flow diagram (DFD)– Shows inputs, processes, storage and outputs and how

they function together– Based on activities (processes) and data that flow in

and out of them

44

BOOK DATA

HANDLE ORDER

CUSTOMER DATACUST.

Square

Example of a data flow diagram

Source or destination of data

Arrow Flow of data

RoundedRectangle

Process whichTransforms flowsof data

Open-ended rectangleStore of data

Orders

Invoices(with books)

Creditstatus

DFD symbols

45

46

• Another key graphical model – the Entity-relationship diagram (ER diagram)– Focuses on identifying types of “things” (entities)

which the system needs to store information about (e.g. customers, items and details)

– Specifies relationships between these things or entities– Used a lot for design of databases – you “carve up”

your business application into entities you will store data about

47

48

Weaknesses of the Structured Approach

• Techniques address some but not all of the activities of analysis and design

• Critics want a more comprehensive set of techniques

• Many thought data modelling using structure chart and ER diagram were more important than modelling processes (using dataflow diagrams)

• However, the structured approach overall still made processes rather than data the central focus

• Many felt a strategic planning technique needed to be included as well

49

50

The Object-Oriented Approach

• Structured approach referred to in text as “traditional approaches”

• Newer approach is object-oriented– Really has swept through computer industry– Application in many areas

• Object-oriented programming (OOP)• Object-oriented database management system (OODBMS)• Object-oriented analysis (OOA)• Object-oriented design (OOD)

51

Object-Oriented Approach

• Based on notion of “objects” – things in the computer system (and the world) which have behaviours and respond to “messages”

• Objects can be anything– A menu bar, or window on the screen– A car– A house– A number etc.!

• Can send a message to an object– E.g. to a window to draw itself on the computer screen– E.g. to a number to square itself!

• Can model very complex systems (e.g. a reactor)

52

53

History of Object Orientation

• Object-oriented approach began with development of Simula in the 1960’s

• In 1970, Smalltalk was developed – Allowed for development of graphical user interfaces

(with menu, button, window etc. objects)• More recently led to other object-oriented

programming languages– C++, Java

• Also to Object-oriented databases and “intelligent” databases

54

Object Oriented Terms• Class Diagram

– A graphical model that shows all the classes of objects in the system– For every class (grouping of related objects) there may be

specialized subclasses– Sublcasses “inherit” properties of classes above them – Allows for reusability

Class Car

Subclass Ford

Subclass GM

Mustang

CLASS

SUBCLASS

INSTANCE

ISA

55

56

System Development Life Cycle (SDLC) Variations

• Traditional approach: “Waterfall method” – only when one phase is finished does the project team drop down (fall) to the next phase– Fairly rigid approach – decisions at each phase get frozen– Can’t easily go back to previous phases (each phase

would get “signed off”)– Good for traditional type of projects, e.g. payroll system

or system with clearly definable requirements– Not as good for many of the new types of interactive and

highly complex applications• applications where it is hard to specify all requirements once and

for all

57

58

59

Differences in Approaches

• Traditional approach include feasibility study at beginning, with system investigation and systems analysis as the Analysis phase

• The objectory model includes only four phases

• Despite differences, the same overall tasks need to be carried out – e.g. planning, analysis, design and implementation

60

SDLC Variations

• The pure waterfall approach is less used now• The activities are still planning, analysis, design

and implementation• However, many activities are done now in an

overlapping or concurrent manner• Done for efficiency – when activities are not

dependent on the outcome of others they can also be carried out

61

Iteration

• Iteration assumes no one gets the right results the first time• Do some analysis, then some design, then do some further analysis,

until you get it right• Idea: not always realistic to complete analysis before starting design• Waterfall no longer applies - Phases become blurred• Decisions are not frozen at the end of each phase• Good for projects where requirement specifications are hard to

arrive at• However, can lead to ambiguity

– Harder to know how far you are along in the project– Could be hard to manage

62

Rational Unified Process

63

The “Classic” Waterfall Life Cycle

Analysis

Design

Implementation

Project planning

64

65

Prototyping tool requirements

• Flexibility and power needed for fast development• WYSIWYG (what you see is what you get)

development of interface components• Generation of complete programs, program

skeletons etc.• Rapid customization of software libraries or

components• Sophisticated error-checking and debugging

capabilities

• In example on next slide you can easily “draw” the interface, by selecting buttons, menus etc. and dragging onto the screen (e.g. Visual Basic)

66

67

Spiral life cycle

• Project starts out small, handling few risks• Project expands in next iteration to address more

risks• Eventually the system is completed (all risks

addressed)• At the middle (start of the project) there is low

risk and project is still small easy to manage• You work out from the middle, expanding out

your project

68

69

Variations based on an emphasis on people• Sociotechnical systems

– Systems that include both social and technical subsystems– Both social and technical subsystems must be considered– User-centered design/Participatory design– Example in text: Multiview

• Main idea: Human activity must be studied in detail (as well as technical aspects) – often forgotten!!– Example – study of activity in intensive care unit as basis

for system design (versus “expert system” approach)

70

71

Variations based on speed of development

• RAD – Rapid Application Development• Try to speed up activities in each phase

– E.g. scheduling intensive meetings of key participants to get decisions fast

– Iterative development– Building working prototypes fast to get feedback (can

then be directly expanded to finished system)– If not managed right can be risky

72

Computer-Aided System Engineering (CASE)

• CASE tools: Software tools designed to help system analyst complete development tasks

• The CASE tool contains a database of information called a repository– Information about models– Descriptions– Data definitions– References that link models together

• Case tools can check the models to make sure they are complete and follow diagramming rules

• Also can check if the models are consistent • Adds a number of capabilities around the

repository

73

74

Types of CASE tools• Upper CASE tools

– Support analyst during the analysis and design phases• Lower CASE tools

– Support for implementation – eg. generating programs• Tools may be general, or designed for specific

methodology (like for information engineering – TIs’ IEF, CoolTools)

• Examples of CASE tools– Visual Analyst for creating traditional models

• Called “integrated application development tool”– Rational Rose for object-oriented modelling

• Based on UML standard for object orientation• Allows for reverse-engineering and code generation (can

integrate with other tools like Visual C++ etc.)

• “Round trip engineering” – synchronized updating

75

76

77

Background: The case for CASE

• Why need CASE?– As software systems get large and more complex they

have become prone to unpredictable behaviour and bugs– Problem of systems that are not reliable, do not meet

requirements or that just plain don’t work!– CASE tries to eliminate or reduce design and development

problems– Ultimate goal of CASE is to separate the application

program’s design (and analysis) from the program’s code implementation

• Generally, the more detached the design process is from actual coding, the better

• Traditional software development emphasized programming and debugging, CASE focuses on good analysis and design

78

Causes of failure (and symptoms) in software development

• Requirements Analysis– No written requirements– Incompletely specified requirements– No user interface mock-up– No end –user involvement (can happen – may have

talked to clients BUT not users!)

• Design– Lack of, or insufficient, design documents– Poorly specified data structures and file formats– Infrequent or no design reviews

79

• Implementation– Lack of, or insufficient coding standards– Infrequent or no code reviews– Poor in-line code documentation

• Unit test and Integration– Insufficient module testing– Lack of proper or complete testing– Lack of an independent quality assurance group

80

• Beta Test Release– Complete lack of a beta test– Insufficient duration for beta test– Insufficient number of beta testers– Wrong beta testers selected

• Maintenance– Too many bug reports– Fixing one bug introduces new bugs

81

Stats on Software Errors (large systems)

• Most software errors originate in the Analysis and Design phases (65%)

• Unfortunately, less than one-third of these errors are caught before acceptance testing begins

• About 35% of errors occur during coding• Cost of fixing an error goes up the later it is

caught!• This is basis for emphasis in CASE on Analysis

and Design

82

Cost to Repair

Analysis Design Code Unit Test Integration Test

Maintenance

Stage when the Error is found

200 x

83

What CASE can do to help

• Help to make analysis and design process more rigorous and complete, to reduce bugs later

• Examples of functions in tools:• Provide support for diagramming (for analysis and design)• Provide support for checking consistency of design• Provide graphing support to help users visualize an existing or

proposed information system (eg. Data flow diagrams)• Detail the processes of your system in a hierarchical structure• Produce executable applications based on your data flow

diagrams (which can be made from point and click placements of icons)

• Integrate specific methodologies into windowing environments

84

Assemblers

Compilers

Debuggers

CASE-Analysis +Design

CASE-Code generators

Evolution of Software Tools

sophistication

85

Current Status of CASE

• A number of commercial products• Some aspects (e.g. diagramming support)

are widely applicable and useful• Other features such as code generation are

more specific– CASE tools not so successful for generic code

generation– However, specific code generation is now being

used for things such as user interface design