unit 6: system quality...
TRANSCRIPT
Calidad del Software
• Best products, from users point of view,
are those which have been developed
considering organizational needs, and how
product is going to help users in their work.
• Hence, to be successful, we must to study
in a very special way product
requirements.
System Requirements
Calidad del Software
• Product requirements must be understood by
clients and developers before design phase
and product development. This is the only
way to be sure that product will fulfill user
needs.
• According to USA Standard and Technology
Institute, imprecise and controversial
requirements produce the 70% of system
defects.
System Requirements
Calidad del Software
• Searching requirement process can be
viewed like a very detailed product
exploration to discover its behavior and its
functionality. This process produces a
written technical product description,
which finally will origin product design.
• Requirements are a statement about
business needs, without any predisposition
about implementation.
System Requirements
Calidad del Software
Requirement: It is a condition or characteristic that
must be satisfied by a system or by a component of
the system in order to fulfill a contract, standard,
specification or any other document formally imposed
(Spanish Association for Quality - AECC).
Functional Requirement: Requirement specifying the
function that a system must be able to perform
(AECC).
Operational Requirement: Requirement specifying a
running characteristic that the system must have
(AECC).
Definitions
Calidad del Software
• Functional Requirements: They describe “what” product does from the business point of view.
• Non Functional Requirements: They describe “qualities” the product must have to be attractive, useful, fast, reliable and secure.
• Restrictions specify product developing boundaries on time, costs, human resources, etc.
Requirement Classification
Calidad del Software
• Non functional requirements are as
important as functional requirements.
• Non functional properties, like usability,
can be the difference between an
accepted and liked product or a non useful
product to the customer.
System Requirements
Calidad del Software
• Look and Feel, product appearance.
• Usability.
• Operativity.
• Execution, aspects like availability,
fastness, efficiency, …
• Security.
• Maintainability.
Non Functional
Requirements
Calidad del Software
To identify requirements, they are used:
Prototypes: they are a draft of a system or a
part.
•High fidelity prototypes, using special tools.
•Low fidelity prototypes, using pencil and
paper.
•Scenarios: they are a step by step description of
the functionality of a case of use.
Requirements evolution
Calidad del Software
Requirements evolution
Case
of Use
Technical
Specification
Scenarios
Functional
Requirements
Non functional
RequirementsRestrictions
To understand
work
To understand
product
Technical
Requirements
Calidad del Software
• Requirement definition is a very difficult
task, but it is crucial for product final
quality. Hence take your time to do it.
• Requirement from successful system can be
reused.
• Once specification is finished, they are
revised with stakeholders.
Requirement Management
Calidad del Software
The requirements elicitation process must
also be reviewed in joining meetings of all
actors :
•What did we well?
•What did we wrong?
•If we will have to do it again, what will
we do different?
Requirement Management
Calidad del Software
Due to a good requirement specification
importance, it is needed to include
requirement verification as a stage in the
product quality life cycle.
To achieve this goal, every requirement
must pass through “quality door” before
enter in the specification.
Requirement Verification
Calidad del Software
• Quality doors are established in such a way
that only a small set of people validate the
characteristic of each one of the
requirements -relevance, coherence,
traceability, testability- before
incorporating them into the specification.
Requirement Verification
Calidad del Software
Target to achieve:
• To validate that requirements are correct
and complete.
• To associate requirements to business
functions.
• To remove ambiguities.
• To validate that every requirement can be
tested.
Requirement Verification
Calidad del Software
• Once requirement specification has been
completed, it must be reviewed.
• The whole specification gives us a
precise view of the product extension or
importance, and functionality.
• This specification must permit project
cost and risk reviews.
Specification Review
Calidad del Software
• During this phase, it is known
requirement associated to project risks.
For example: do we develop the product
with a new technology or with a
technology never used before?
• To review risk calculus at this point could
be useful to reach the success.
Specification Review
Calidad del Software
• A risk can be defined as a variation of the
expected results. This variation can be many
times of a random character, and it is out of
control from decision taken. Hence, it generates
an uncertainty problem.
• Every project implies risks. In general, risks are
damaging if they are ignored, and they can
generate problems.
Risks
Calidad del Software
They can be composed by:
• Random unexpected: which is the value or
behavior that the random variable could
take to which the project faces.
• Vulnerability: which is how vulnerable is the
project with respect to one of the random
unexpected behaviors.
Risks
Calidad del Software
• Reactive manner: only when problems
occur reaction is produced.
• Proactive manner: risks are
prevented, contingency plans have
been implemented. Prevention and
anticipation are wanted.
Face up to Risks
Calidad del Software
Every project has to estimate the possibility of risk becomes as a real fact. Negative consequences have to be also considered when you think on the risk level associated to a project.
To calculate business risk it has be determined and valuated negative consequences due to a fault, and also the probability of fault occurrence.
Risks Estimation
Calidad del Software
Risk assessment is done in two phases:
•To estimate for every business function its
impact in case of fault. In this context,
impact represents damage caused to the
business.
•To calculate the probability of fault per
every business function.
Risk Calculation
Calidad del Software
Business Impact
CriteriaResults
High Impact Medium Impact Low Impact
Processes TypeCalculus
ValidationData change Visualization
Business
implicationsLegal
Incorrect
InformationNone
Frequency of use Very frequent Often Rare
# affected
customersVery important Group some
Calidad del Software
CriteriaResults
Slightly Probable Probable Very Probable
Change rate Without changesChanging
functionNew function
Software
maturity
Mature
(>10 years)
In progress
(5-10 years)
Immature
(<5 years)
Defect rate Low Medium High
Fault Probability
Calidad del Software
Categories Calculation
CriteriaResults
Slightly Probable Probable Very Probable
Alto impacto Medium risk High risk High risk
Impacto medio Low risk Medium risk Medium risk
Bajo impacto Low risk Low risk Medium risk
Calidad del Software
PROJECT RISKS
Unforeseen or events which provoke delays in the completion of activities generating a possible delay at the ending of the project.
They are caused by:
• Budget.
• Staff.
• Planning.
• Resources.
• Clients and requirements.
Risks’ Types
Calidad del Software
Risks’ Types
PRODUCT RISKS
Possibility that the system or software could fail and does not satisfy customer’s needs, or expectations from people related to the project.
Not satisfactory software generally can omit some key functions which have been specified by the client, or that are needed by users or that have been promised by business agents.
Calidad del Software
Risks’ Types
TECHNICAL RISKS
It threatens quality and planning of the
developed software making difficult or
impossible any implementation.
Influential factors are:
• Problems of design and implementation.
• Of Cross-check and Maintenance.
• Technical uncertainty…
Calidad del Software
Risks’ Types
BUSINESS RISKS
• To develop a product that nobody wants or needs
(market risk).
• To develop a product that does not fit into the
strategic plan of the company (strategic risk).
• To develop products that we don’t know how to sell
them (strategic risk).
• Loss of support for changes of targets or staff (risk
of direction).
• To lose the budget or assigned personnel (risk of
budget).
Risk identification is a systematical attempt
to specify the threats to the project plan
(estimations, temporary planning, load of
resources, etc.). Identifying the well-known
and predictable risks, the project manager
can to avoid them when it is possible and to
control them when it is necessary.
Calidad del Software
Risks’ Types