|
||||
University of Oregon
|
Sommerville says one of the basic problems of evolutionary
development is: "The process is not visible. Managers need
regular deliverables measure progress. If systems are
developed quickly, it is not cost-effective to produce
documents which reflect every version of the system."
Describe the concept of process visibility very briefly, and
propose a way to achieve some level of process visibility in
an evolutionary development project without extensive
documentation of intermediate versions of the system.
Process visibility is about gauging one's progress with respect to the process. I gave at least 3 points if you had a clear description of what process visibility is, and the remaining points depended on a clear and plausible approach to achieving process visibility. The best answers described very specifically how prototypes could be used to gauge progress, e.g., by noting which features have been implemented and which remain to be implemented.
Many people confused the means (documentation) with the end (visibility), and you did not receive any credit if your answer says that visibility means documentation. Some people proposed ways of reducing the cost of documentation, rather than proposing ways to achieve visibility without a lot of documentation. I didn't give much (or any) credit for that.
Suppose a software requirements statement is incomplete. Is
it possible to produce an implementation that satisfies the
stated requirements? If so, how? If not, why not?
This and the next question were simple questions of logic. They don't ask whether it is a good idea to have an incomplete specification, or whether the customer is likely to be satisfied. Together they are asking, what does it mean to satisfy a specification? An incomplete specification can be satisfied by many implementations; essentially it lets the implementer make choices. An inconsistent specification contradicts itself, so no implementation can satisfy it.
Suppose a software requirements statement is inconsistent.
Is it possible to produce an implementation that satisfies
the stated requirements? If so, how? If not, why not?
More people got this part right than the part about inconsistency. Still, many answers showed a misunderstanding of what it means to satisfy a specification, including some that discussed inconsistency in the design (components that don't fit together properly) rather than inconsistency in specification.
Does it ever make sense to create a rigorous software
requirement statement and use prototyping in the same
project? If so, why and under what circumstances? If not,
why not?
I gave many people full credit for various reasonable answers. The particular answer I was looking for is that prototyping can be used as a way to validate and refine a rigorous specification, so of course they can be used in the same project.
I was surprised that many answers implicitly assumed that, if one were to use prototyping in a project with a rigorous SRS, that the SRS (in more-or-less final form) would be written before the prototype. If you made that assumption, you probably didn't get any points for this question.
Smurftronix Inc. is designing a new software-controlled toy
to compete with Furby. One of the critical components of
the new Smurfy toy is a speech generator, which will
generate annoying noises when the toy is approached, lifted,
or stomped. Initially the speech generator module will
control a hardware device manufactured for smoke alarms, but
it is considered likely that cheaper mechanisms may be
substituted in the future. Other parts of Smurfy software
will access the interface to the speech generator module.
Alf has proposed a software interface for the speech
generator module, and Betty has proposed another; each
claims that their interface design is more "abstract" and is
better with regard to information hiding. Is it possible to
objectively compare the abstraction and information hiding
of the interfaces proposed by Alf and Betty? If so, how
might you do so? If not, why not?
I was really disappointed in the answers I saw here, and in fact I gave zero points to more than half of them. I didn't give credit for a "yes" answer alone unless the explanation also made sense.
The question gives you a very clear clue about what is likely to change: The smoke detector noise generator is likely to be replaced by an even cheaper part. Wouldn't it make sense, then, to compare Alf and Betty's designs with respect to the impact of changing that device? Even if we don't know exactly what hardware might be substituted, we could evaluate the interface with respect to whether it would be suitable for other hardware (and we wouldn't need to build a prototype to make this evaluation).
Some people confused "objective" with "quantitative." You can have an objective comparison that doesn't involve assigning numerical scores. Some people said information hiding and abstraction were intrinsically subjective. The point of this question (and of things I said in lecture) is that it isn't --- with respect to a particular set of expected changes, one can objectively evaluate whether an interface is successful in hiding those changes.
How might information hiding be used as an aid to
incremental development and phased delivery of a large
software system? Be as specific as possible.
I was hoping for something in particular (getting out a "good enough" implementation quickly, then improve algorithms and data structures for a subsequent delivery), but I accepted a wide variety of reasonable answers, and many people earned the full 10 points. Among the better answers: information hiding can help keep the interfaces of already-delivered parts stable, and it can make it easier to change (hidden) details of the parts that haven't been delivered yet.
7. (15 points)
In our reading and discussion of requirements we have
pointed out potential difficulties with both informal (e.g.,
English prose) specifications and with formal (e.g., Z
[Zed]) specifications.
Over the course of a software product's life cycle, which
approach has the potential to be a bigger problem for some
particular, key requirement one must specify:
A) An informal specification that is easy to read but open
to different interpretations by different people.
B) A formal specification that can be fully understood by
only a part of the development team but it is unambiguous in
its meaning (i.e., you know whether you understand it or
not).
Give your answer (A or B) followed by a few sentences (no
more than 8, 80 column lines) describing why the situation
you picked can lead to bigger problems. Spend one or two
sentences describing "why" it is a problem and the rest
describing the problems that can arise (e.g., a worst-case
scenario).
Stuart graded this question. Here are his notes:
Question 7: The preferred answer is "A". The driving issues are when errors
will be detected and what it will cost to fix them. Where the specification
permits ambiguity, different stakeholders can believe they have the same
understanding of the specification while making very different assumptions.
Differing assumptions of this kind are difficult to detect until products
are actually produced and validated. In the worst case, such errors will be
detected only at the end of the development when the problems are most
difficult and expensive to fix. For full credit you needed to both describe
what problem occurs and how the delay in detecting and fixing the problem
drives up the cost/difficulty.
In general, the development will be better off when people know whether they
understand something or not than when people think they understand something
but do not.
Reasonable (if less compelling) arguments could also be made for "B" based
on the notion that mutual understanding of the specification by all
stakeholders is necessary to build the right system. In particular, if some
parties (esp. the customer) do not understand what is to be built, you might
not find this out until very late in the development, leading to much the
same problem as above. However, this is a much easier problem to fix since
the problem becomes evident very early in the development and can be
addressed by adding expalnitory material or using more easily read
formalisms. Nonetheless, I gave nearly full credit to those who made a sound
argument for B.