Lecture 4

CS 473 EX
March 5, 2016

Learning Objectives
Upon successful completion of this course, you will be prepared to:

Justify, implement and manage a global product development

Solicit, define and scope requirements as part of the product backlog grooming.
Play an effective role of a Software Engineering Manager in a context of IEEE CSDP
(Certified Software Development Practitioner) with a specific emphasis on organizational
policies as guiding principles.
Select an estimation method that is appropriate for a specific phase of a product life
cycle. Oversee adoption of a consistent methodology to narrow the Cone of Uncertainty.
Support the Scrum delivery framework; become aware of several agile certification paths.
Play a role in a peer review, request and provide constructive and concise comments.
Evaluate software development tools (approved, allowed, restricted), while following the
Magic Quadrant technique. Maintain a logical relationship between tools and processes to
optimize their variety throughout an organization.
Articulate the strategy for system and unit test leading to continuous integration and
delivery.
Structure a project asset library aiming at a single-click navigation to a requested artifact.
Provide leadership to a process program using SEI CMMI as an improvement model.

Engineering
Management

UML

Git

ISO

Test Essentials
Faults & Failures

Cost Of Delay
Black Swan

Requirements

Pivotal
Version
One
Rally

Backlog Grooming

5/20 Rule

Story Points

Architecture

Asset Library

Motivation

Peer Reviews

Defect Density &

Examination Rate

Estimation

Low Coupling and High Cohesion

Quality
Center

Continuous
Delivery

SW Tools
Evaluation

Agile Manifesto

Scrum

CMM

Regression

Cone Of Uncertainty

Software Process
Configuration
Management

MVC

Mocks & Stubs

Unit Test
Process Improvement

MET
CS473
Principles
Process has no goal in itself

Process
Improvement

Process
A Glue. A Heart bit. A Librarian. Architecture

Data-driven design

Test
Essentials

Mocks are not Stubs

Unit
Test

Deployment pipeline

Continuous
Delivery

Low coupling and high cohesion

Scale optimization

Globalization
Offshoring
Taxonomy

Do not offshore if unable to monetize

Requirements
Backlog
Grooming

If its not on a backlog it does not exist

Engineering
Management

Myth of organizational hierarchy

Software
Configuration
Management

2
4

Estimation

Identification , Control,
Auditing, Reporting
Precision equal to accuracy

Software
Design

Agile

SW Tools
Evaluation

Peer
Reviews

Wisdom of vertical slices

It is cheaper to find defects early

MET
CS473
Responsibilities
Find the shortest path
Separate released from drafts

Select best tests

Unit
Test

Merge each commit

Continuous
Delivery

Requirements
Backlog
Grooming

Process
Improvement

Engineering
Management

Process
Architecture

Test
Essentials

Fail, Pass, Refactor

Globalization
Offshoring
Taxonomy

2
4

Maintain requirements in canonical form

Manage flow of features
Focus your team

Software
Configuration
Management

Document Project Taxonomy

Estimation

Control changes
Retain historical estimates

Fit components into architecture

Software
Design

Agile

Facilitate convergence of tools

SW Tools
Evaluation

Peer
Reviews

Split
Ask for and provide comments

Selected Elements Of Software Design

Selected Elements Of Software Design

The purpose of this section is to cover selected elements of software design. In a product life
cycle, this is the next logical step from requirements analysis toward coding. High-level design
often referred as "software architecture". Low-level design becomes sufficient for a software
engineer to develop code without any additional documentation.
After completion of this section you should be able to do the following,
become aware of the goals of software design
be able to position software design within a product life cycle
use UML basics to design a system
leverage previous experiences of UI design

Taxonomy

low coupling and high cohesion

state transition diagram
UML
wireframes

Goals Of Software Design

Following list is quoted from Eric Braude,

Sufficiency: handles all requirements

Understandability: can be understood by intended audience

Modularity: divided into well-defined parts

Cohesion: organized so like-minded elements are grouped together

Coupling: organized to minimize dependence between elements

Robustness: can deal with wide variety of input

Flexibility: can be readily modified to handle changes in requirements

Reusability: can use parts of the design and implementation in other applications

Information hiding: module internals are hidden from others

Efficiency: executes within acceptable time and space limits

Reliability: executes with acceptable failure rate

Low Coupling and High Cohesion

Here are several examples to illuminate the key concept of Low Coupling and High Cohesion.
Example. A Building.
Suppose you are an architect requested to construct a building of five apartments with a
single thermostat in a basement. The first floor is occupied by an elderly gentleman who
always feels chilly and needs to raise the temperature. The fifth floor is taken by a pregnant
woman who frequently opens a window so not to feel hot. How do you reconcile these two
requirements? Apparently, there is a problem as both apartments are tied together and
dependent on each other. This clearly violates the design principle called "low coupling".
According to this principle, software components should be able to run independently and
not to hinder each other's operation.
Continuing with this metaphor, each apartment has a bedroom and a living room. The key
function of a bedroom is to provide a quiet place to sleep. The key function of a living room is
its ability to watch television. Now imagine the third floor occupied by a wife and a husband,
where they placed a television right into the bedroom. This would clearly violate the "high
cohesion" principle, as the wife watching the television prevents the husband from sleeping.
The component called "bedroom" started performing both functions, instead of performing a
single function only. And the component called "living room" has abandoned its predefined
functionality all together.

Example. Four Databases.

In real-life software architecture, there are
hundreds of components interacting toward a
common product/service goal. Consider several
databases depicted below,
a) defect tracking,
b) requirements,
c) test cases, and
d) project tracking.

Requirements
(b)

Traceability
Matrix

Test Cases
(c)

Project
Tracking (d)

Following are several architectural considerations,

Suppose we create a traceability report describing what
requirements are covered by which test cases. We need to
Defects
Time Trend
query (b) and (c) to generate such a report. The next month, we
Def ects (a)
need to re-generate the traceability matrix for the new release.
Where would the attributes of the new release come from?
These are sourced from (d) Project Tracking database. Imagine
that folks supporting (b) Requirements database maintain a
duplicate data and record the release information also. This
would be a clear violation of the "high cohesion" principle.
Regular reports about defects found in the field are expected to trace back to those test cases that should have been
catching these defects. Such reporting imposes an important association between both components, so the integrity of one
component is verified by the other component. Since the risk of losing integrity for both components at the same time is
smaller than the risk of losing integrity of one component.
Time trends are very common in the industry. For example, one could expect a downward trend of defect data. This adds
an elaborate requirement to all relevant databases, namely to be able to re-generate a report "as of a certain snapshot of
time". It is a common policy to restrict any valuable information to be maintained outside of a predefined repository. To
this end, it would be a violation to maintain a snapshot of time bug trend in a repository that is different from the bug
database itself. One might consider this restriction as an extension of a "high cohesion" principle.

Example. A discussion on coding lessons.

(Mary) As a developer, I can speak first-hand about the importance of loose coupling. The system I inherited when I started
working at my current company centered around one large program. This was a Micro Focus COBOL application, so the idea of
classes does not apply, but the concepts are the same. For those unaware, COBOL is a procedural language as opposed to objectoriented and Micro Focus is a company that allow for open-systems (non-mainframe) development of COBOL applications. Generally
speaking, there would be an executable program (*.exe) that would call various subprograms (*.dll). This is the same architecture
used in many programming languages.
So, we had a main driver program (exe) that called a dll that performed most of the logic for the entire system. That program was
called zwimage.dll. Zwimage contained logic for almost every feature in our system. If I needed to change our faxing functionality
and another developer needed to alter our printing functionality, we would both need to change zwimage. Lets say that I made a
coding error (very unlikely, I know!) while changing the faxing logic. That error may be found by users invoking a totally different
feature. It made testing efforts long and painful, implementations difficult, and debugging very time consuming. The system was
very tightly coupled.
We underwent a project many years ago to decouple zwimage. It was a tough sale to the business since there was no direct business
benefit to this project. It was approved based on the promise that it would make development faster and cleaner in the future. Of
course, it certainly did. Now, we have a faxing dll, a printing dll, an email dll, etc. Each feature and function of our system is
encapsulated within its own dll. Now, development truly is faster, more efficient and less error prone. Testing is easier for our users
and troubleshooting it generally pretty straight forward.
(John) You bring up classic example of coupled software developed earlier with tools like COBOL; we had similar experience with
one of the software product. It is always hard to sell software improvements to business, especially, if it does not add new feature
(Peter) You make a great point about sharing code across multiple teams and reuse in code.
There is a principle in software development called DRY (Don't Repeat Yourself), which when you think about it is amazingly obvious.
Basically it says (and this works better for OOP than older procedural coding styles) if you have code, logic, etc. that can be
centralized and reused, you should try to if at all possible. The value in this is not overly evident at first glance but put into the
perspective of your company's XML reader makes it easy to see.
If you've never read The Pragmatic Programmer (http://en.wikipedia.org/wiki/The_Pragmatic_Programmer), the book coining this
term, it's a great quick read.

Elements of UXD (User Experience Design)

Following principles of an effective UI design could be very helpful in your term project,
Elements of UI are logically positioned on each screen in support of the common stepby-step operation.
Documenting operational steps (personas, use cases) is done first. Final UI design
comes later.
User experience is streamlined to become most intuitive and simple.
Iterative design is an effective way to implement UI, as user input proved to be
invaluable all the way through the process, not just in the beginning.
UI patterns are applied to perform similar operations. UI elements are grouped into
logical affinities supporting similar scenarios.
Color schema, sizes and shapes serve the same coherent purpose of creating the most
effective user experience
The goal of a single click navigation is preserved (scrolling of multiple pages is avoided).
Wireframes are designed, reviewed and tested prior to integrating UI into the final
product. UX Engineer facilitates the integration of mockups arriving from various
sources, e.g. new features, customer opportunities, architectural changes.
There are number of tools available to do wireframes, e.g. UXPin, BalsamIQ. Several
tools support the toggling between REST API and mockup.

Here are several examples of students' submissions of previous semesters. It has been
agreed to re-use these examples to enhance the learning of future classes. These
examples are initial attempts of UI design. Corresponding comments are offered. Several
examples are done by students who are professional developers currently working in the
industry.

Looking at the UI,

attempt to determine
the background of a
person who designed it.

(1) Fields are misaligned.

(2) Positioning of UI elements should be thought through and justified.

(3) An unusual color schema will be most certainly unloved by many users.
During review, the author was asked as to why he picked this color?
His response was Which color?
Apparently he did not pay any attention to the color.

(4) A professionally-done screen with perfect alignment. A somewhat boring view

done by UxD engineer, who could have add a spark to it.

(5) A nicely coded screen with lots of practical ideas.

Needs some additional alignment and affinities.
The person who designed this UI is the professional developer but not UxD.

(6) Fields are not grouped into logical affinities and look randomly dropped on a screen
that is too large for its own purpose. UI is done by a novice software developer not
UxD. Another student looking at it made a comment this UI gives me a headache, as I
am trying to follow its logic and I could not find one.

(7) The advantage of using a standard framework is apparent.

(8) Everything is perfectly aligned. My vote is to use a standard framework.

User-Centered Design
The design is based upon an explicit understanding
of users, tasks and environments. Users are
involved throughout design and development. The
design is driven and refined by user-centered
evaluation. The process is iterative. (Wikipedia)
Jesse James Garretts The Elements of User Experience: User-Centered
Design for the Web and Beyond (2nd Edition)

Wireframes a great way to start a development project

www.usability.gov includes wealth of information

most expressive UCD examples
blackboard UI example
the save button is missing and
comments are missing along with it

Is it clear why do we
a)

create wireframes before jumping into UI design.

Because it is more effective to review and receive feedback on basic
functionality and user steps - before all UI details are pinned down

b) Involve a user every step of the way

Because a user cannot phantom a UI unless he/she has a chance to play with it
c)

Provide explanations to wireframes

Since, as any incomplete product, it could easily be misinterpreted

UML (Unified Modeling Language) Diagrams

The names of "three amigos", Booch, Jacobson and Rumbaugh associated with a wide
adoption of UML and OOD (Object Oriented Design). In 2003, their company "Rational"
was sold to IBM for $2.1B.

The good news that UML is a well-controlled entity. Its latest version number is 2.5.
Here is a link to a great educational site elaborating on UML.
http://www.uml-diagrams.org/class-diagrams-overview.html
There are two types of a diagram,
Behavior (Dynamic: use cases, state transitions, sequence)
Structure (Static: class, object, component)

Transition from a Screen Mockup to a Use case is shown below.

The book by Doug Rosenberg, titled "Use Case driven Object Modeling with UML" has the
following pictorial as a thread. Each diagram on the pictorial is described in great length in a
corresponding chapter. The transition from Dynamic to Static modeling does advance the
process from "What" to "How". A development project starts with GUI Prototype, not as we
do in our course starting with Definition of Personas.

The following pictorial explores the iterative nature of "from What to How", as this order
is preserved at each stage of product evolution.

Users Needs

System
Requirements
System
Design
Software
Requirements
Software
Design

State Transition Diagram

Diagram below shows an example of an OnlineShopper class, from Eric Braude. Note
that the transition from one state to another is accompanied by relevant conditions and
actions.

Example below from Eric Braude Chapter 20 - highlights several common "defects" within a
state transition diagram. For example, condition "player ready to proceed" is not specific
enough, as it does not respond to a question ... what needs to be accomplished in order to
advance from Engaging state into Waiting state.

Creation of a state transition diagram usually precedes the documentation of fields and
reports. It is common that the initial diagram is far too complicated to be supported within
a given timeframe and has to be trimmed down. A common defect reported during a peer
review of a state transition diagram is that there are no fields to support a given state or a
given condition. Note that example below has states "Unassigned" and "Unclear Test" that
appear redundant.

Use Cases

Use case diagramming is a great method for capturing relevant scenarios and defining the
system boundaries. Those use cases and actors that are outside of the defined rectangular
are not a part of the current release. It demonstrates that a project is well-controlled, since
the next release is defined, not just the current release.
There is no one-to-one mapping between use cases and requirements. They create two
different angles; both of these angles are important.
Test cases must cover all requirements and key points of use cases
There could be many effective test cases that do not have a corresponding directlytraceable requirement
Actors could be human and non-human
Auditor

Audit

Instead of focusing on individuals, the

notion of an actor could be expanded into
an archetype, which is similar to the
concept of market segmentation.
As product transitions within the same
organization from one department to the
next. Those who are on receiving end are
often called users.
Use cases do not need to be completely
exhaustive. There is a line to be drawn in
sand ... to stop the requirements and stop
design and advance into construction. At
some point, it is counterproductive to
continue polishing requirements.

Use Case
Detailed
Template

Figure 12.9 of Eric Braude shows five different ways to organize requirements

Several Standard Notations

Components Diagram
As you have a Component Diagram as one of your in-process deliverables, it is important
not to over-engineer it and not to make it too complicated. Visio or Power Point are
perfect. Each box is a component. A brief two-line description as to what each component
does.
For a peer review system, a Database could be a perfect component, where you keep
snippets along with comments. UI - as another components with all drop downs and radio
buttons. You should have a Controller component with business rules.
In an ideal world, you assign to each team member - a separate component. In any case,
each team member is expected to have a piece of code to his/her name.
Here is the link to UML definition site, specifically to the page with Components. Although
the diagrams there are complicated and there is no need to replicate their exact notations.

MVC (Model, View, Controller)

MVC (Model, View, Controller) is a common architectural pattern creating

affinities of components, and separating ... a) business logic from b) application
data and from c) user presentations. This pattern fits nicely and expands the
notion of low coupling and high cohesion.
Here is an MVC example from CMS system constructed during a term project.

MVC is the very first pattern described

in the classic book by the Gang Of Four
with introduction of Grady Booch.

How to Beat
Black Swans?

Here is the slide published at

the MASS EEPAS
(Environmental Agency) site.
The message is clear - avoid
protracted projects.
Probability of a black swan
for a long project is much
higher than for a large
project. (41% VS 13%) .
Here is the MASS state site facilitating various bids. It has some useful attachments. The last slide of Appendix 4
is referenced above.
Here is an interpretation of these stats. Suppose you have two groups of a hundred projects in each group. The
first group of most expensive projects has 13 projects going black swans. The second group of the longest
projects has 41 of them going black swans. It is understood that some projects do belong to both groups.
Question is, why the "TIME" makes such a big difference? This is because the whole industry, tools and
methodologies are changing rapidly. People are being reassigned. This makes it very difficult for a prolonged
failed project to recover.

If we examine a component diagram. Question remains ... how to decompose a whole

product into several meaningful releases, so that each release is fully appreciated by a
user community?
Modularity is the inherent attribute of systematic product architecture. This is contrary
to the spaghetti code that is difficult to decipher.
It is a clear task belonging to both, a) product architect and b) process architect - to
facilitate the incremental delivery.
Here is the picture of black swan farming in Melbourne
During the Software Engineering class, one
student by the name Michele commented
that comparing Long projects with
Expensive projects is like juxtaposing Apples
with Oranges. I like his comment. It relates
to the empirical study that is being
discussed. Still, I believe the study is not
only valuable but it feeds well into the
same consistent message of our course.
"Split, Split, Split".
Cost Of Delay Divided by Duration ... great
example
http://blackswanfarming.com/cost-ofdelay-divided-by-duration/

Common Tools Supporting Common Process

Common Tools Supporting Common Processes

The purpose of this section is to describe how tools are managed throughout an
enterprise. Since tools play a huge role in software development, it is important to
assure that the common process is in fact well-supported by various tools. The
systematic adoption of tools shall be a planned activity that is explicitly endorsed by
management.
After completion of this section you should be able to do the following,
Identify the need and promote within your organization a centralized function that
manages tools
Build an interrelationship diagram
Resolve overlapping conflicts among tools
Maintain an asset management repository where each tool's version is tagged as
"recommended" or "restricted"

Taxonomy
System Interconnectivity Diagram
Application Registry

What Comes First? a tool or a process ?

I was looking for a picture of a chicken and egg.... In this two-step hierarchy, I would
make the "process" driving the "tool" and not the other way around. Consider two
departments, the first one is responsible for systematic improvement of process
maturity, and the second one responsible for tools support. I would start worrying if the
lead of the first group is reporting to the lead of the second group. Such an inverse
arrangement usually results in an abundance of bells and whistles of a great number of
tools that are hardly ever used.
I observed some folks do not distinguish a process from a tool. Although such a
distinction is crucial in establishing a well-focused action plan.
A requirements management process (documented in a Visio diagram) is quite distinct
from a corresponding tool (maintaining requirements in Doors).
A project management process (documented in Power point slides) is quite distinct
from a tool that maintains project plans (in Microsoft Project).

System Interconnectivity Diagram

An Enterprise Architect maintains a System Interconnectivity Diagram, see example
below. Key tools are positioned in a logical manner. The data that is exchanged
between various tools is clearly defined. There is a Current State and a Future State.
The diagram does not display those tools that are not approved and bear the
"restricted" status.
There is a repository with Common Project Info. It provides data to many other
repositories, e.g. to Defect Tracking, Requirements Management, Test Case
Management. Without a consistent names of projects, their phases and current states
- it is impossible to produce a coherent summary report.
Both, Test Cases Repository and Requirements Management Repository do exchange
information regularly. This enables the traceability reports. For example, the basic test
coverage report assuring that each requirement is covered by at least a single test
case.

Generalized Model (IBM example)

of an Interconnectivity Diagram

https://insights.sei.cmu.edu/sei_blog/2014/06/a-generalized-model-for-automated-devops.html

Tools Development
Development of tools should be treated as a well-managed activity, with all traditional
attributes of a development project. It should report its progress in the same manner as
other development projects. The goal of this project is to provide required connectivity
between tools. See example
diagram.
The evolution of Clear Quest
is tracked as it is connected
with other entities. For
example QTP logs defects
automatically into the Clear
Quest.

Technology Adoption Reports

An adoption report reflects on the degree of acceptance, a percentage of an organization
that is successfully using a tool.
Chart below shows the adoption of BPT (Business Process Testing). The upward trend
demonstrates the increasing adoption over time of various attributes of BPT.

Tools Tracking
The purpose of this enterprise repository is to facilitate convergence on a limited number of
tools used throughout the organization, so to take advantage of the economy of scale.
A version of each tool is tracked along with its corresponding features. Each version is labeled
with three possible tags,
recommended
restricted
non-restricted
For example, Microsoft Project on this diagram is "non-restricted" from supporting the
Program Management process. Although, Rally is the tool of choice that is "recommended"
for this process.
Looking at the diagram, among five tools that could possibly be used for Code Control, only a
single tool (AccuRev) is "recommended". Apparently, some parts of an organization, are using
the legacy versions of the other four tools. The step-by-step transition toward the single code
control tool is in the works.
There are four tools that are used throughout an organization for peer reviews. Only one of
them is "recommended". Maintaining comments from peer reviews in AccuRev is restricted.
There are seven tools on the list that are "recommended" for a unit test. Apparently the unit
test process has multiple environment that have to be supported by a variety of tools.

Legend:

recommended
non-restricted
restricted

Tools Categories

This might seems to be a simple task

to document the definition of each
category. Although, in a face of
redundant tools that overlap in
their scope, without a clear
understanding of features offered
by each category, the decision
making is severely hindered.
Let us consider three categories
that traditionally overlap.

Tools Category

Key Features and Goals

PAL (Process Assets Library) Make process docs readily available

Distinguish Released from WIP (Work In Progress)
Control versions of docs and maintain their revision history
Peer Reviews

Reveal hidden defects

Maintain comments per document and per F2F meeting
Convert final drafts into public released versions

Social Media

Encourage discussion groups on certain topics

Flattens the organizational hierarchy
Encourages self-empowering teams
Encourages cross-pollination of ideas
Facilitate Q & A sessions
Make Announcements widely available

Both these organizational processes (Social Media and Process Library) along with their corresponding
tools, should be harmonized. The goals of Social Media and Process Library do overlap. Unless we clearly
define the distinction and scope of each tool, they might enter into a conflict and ultimately result in a
waste of resources. The table juxtaposes several dimensions of each process, by focusing on a Key
Purpose of each one.
Apparently, if the overlap between these processes is significant, the result is a waste of resources. Here
are several common scenarios.
Scenario. People are engaged in a prolonged discussions during a peer review. Result is
inconsequential, as no defects are documented.
Action. Suggest to shift the topic into Social Media where such discussions are more appropriate.
Scenario. A document is distributed through Social Media for review. Everyone receives a link. The
official released version in process library has never been established.
Action. Position the document into the WIP area of the process library. Schedule a peer review to
advance the doc into the Released area of process library

Application Registry (example Flashline)

As organizational assets have to be maintained. Application registry is an important
repository with the following key features,

supports SOA
avoids redundancy
maintains the list of versions and features of all applications
promotes reuse
enables the management of assets in a most effective manner

Tools Evaluation and Selection

The enterprise tools evaluation and selection includes the following steps.
Defining the non-overlapping categories of tools
Maintaining the list of tools that are currently used and positioning them into the
predefined categories
Documenting the selection criteria
Communicating with vendors
Documenting the gaps and overlaps in tools coverage
Positioning and maintaining each tool's version in the registry
There is a Tools Evaluation Committee consisting of decision-makers and representatives
from various departments assuring that the selection of tools is fair. There is a team of
technical experts who install the trial versions into lab servers and test them to assure
security and other features are sound.

Selection Criteria
Selection criteria could contain the following items. Each item is weighted and
evaluated from two angles.
1. Completeness Of Solution
2. Quality of Solution
3. Flexibility of Architecture
4. Scalability
5. HW & SW Platforms
6. Connectivity to Others
7. Usability
8. Market Share and Company
9. Length of Operation
10.Future Prospects
11.Current Organization Adoption
12.Cost

( level of importance ) (level of compliance)

( )

Here is another way showing the representation

of a comparison between two common tools
covering two important categories.

Magic Quadrant
Magic Quadrant is commonly used by various market research firms to
juxtapose several vendors and their features. Gartner regular reports
including Magic Quadrant - are an industry standard for disseminating
valuable information and preparing companies to an unexpected market
moves.

Example from Gartner - Magic Quadrant

for CMS (Content Management Systems)
Pictorial below provides a great overview of major players in the CMS marketplace.
One could observe that the space is quite crowded with many leaders trying to get
to the top right corner.
http://www.gartner.com/technology/reprints.do?id=1-229MH3F&ct=140925&st=sg

One could derive many invaluable lessons,

while observing over the years,
as some companies are advancing into
the market leadership positions
and other companies are descending
into oblivion.

Common Difficulties in Tools Adoption

When examining enterprise tools, it is common that one could immediately conclude
that the list of tools is far too long. There are several inherent reasons for that.
A small teams have been accustomed to a certain tool and it is very difficult to
change the muscle memory, the habit. The discussion about various tools could easily
turn into a "religious war" where folks forgot where they started the conversation and
are focusing on something else besides the tools evaluation. Then it is so much more
difficult to bring everyone back to a fair exchange of information.
While listening to a pitch of a tool vendor, it is common to hear the claim of being a
LCM (Life Cycle Manager) and be able to respond to any need you might have. In other
words, a vendor has a great incentive to sell you something he does not really have. It
is usually takes a skillful SME, who is well familiar with a market place, to dig to the
bottom of the discussion.