Beruflich Dokumente
Kultur Dokumente
Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using UML 4th Edition, McGraw Hill, 2010
2010 Bennett, McRobb and Farmer 1
What is a Model
Like a map, a model represents something else A useful model has the right level of detail and represents only what is important for the task in hand Many things can be modelled: bridges, traffic flow, buildings, economic policy
2010 Bennett, McRobb and Farmer 3
Modelling Organizations
Organizations are human activity systems. The situation is complex Stakeholders have different views We have to model requirements accurately, completely and unambiguously The model must not prejudge the solution
2010 Bennett, McRobb and Farmer 7
What is a Diagram?
Abstract shapes are used to represent things or actions from the real world Diagrams follow rules or standards The standards make sure that different people will interpret the diagram in the same way
40
Author
Reviewer
Typesetter
Printer
An Example of a Diagram
An activity diagram of the tasks involved in producing a book.
Write Chapter
Review Chapter
Correct Proofs
Reset Book
Print Book
Author
Reviewer
Typesetter
Printer
Hiding Detail
Write Chapter Plan Chapter Write Chapter Produce First Draft Review Chapter
Revise Draft Revise Chapter [book not [not satisfied] complete] [satisfied] [book complete] Add Exercises Typeset Book Add References to Bibliography Correct Proofs
Reset Book
Print Book
10
Diagrams in UML
UML diagrams consist of:
icons two-dimensional symbols paths Strings
Plan Chapter
11
12
Examples of Models
Requirements Model
complete view of requirements may include other models, such as a Use Case Model includes textual description as well as sets of diagrams
13
Examples of Models
Behavioural Model
shows how the system responds to events in the outside world and the passage of time an initial model may just use Communication Diagrams a later model will include Sequence Diagrams and State Machines
14
Models in UML
A system is the overall thing that is being modelled A subsystem is a part of a system consisting of related elements A model is an abstraction of a system or subsystem from a particular perspective A model is complete and consistent at the chosen level of abstraction
2010 Bennett, McRobb and Farmer 18
Models in UML
Different models present different views of the system, for example:
use case view design view process view implementation view deployment view (Booch et al., 1999)
19
Developing Models
During the life of a project using an iterative life cycle, models change along the dimensions of:
abstractionthey become more concrete formalitythey become more formally specified level of detailadditional detail is added as understanding improves
20
Iteration 1 Obvious use cases. Simple use case descriptions. Iteration 2 Additional use cases. Simple use case descriptions. Prototypes. Iteration 3 Structured use cases. Structured use case descriptions. Prototypes.
Add a new staff grade Change the rate for a staff grade
Acc ountant
Acc ountant Change the grade for a staff member Calc ulate staff bonuses
Staff Management
Add a new staff member Staff Management Add a new staff grade Add a new staff member Add a new staff grade Change the rate for a staff grade Add a new staff grade Acc ountant
Acc ountant
Change the grade for a staff member Calc ulate staff bonuses
Acc ountant Change the grade for a staff member Calc ulate staff bonuses
Holborn Motors Lynch Properties Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Yellow Partridge Zeta Systems
OK OK OK Quit Quit
Quit
include Add a new adv include ert to a cam paign Campaign M anagement
Campaign Manager
include
Campaign Manager
include Add a new adv ert to a cam paign extend Check campaign inc lude budget P rint campaign summ ary extend Check campaign budget Accountant P rint campaign summ ary extend extend Print cam paign invoice extend Print cam paign invoice extend
Campaign Selection Campaign Selection Client: Campaign Selection Client: Client: Campaign: Campaign: Campaign: OK OK OK Quit Quit Quit Holborn Motors Lynch Properties Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Holborn Motors Yellow Partridge Lynch Properties Zeta Systems Yellow Partridge Zeta Systems
Campaign Manager
Accountant
21
Summary
In this lecture you have learned about: What is meant by a model The distinction between a model and a diagram The UML concept of a model
22
References
Booch, Rumbaugh and Jacobson (1999) Bennett, Skelton and Lunn (2005)
(For full bibliographic details, see Bennett, McRobb and Farmer)
23
Development Process
Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using UML 4th Edition, McGraw Hill, 2010
2010 Bennett, McRobb and Farmer 24
25
Four Phases
Inception Elaboration Construction Transition
27
28
Project Phases
Inception
Elaboration
Transition
1
Requirements
Analysis
Design
Implementation
Test
Workflows
Size of square relative to time spent on workflows 2010 Bennett, McRobb and Farmer
time
29
Techniques
Requirements Elicitation Use Case Modelling Architectural Modelling Prototyping
Key Deliverables
Use Case Model Requirements List Initial Architecture Prototypes Glossary
30
Techniques
Communication Diagrams Class and Object Modelling Analysis Modelling
Key Deliverables
Analysis Models
31
Techniques
Deployment Modelling Component Modelling Package Modelling Architectural Modelling Design Patterns
Key Deliverables
Overview Design and Implementation Architecture
32
33
Techniques
Class and Object Modelling Interaction Modelling State Modelling Package Modelling Prototyping Design Patterns
Key Deliverables
Design Models with Interface Specification
34
Techniques
Key Deliverables
Class and Object Design Models Modelling with Database Specification Interaction Modelling State Modelling Package Modelling Design Patterns
35
Techniques
Programming Component Reuse Database DDL Programming Idioms Manual Writing
Key Deliverables
Constructed System Documentation
36
Techniques
Key Deliverables
Programming Test Plans Test Planning and Test Cases Design Tested System Testing
37
Techniques
Key Deliverables
38
Summary
In this lecture you have learned about: The Unified Software Development Process How phases relate to workflows in an iterative life cycle An approach to system development Major activities in the development process
2010 Bennett, McRobb and Farmer 39
References
Jacobson, Booch and Rumbaugh (1999) Kruchten (2004) Chapter 21 of Bennett, McRobb and Farmer includes more about the Unified Process as well as Agile alternatives
(For full bibliographic details, see Bennett, McRobb and Farmer)
40
Requirements Capture
Based on Chapter 6 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using UML 4th Edition, McGraw Hill, 2010
2010 Bennett, McRobb and Farmer 41
42
User Requirements
Need to understand how the organization operates at present What are the problems with the current system? What are the requirements users have of a new system that are not in the current system?
2010 Bennett, McRobb and Farmer 43
Current System
Much of the current system meets the needs of people who use it Sections of the system no longer meet the needs of the organization Some aspects of the organizations work are not covered by the current system The system can no longer evolve but needs to be replaced
2010 Bennett, McRobb and Farmer 44
Current Systemcont.
It is important to understand the current system to carry functionality forward into the new system It is also important to understand it so that shortcomings and defects can be corrected in the new system
45
Current System.cont.
Advocates of Agile methods focus on developing the new system and not on extensive analysis of the existing system In the Agile Manifesto they state that they value working software over comprehensive documentation
46
New Requirements
Organizations operate in a rapidly changing business environment Organizations operate in a changing technical environment Governments and supra-governmental organizations introduce legislation Organizations merge, de-merge, take-over and get taken-over All this drives the need to replace systems and build new ones
2010 Bennett, McRobb and Farmer 48
Types of Requirements
Functional Non-functional Usability
49
Functional Requirements
Describe what a system must do Include:
processes interfaces with users and other systems what the system must hold data about
Modelled with Use Case Diagrams. Later will be modelled with other kinds of diagrams that show the structure of the system (Class Diagrams) and its behaviour (Interaction Diagrams and State Machines)
2010 Bennett, McRobb and Farmer 50
Non-functional Requirements
Concerned with how well the system performs Include:
response times volumes of data security considerations
Documented in Requirements List or in Use Case Model (for requirements that can be linked to specific use cases)
51
Usability Requirements
Concerned with matching the system to the way that people work Sets measurable objectives Include:
characteristics of users tasks users undertake situational factors acceptance criteria for the working system
Background Reading
Aim is to understand the organization and its business objectives Includes:
reports organization charts policy manuals job descriptions documentation of existing systems
54
Background Reading
Advantages:
helps to understand the organization before meeting the people who work there helps to prepare for other types of fact finding documentation of existing system may help to identify requirements for functionality of new system
55
Background Reading
Disadvantages:
written documents may be out of date or not match the way the organization really operates
Appropriate situations:
analyst is not familiar with organization initial stages of fact finding
2010 Bennett, McRobb and Farmer 56
Interviewing
Aim is to get an in-depth understanding of the organizations objectives, users requirements and peoples roles Includes:
managers to understand objectives staff to understand roles and information needs customers and the public as potential users
57
Interviewing
Advantages:
personal contact allows the interviewer to respond adaptively to what is said it is possible to probe in greater depth if the interviewee has little or nothing to say, the interview can be terminated
58
Interviewing
Disadvantages:
can be time-consuming and costly notes must be written up or tapes transcribed after the interview can be subject to bias if interviewees provide conflicting information this can be difficult to resolve later
2010 Bennett, McRobb and Farmer 59
Interviewing
Appropriate situations:
most projects at the stage in fact finding when in-depth information is required
60
Observation
Aim is to see what really happens, not what people say happens Includes:
seeing how people carry out processes seeing what happens to documents obtaining quantitative data as baseline for improvements provided by new system following a process through end-to-end
Observation
Advantages:
first-hand experience of how the system operates high level of validity of the data can be achieved verifies information from other sources allows the collection of baseline data
2010 Bennett, McRobb and Farmer 62
Observation
Disadvantages:
people dont like being observed and may behave differently, distorting the findings requires training and skill logistical problems for the analyst with staff who work shifts or travel long distances ethical problems with personal data
2010 Bennett, McRobb and Farmer 63
Observation
Appropriate situations:
when quantitative data is required to verify information from other sources when conflicting information from other sources needs to be resolved when a process needs to be understood from start to finish
2010 Bennett, McRobb and Farmer 64
Document Sampling
Aims to find out the information requirements that people have in the current system Also aims to provide statistical data about volumes of transactions and patterns of activity Includes:
obtaining copies of empty and completed documents counting numbers of forms filled in and lines on the forms screenshots of existing computer systems
2010 Bennett, McRobb and Farmer 65
Document Sampling
Advantages:
good for gathering quantitative data good for finding out about error rates
Disadvantages:
not helpful if the system is going to change dramatically
Appropriate situations:
always used to understand information needs where large volumes of data are processed where error rates are high
66
Questionnaires
Aims to obtain the views of a large number of people in a way that can be analysed statistically Includes:
postal, web-based and email questionnaires open-ended and closed questions gathering opinion as well as facts
67
68
Questionnaires
Advantages:
economical way of gathering information from a large number of people effective way of gathering information from people who are geographically dispersed a well designed questionnaire can be analysed by computer
69
Questionnaires
Disadvantages:
good questionnaires are difficult to design no automatic way of following up or probing more deeply postal questionnaires suffer from low response rates
70
Questionnaires
Appropriate situations:
when views of large numbers of people need to be obtained when staff of organization are geographically dispersed for systems that will be used by the general public and a profile of the users is required
User Involvement
A variety of stakeholders:
senior managementwith overall responsibility for the organization financial managerswho control budgets managers of user departments representatives of users of the system
2010 Bennett, McRobb and Farmer 72
User Involvement
Different roles:
as subjects of interviews as representatives on project committees as evaluators of prototypes as testers as trainees on courses as end-users of new system
73
Documenting Requirements
Documentation should follow organizational standards Modelling tools that produce UML models maintain associated data in a repository Some documents will need separate storage in a filing system:
interview notes copies of existing documents minutes of meetings details of requirements
74
Documenting Requirements
Documents should be kept in a document management system with version control Use use-cases to document functional requirements Maintain a separate requirements list Review requirements to exclude those that are not part of the current project
2010 Bennett, McRobb and Farmer 75
Requirements Analyst Project Initiation Document Elicit requirements Glossary Candidate Requirements Select requirements
Requirements List
76
Requirements Team
Interface Prototypes
Glossary
77
Summary
In this lecture you have learned about: The distinction between the current and required systems When and how to apply the main fact finding techniques The roles played by users The need to document requirements
78
References
Oppenheim (2000) Allison et al. (1996) Usability is covered in more detail in Chapter 16 of Bennett, McRobb and Farmer Chapter A2 shows products of requirements capture and modelling
(For full bibliographic details, see Bennett, McRobb and Farmer)
79