systems development revision 2012. revision guide – lecture 17 user perspectives – their needs...

Systems Development Revision 2012

Revision Guide – Lecture 17• User perspectives – Their needs specify the inputs and outputs

• Data Protection Act • The 3 roles, Data Subject, Data Controller and Information

Commissioner • 8 principles.

• Computer Misuse Act

User perspectives• There are several kinds of user for most computer systems

• Clerical users from business area• Managers from business area• Developers • Technical support team

• Each type has a different perspective on the system• Clerical: tool to do the day-to-day job• Manager: tool to see trends and manage the business area• Developer: system to be developed and implemented• Technical support: system and users to be supported

IMAT 1906 Lecture Week 17 (c) De Montfort University 2010-113

Data Protection - eight principles• Data protection framed within 8 principles

1. Obtained and processed fairly and lawfully2. Processed for specific purposes3. Adequate, relevant and not excessive to processing purpose4. Accurate and up to date5. Not kept for longer than necessary6. Processed in accordance with data subject rights7. Secure8. Not transferred outside EEA without assurance of protection

• Look at each in turn…


Revision Guide – Lecture 19• Implementation overview

• Business procedures slides 6-16

• User training – slides 18-22 – Think about what you covered in your presentations

Installation - overview• Installing the system sounds simple• But there are several things to consider

• Live environment as opposed to test environment• Distribution of software and database• Program-code independence• Communication networks• Data migration

• Look at each briefly…


Deployment strategies - overview


• Three major options for putting the system into operation - also called deploying the system • Direct changeover• Parallel running• Pilot followed by roll-out

• Look at each briefly…

Direct changeover - what it is


• Direct changeover is also called Big Bang

• In this strategy, system is ‘turned on’ on day one• Old system is ‘turned off’ if there was one• All data has been migrated• All users start using new system at once• Usually scheduled during a business quiet time• Least expensive strategy but riskiest

• What if system fails in some way?• Support team on hand• Developers and testers usually on hand as well

Direct changeover - when to use


• When to use • No existing system to replace• All users have been trained and ready• System has been completely tested and found acceptable• All system functionality needed at same time

• Phased implementation not a viable business option

Direct changeover - example


• For example… • A small company is automating its order processing• All users in the order department have been trained• User guide and documentation are ready• System has been completely tested and is acceptable• Product data and customer data has been input• Implementation taking place over bank holiday weekend after

all existing orders filled and sent out• Old paper-based orders filed in archive boxes• From day one, new orders are entered and processed on the

new system• New reports required – to users who require them

Revision Guide – Lecture 15

•Types of Systems inc Commercial, Internet and Real time

•Components of a System – software, hardware, people, data,

Components of systems • Systems contain many things• System components

• Hardware – the machine(s) the system runs on• Software – the operating system and application systems• Data – the information used by the system• Processes – steps taken to transform input into output• People – the users supported by the system

• Components work together to carry out the required functions• No single component can work on its own


Types of system • Common types of system:

• Commercial systems• For business activities • Not just companies but other organisations as well

• Real time systems• Results acted on immediately

• Internet systems• Web-based business or communication channel


Internet systems• Tend to be commercial systems supporting organisations

• Provide communication between suppliers and customers• Three main types:

• Business to Consumer (B2C)• Business to Business (B2B)• Consumer to Consumer (C2C)

• Think of the inputs and outputs required


Commercial systems • Support business activities

• Transaction processing • Management information• Business support• Resource planning• User productivity

• Think of the inputs and outputs required


Real time systems• Not all systems support commercial business activities• Commercial systems are time-critical

– Must use up-to-date data– Must give prompt response

• Some activities are time-critical in a different way– Must use up-to-date data– Must issue prompt and correct instructions– Results acted on immediately

• Real time systems tend to control processes rather than information flow

• Examples: manufacturing control, traffic control• Think of the inputs and outputs required


Manufacturing control systems• Systems that control arrival of parts and raw materials in a just-in-

time fashion– Parts arrive just as the assembly line requires them– No need to store large quantities of parts not yet needed

• Systems that control assembly activities– Moving the products being assembled along from one part of the

assembly process to the next– Controlling the machines that do the assembly eg robots, drills

• Input data taken from monitoring state of progress• Output data is instructions to machines or other systems• Interface largely automated ie no screens or keyboards


Summary • There are many types of computer system

– Commercial – transaction processing, business support– Real time – process control– Internet – B2C, B2B, C2C

• Systems have several components– Hardware– Software– Data– Processes– People


Revision Guide – Lecture 16• Methodologies – inc traditional (SDLC, waterfall, SSADM),

Agile (extreme, pair programming, joint), Rapid (iterative, joint, incremental)

• SDLC stages– inc feasibility, implementation, design, evaluation.

• Prototype – Throwaway and Evolutionary

System development activities• Developing a system involves several kinds of activity

– Feasibility study– Requirements definition– Analysis – Logical system design– Process design, specification, development (coding)– Data model, database design, implementation– Interface design, confirm with users, screen building– Testing and deployment

• How many of these activities have you seen or done?


Methodologies - overview• Common methodologies include….

• Traditional life cycle methodologies• Rapid development methodologies• Agile methodologies• Prototyping

• Look at each in turn….


Traditional life cycle methodologies• Also known by other names

– System Development Life Cycle (SDLC)– Waterfall development – V model - links testing to development stages

• Each stage is completed and signed off before next one starts– Teams of experts only needed during ‘their’ stage – For example, programmers only needed during build phase

• Working system is final deliverable, no interim system available• Easy to plan but not very flexible


Waterfall diagram


feasibility

inception

requirements

design

build

testing

implementation

Traditional life cycle - stages• Typical pattern of activity

• Feasibility study• Project inception• Requirements analysis and definition• System design - logical design• Construction - coding, unit testing• System testing including user testing and end-to-end testing• Implementation

• Some variation but not much


Traditional life cycle - feasibility stage• As we have seen, feasibility studies the overall concept of a

proposed system• Develops an overview-level understanding of requirements• Examines proposed system in several contexts:

– Operational alongside other existing systems– Business within existing business processes– Financial in terms of costs of system balanced by benefits– Technical performance predictions and constraints

• Deliverable is feasibility report• Milestone is decision to go ahead with project


Traditional life cycle - inception stage• Means starting the development project going• Includes for example

– Identifying the project team– Identifying and estimating development activities– Making the project plan– Setting out risks and issues

• typically these are things that are not yet well-understood or decided but might have a big impact on the project

• For example new untried technology

– Setting out project budget– Agreeing how progress will be monitored

• Deliverable is set of project plans, risk and issue logs


Traditional life cycle - requirement stage

• As we have seen, requirements stage finds out the detailed requirements – Fact-finding techniques – Analysis of findings– Documented in summary level and detailed level– Test strategy and test cases also defined

• Deliverables– Requirements specification document– Test strategy and test plans

• Milestone is requirements sign-off– User management agrees that requirements are complete


Traditional life cycle - design stage• Design stage covers the logical design of the new system

• Processes• Interface - input and output• Data • Perhaps outline business procedures around the system

• Deliverable: set of logical models• Milestone: design sign-off

• User management agrees that designed system will meet their needs


Traditional life cycle - build stage• Construction stage also called build stage

– Specification of processing details– Coding of processes into programs or routines– Implementation of database – Turns interface design into screens and reports– Includes unit testing of programs, screens, reports– Includes quality reviews of programs, screens, reports

• Deliverable: components of physical system• Milestone: construction sign-off

– Project management agrees that all components are built and fit for purpose

– System testing can begin


Traditional life cycle - system test stage

• Test strategy designed at end of requirements stage– System testing ensures that components link together– End-to-end testing ensures that input is correctly transformed

into outputs and is delivered to right places– User acceptance testing ensures that realistic test cases are

correctly processed and give required results– Tests processes, interface, reports, configuration

• Deliverable: test logs at relevant levels• Milestone: testing sign-off

– System performs as expected and required– Users accept developed system


Traditional life cycle - implementation• Several activities to implement system

– Install system as appropriate– Populate relevant databases - migrate or input– User guide and other documentation– User training– Include new system functions in business procedures

• Deliverable: working system now operational• Milestone: system development completed

– System up and running– Users trained– System functions integrated into business processes


Agile methodologies• Also known by other names

• Adaptive development• Extreme programming - pair programming• Joint development - joint with users

• Principle is to be able to move very quickly and be very flexible


Agile development principles• Iterative, incremental development as with rapid methods• Constant feedback on how development progressing• Team knowledge base maintained and shared• Each phase incorporates what was learned in earlier phases• Intense teamwork involved to achieve each phase


Agile development stages• Development team includes business people and system

developers• System phases identified and prioritised by business users• Each phase is a self-contained iteration

– Delivers a set of functions– Builds on previous iterations– Designed by users and developed by developers in tandem

• Time-boxing often critical• Follows spiral model


Agile development diagram - spiral


Ref: Boehm, B (1986) A Spiral Model of Software Development and EnhancementCan also be found in Shelly & Rosenblatt p 23

Rapid development methodologies• Also known by other names

• Iterative development• Incremental development• Dynamic systems development

• Development proceeds in phases according to priorities


Rapid development principles• It is possible to streamline system development• Some things can be done in parallel• Development and implementation can be done bit by bit

• Must still maintain quality product• Must get and confirm user requirements• Must get design right• Must build and test each bit

– Often time-boxed ie limited amount of time allowed


Rapid development stages• First stage is high level requirements definition• With user agreement, divide requirements into development

phases• Business managers set priorities for delivering the phases

– Often done in workshops to allow discussion and debate– Discussion can get heated; diplomacy needed– Agreement easier if project sponsor takes part

• System development then becomes series of iterations


Rapid development - iteration tasks• Within each iteration, the usual development tasks are carried out

• Design• Build• Test• Integration testing alongside previously-delivered phases• Implement

• Next phase is next iteration


Rapid development diagram


prioritisedrequirements

detailed requirements

design

build and test

implement

each phase

Rapid development - example• When would rapid development be needed?

• When there is a strong business need to have the system up and running quickly

• For example, to support a new product being launched quickly to beat the competition• Cannot develop in time using traditional methods• Business priorities are marketing then production then sales• System functionality developed in that order

• Marketing functions developed and implemented• Production and distribution functions• Sales and order processing functions


Prototyping methodologies• Two main types

• Throw-away prototyping• Evolutionary prototyping

• Principle is to develop cut-down versions of system but working system at all stages


Throw-away prototyping• Used to aid users in understanding their requirements• Similar to a film set

– Screens may look real– Little or no processing behind screens

• Can be developed very quickly• Can be amended very quickly to allow users to work out what they

need• Useful when users unfamiliar with concept of new system


Throw-away prototyping diagram


Implement

Analysis

Design

Build

Test

Evolutionary prototyping• Used to build up system incrementally• Initial prototype eventually becomes final system• Particularly useful when using CASE tools that generate working

prototypes• As each iteration adds more functions, previous functions should be

tested again• Tests that integration has been successful at each phase

• System evolves through iterations• Changes in requirements can be accommodated• Can be combined with throw-away prototypes used for

requirements gathering


Evolutionary prototyping diagram


Implement

Analysis

Design

Build

Test

Release 1

Release 2

Release 3

When are different methods suitable?• Methods suitable under different circumstances• Traditional

• Requirements can be well-defined and stable• Rapid

• Insufficient time for traditional approach• Requirements not fully known at outset

• Agile• Business users available for development team• Partial system functionality acceptable and/or necessary

• Prototyping• When robust CASE tools available


Revision Guide – Lecture 7• Fact finding techniques inc workshops/interviews/Questions/

• Information gathering – analysing documentation

Factfinding for overall understanding• Factfinding is done at two major stages of system

development• Overall understanding, for feasibility study• Detailed understanding, for requirements specification

• For overall understanding, need to talk to people• Main techniques are

• Interviews• Workshops


49

Factfinding for detailed understanding• Useful techniques

• Interviews • Workshops• Questionnaires• Document analysis• Observation

• Plus – analysing the results; question format has a bearing on analysing the results


50

Factfinding for detailed understanding• Useful techniques

• Interviews • Workshops• Questionnaires• Document analysis• Observation

• Plus – analysing the results; question format has a bearing on analysing the results


51

Interviews• We have seen something of interviews in tutorials• Interview is a directed conversation• Basic structure of interview for detailed understanding is similar to

interview for overall• Questions now focus on detail

• What is done - what tasks do you do every day?• How it is done - how do you process a new order?• When it is done - do orders come in at a specific time?• Peaks - is the work steady or are there busy times?• Interviews can be longer as there is more detail to explore


Workshops• Workshop is a directed group conversation• Basic structure of workshop for detailed understanding is similar to

workshop for overall• Tends to look at flow of information and work across several teams

or areas in a department, or several departments• Questions now focus on detail

• What is done - what tasks are carried out in the area?• How it is done - how is a new order processed and filled?• Who is involved - how many teams deal with each order?• Peaks - when is the busiest time? how many orders then?


Questionnaires• Series of questions people fill in on their own• Structured questions:

• Unambiguous so person can tell what you’re asking• Responses structured in some way

• Yes/no• Range eg 1-5 or Often to Seldom• Options eg <5 / 5-10 / 11-15 / >15• Some free text responses but not too many

• Questions about one topic can be grouped together• Relevant to what the respondents do in their work

• Clear instructions with return date

• Analyse by counting responses in each category


Document analysis• Examine samples of documents and records currently being used• Analyse what’s on the document:

• Identify things being recorded eg books• Identify data items recorded eg titles and authors• These become input fields and data requirements

• Find out who starts the document and where it is sent next• Find out how each area deals with the document• Find out how many are dealt with in a day for example


Observation • We may be able to sit alongside a user and watch how they do their

work or carry out a function• Make notes

• what they do, either what tasks or what steps in a task• how they do it• what they use in order to do the tasks• how often in a time period• how long it takes• who else they need to involve

• Need to be careful not to get in the way• Needs permission


Revision Guide – Lecture 26&27

• Logical layout - How to specify processes:- use case diagram and description- Data flow diagram, context, level 1 & 2- Structured English- Decision Tables

• Decision Tables

• Physical layout• - Storyboard• -Screen layout• - Reports

Today’s Agenda


• Weeks 1-5 : evaluation• Weeks 6-9: logical system design • Weeks 10-11: physical system design

Today’s Agenda


• Weeks 15-17 : system concepts• Weeks 19-22: system implementation• Exam technique

Decision tables


• Used to describe how to make complex decisions• Clear and unambiguous • Components

• Conditions – usually as questions with yes/no answers• Rules – combinations of answers to questions• Actions – what will happen in each case• Decisions – which actions apply to which rules ie in which

circumstances

Decision tables - example


• To calculate ticket fares• Conditions:

• Concession (child, senior), return ticket

• Actions:• No discount, 10% discount, 50% discount

Concession Y N Y N

Return N Y Y N

No discount X

10% discount X

50% discount X X

Storyboard


• Technique to clarify requirements for the interface• Low-tech mock-up of the interface and the user’s conversation with

the system• Paper and pencil or flip chart pens• Analyst or analyst and user together

• Common uses• Clarify flow of work or information from beginning to end including

things outside the computer system• Clarify content and format of screens• Clarify sequence of screens and navigation

Screen design


• Interface combines input and output• Basic design rules

• Consider the user• Choose appropriate data entry method• Minimise effort required

• HCI concepts – human-computer interface• Appearance - uncluttered• Layout – consistent• Controls – text boxes, buttons etc• Flow through fields on screen• Conversation flow from screen to screen

Report design


• Detail report• Header• Body• Trailer

• Other types • Exception report• Summary report• On demand report• Internal report• Archival report

systems development revision 2012. revision guide – lecture 17 user perspectives – their needs...

Documents