This course talks about software development lifecycles a description/prescription for how we write software. Design is a step in this life cycle, and the course explores the implications of this. Design has a role in the life cycle; it is always there, regardless of the kind of life cycle we’re talking about. Why is that? Why was design considered as a step in this life cycle?
Interfacing with Requirements and Implementation
Loading...
Do curso por University of Colorado System
Software Design as an Element of the Software Development Lifecycle
18 classificações
Na lição
Design in the Context of Different SDLC's
There are different ways to develop software, but design plays a similar set of roles regardless of why way is used.
Conheça os instrutores
Albert GlockInstructor
Computer Science
This talk is about interfacing requirements and implementation with design.
In principle, regardless of the soft development life cycle – design takes
some sort of requirement input and
converts it to something an implementor can understand.
But before we get going on the mechanics of doing this,
let's take a minute to think about what we're really trying to do.
In the interface with requirements,
the designer is trying to understand what the requirements are.
Now, what would be the absolute best way for the designer to understand the requirements?
One easy answer is that the designer would
also be the person who elaborates the requirements.
This doesn't happen in practice very often.
So it's a question of how best to get
the design person to understand what the requirements person knows.
What I'm going to explain is about teaching requirements.
Since I'm a teacher,
I'm all the time trying to get students to understand what I know.
I have written requirements in the sense that my courses generally have textbooks.
But, first, reading the textbook is a very dulling experience and,
two, it often doesn't lead to the understanding I'm looking for.
So we have classroom experiences where I can talk where students can ask questions.
Sometimes when I find out that a group of students has a common deficit,
I arrange for a teaching assistant to
instruct small groups of students in the problem area.
And then I have office hours,
where I can work with a student one-on-one to answer
questions and try to ensure a good understanding of the subject.
I have never, in my fairly long life in government industry,
never seen or heard of a situation where a requirements person
takes the time to teach the requirements to design people.
Normally, what happens is that requirements
people write a document and then they disappear.
Designers are left with the textbook.
Worse, there aren't technical editors and reviewers who scour that textbook,
the requirement specification, for clarity and consistency.
So the requirements are hardly a solid document which can be
depended upon to relay the same story to each person reading it.
There is a branch of study called philology which deals with languages.
Textual philology concerns itself with the interpretation of ancient texts.
A designer interpreting a requirements document
is somewhat like a philologist interpreting
an ancient text because all there is to work with is
the words and the author is not around to answer questions.
I've seen this in practice.
At a very large defense contractor's facility in Florida,
I sat in amusement as designers discussed written requirements for a system as if
the requirements were written by ancient gods whose knowledge
was infinite and to which knowledge we can only hope to aspire.
Some reference was accorded to the source,
as if it was an unearthed tablet that held secrets of the universe.
The experience for me was as comical as it was tragic.
We were looking at inconsistent, incoherent,
and largely incomprehensible language and trying to make sense of it.
It was clear to me that the authors had an inadequate grasp of
the situation and were hiding behind ambiguous and sometimes senseless phrases.
The requirements document was signed off by a number of important people.
I suspect that they never read it entirely and were only really
approving the document from the standpoint that it
didn't offend them or threaten their organization.
Whether or not the document actually made sense wasn't really on the table.
My motive in describing this vignette is that there is nothing about
at least the common implementation of a process that guarantees good results.
You might have heard the story about the nail company in the former Soviet Union.
When told they would be measured on the number of nails they produced,
produced brads, very small nails and large numbers.
When told they'd be measured by the amount of metal consumed in manufacturing,
they made railroad spikes.
Most measures of quality,
when pushed to the extremes become senseless.
What's the designer to do?
Well, first, a whole lot of work.
If you don't have any real persons to talk to about the requirements,
my first suggestion is to attempt to rewrite
them in a more rigorous but still understandable form.
Attempting to rigorize ambiguous requirements is
tricky and when you run into questions about meaning,
sometimes you simply have to think about the situation.
In several jobs and industry,
I've been fortunate enough to have access to trails and
scenic areas as one of the advantages of working there in the mountains in Colorado.
As strange as it sounds,
getting out of the office can be very helpful.
If you see the same things every day,
you think the same way.
If you take a walk and see something different, different thoughts occur.
I've very often had the experience of having a problem in
my head and solving it just as I was leaving my building.
Sometimes it only takes that long.
So then I could enjoy the rest of my time thinking about something else.
If you have requirements people to talk to,
great, sometimes knowledgeable users can help you too.
In one commercial organization I worked in,
newly hired product developers were put through
six weeks of help desk operations so they could learn
the existing software and be aware of
user satisfaction levels so that they could understand where the product should be going.
However you acquire requirements knowledge as a designer,
the objective is to get the whole project in your head in detail.
Having this synoptic view allows you
to see how one part of the project relates to another.
In the design phase, my recommendation,
what I tell my students is to try to find the major fault lines in the project.
In my terminology, fault lines bound more cohesive sections of a project.
There is generally a fault line between user screens and backend software,
and another between the backend software and the database,
and there may be others.
A second task is to identify high-risk parts of the project.
This, of course, can vary by a person's experience.
I know a lot about databases – replication, scaling, management.
So the database segment of a project seems to me to be low risk.
Another person may not be so familiar with
databases and may identify that section as high-risk.
That's appropriate. The bottom line is that
the designer does have to understand the whole project in a lot of detail.
Once you've identified the fault lines and the high-risk areas,
you need to mitigate the risks.
This can be done in several ways.
Learning more about the risk,
understanding it, and doing research on the problem is a good start.
You can talk to people familiar with the risky technology.
This generally doesn't provide
a definitive answer but it's a good step in the right direction.
The second thing you can do,
and this provides a definitive answer,
is to create a prototype.
Yes, we're talking about a designer writing code.
An alternative is to have someone else do the prototyping but you
have to be sure that you understand the assumptions behind the prototype.
This would primarily have to do with scaling and perhaps maintainability.
I once had a project that required the use of a voice over IP solution,
so the participants in an activity could all talk to each other.
I never worked with voice over IP before but
I knew several gamers who were quite familiar with it.
For me this was a high-risk item,
I wasn't sure I could produce a design using voice over IP and have it work.
After several conversations with my friends,
I understood enough to put together a working model of what I wanted.
And I could scale the size of the model to
show that it was adequate to the task for the project.
I was then able to specify to the developers how to set up
the software to use the voice over IP technology.
Now if you've noticed,
I've talked both about understanding requirements
and communicating with developers in the same story.
This is because the second task we have after interfacing or communicating with
the requirements or requirements people is to communicate with
the developers being aware of the ambiguity,
having difficulty in interpreting written documents when the author is no longer around.
We can perhaps write our directions to the developer and make them
clearer than the requirements we received in the first place.
Fortunately, design can be a more rigorous phase than requirements.
Any set of technical sounding sentences sometimes seems can pass for requirements.
Designs using specific design tools like the Unified Modeling Language or UML,
add a little more rigor to dispel the ambiguity.
This can better communicate with the developers.
I ran across an interesting analogy recently.
In civil engineering, the usual way of
constructing a building is that an architect designs it.
Two requirements, the architect has some knowledge of
building practices and some understanding of
mechanical principles of the strengths of materials.
But when the architect is done with a design,
the design is passed to a construction engineer who decides how the design will be built.
This is a bit the same way we work in software development
especially when using waterfall like techniques.
A design is done and it's thrown over the wall to
the implementers who have to figure out how to turn the design into a source code.
If the designer was rigorous enough in
the representation of the design then the implementors have a fairly easy task.
If there are holes in the design or areas that
are incomplete where the implementers either have
no idea how to perform a task or there is
such a wide variation on how the task could be performed that there is a risk,
the implementation might violate some other characteristic of the design.
In particularly critical designs in civil engineering,
an example is tunnel engineering.
The technologies used to implement the design, the tunnel digging,
are so closely related to the design
itself that the designer and the construction engineers work
hand in hand to produce both the design and the implementation plan at the same time.
In general, this close collaboration is required by safety considerations.
In a particular soil type,
which limits the possible construction methods,
only certain designs are known to work.
Producing design which can't be safely built is a primary concern.
The illustrations above are from the Holland Tunnel
designed by Clifford Holland which connects New Jersey and New York.
The design of the tunnel included a still amazing ventilation system.
The towers of which are seen in one of the photos here.
The design and implementation of this case were extremely
tightly related for both safety and for success reasons.
And I would propose that we might consider the safety factor in
public construction similar to the security factor in secure software design.
We'll see later, in the discussion of Bitcoin,
that a total integration of various facets of design and
implementation are required to make the software reasonably secure.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
