Chapter 4
The Old Way and the New
Overview
❑ Conventional software
engineering has numerous well established principles. Many are still valid,
others are obsolete.
❑A
modern software mgmt process will incorporate many conventional principles but
will also transition to some substantial new approaches.
The principles of conventional software
engineering
❑ Make quality number one
■
Quality must be quantified and mechanism put into place to motivate its
achievement.
❑ High quality software is possible
❑ Give products to customers
early
❑ Determine the problems before
writing the requirements
The
principles of conventional software engineering
❑ Evaluate design alternatives
❑ Use an appropriate process
model
❑ Use different languages for
different phases
❑ Minimize intellectual distance
❑ Put techniques before tools
❑ Get it right before you make
it faster
❑
Inspect code.
The principles of conventional software
engineering
❑
Good management is more important than good technology
❑
People are the key to success
❑ Follow with care
❑
Take responsibility
❑Understand the customer's
priorities
❑ The more they see, the more
they need
The principles of conventional software
engineering
❑ Design for change
❑ Design without documentation
is not design
❑
Use tools but be realistic
❑ Avoid tricks
❑Encapsulate
❑ Use coupling and cohesion
❑ Use the McCabe complexity
measure
❑Don't test your own software
❑ Analyze causes for errors
❑
Realize that software entropy increases
❑ People and time are not
interchangeable
❑ Expect excellence
The principles of modern software management
❑ Base the process on an
architecture first approach
§
Focus on critical use cases, architecture design
decisions, life cycle plans before committing resources, Address architecture
and plan together.
❑ Establish an iterative
life-cycle process
■Each
iteration should focus on a specific risk and move the requirement, the
architecture and the planning in balanced manner
❑ Transition design methods to
emphasize component-based development
■
Minimize human generated lines of Code. Use commercial componenets.
❑ Establish a change management
environment
§
Automate change mgmt process to deal with
changes introduced by iteration
Enhance
change freedom through tools that supports that support round-trip engineering
RE
is the environment support necessary to automate and synchronize engineering
information in different formats
❑
Capture design artifact in rigorous, model-based notation
■
A model based approached (UML) supports the evolution of semantically rich
graphical and textual notation
❑ Instrument the process for objective
quality control and progress assessment
■
Life Cycle assessment of the progress and the quality of intermediate products
must be integrated into the process.
❑ Use a demonstration-based
approach to assess intermediate artifacts.
■
Identify performance issue early and assess intermediate artifacts
❑ Plan intermediate releases in
groups of usage scenarios with evolving levels of details.
❑
Establish a configurable process that is economically scalable
■
Economy of scale and return on investment exploiting a common process spirit,
extensive automation and common architecture
patterns and components.
Iterative Process
❑ Conventional waterfall model -
each stage of the development process is dependent on the completion of the
previous stage.
❑
Modern approach requires that initial version of the system be rapidly
constructed early in the development process emphasizing the high risk area.
Iterative Process
❑ Development proceeds as a
series of iterations, building on the core architecture until the desired
levels of functionality, performance, and robustness are achieved.
❑It emphasizes whole system
rather than individual part.
❑ Reduce risk at the early phase
through continuous integration and refinement.
❑ Economics benefits are
significant but difficult to quantify.
Iterative Process Process
❑The process exponent parament
has much effect on economy of scale (1.0 - economy of scale).
❑ The parameters that effects
the value of process exponent are
❑ Application precedentedness
(iterative life cycle process, evolving level of details)
❑ Process flexibilty (change
mgmt, configurable process)
❑ Architecture risk resolution
(architecture first development, component based development)
❑ Team cohesion
(successful/cohesion team, model based formats enabled the round trip
engineering)
❑ Software process maturity
(truly mature processes are enabled through an integrated environment that
provides the appropriate level of automation to instrument the process for
objective quality control)
Chapter 6
Artifacts of the Process
Introduction
❑ Know that most
modern systems are composed of many components — some custom, some reused, some
commercial — and many of these may operate in a variety of dissimilar networks
on a variety of computing platforms with different operating systems.
❑ This
different sources of these components dictates
■ different
methods in creating artifacts and,
■ different
approaches to traceability.
Artifact
Development
❑ No longer
sequential, complete. (Very difficult — especially — for senior management to
buy into in some cases...
❑ Now, artifacts
are developed iteratively; evolve with development ... together;
■ Different
levels of abstractions ....
■ Artifacts
evolve together in balanced granularity
❑Exactly what the
evolutions are - are choices and affect how requirements, design, etc.
proceed...
❑ Activities
necessitate repeatedly upgrading and 'enriching' these artifacts as our
knowledge increases.
■ Models are continually refined,
improved, enhanced....
6.1
The Artifact Sets
❑ Artifacts are
organized into two sets
■
Management set
❑ Planning
artifacts and Operational artifacts
■
Engineering set — all have different qualities and representations
Requirements
set
Design
set
Implementation
set
Deployment
set.
A
set represents a complete aspect of the system.
An
artifact represents some cohesive information typically developed and reviewed
as a single entity
■
e.g. prototype, or Use Case model, design model
Management
Set
❑Mainly captured
in text perhaps some graphics.
❑These artifacts
are mainly designed to capture data associated with process planning and
execution.
❑ Text and graphics will include whatever
is necessary to capture the contracts among the project personnel, among
stakeholders, and between project personnel and stakeholders.
Specific
Artifacts in the Management Set
❑ WBS - Activity breakdown
and financial tracking mechanisms
❑ Business Case -
Cost, schedule, profit expectations
❑Release
Specifications - Scope, plan, objectives for release baselines
❑Software
Development Plan - Project process instance
❑Release
Descriptions - Results of release baselines
❑Status
Assessments - Periodic snapshots of project progress
❑Software Change
Orders- database descriptions of discrete baseline changes
❑Deployment documents-Cutover plan,
training course
❑ Environment
- Hardware and software tools, process automation, documentation, training, production
of engineering artifacts (documents, manuals, ...)
ALL
ARE VERY IMPORTANT IN THE MANAGEMENT SET!
Management
Set Artifacts.
❑ Evaluated,
assessed and measured primarily via
§ Reviews with
relevant stakeholder
§ Analysis of
changes between current version of artifact and previous versions
§ Milestone
demonstrations of the balance among the artifacts, and the accuracy of the
business case and vision artifacts (cost, schedule, profit expectations,
quality, progress...)
Engineering
Set
❑ Unlike the
Management Set,
■ where we evaluate via stakeholder review,
comparing current with previous versions, progress between artifacts (delivered
and planned),
❑ In the
Engineering Set, the primary mechanism for evaluating the evolving quality of
these artifact sets is in the transitioning of information from set to set
(requirements to design to ...) thereby maintaining a balance of understanding
among the artifacts in these sets.
❑Each of these
evolve over time!
Engineering
Set — Requirements Set
❑ Vision
Statement — Notation: normally text.
■ Documents project scope that supports the
contract between the funding authority and the project team.
❑ Supplementary
Specs — variety of formats
■Can come from regulatory agencies,
other prototypes indicating proof of concept.
❑ Requirements
models - Notation usually captured in UML
■ Use Case modeling and domain modeling;
activity diagrams.
❑ "-The
requirements set is the primary engineering context for evaluating the other
three engineering artifact sets and is the basis for test cases."
Engineering
Set — Requirements Set
❑ Evaluation,
Assessment, and Measurement? (main...)
■
Evaluate the consistency between vision and requirements models; (What are
requirements models?)
■
Mappings against the design, implementation, and deployment sets to evaluate
the consistency and completeness and semantic balance between the information
in different sets. ❑ Meaning?
Discuss...- ... level of granularity...
■
Analysis of change between current versions of requirements artifacts and
previous versions.
❑How much
scrap/rework are really needed?
■
Overall subjective review of other factors....(quality)
Engineering
Set — Design Set
❑ Notation: UML;
Tools used: visually modeling tools.
❑ Contains levels
of abstraction: components in the solution space.
■
Identities, static relationships, dynamic interactions
❑ Class diagrams,
interaction diagrams, state charts, relationships...
■
Can, in some cases, be automatically translated into a subset of the
implementation and deployment set artifacts.
❑ Design set
artifacts normally include: design model, test model, software architecture
description (part of design model).
❑ some authors:
preliminary design (architectural components; static relationships...) and
detail design (more detailed dynamic interactions)
Engineering
Set — Design Set
❑ Evaluation,
Assessment, and Measurement? (main...)
■
Analysis of internal consistency and design model quality
■
Analysis of consistency with the requirement model
■
Translation into implementation and deployment sets and notation to evaluate
the consistency and completeness and the semantic balance between information
set.
■
Analysis of change between current versions of requirements artifacts and
previous versions.
■
Overall subjective review of other factors....(quality)
Engineering
Set — Implementation Set
❑ Tools used
in Implementation: debuggers, compilers, code analyzers, test coverage
analysis tools, test management tools...
❑ Implementation
Set artifacts includes: source code (as implementation of components) their
form, interfaces, and dependencies) and executables necessary for stand-alone
testing of components.
■These
executables are the primitive parts needed to construct the end products
including custom components, APIs, other reusable or legacy components in some
programming languages.
❑ Implementation
sets are often packaged and form a, subset of the deployment set.
Engineering
Set — Implementation Set
❑ They are human
readable formats and are evaluated assessed, and measured via..
■
Analysis of consistency with design model
■
Assessment of components source or executable files against relevant evaluation
criteria through inspection, analysis, demonstration or testing
■
Translation into deployment sets notation to evaluate the consistency and
completeness and the semantic balance among artifact sets.
■
Analysis of change between current versions of requirements artifacts and
previous versions.
■
Overall subjective review of other factors....(quality)
Engineering
Set — Deployment Set
❑ Tools used in
setting things up for / getting ready for deployment: test coverage and test
automation tools; network management tools, commercial components (OS, GUI,
DBMSs, middleware, installation tools, etc.)
❑ Deployment set
artifacts normally include the deliverables and machine language notations,
executable software, build scripts, installation scripts, and executable target
specific data necessary to use the product in its target environment.
Engineering
Set — Deployment Set
Evaluated
measured and assessed through....
❑ Test the
partitioning, replication, and allocation strategies in mapping components of
the implementation set to physical resources of the deployment system (platform
type, number, network topology). (test the loading, configuring, building...)
Remember, you are often getting ready to send these thing out!
❑ Tested against
defined use scenarios in the user manual such as installation, user-oriented
dynamic reconfiguration, mainstream usage, and anomaly management.
❑ Analysis of
changes between current version and previous version of deployment set (if
appropriate).
❑ Subjective
review of other quality dimensions...
Comments
on Sets
❑Each artifact
set uses different notations appropriate to its focus.
■
Management Set uses text, graphics, Use Cases... to capture of plans, progress,
acceptance criteria, and other management docs.
■
Requirement notations (in Engineering
Set) uses (structured text and UML models) to capture engineering context and
the operational concept. (Structured English, Use Case Diagrams, Activity
Diagrams) (problem space artifacts, if you will...)
■
Design notations (use UML) capture
engineering blueprints (architectural design, component design). (class, Use
Case realization artifacts (sequence diagrams, collaboration diagrams, state
diagrams...) (solutions space)
Comments
on Sets
■
Implementation notations (software languages ...) capture building blocks in
solution space in human-readable form (source code, dll, exe., test scripts,
test plans, test data, results.
■
Deployment notations: (executable artifacts and data files) — capture solution
in machine-readable formats. What is sent to the customer or installed for the
customer....
Artifact
Set Focus:
❑ Requirement
sets — covered mainly in Inception
❑ Design artifact
sets — mainly in elaboration
❑ Implementation
sets — construction
❑ Deployment sets
— transition
❑But not EXCLUSIVELY
in these phases!!!
❑ Management —
fairly constant level across life cycle
❑ Software
development tools map closely to one of the five artifacts.
Implementation
Set versus Deployment Set Artifacts (1 of 3)
❑Several
similarities and significant differences!
❑ Generalizing:
Implementation set — source code; deployment set — executable code.
■ Sounds similar, but there are several
very different concerns associated with these... ❑ Remember, in Implementation, we are
coding (source code) and performing unit testing (and more...)
■ Almost all these activities are
included in Construction
• In Deployment, the organization of
'code' presented to the user and sometimes the test organization in customer's
shop is vastly different from the source code information characterizing the
implementation set.
Implementation
Set versus Deployment Set 2 of 3
❑ In the
deployment set, we are concerned with providing artifacts that support loading,
installation, configuration, testing, and operations. So, we are concerned
with: (directly from text — for
discussion...)
■
Dynamically reconfigurable parameters — Meaning?
❑ Buffer sizes,
color palettes, number of servers, number of simultaneous clients, data files,
run-time parameters...)
■
Effects of compile/link optimizations (space versus speed optimizations) —
Meaning?
■
Performance under certain allocation strategies —Meaning?
■
Centralized versus distributed; primary vs shadow threads, dynamic load
balancing, hot backup vs checkpoint/rollback
Implementation
Set versus Deployment Set 3 of 3
■
Virtual machine constraints (file descriptors, garbage collection, heap size,
speed of disks, ...)
■
Process-level concurrency issues (deadlock and race conditions)
❑ Know what
deadlock and races are? Meaning?
■
Platform specific differences in performance or behavior
❑ All kinds of
installation and configuration info must be passed into operational environment
either
■
Via implementation set (embedded in source code...) or
■
Via deployment set (embedded in data files, configuration files, installation
scripts, ...)
■ Example: try 'blocking factor....'
❑ Deployment of
commercial products to customers can span a broad range of test and deployment
configurations.
Artifact
Evolution over Life Cycle (1 of 2)
❑ Unlike the
conventional approach, phases (requirements, design, etc.) are NOT complete
before proceeding to next phase.
❑The entire
system evolves as the 'state of the system evolves into more elaborate states.'
❑With this, the
artifact sets evolve accordingly.
❑Each phase
(inception, elaboration, construction, transition) realizes some degree of
effort (more evolution) on all artifact sets plus the management set.
■Clearly,
some phases emphasize one artifact set over others...
Artifact
Evolution over Life Cycle (2 of 2)
❑ "During
the transition phase traceability between the requirements set and the
deployment set is extremely important.
■The
evolving requirements set captures a mature and precise representation of the
stakeholders' acceptance criteria
■
the deployment set represents the actual end-user product.
❑
"Therefore, during the transition phase, completeness and consistency
between these two sets are important.
❑
"Traceability among the other sets is necessary only to the extent that it
aids the engineering (development) or management activities."
Test Artifacts (1 of 2)
❑ In Conventional
development, a number of test documents were created.
■
Very difficult to keep them all consistent
■
Test documents for everything:
§
Unit
test, integrated testing, test plans, test procedures...
§
Different
formats; levels of granularity, ...
❑ In modern process, the same artifact
sets and notations that were used for product development for the test
activities are used.
Test
Artifacts (2 of 2)
❑ Testing
information is used in all development artifacts.
■
Test artifacts are developed concurrently with product from inception through
development.
❑ Testing is a
full life-cycle activity — NOT a late life-cycle activity as it used to be in
Conventional software development.
❑ Test artifacts
are included in same artifacts as the developed products.
❑ Test artifacts are thus documented in
the same way that the product is documented
❑ Developers of
the test artifacts use the same tools, techniques, and training as the software
engineers developing the product.
Management Artifacts
❑ Many artifacts
that document the product, the process, improvement actions, and management of
the process in general.
❑
"Document" does not necessarily mean 'paper,' as so much nowadays is
done via electronic means.
❑You need to be
aware of some of these basic concepts/emphases of management artifacts that
follow, as they leave an audit trail of our efforts.
Management
Artifacts: Work Breakdown Structure (WBS)
❑ WBS is a VERY
commonly used 'document'
❑ Absolutely
essential for Management!!
❑ Essential for
tracking expenses throughout development — all phases and activities. ❑Basically it
focuses on budgeting, monitoring, and controlling project costs.
■How
resources are expended for activities undertaken
■
Trends and projections....
■
Checked at end of minor milestones (iterations) and definitely at major
milestones (phase completions)
Management
Artifacts: Business Case
❑ Essential!
Provides info to decide whether or not project is worth investing in. Pure
Economics!
■
Includes expected costs, expected revenues, technical and management plans,
consideration of risk, expected ROI, etc.
■
Effects of NOT investing in project, etc.
■
Normally accommodated in text; graphics....
❑ Purpose:
transform Vision document into economic terms.
❑ A Global View
of the Vision document is that it contains the requirements... (functional and
non-functional) Customer views / expectations of the delivered, operational
system. Management Artifacts: Release Specifications
❑ Documentation
(plan,scope,obj.)accompanying every release.
❑ Derived from
Vision statement, development, and testing.
❑ Artifacts
constituting the Release Specs evolve and achieve finer granularity as
development proceeds. Not written up at the 'end!!'
❑ Two kinds of
requirements info addressed in Release specifications:
■
Vision Statement — evolutionary... High level requirements modeled here...
❑ Recall: Vision
statement serves as Contract between developers and customer
❑ Vision usually
contains the Use Case Model and Use Case Descriptions to capture operational
concept.
Management
Artifacts: Release Specifications
■ Evaluation criteria — details (often lower
level) on how to evaluate...
❑ Snapshots of
objectives for a milestone achieved
❑ How do we know
/ demonstrate that we achieved the objectives of the iteration??
❑ Evaluation
Criteria are defined as "Management Artifacts" vice Requirements Set.
❑ Evaluation
Criteria are organized 'by iteration,'
❑ Each iteration's evaluation criteria
may be discarded, once the milestone is complete.
❑ Address high
risk early and core functionalities...
■
Represented by use cases realization, annotations on use cases, structured text
representation
Management
Artifacts: Software Development Plan (SDP)
❑ SDPs address
development process in fine detail.
■
Sometimes called DPP, DPD, etc.
❑ Discusses
required artifacts, who will do what, quality checkpoints, the development
environment, configuration control board planning and procedures; change
management, base-lining, assessment, risk and status assessment, standards to
be adhered to, etc.
❑ Covers whole
spectrum of development activity.
❑ Elaborates the
process framework
Management
Artifacts: Release Descriptions
❑ Release
Descriptions document the contents of each release including performance
against each of the evaluation criteria in the corresponding Release Spec.
❑ Release
Descriptions have a Release Baseline that assert that the objectives of a
release have been addressed and verified via:
■
Demonstration,
■
testing,
■
inspection, or
■
analysis
Management
Artifacts: Status Assessments
❑ Essential for
good project management
❑ Snapshots of
project health and status via
■
Risk assessment
■
Quality indicators
■
Management indicators....what do you think?
■
Project proceeding according to expectations?
■ "periodic heartbeat" of project.
❑ A 'How Goes
It?" or "Weekly Activity Report"...
■
Resource review, financial review, technical progress, action items and follow
through....
■
Always done at end of minor and major milestones — and any other time
management wishes, really..:
Management
Artifacts: Software Change Order Database
❑ Managing
changes is fundamental in iteration
❑ Essential!
❑ Change
flexibility helps in productive iteration
❑Now we have
automation to assist in change management / control
❑ No more manual
management/control!
■ System Change Proposals (SCPs)
...paper!!!
❑ Have database to control, track, and
manage change records (dates, priorities, ...)— on line!
❑ Reduces bureaucracy and supports
metrics collection and reporting!!!
Management Artifacts: Deployment
❑ For Large Contracts
■ Software may be delivered to a
separate maintenance group; deployment artifacts include operation manuals,
software installation manuals, plans and process for cutover
❑ For Small Contract; smaller
corporation...
■ Much Much less.
■Often same group of people do ALL!
❑For commercial s/w products
■ Marketing plan, sales rollout kits,
training courses
❑ Varies considerably from project to
project.
Management Artifacts: Environment
❑Any first class development shop must
have a robust, integrated suite of development tools to support the automation
of the development process.
❑ Suite must include tools for:
■ Requirements management,
■ Visual modeling,
■ Documentation automation,
■ Host/target programming tools,
■ Testing,
■ Integrated change management,
■ Defect tracking...
Management Artifacts: Recognize
❑ Different
activities generate different artifacts as part of minor milestones (ends of
iterations) and major milestones (ends of phases).
❑ Different
artifacts are updated at different times and with different degrees of detail.
Engineering Artifacts
❑Three main
documents (there are others...)
❑ 1. Vision Document
❑ 2. Architecture
Description
❑ 3. User Manual
Engineering
Artifacts
Vision
Document
❑ Complete vision
for the software system under development and supports the contract between
funding authority and development organization.
❑Can vary
immensely in size.
❑Meant to be
changeable as understanding evolves - but should be slow...
❑ The vision
document is written from the user's perspective, focusing on the essential
features of the system and acceptable levels of quality.
Engineering
Artifacts
Vision…………….
❑ Contains
❑ Use Cases and
descriptions.
■
Risks inherent in the use case development and realization
■
Operational capacities (volumes, response times, ...)
■Interoperational
interfaces with entities outside the system boundary.
❑Should contain
two appendices
■
Operational Concept using use cases and
■ Risks inherent in the vision statement
Engineering
Artifacts
Architecture
Description
❑ Organized view
of the software architecture under development
❑ Extracted from
design level models and includes views of design, implementation, and
deployment sets describing the way to achieve req. operational
❑ Breadth will
vary from project to project.
❑Usually
described using a subset of the design model or as an abstraction of the design
model with supplementary material or combination of both...
❑ Evolves just as
any other artifact.
Engineering Artifacts
User
Manual
❑ Reference
document
❑ Content varies
across application domains.
❑ Must contain:
■
Installation procedures - how to install software; how to convert...
■
Usage procedures and guidance - How to use application
■
Operational constraints
■
User Interface description - at a minimum.
Engineering
Artifacts User Manual....
❑Should be
written by members of the team.
❑ Can be written
in parallel with development and evolve...
❑ Provides the
basis for -3 test plans and test cases!
❑ Ties back in
with Vision Document (use cases) and prototype
Pragmatic
Artifacts
❑Many years of
many many documents!!!!
❑Have often been
impediments to progress...
The
quality of the documents had become more important than engineering information
content.
❑ Very lengthy
and very detailed documents were perceived to indicate to progress and resulted
in premature engineering details and increased scrap and rework later...
■In
many cases level of detail did not reflect current understanding or decisions
were made too early and rendered some information obsolete prior to the
delivery of the application!
Pragmatic
Artifacts
❑ Now - encourage on-line review of
information by using smart browsing and navigation tools.
❑Eliminates huge,
unproductive sources of scrap later on.
❑ Provides for
continuous review, not periodic review....
Cultural
Issues:
1.
People want to review info but don't understand the language of the artifact
..."provide a separate
document/description?"
-Adds
considerable time and cost w/o value
Pragmatic Artifacts
Cultural
Issues....
❑ 2. People want to review the info but
don't have access to the tools.
■
Forced to produce paper?
■
Visualization tools, Web, and more are making artifacts readily accessible.
❑ 3.
Human-readable engineering artifacts should use rigorous notations that are
complete, consistence and used in a self-documenting manner.
■
Good grammar; reading levels; professional editors.
■
Avoid encrypting and abbreviations in documents and code.
■
Make code-self documenting
▪
Software is written once; Add and changed many times
Emphasize
readability and proper grammar!
Pragmatic
Artifacts
Cultural
Issues.....
❑ 4. Useful documentation is
self-defining. It is documentation that gets used.
§ Good
documentation provides an engineer the opportunity to work alone!!!
§ Use notations
that everyone uses and needs!
§ Strive to be
produce self-documenting artifacts!!
§ ■ 'Documents'
can stand alone.
Pragmatic
Artifacts
Cultural
Issues....
❑ 5. 'Paper is
tangible; artifacts are too easy to change.' True, but...
■
Comment lament by some stakeholders.
■
Skeptical due to volatility of on-line documentation.
■The
whole world will eventually adopt this philosophy!
No comments:
Post a Comment