Assigned Reading and writing
if you don't have a question about the assigned reading are you penalized?
Yes -- you only get 1 point for a sheet of paper with no question.
But I give credit for good creative problem solving.
Use CAse Diagrams
Is that necessary to create use case diagrams?why we have to create it? Is this diagram for our custom or just for reference stuff? And How do I organize effective information include use cases, scenarios, sequences, fully dressed use cases and put them together?
THey make a good poster in a room where a team works. They can be used to
rapidly sketch out the scope of a piece of software. They make an excellent
presentation Audio-visual aid (power point slide) for user, managers,
and other stakeholders.
Organization: put them on a web site.
UML Stereotypes
When applying UML Use-Case Diagrams, what are UML stereotypes?
A stereotype restricts the meaning of an icon in the UML. In the
UML a rectangular box represents a "classifier" -- something that describes a
class of objects. The stereotype "<<actor>>" means that the box describes
an active object that is outside the system under design.
page 81 -- Black box use cases
Are black box use cases the most recommended only because of their simplicity?
No. They are recommended because users don't want to know about the internal
details of a piece of software. They want to use it. So a use case
documents how to use the software and not how the software achieves that
effect.
Quality Attributes
can you explain more on quality attributes?
I call them "Qualities" or even "Ilities". They are properties of the
software. For example: how fast it runs, How much disk space it uses,
How often it breaks down, how difficult is it to change it, how much
do people value it, how secure is it, ....
Qualities are nearly always measurements rather than Yes/No properties.
They are also holistic -- you can not confine "security" to a special
object. It comes from the careful design of all the objects
in the system.
Chapter 6 page 93 -- Requirements in Context
I am glad that sometimes use cases do not REALLY fit. Nonetheless, as
important as training is required in an organization and as a part of any
system design and implementation, is training per se considered just a
feature? And, if it not, can it be included in the AD phases?
I don't think that training is thought of as part of the analysis
and design -- it is not covered in the UP. However it part
of the deployment discipline in the RUP
[ File:RUP_disciplines_greyscale_20060121.svg ]
and tends to start
up at the end of elaboration and continue through construction
and die down during transition.
Training can only take place when you have got a stable and fairly
complete piece of software running hence the delay until elaboration is
pretty complete. Prior to that you should be showing the software to
your users, but not as training, but in requirements workshops to determine
how the software should look, fell, and work.
Chapter 6 page 97 Figure 6.7 Requirements Workshop
I don't understand what the figure is trying to show me versus the text on pg 95.
![[Process and Room Figure 6.7 page 97]](./processroom.wmf)
It is a diagram of a room where a requirements workshop is held. It shows
the people who should attend. It shows the ideal equipment you should
have. And on the calendars it shows you when such a workshop
should take place: in inception, and several times in elaboration.
Supplementary specifications
Does the supplementary specifications have to be visible to the end user since it has licensing information?
All requirements documents must be shared with stakeholders -- including
end users ... exception mass marketted software, where it is hard to
get end users for a new product before releasing it.
Chapter 7 pages 104-105 Supplementary Specifications
Under supplementary specification, I noticed the author goes into very specific details in documenting project requirements. However, a contingency plans is never mentioned in the inception phase. Should a contingency plan or disaster recovery be discussed during this phase? Or, will it be best to wait until the construction phase?
Contingency planning should start before software analysis and design
and should be a part of developing software at all phases.
Disater recovery planning is part of Systems Analysis and Design
(CS372).
To a
large extent, most contingencies should be discovered about during
inception and classified as "out of scope", "Alternative scenarios",
"use case extension", "special use case", etc.
For example most real projects will need a "Back up" use case
and a "Recover" use case, both with some thing like "Administrator"
as the primary actor. Oddly, designing for these use cases is
very similar to designing any other data intensive use case.
Chapter 7.6 page 108 Visions vs Goals and other requirements artifacts
There seems to be quite a bit of overlap in the vision and the
requirements, as in user level goal.
A
Vision Statement
is a short statement of what we expect the project to achieve. It
is inspirational. It is an "Executive summary". But it leads
to many goals and requirements. These are only implicit
in the vision, they are discovered in "Requirements Analysis"
Example: the vision may talk of "reliable 24/7" services. Requirements
analysis uncovers a dozen of use cases involving monitoring, back up,
restoration, roll backs, disaster recovery, etc. To say nothing
of a ton of systems design... like the UPS, the multiple servers,
no single point of failure, ...
At the end of Inception is the vision complete
Yes.... but it is also wrong. Only when the project is over do
you discover where you ended up. The vision points the direction,
the journey defines what you've got.
Chapter 7 page 114 -- Vision changes
Is it common for the vision to change as the use cases and supplementary specifications are being written?
I can't give you any statistics about real projects. I'm it does happen.
It has never happened with my own projects, as far as I can recall.
In the student projects I have supervised in the last 37 years
I have seen two projects completely implode and need rethinking while
we were working on the specifications. In both cases the whole
basis of the work was an assumption that proved false.
A well written vision should be a high level picture that can survive
discoveries made when writing use cases and other specifications.
Data Dictionary
How do you write a data dictionary? I noticed the term is defined as data about the data, but how is it applied?
We cover these briefly in CS372 and in data base classes.
A data dictionary has a lot of definitions: data elements, data types,
data processing, data records = entities, ...
You can buy expensive data dictionary software.
You can get one with your Data Base Management System.
You can use a spread sheet or personal data base.
I use a file/web page that is full of definitions.
Chapter 7 page 117 Glossary changes
Can the glossary grow or change as we progress through iterations and the scope grows, changes or shrinks?
It grows.
Questions from 2008 and before
Chapter 6 pp 89-100 -- Additional systems.
When you discover the need for a supporting system to be created before
your main system can be fully utilized, what is the best way to incorporate
that into your project schedule?
Most projects need some infrastructure -- work on it mainly in
inception and a bit at the start of each iteration during elaboration,
possibly later.
Chapter 6-7 pp 89-120 -- Use cases vs Business case
Can you compare and contrast system use case and business use case?
Business case says why the system should be done.
Use case says what the system does for its users.
Chapter 7 pp 89-120 -- Vision vs. Use cases
In a small business model, can vision be considered as a well described use
case? If not, How can be differentiate?
No. Use cases are detailed and visions broad-brush. One vision
has many use cases.
Chapter 6 pp 89-120 -- Mistakes
What seems to be the biggest mistake students make when making use cases?
I'm not sure. Possibly starting to describe the technical details
of the user interface or the design of the software.
Chapter 4 pp 81-120 -- More Requirements
Are ERD's considered Data Dictionary/Glossary ? Why isn't an ERD mentioned
as a requirement?
I think of ERD's as a visual data dictionary. Larman and RUP have
a "Business Model" that is close to a conceptual ERD. I guess
that a Chen ERD should be filed as a supplementary requirement.
ERD's are static models and tell you about the domain.... more
about domain models later.
Chapter 7 pp 89-120 -- Feature List
Can you explain how to write a feature list and what exactly belongs in one.
Follow the book's advice -- bulletted lists of things that the system
will/shall do.
Chapter 6 pp 90 -- Use case relationships
How to avoid organizing two use cases into one? Like put Cash In into
Process Sale? Why Cash In and Cash Out are not in the same use case, I
think they are just different steps of paying.
This is the kind of question you have to ask when working in a
new Domain/Business/Enterprise -- "what do you mean 'Cash in'?"
I think the answer would be: At regular intervals and when the
cashier goes off duty the cashier must hand over the big bills from their
tills and .....
In other words, you avoid the mistake of combining
"Cash in" and "Cash out" into "Process Sale" by asking questions
about the meaning of the phrases.
Chapter 6 pp 91 -- Use Case Actor
Can we use stick figures to represent external systems?
Yes. But some people may get confused.
Chapter 6 pp 91-92 -- Downplaying Diagramming
So its better to downplay diagrams for use cases?
Yes. I guess so. More precisely -- it is more dammaging
to enlarge use case diagram until they are are the only work
done on requirements. I see the diagram as a tool for
presenting requirements to stake holders. They make excellent
Power Point slides....
Chapter 6 pp 93 -- feature lists
Feature lists were mentioned on pages 93 and 113. It appears that either
use cases or feature lists are used. Can you use both? Will we be using
feature lists?
Feature lists were popular before people learned about use cases.
Some enterprises may still use them -- we won't!
Chapter 6 pp 93 -- Boss Rule/Monopoly
What is the Boss Test?
A test for good use cases.... would your boss be happy if the user did this
use case all day?
Chapter 6 pp 95 -- Use Case Realizations
What exactly are use case realizations and how do they work with a use
case?
A realization describes, in detail how the software handles a use case.
It will say precisely what objects are involved and how they
interact to get the job done.
Chapter 7 pp 101-120 -- Other Requirements
The book says that these secondary requirements aren't central to learning
OOA/D, so how is it decided when they should be applied to your case
studies?
Larman and this course will return to this topic later.
Chapter 7.4-7.5 pp 104-108 -- Supplementary Specification
In the NextGen Example of a partial Supplementary Specification, is the
Supplementary Specification a part of the Use Case or is it completely
separate? I am assuming it is a separate document and if so where would it
be included with the other documents?
The Supplementary Specification is not part of a particular use case
but a separate artifact -- a document/web page/file. Probably placed
after the use cases.
Chapter 7.5 pp 107 -- Special Requirements
Can you give us an example of what we would consider special requirements?
Try this that arrived by EMail last week: "To establish A.D.A. compliance
all syllabusses will follow this .doc file template..."
Or this: "The pace maker must defibrillate the heart within 1 second of
fibrillation occurring".
Or: "This is a throw-away prototype -- non-portable, incomplete,
and unmaintainable".
Chapter 7 pp 111 -- Vision
There is a commentary on page 111 that says "Please go read the 7-page
Vision at the project website" isn't the vision supposed to be a short
description of the project and not a 7 page report?
A 7-page vision is for a big project! The book is using a industrial
scale project and for these the vision statement can get a lot
larger than the ones we are going to need in out 10 week projects.
Chapter 7 pp 111-114 -- Summary of System Features
Why listing the use case names is not sufficient in the Vision to grasp the
major features?
The answers are in the book! I agree with them.
Chapter 7 pp 111 -- Vision
It seems as though the use case and the vision go hand in hand, does the
vision summarize the entire project detail for detail? If so then shouldn't
that be in the use case?
Vision
statements should go for the big picture and avoid the details of
how the vision is achieved in my opinion.
I agree that uses cases and the vision go hand-in-hand.
Chapter 7 pp 101-120 -- Order of writing Vision and use case
The author says it "isn't useful to be rigid about the order," of weather
one should write the use case or the vision first. then gives a
suggestion, what is your suggestion?
See below.
Chapter 7 pp 114 -- Vision or Use Cases first?
The book states that "it isn't useful to be rigid about the order", but
doesn't a use case first require a vision to create a use case???
I agree that in theory the Vision should come first, but in practice
you might need to sketch a view use case to get an idea of the
scope of the system.
Indeed they probably develop together as a real project proceeds.
Chapter 7 pp 115 -- Glossary
The author talks about the Glossary very briefly. Where can I find a better
example of one?
I'm not sure if it is better but I put one at the end of all my notes
in this course. Keep it simple -- a list/spreadsheet/database
of terms and what they mean in particular contexts.
Chapter 7 pp 102-102 -- Glossary
Is there any particular way that the glossary should be organized?
Alphabetically is good for looking things up.
Personally I write my glossaries using an eXtended Bacchus-Naur-Form.
Examples:
[ ../samples/glossary.html ]
[ ../samples/languages.glossary.html ]
[ ../samples/uml.glossary.html ]
[ ../samples/objects.glossary.html ]
[ ../samples/c++.glossary.html ]
[ ../samples/stl.glossary.html ]
[ ../samples/java.glossary.html ]
[ ../samples/comp.html.glossary.html ]
[ ../samples/methods.glossary.html ]
[ ../samples/math.glossary.html ]
[ ../samples/php.glossary.html ]
Chapter 7 pp 115-116 -- Data Dictionary
Is it appropriate to define user types (Salesperson, Manager, etc.) in a
Data Dictionary?
Yes. I think it is valuable to define some very specific "personas"
to understand how different users will want the system to work.
Chapter 7 pp 117 -- Domain and Business rules
What is the difference between Domain Rules and Business Rules?
Nothing.
It is just that many enterprises would be shocked to be
described as a business -- for example -- students who have
been working in the summer at the University Of California,
Santa Barbara would be wise to document the various rules
that their software must respect as "Domain rules" not
"Business Rules". By the way -- these rules come from
Physics and Biology.
Or, contra-wise, if you work for Citrix you would be wise to
ask people for the Business Rules seeing they are trying to
make money.
6 pp 61-89 -- Use Cases
Does writing use cases help as much as drawing diagrams, it seems harder
and not as productive.
I agree with the book -- I've seen a lot of projects that wasted time
drawing
complicated use case diagrams when a few simple written use cases would
have
been time well spent. Sadly several software engineering texts actively
encourage diagrams and don't even mention the writing...
Fact: in games and IT,
writing is were design happens.
In scientific work the design tends to be done using mathematics.
3 pp 61-89 -- Non-functional requirements
How is a resources measured in terms of mistakes per hour? Rather, how is
a mistake classified?
Hmmmm, Yes it does need refining. So let me refine it a little bit:
- Take a random user from the target pool and train them in using the
product,
- Set them a task using the project in the usability lab,
- Videotape them,
- Two independent reviews count the number of times the user makes a
mistake.
Or.... simpler.
- Software is instrumented for testing purposes to count the number of times
a user clicks the "undo" button.
Exercise: work at another more detailed procedure for measuring the number
of mistakes a user makes...
6 pp 83 -- Use Cases
The book states, " user-goal level use cases will be one-to-one with user
goals". Does this mean that each use case covers only one user goal?
Yes, and vice versa, each high-level user goal should have precisely on use
case.
05 pp 89-120 -- Use Cases
Could you provide an example of a Vision/Business case?
No. The book and your project documents are excellent examples
already.
05 pp 89-120 -- Use Cases
Also, are all the diagrams in "Use-Case Model" (front cover of book) a
necessary part of a Use-Case Model?
Yes -- if you need them. The Systems Sequence Diagram is not used
by all methodologists. And I'd happily omit a complete use case diagram:-)
Think of all the artifacts -- documents -- as optional, useful
at the time, and evolving as you go. Not tablets cast in stone.
6 pp 90-92 -- Context and Activity diagrams
What is the difference between a Context Diagram and an Activity diagram?
A Context diagram shows the System Under Design in the center and the
things it interacts with around the outside.
An activity diagram has a mess of boxes, all connected together by control
flows, with no center, and no indication of connections with other
systems or things.
Activity diagrams show, in detail, what can happen inside the central
system in a Context diagram.
Chap6 pp 91-94 -- Use case/Monopoly game
How we can identify in Use Cases a displayed image, monopoly game or a game
where an actor intervenes as a player?
Yes.
I guess Larman didn't want to make it too complicated.
Or perhaps it was left to be done as an exercise.
7 pp 100-108ish -- Supportability
I know sometimes when you are looking into systems you know what system you
are going to be using and can define adaptability and configuration and
would know the implementation constraints. But what if it is the case that
you are developing for a system that is not yet available for testing or is
being changed?
You've got a risky situation. You need to allow extra time after the
delivery of the system to remove the unexpected things that can happen.
Perhaps you should consider creating or getting an emulator for the new
system.
Possible exception: small projects on a very well defined platform.
7 pp 102 -- Organization
Chapter 7 contains lot of requirement artifacts that can be key in adding
clarity to use cases. Since there are so many of these artifacts, is there
a particular way to organize all of these artifacts together or produce a
sort of "design document" out of them?
Good question -- I've spent 20 or 30 years working on it.
Larman uses 4 or 5 documents, The supplementary specs have headings from
the FURPS+ classification. I've tried PQRST in a prototype
IDE but it didn't work as well as many small documents and a good search
engine
or two. I know other famous people who put each requirement
on a 3><5 card and use a rubber band to keep the pack together. The
IEEE standard SRS provides another way to organize requirements
[ http://www.csci.csusb.edu/dick/SRS/ ]
and the literature of software engineering has lots of
designs for "repositories"...
I don't think we have found the perfect one-size-fits-all structure yet,
so I go for flexibility and a little bit of automation and content
control.
Personally in projects at this university
I'm leaning towards a simple web site with a project
blog as index, a search engine, and a lot of simple HTML, GIF, JPEG, PDF,
and TXT files. Perhaps add an upload page that records some
metadata....?
One thing I plan to explore, now I've got a workstation in my office
again is integrating the tools and languages I developed in the
last 20 years into Eclipse... And see what structure evolves.
7 pp 103 -- vision and Supplementary specification
If the vision is specified, is it absolutely necessary to include the
supplementary specification? Is the vision alone enough to detect what is
wanted?
The Vision is a high-level fuzzy document: ` the system shall be
reliable`.
The supplementary specs will be detailed: ` the mean time to failure under
normal load will be 10 weeks, the time to recover from a failure will be
less than 6 hours 90% of the time`, ... Etc.
Or: Vision: fast. Spec: `reacts to user input in less than 0.1s under
normal load, 95% of the time. Etc.
Or -- Vision: user friendly. Spec: a randomly chosen secretary will prefer
to use our product over MS Word 60% of the time". Etc.
7.7 pp 111 -- Vision
How short can a vision be? Can it be at least a half a page?
Yes. As long as it covers the subject -- defines the direction and
scope of the project. Where are we going and what will be involved
in the journey.
7 pp 111 -- Vision
Other than the vision and the executive summary are there any other
documents that would be useful to help introduce a new person to the
project?
I like Domain (or Business) models, but they are an acquired taste!
Most people like some kind of context diagram: DFD or use case.
I'm tempted to add that a really good video can help. For a sample
go to
[ http://csci.csusb.edu/dick/cs690/ ]
and select some of the PowerPoint downloads. Some a good and some
less good...
Personally I think that software developers under use the audio-visual
technology
that we have to communicate our vision. We need to think less like
bureaucrats and more like Steve Jobs, perhaps.
7 pp 112 -- Fishbone Diagram
I saw the word fishbone diagram and it caught my eye.
I was wondering is a fishbone diagram good diagram to use when developing
software? I know that it is a cause and effect diagram would that be useful
in software development?
A fishbone diagram
[ Fishbone_diagram ]
is a diagnostic tool working back from some problem
to its causes. I've never used them -- I use a much freer "brain mapping"
technique. But they have turned up in many papers and articles. Google
.See
http://images.google.com/images?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&q=%22Fish-
bone+Diagram%22&btnG=Search+Images
finds 204 images today.
7.7 pp 112 -- affinity grouping
Can you explain and or give an example of affinity grouping?
YAGNI in this course. Unless you find it helps...
Google Images:
.See
http://images.google.com/images?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&q=%22affi-
nity+grouping%22
Again I prefer brain mapping for personal work, but I can see this
technique
working well in a team setting.
Note: I'm surprised the book didn't mention
Kelly grids
and personal construct theory
.See
http://www.google.com/search?svnum=10&hl=en&lr=&ie=ISO-8859-1&oe=ISO-8859-1-
&q=%22Kelly+Grid%22&sa=N&tab=iw
that also are useful for sorting out fuzzy areas -- especially pathological
ones.
7 pp 115 -- Data Dictionary Guideline
It was stated in the book:
"Start the Glossary early. It will quickly become a useful repository of
detailed information related to fine-grained elements."
What fine-grained elements is the book referring to?
Mostly data elements like a "student id" or "course name abbreviation".
Think -- a noncomputerized declaration of a variable or data type.
pp -- other requirements
Do we have to refine the supplementary specification
in the construction phase?
Yes.
Think of every artifact, including the Supp Spec, as dynamic,
changing, evolving towards perfection as the project progresses.
As in mathematical iterations the imperfections get as small as
we would want if we iterate enough.... and imperfections are
ultimately measured in terms of the code not doing we want, the way we
want it to.