This is not a complete facit, it just mentions some points that
I was looking for in your answers.
- Feasibility study vs. market analysis
- More need for/possibility to interact with stakeholders
if there is a customer.
- If there is a customer, the requirements specification
often serves as a contract.
- Not so much difference in design and testing.
A customer may have process requirements.
- Testing: acceptance vs. beta-testing
- Maintenance: with a customer: part of the contract,
on the market: new releases
- Users and the Customer (in case of a custom-made product), want
readability,
completeness,
consistency,
correctness,
may serve as a contract (testability)
- Designers:
readability,
consistency,
non-ambiguity,
traceability
- Testers:
testability
- Maintenance staff:
completeness,
traceability
-
a)
- Databases: at least two, one with customer info (how much of
each stock), one with stock info (value, now and in the past, etc.)
- Database access layer: allows access to these databases
- Business layer: contains rules, for example it can compute the
value of someone's assets by multiplying and adding data.
- Presentation layer: creates flashy diagrams
b) Encryption is most important between the presentation layer and
the business layer. Authentication (by password or cryptographic
techniques) is needed for transactions mostly. The business layer
should be the only way to access data (there may be other business
layers, for instance for bank personel). The database access layer
ensures database consistency: the ACID properties (atomicity,
consistency, isolation, durability).
-
a) Two things: 1. The control system is very safety critical, and in
order to make it correct and verify it, it should be as small as
possible. As much as possible should be kept outside.
2. The two parts have different functions, and low coupling. So it
is good design to keep them apart. This would for instance make it
possible to reuse a traffic direction system in another country,
with another control system.
b)If it fails, the railway system will soon come to an almost
complete standstill. This may cause significant economic damage.
(It might even cause chaos on the roads, and accidents.)
Note however that it will not create train collisions.
It should not even create danger for track-workers, although in
practice it might.
- Structural: An identifier (number), or any other way to
find stakeholder, rationale, etc.
- Content: It does not specify what kind of failure.
For a transient failure, the requirement is quite hard
(these money changers fail quite often to recognize a note).
For a permanent failure (service needed), the requirement
is very weak.
Note: using ROCOF is correct here, as is the unit "per request".
Of course, there will be other requirements on the machine, also
about reliability (notably AVAIL). Availability is related to the
frequency of permanent failures.
-
a)
- Draw a flow-chart, identify nodes and branches.
- Find a collection of paths that visits all nodes/branches
- Find input data that makes the program follow each path
(if it turns out that there is no such data, the path is
infeasible, go back to 2 and replace it by other
paths).
In this case, the difference is that branch coverage requires
that the test A(i)>max is true sometimes, and false sometimes.
For node coverage, it may always be true. In any case, only one
test is necessary. Say C=3, and A=[5,2,3,6].
Note: this method is not to be confused with boundary
value testing, as described by Sommerville. Boundary value is
a form of black-box testing: you need only the specification, not
the code.
b) The error is that A(1) is never checked. A statistical test has
probability 1/C to detect this. From a) we can see that it is easy
to achieve branch coverage and yet miss the error.
A boundary value test might detect
it, if you have a rather broad definition of "boundary". Such a
definition will soon be unworkable. Inspection has a good chance
(most of you found the bug). Formal verification, that can be done
mostly automatically when loop invariants are provided, is another
candidate.
-
Important: realise that the bug is not fixed. A work-around is not
a fix, and you cannot fix a serious, non-trivial bug in a day.
It is not even given that the bug has been located exactly,
maybe all we know is that a call with certain parameters results in
a crash. So what we need to do is:
- Analyse the bug
- design a solution
- implement the solution
- verify the solution (test and/or inspection)
- update documentation
- version management has now two new versions:
the one with the workaround and the new correct version
- learn from the bug (statistics, list of "common" faults, etc.)
- For Cleanroom, read the book/articles. Two points that are
worth taking up: 1. Would you like a working environment with such
strict roles and rules? Do they limit your creativity, or do they
save you wondering what you should do, so that you can concentrate
on how you should do it? What roles would you like/not like?
2. Would you like to work with the kind of
projects that are suitable for Cleanroom?
-
- Educated guess, experience, comparison with previous
projects.
- Breakdown in smaller projects and phases, tasks, how many
working hours needed. Multiply by "external hourly fee", which
includes overhead and standard uncertainty.
- Apply some measures to estimate complexity, like COCOMO
(still this is based on an estimated size).
- Whatever resources are available (customer budget, or man-months).
Make as much functionality as is possible with the resources, as
opposed to making a fixed required functionality whatever the cost.
-
a)Since we planned to train 4 programmers, training 8 is not going
to take much extra effort. But communication between 8 programmers
will be substantially more than between 4. It is not clear if the
work can be divided over 8 programmers.
b)Intuitively it should. But if we compare the communication
according to the C = 0.5*n*(n-1) estimate, we see:
1 project, n=4 C=6 versus n=8 C=28, factor 5.
2 subprojects, n=2x2, C=2x1 versus n=2x4, C=2x6, factor 6.
So the factor of increased communication hardly differs, but the
absolute amount of communication increases less with 2 subprojects.
- a) The following points you must do, or assume that you have
done them already:
- write down the process that your team follows
- collect data to prove that you actually follow this process
- now you can apply for certification
- set aside time and money for assessments
For the other departments, you should
- Study their process (the one that they actually follow, and
also the one on paper, if they have).
- Discuss possible improvements (based on your process)
- Motivate the department to go for quality, and to carry out
the steps above.
b)To see certification as the goal, and quality as the medium,
rather than the other way around.
To impose your process on other departments.
To impose a quality programme without support from "below".