|
|
|
Identifying the model assumptions for how a
“Target of Evaluation” is generated. |
|
Understanding the gap between the model and the
reality. |
|
Tools that are ready to hand. |
|
|
|
|
|
|
Requirements |
|
Statement of the problem you are trying to solve |
|
Defines criteria for success |
|
Rigorous Model |
|
Idealized capture of intent |
|
Abstraction/simplification of real system
semantics |
|
Mathematically expressable |
|
Allows you to reason formally about the
architecture |
|
Architecture |
|
Model qualified by reality |
|
Usually not mathematically expressable |
|
Establishes definitive (normative) specification
of behavior [implementation is correct if matches architecture] |
|
May allow implementation-specific details (e.g.
performance) |
|
|
|
|
|
|
|
Implementation |
|
Embodiment of the design in the target
technology |
|
The part Christian Scheideler hates L |
|
Validation/QA |
|
Comparison of the implementation behavior
against the semantics of the architecture and the specifications of the
design |
|
Delivery |
|
The means by which the trusted software gets to
the customer |
|
Issues: man in the middle, integrity |
|
|
|
|
|
Acceptance Qualification |
|
Where the customer decides if it meets their
needs |
|
Output of assurance evaluation is generally
considered here |
|
Customers generally do an initially limited
deployment |
|
Deployment |
|
When the software first sees wide use within an
installation |
|
Flaws identified at/after this point are very
costly to fix |
|
|
|
|
|
It is a simple, easy to understand story about
how development occurs |
|
It describes how large, late-in-life projects
are actually managed at large companies |
|
It is well known that security cannot be
retrofitted |
|
We will focus in this course on new products. |
|
To understand real process for new software,
it’s necessary to understand realities of new product development |
|
So how well does this model hold up for new
projects? |
|
|
|
|
“…when weighing the competitive strengths of
Apple and IBM, we win in one key category: PRODUCT SUPERIORITY. It is out
preemptive Lisa Technology at a recognizable price/performance advantage
that will allow us to successfully compete with IBM for the next 18/24
months.” |
|
Macintosh Product Introduction Plan
October 7, 1983 |
|
“To maintain leadership in a mainstream
market, you must at least keep the pace with the competition. It is no
longer necessary to be the technology leader, nor is it necessary to have
the very best product.” |
|
Crossing the Chasm, p. 49
Geoffrey A.
Moore |
|
“Disruptive technologies bring to market a
very different value proposition than had been available previously… are
first commercialized in emerging or insignificant markets … by and large
[cannot be used by leading customers] … [and are] initially embraced by the
least profitable customers in a market.” |
|
“Ironically, in each of the instances
studied in this book it was disruptive technology that precipitated the
leading firms’ failure.” |
|
The Innovator’s Dilemma, p. xv |
|
Clayton M. Christensen |
|
|
|
|
|
Technology buys entry to a market, if it: |
|
Strikes from ambush (surprise) |
|
Attacks an unperceived/undefended position |
|
At lower cost |
|
But it doesn’t keep you there! |
|
Continued evolution, repackaging, and
repositioning are required for each new market segment |
|
Yesterday’s segment is tomorrow’s road kill |
|
Reputation takes a long time to catch up with
you |
|
Development Model != LifeCycle Model |
|
|
|
|
|
Understand “hit and run” marketing |
|
Are in a perpetual state of product transition |
|
Recognize that |
|
An acceptable product that is first to market always
beats a good product that gets there after the first product is entrenched |
|
Market share is an exponential process. You
don’t have to be very late to be too late. |
|
Market growth is about managing perceptions, not
realities. |
|
No time for long, linear processes! |
|
|
|
|
|
|
Assurance is raising the bar for what
constitutes “acceptable” software |
|
Software liability will create standards of
practice |
|
Component structure makes the process investment
reusable |
|
The per-component overhead is acceptable |
|
|
|
|
Build it, make it work, ship it |
|
Back-fill the support documents for maintainance |
|
Then enter the more conventional process cycle. |
|
|
|
|
|
The purpose of process is 4 things: |
|
To formalize communications in a large
development group |
|
To prevent mistakes |
|
To allow scheduling |
|
To provide checks and balances |
|
Must somehow achieve similar results in very
short timeframes |
|
The solution lies in the “large group” part… |
|
|
|
|
|
|
|
Large project Þ more developers Þ lower quality |
|
No hard figures on improvements from process,
but clearly not enough |
|
You really are better off with a “tiger team”
for a new effort |
|
This is demographics, not elitism |
|
For sustaining engineering, tiger teams aren’t
an option |
|
|
|
|
|
Goals of light process: |
|
Get the job done the first time |
|
Provide a sufficient trail to back-fill the
documentation |
|
The best way to reduce long-term maintenance
overhead is good initial architecture |
|
Bad code drives out good, but… |
|
Good architecture has an internal coherency that
is difficult to dislodge |
|
Adopt a process that preserves flexibility, as
architecture will evolve during development |
|
|
|
|
|
(Searchable) discussion lists, not a priori
design |
|
API docs – preferably extracted from code |
|
Architecture docs – need to specify normative
behaviors clearly |
|
Code browsers |
|
A decent CM system |
|
Tests right in the code tree |
|
Experience: the boundary between test and
development was always an impediment |
|