Embed Size (px)
Citation preview
O IMPACTO DA
ENGENHARIA DE
REQUISITOS EM
PROJETOS DE
SOFTWARE
PROF. RAFAEL MAIANI DE MELLO, MSC.
PROF. RAFAEL MAIANI
DE MELLO
Mestre e Doutorando na linha de Engenharia de Software do
Programa de Engenharia de Sistemas e Computação da
COPPE/UFRJ
Especialista em Gerência de Projetos de Software pela PUC-
RJ
MBA Executivo em Negócios Financeiros pela FGV
Bacharel em Informática e Tecnologia da Informação pela
UERJ
PROF. RAFAEL MAIANI
DE MELLO
Membro do Grupo de Engenharia de Software Experimental
(ESE) da COPPE/UFRJ
• QUATIC 2012: International Conference on the Quality of
Information and Communications Technology
• JCC 2011: Jornadas Chilenas de Computacíon
• SBQS 2011: Simpósio Brasileiro de Qualidade de Software
• SBES 2010: Simpósio Brasileiro de Engenharia de Software
• ISMICK 2008: International Symposium on the Management
of Industrial and Corporate Knowledge
PROF. RAFAEL MAIANI
DE MELLO
Professor de Graduação e de Pós-Graduação no Instituto
Infnet
• Engenharia da Computação
• Análise e Desenvolvimento de Sistemas
• Gestão de TI
• MIT em Engenharia de Software com Java
Analista Sênior no Banco do Brasil
Professor Substituto na UERJ
VOCÊS SABEM QUE...
Requisitos são a base para o desenvolvimento do software
Requisito também é software!
Nada deve ser incluído no resto do software que não esteja
especificado nos requisitos
VOCÊS SABEM QUE...
Quanto mais tarde corrigir o defeito em um software, mais
____________ fica o esforço da correção
a) Barato
b) Bonito
c) Triste
d) Caro
e) NRA
VOCÊS SABEM QUE...
VOCÊS SABEM QUE...
PROPOSTA
Que tal ver mais de perto este cenário?
Vamos ver os FATOS?
PRIMEIRO, UM BREVE
EXERCÍCIO...
ALERTA
Este conteúdo é inadequado para os que
sofrem de problemas cardíacos, gestantes,
menores de 18 anos, hipertensos, etc...
OU NÃO!
1962- O BUG DO
FOGUETE MARINER 1
Cost: $18.5 million
Disaster: The Mariner 1 rocket with a space probe headed for
Venus diverted from its intended flight path shortly after
launch. Mission Control destroyed the rocket 293 seconds
after liftoff.
Cause: A programmer incorrectly transcribed a
handwritten formula into computer code, missing a
single superscript bar. Without the smoothing function
indicated by the bar, the software treated normal variations of
velocity as if they were serious, causing faulty corrections
that sent the rocket off course.
1985- MÁQUINA DE
RADIOTERAPIA
Cost: Three people dead, three people
critically injured
Disaster: Canada’s Therac-25 radiation therapy machine
malfunctioned and delivered lethal radiation doses to
patients.
Cause: Because of a subtle bug called a race condition,
a technician could accidentally configure Therac-25 so the
electron beam would fire in high-power mode without the
proper patient shielding.
1987- QUEBRA DA BOLSA
DE WALL SREET
Cost: $500 billion in one day
Disaster: On “Black Monday” (October 19, 1987), the Dow
Jones Industrial Average plummeted 508 points, losing 22.6%
of its total value. The S&P 500 dropped 20.4%. This was the
greatest loss Wall Street ever suffered in a single day.
Cause: A long bull market was halted by a rash of SEC
investigations of insider trading and by other market
forces. As investors fled stocks in a mass exodus,
computer trading programs generated a flood of
sell orders, overwhelming the market, crashing
systems and leaving investors effectively blind
1991- MÍSSIL NÃO-
INTERCEPTADO
Cost: 28 soldiers dead, 100 injured
Disaster: During the first Gulf War, an American Patriot
Missile system in Saudi Arabia failed to intercept an
incoming Iraqi Scud missile. The missile destroyed an
American Army barracks.
Cause: A software rounding error incorrectly
calculated the time, causing the Patriot system to
ignore the incoming Scud missile.
1993- FALHA DE
DIVISÃO DO PENTIUM
Cost: $475 million, corporate credibility
Disaster: Intel’s highly-promoted Pentium chip occasionally made mistakes when dividing floating-point numbers within a specific range. For example, dividing 4195835.0/3145727.0 yielded 1.33374 instead of 1.33382, an error of 0.006%. Although the bug affected few users, it become a public relations nightmare. With an estimated 5 million defective chips in circulation, Intel offered to replace Pentium chips only for consumers who could prove they needed high accuracy. Eventually Intel replaced the chips for anyone who complained.
Cause: The divider in the Pentium floating point unit had a flawed division table, missing about five of a thousand entries and resulting in these rounding errors
1996- EXPLOSÃO DO
FOGUETE ARIANE
Cost: $500 million
Disaster: Ariane 5, Europe’s newest unmanned rocket, was intentionally destroyed seconds after launch on its maiden flight. Also destroyed was its cargo of four scientific satellites to study how the Earth’s magnetic field interacts with solar winds.
Cause: Shutdown occurred when the guidance computer tried to convert the sideways rocket velocity from 64-bits to a 16-bit format. The number was too big, and an overflow error resulted. When the guidance system shut down, control passed to an identical redundant unit, which also failed because it was running the same algorithm.
2000- SOFTWARE DE
RADIOTERAPIA
Cost: Eight people dead, 20 critically injured
Disaster: Radiation therapy software by Multidata Systems
International miscalculated the proper dosage, exposing
patients to harmful and in some cases fatal levels of
radiation. The physicians, who were legally required to
double-check the software’s calculations, were indicted for
murder.
Cause: The software calculated radiation dosage based on
the order in which data was entered, sometimes delivering a
double dose of radiation.
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
1
If you don’t get the
requirements right, it doesn’t
matter how well you execute
the rest of the project.
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
2
Requirements development is
a discovery and invention
process, not just a collection
process
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
3
Change happens
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
4
The interests of all the project
stakeholders intersect in the
requirements process
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
5
Customer involvement is the
most critical contributor to
software quality
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
6
The customer is not always
right, but the customer always
has a point
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
7
The first question an analyst
should ask about a proposed
new requirement is:
“Is this requirement in
scope?”
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
8
Even the best requirements
document cannot—and should
not—replace human dialogue
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
9
The requirements might be
vague, but the product will be
specific
PARA REFLEXÃO
“COSMIC THRUTHS”, DE
KARL WIEGERS
10
You’re never going to have
perfect requirements
REQUISITOS DE
SOFTWARE
Os Requisitos de software devem ser SMART
• Specific – Objectives should specify what they want to achieve
• Measurable – You should be able to measure whether you are meeting the objectives or not
• Achievable - Are the objectives you set, achievable and attainable?
• Realistic – Can you realistically achieve the objectives with the resources you have?
• Time-framed – When do you want to achieve the set objectives?
REQUISITOS DE
SOFTWARE
• Requisitos são os objetivos a serem alcançados, portanto
devem ser expressos “por inteiro” (responder 5W1H)
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Use the most simple words
appropriate to the intent of the
statement. Hide is defined as "to put
out of sight". Obscure is defined as
"lacking light or dim". Don't use
obscure if you mean hide.
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Use imperatives correctly and be
consistent. Remember, shall
"prescribes", will “describes", must &
must not "constrain", and should
"suggests"
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Avoid weak phrases such as "as
a minimum", "be able to",
"capable of", and "not limited to".
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Do not use words or terms that give
the provider an option on the extent
that the requirement is to be satisfied
such as "may", "if required", "as
appropriate", or "if practical".
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Do not use generalities where
numbers are really required such
as "large", "rapid", "many",
"timely", "most", or "close".
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Avoid fuzzy words that have relative
meanings such as "easy", "normal",
"adequate", or "effective".
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
Apresente exemplos, deixando claro que são
exemplos!
Cite suas referências claramente!
Se for utilizar gráficos ou tabelas, identifique e
referencie cada uma conforme sua utilização na
especificação de requisitos!
REQUISITOS DE
SOFTWARE-
ORIENTAÇÕES
REVISE – INSPECIONE!
E... MANTENHA A
CALMA...
REFERÊNCIAS
Devtopics. 20 Famous Software Disasters. Disponível em:
http://www.devtopics.com/20-famous-software-disasters/,
2012.
Sommerville, I. Engenharia de Software- Teoria e Prática.
Wiegers, K. E. More About Software Requirements- Thorny
Issues and Practical Advice. Microsoft Press, 2006.
Wilson, W. M. Writing Effective Requirement Specifications.
Software Technology Conference, Utah, April 1997.
O IMPACTO DA
ENGENHARIA DE
REQUISITOS EM
PROJETOS DE
SOFTWARE
43
Prof. Rafael de Mello, Msc.
