HelloChapter6fgfg-Artifacts__of_theProcess.ppt

1
Chapter 6
Artifacts of the Process
Materials taken directly from Walker
Royce’s textbook.

2
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 plateforms with
different operating systems.
 This different sources of these components
dictates
 different methods in creating artifacts and,
 different approaches to traceability.

3
Artifact Development
 No longer sequential, complete. (Very difficult –
especially – for senior mgmt 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….

4
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

5
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.

6
Specific Artifacts in the
Management Set
 Work Breakdown Structure - 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 - 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!

7
Specific Artifacts in the
Management Set
 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…)

8
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!

9
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.” (p.86)

10
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….

11
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.
(Discuss)
 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 )

12
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.

13
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.

14
Engineering Set – Deployment Set
 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…

15
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)
 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….

16
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!!!
 Requirements receive a lot of treatment in Elaboration;
Some Design precedes and follows Elaboration; What?
Some Implementation will take place in Transition; What?
and Some preparation for Deployment sets will take place
during Construction. What? Do you understand what?
Good, and important questions. Study these.

17
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.

18
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
 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

19
3 of 3
 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.

20
Artifact Evolution over Life Cycle
1 of 2
 Unlike the conventional approach, phases (requirements,
design, etc.) are NOT complete before proceeding to
next phase.  (Cite NFRUG’s meeting discussion.)
 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…

21
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, and (what does this sentence MEAN to you?)
 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.” p. 93

22
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 our process, we use the same artifact sets
and notations that were used for product
development for the test activities

23
Test Artifacts (2 of 2)
  We include testing information 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.

24
6.2 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
(discussed ahead).
 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.

25
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)

26
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.

27
Release Specifications
 Documentation 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. (SRS)
 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,’
  Need to be demonstrated…..
  Traceability is essential
 Each iteration’s evaluation criteria may be discarded, once the milestone is complete.
 Address high risk early and core functionalities…

28
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.

29
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

30
Status Assessments
  Essential for good project management
  Snapshots of project health
 Risk assessment
 Quality indicators
 Management indicators….what do you think?
 Project proceeding according to expectations?
 “periodic heartbeat” of project.
 A ‘HowGoesIt?” 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…

31
Software Change Order Database
 Essential!
 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!!!

32
Deployment
 For Large Contracts
 Software may be delivered to a separate maintenance
group; artifacts include operation manuals, software
installation manuals, conversion plans, … for cutover.
 For Small Contract; smaller corporation…
 Much MUCH less.
 Often same group of people do ALL!
 Varies considerably from project to project.

33
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…

34
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.
  See figure on page 102.

35
Engineering Artifacts
 Three main documents (there are others…)
 1. Vision Document
 2. Architecture Description
 3. User Manual

36
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 the system is to provide and
acceptable levels of quality.
 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

37
Architecture Description
 Organized view of the software architecture under development
 Extracted from design level models and includes views of
design, implementation, and deployment sets
 (Think 4+1 architectural view…);
 Levels of granularity from design artifacts and their contents to
architectural layers.
 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.

38
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.
 Should be written by members of the team.
 Can be written in parallel with development and evolve…
 Provides the basis for  test plans and test cases!
 Ties back in with Vision Document (use cases) and prototype

39
Pragmatic Artifacts
 Many years of many many documents!!!!
 Have often been impediments to progress…
 The quality of the documents had become more important than
information content.
 Very lengthy and very detailed documents were perceived to
indicate 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!
 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….

40
Pragmatic Artifacts
 Cultural Issues:
 1. People want to review info but don’t understand
the language of the artifact
 …”provide a separate document/description?” No!
 Adds considerable time and cost w/o value
 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.

41
Pragmatic Artifacts
 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; read and changed many times
 Emphasize readability and proper grammar!
 Anything else is … uncivilized!

42
Pragmatic Artifacts
 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.

43
Pragmatic Artifacts
 ‘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!
 Most tools and environments will be developed to
support change management, audit trails, electronic
signatures, and other advances so that electronic
interchange replaces paper!
 This is the 21st century!

HelloChapter6fgfg-Artifacts__of_theProcess.ppt

More Related Content

Similar to HelloChapter6fgfg-Artifacts__of_theProcess.ppt (20)

Recently uploaded (20)

HelloChapter6fgfg-Artifacts__of_theProcess.ppt