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?
What's an SDLC
Loading...
來自 University of Colorado System 的課程
Software Design as an Element of the Software Development Lifecycle
42 個評分
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
從本節課中
How Design fits into the flow of software development
How Design translates requirements into specifications which coders can understand and use.
與講師見面
Albert GlockInstructor
Computer Science
Welcome back.
Last time, we talked about the importance of thinking and
how the ability to understand and adapt are important.
We'll now turn to some of the classical features of design as it's conceived of
in the software development world.
This should give you an idea of where the software development process has been, and
where it's going.
I think you'll see that it's heading in a more adaptive direction, and
that's a good thing.
SDLC stands for Software Development Life Cycle.
In general, the SDLC is a set of cradle to grave steps
through which a software project passes in its lifetime.
Back in the early days of computing, in the mid 1950s, when computers
switched from using vacuum tubes to using transistors and iron core memory.
Computer engineers who were participating in organized software
writing efforts began to reflect on their experiences.
And this is a natural characteristic of human thinking,
to coalesce individual episodic experiences into semantic structures,
meaningful structures, which convey meaning.
Herbert Benington, a computer engineer working on a computer system who's job
was to protect the United States against Soviet aircraft and missiles,
first described a step by step sequence through which the software passed.
This is what we now called the waterfall model.
He described five steps, requirements, design,
implementation, verification, and maintenance.
To a degree, these steps are present in all modern forms of the SDLC.
Software development traditionally follows a series of phases,
which together are called the software development life cycle.
The most familiar life cycle is the waterfall model.
One first determines requirements for a piece of software.
Traditionally, requirements are considered a statement of the problem to be solved.
Technology is injected into the process and design is produced.
The design is the first evidence of a solution to the problem.
Implementation is where the design is put in the computer code.
In the implementation phase, the source code is also converted into files of
instructions which your computer can execute.
The executing program is checked to see that it performs properly in
the verification phase.
Once the software is delivered and set up for
the users to operate, any actions to correct, adapt, or
perfect the software fall into the maintenance phase.
The IEEE EIA 12207 standard describes the waterfall model and
a number of variations to the model.
One of the variations is to fold the waterfall back on itself about halfway,
the result is called a v shaped waterfall.
This scheme is linear sequential just like the original waterfall.
But it acknowledges that the phases before coding and
implementation phase contain information useful in the various testing phases.
In the figure at the right,
the unit test phase is closely coupled to the coding phase.
The system test phase has its roots in a design phase.
And the acceptance test phase is based on an information derived
in a requirements phase.
One advantage that V-shaped waterfall is that it clarifies
the relationships among phases, which can proceed coding or
implementation, and the phases which follow it.
Another variation on the traditional waterfall model is the waterfall with
feedback.
This model understands that in each subsequent phase,
it may be necessary to rework tasks previously done.
Thus in the design phase, it might be necessary to rework some requirements.
In the implementation phase, it may be necessary to rework part of the design.
This is one way of making the life cycle iterative,
where a phase may be executed several times.
Feedback can also occur across the entire software development life cycle.
There are two lifecycle models which are considered iterative in nature.
The first of these is the incremental model, Ketrell characterizes this
model as having overall requirements phase and initial design phase.
Followed by multiple cycles through the remainder of a lifecycle In this figure
each of the three iterations begins with the detailed design phase.
Although development proceeds in increments,
there is a single requirements phase for the entire project.
The advantage of this process is that there is some semblance for
a product early on, which has a positive effect on team motivation.
The fact that each phase has gone through multiple times in the course of product
development means there's an opportunity for learning.
The second and third times through the design implementation phases,
allow developers and managers to understand
better the implications of the decisions made early on.
This feedback tends to make downstream phases more efficient.
Unfortunately, the single occurrence of the requirements phase and
the lack of feed back arrows to the requirements phase mean
that the requirements must be right the first time.
Fixing an incorrect or
incomplete requirement constitutes a disruption to the process.
A final variation on the life cycle is the spiral model.
The model is similar to the incremental model, with the exception that
there is a delivery to the customer following each verification phase.
The disadvantage Here is that the customer and
the users can see early on what form the software is taking.
Subsequent requirements phases leverage customer feedback and
this tends to yield a product more adapted to the users needs.
Additionally it allows the customers and users more time
to understand the impact of the software on their business processes.
In this manner, the customers and
the users don't have to try to imagine all of the requirements at once.
The learning that takes place from iteration to iteration
yields better quality requirements.
More recently, the concept of extreme programming, xp has surfaced
In XP, a number of conventional ideas are transformed.
For example, one of the tenets of XP is
that a customer is working with the developers on a daily basis.
This allows continual integration with the customer through the development process.
Second, XP is highly iterative While there are a few once-through planning steps,
most of the work is done in short cycles, suggested length of which is three weeks.
Third, XP is test driven development.
When new functionality is required, a test for that functionality is written.
The developer is done when the test and all of existing tests run.
Forth, each programming task is done by two people at the same time.
In pair programming one person is The tactician, the person with the keyboard,
the mouse, and the ideas on how to satisfy a particular test.
The other person is the strategist,
looking at what the tactician is doing but against a larger backdrop.
The strategist may see a better way to resolve a problem.
A way to unify several specific problem solution into a more general case.
The next P, a lot of design is done by refactoring.
Refactoring is reorganising and rewriting existing code so
that it is more efficient in the context of your code.
Although the XP model is quite different, the familiar ideas of requirements,
design are simply hidden, they're not absent.
Requirements are most clearly represented in terms of the tests.
There may be thousands of automated tests that are run
to verify the functionality of the software being developed.
XP wisdom is that, a feature without a test is not a feature.
In more familiar terms, if there's not a test, it's not a requirement.
Design is accomplished through refactoring.
To be sure,
there is a broad design concept in place when the project has begun, But an XP
design is not pre-determined rather it evolves over the course of developement.
Provision for
provision requirements exist as well they are often called stress tests.
The evolutionary prototyping life cycle model however
Gives a very short software to formal requirements.
In the evolutionary prototyping,
the prototype intentionally becomes the delivered software.
According to McCall, with evolutionary prototyping, you start by designing and
implementing the most prominent parts, the programming or prototype And
then adding to and refining the prototype until you're done.
The prototype becomes the software that you eventually release.
As the concept is simple, so is the diagram.
Requirements in this system would appear as bug reports.
A modification request for the prototype.
If there is a clear and
defined [INAUDIBLE] by which the prototype is evaluated and upgraded,
then a reasonable list of requirements is available at the end of the Process.
Under the title of dynamic systems development method,
evolutionary prototyping has been turned into a process
in which requirements are explicitly called out.
In a diagram here, the explanation of functional model iteration is Quote.
Selecting your requirements according to their priority in performing detailed
analysis and modeling of the selected requirements through prototyping, unquote.
The requirements are more apparent being referred to explicitly
than in the early version, showing on the previous figure.
Dynamic systems development method.
Let's take a look at agile software development.
Agile is an iterative process where each iteration
has common features such as requirements analysis, design and test.
This diagram shows these iterations as separate from one another.
A different way of looking at the cyclical Agile process has been proposed by
Allister in a, he was a noted writer and practitioner of Agile.
His representation is a set of nested cycles.
The outer level is the entire project.
It proceeds from beginning to end,
clockwise from the 12 o'clock position in the diagram.
The circle inside the project circle is the delivery cycle.
The idea is that multiple deliveries per project, and
that's one of the fundamental characteristics of agile.
Inside the delivery circle is the iteration circle,
so there can be multiple iterations per delivery.
The next circle is the day circle,
which means that an iteration is composed of a set of days,
during which A similar set of steps is followed.
Scrum practitioners are familiar with the morning standup, and
the subsequent activities throughout each day.
Inside the day circle is the integration circle.
Meaning that ideally, there are multiple integrations of the software per day.
Of course this implies a lot of animation.
And, most notable, inside the iteration circle is the design,
code and test process.
Far from the original notion of the waterfall design step that may take
months or years We have a design process that goes on from minute to minute,
hour to hour, and is probably unique to each developer.
In each of these models,
it's important to identify where the requirements are, how they're constructed.
The table shows Where the requirements
are located in software development life cycle models that we have discussed.
The important point to be made here is that simply that regardless of the life
cycle software developers must deal with requirements in some form.
Okay this was a long lesson.
We've talked about where design sits in various software development life cycles.
There are two major points to be made.
First is that design is present in every software development life cycle.
Second, as the software development life cycle becomes more adaptive
Design happen in shorter and shorter cycles.
In the next lesson we'll talk more specifically
about what happens in the design phase in these various life cycles.
Thank you.
