Evolução de Software - PUC-Rio

Qualidade Através da Transparência: Uma Visão de Engenharia de

Requisitos

Apoio:

Julio Cesar Sampaio do Prado Leite

Departamento de Informática

Pontifícia Universidade Católica do Rio de Janeiro

(PUC-Rio)

©jcspl

O quem vem por aí

• Um pouco de história

• Transparência

• Requisitos

• Qualidade

• Qualidade como Requisito

• Qualidade de Software através de Transparência

2014 2

©jcspl

Então ...

• Arndt von Staa - Contabilização de Custos no

Desenvolvimento de Software

• Peter A. Freeman - Uso de Pontos de Vista na

Validação de Requisitos

• O Projeto Draco-PUC (UFSCar)

• Léxico e Cenários (Projeto Belgrano)

• Requisitos Não-funcionais (York 1995)

2014 3

©jcspl

Então ...

• John Mylopoulos - Aspectos Derivados de Metas

Flexíveis, Reutilização de RNF, Variabilidade, i*

• WerPapers, C&L, Lattes-Scholar (Lua)

• Transparência (SBES 2006)

• Modelo de Maturidade

• Qualidade de Software através de Transparência

2014 4

©jcspl

Transparência

• Interesse em função da curiosidade (GPS no

celular, redes sociais, extermínio em São Paulo)

• Informar para esclarecer

• Diferente da noção de corrupção

• Estudo da literatura

• Cadeira de Pós-Graduação

• Trabalho de tese de Claudia Cappelli

2014 5

©jcspl

Transparência

2014 6

Transparência tem sido, por muito tempo, um requisito

geral para sociedades democráticas. O direito de ser

informado e de ter acesso à informação tem sido uma

consideração importante nas sociedades modernas. As

pessoas querem ser informadas de maneira apropriada.

Desta forma, transparência é uma característica muito bem

vista para organizações. Entretanto, como o software

permeia vários aspectos da nossa sociedade, em algum

ponto no futuro, engenheiros de software terão que dar

conta de mais uma demanda: transparência. Neste

ambiente vislumbrado, engenheiros terão que possuir

métodos, técnicas e ferramentas para ajudar a fazer

software transparente.

©jcspl

Transparência (Livros)

2010 7

©jcspl

• Holzner B., Holzner L., Transparency in Global Change: The Vanguard of the Open Society. University of Pittsburgh Press; 1 edition, 2006.

• Henriques A., Corporate Truth The Limits to Transparency, EARTHSCAN, UK, 2007.

• Lord K. M. The Perils and Promise of Global Transparency, State University of New York Press, 2006.

• Fung A. Graham M., Weil D., Full Disclosure, the Perils and Promise of Transparency, Cambridge. University Press, 2007.

• Mendel, T. , Freedom of Information: A Comparative Legal Survey, UNESCO: Paris, 2008

• Claudia Cappelli Aló. Uma Abordagem para Transparência em Processos Organizacionais Utilizando Aspectos. 2009. Tese (Doutorado em Informática) - Pontíticia Universidade Católica do Rio de Janeiro.

Transparência (Livros)

©jcspl 9

Transparência (Citações)

Holzner and Holzner [1] states that transparency is:

“the social value of open, public, and/or individual access to information held and disclosed by centers of authority.”.

Henriques [2] states:

“ …transparency cannot be purchased wholesale. One thing it requires is painstaking attention to detail. Yet transparency is not just a technical issue of communications. The fundamental argument of this book is that transparency is required wherever power is exercised.”.

Lord [3] says: “Transparency is a condition in which information about the priorities, capabilities, and behavior of powerful organizations is widely available to the global public.”

Fung et al [4] uses the concept of target transparency: “Instead of aiming to generally improve public deliberation and officials´ accountability, target transparency aims to reduce specific risks or performance problems through selective disclosure by corporations and other organizations. The ingeniousness of target transparency lies in its mobilization of individual choice, market forces, and participatory democracy through relatively light-handed government action”.

[1] Holzner B., Holzner L., Transparency in Global Change: The Vanguard of the Open Society. University of Pittsburgh

Press; 1 edition, 2006.

[2] Henriques A., Corporate Truth The Limits to Transparency, EARTHSCAN, UK, 2007.

[3] Lord K. M., The Perils and Promise of Global Transparency, State University of New York Press, 2006.

[4] Fung A., Graham M., Weil D., Full Disclosure, the Perils and Promise of Transparency, Cambridge University Press, 2007.

2010 9

©jcspl

Transparência

2013 10

– A característica que possibilita ao cidadão: acesso,

facilidade de uso, qualidade de conteúdo, entendimento

e auditoria às/das informações de seu interesse, sob a

tutela de centros de autoridade.

– A característica que possibilita ao cidadão: acesso,

facilidade de uso, qualidade de conteúdo, entendimento

e auditoria aos/dos processos que tratam de

informações de seu interesse, sob a tutela de centros

de autoridade.

©jcspl

Transparência

2013 11

©jcspl

2014 12

©jcspl 13

Requisitos

• Sempre Existem

• Podem ter graus de transparência (explícitos,

implícitos)

• Para explicitá-los, torná-los transparentes, há

a necessidade da Engenharia de Requisitos.

• Requisitos são construídos

• Requisitos mudam

• Confusão de necessidades/conhecimento

contextual

2014

©jcspl 14

Requisitos

• “There is no sense in being precise if you do

not know about what you talking about”

• Gerência por Requisitos (como gerenciar sem

metas?)

• Como comparar, sem base sólida?

2014

©jcspl 15

Requisitos (Engenharia)

Entender as necessidades e atender os desejos dos

clientes sempre foi colocado como um dos maiores

desafios da Engenharia de Software. A postura da

Engenharia de Requisitos é a de prover ao Engenheiro

de Software, métodos, técnicas e ferramentas que

auxiliem o processo de compreensão e registro dos

requisitos que o software deve atender. Diferentemente

de outras sub-áreas da engenharia de software, a área

de requisitos tem que lidar com conhecimento

interdisciplinar envolvendo,muitas vezes, aspectos de

ciências sociais e ciência cognitiva.

2014

©jcspl 16

Requisitos (Porque da Engenharia?)

2014

©jcspl 17

Requisitos (Contexto)

2014

• A ilusão da página em branco

• A ilusão da completeza

• A definição de um sistema é função do

desenho/implementação do macrosistema

• A distância entre solicitações de clientes e

requisitos de software

• A constante evolução das solicitações (pressão do

mercado)

©jcspl 18

Requisitos (Baseline)

2014

©jcspl 19

Requisitos (Atores)

2014

• Interessados

– Freguezes

• Usuários

– Operadores

– Clientes

– Clientes terceirzados

• Clientes

– Investidor

– Dono

– Especialista

– Parceiro

– Desenvolvedores

• CQ

• Engenheiros de Software

• Escritores Técnicos

©jcspl 20

Qualidade

2014

• A importância de Métricas

• Sem métricas não se pode comunicar de uma

maneira precisa.

“ When you can measure what you are speaking about, and

express it in numbers, you know something about it; but

when you can not measure it, and when you can not

express it in numbers, your knowledge is of a meagre and

unsatisfactory kind.“ (Lord Kelvin)

http://www.groups.dcs.stand.ac.uk/~history/Mathematicia

ns/Thomson.html

©jcspl 21

Qualidade

2014

• Qualidade delimitada pela “Racionalidade Com Limites”

(Herbert A. Simon), isto é o a racionalidade dos humanos é

limitada pela informação que cada um dispõe, pelo limite

de sua capacidade cognitiva, e pelo tempo finito disponível

para tomada de decisão.

• Para a tomada de decisão o humano simplifica e passa a

usar uma satisfação a contento (“satisfice”) ao invés de

procurar maximizar a satisfação.

• Os termos “satisfice”/”satisficing” foi inventado por Simon

para caracterizar a ideia de que há uma satisfação dentro

de limites.

• Esse conceito é fundamental para lidar com aspectos onde

métricas são insuficientes.

©jcspl

Qualidade

• What

• When

• Where

• Why

• Whom

• How

• How much

2014 22

©jcspl 23

Qualidade

2014

• Análise (V&V)

• Retro-Alimentação

• Auditoria

• Grupo de Qualidade

©jcspl

Qualidade (Software - SBQS)

2014 24

©jcspl

Qualidade (em Software)

• Qualidade do

Produto

• Qualidade no

Produto

2014 25

©jcspl

Qualidade (no Produto)

• RNF no mesmo nível de RF.

• Representar RNF como metas flexíveis.

• Reutilizar RNF.

2013 26

Variabilidade

©jcspl

Qualidade (Variabilidade)

2014 27

Quality-Based Software Reuse. Julio Cesar Sampaio do Prado Leite, Yijun Yu, Lin Liu, Eric S. K. Yu, John

Mylopoulos: CAiSE 2005: 535-550

©jcspl

Qualidade (Variabilidade)

2014 28

Herbet de Souza Cunha, Uso de estratégias orientadas a metas para modelagem

de requisitos de segurança, Dissertação de Mestrado, Abril de 2007, PUC-Rio.

©jcspl

Qualidade através de Transparência (Lei de Linus)

2014 29

A Lei de Linus: “Mais olhos, menos problemas”

(“Given enough eyeballs, all bugs are shallow”) Eric

S. Raymond.

©jcspl

Qualidade através de Transparência(N-Fold Inspection)

G. Michael Schneider, Johnny Martin, and W. T. Tsai. 1992. An experimental

study of fault detection in user requirements documents. ACM Trans.

Softw. Eng. Methodol. 1, 2 (April 1992)

This paper describes a software engineering experiment designed to confirm

results from an earlier project which measured fault detection rates in

user requirements documents (URD). The experiment described in this

paper involves the creation of a standardized URD with a known number

of injected faults of specific type. Nine independent inspection teams were

given this URD with instructions to locate as many faults as possible using

the N-fold requirements inspection technique developed by the authors.

Results obtained from this experiment confirm earlier conclusions about

the low rate of fault detection in requirements documents using formal

inspections and the advantages to be gained using the N-fold inspection

method. The experiment also provides new results concerning variability

in inspection team performance and the relative difficulty of locating

different classes of URD faults

2014 30

©jcspl

Qualidade através de Transparência(Confirmação do Mais olhos)

2014 31

Too Many Cooks

vs.

More Eyeballs

• At a fine-grained level, “more eyeballs” may help

reduce defects

• More eyeballs are better

• Too many Cooks may bring more problems

Foyzur Rahman and Premkumar Devanbu,

Ownership, Experience and Defects: A Fine-‐Grained Study of Authorship, ICSE 2011.

©jcspl

Qualidade através de Transparência(Ponto de Vista)

2014 32

Demonstração de que o uso de diferentes

perspectivas e o uso de diferentes pontos de vista

aumenta a qualidade da elicitação de requisitos ao

prover uma estratégia de análise, base para um

processo de negociação com base em fatos

contraditórios e fatos faltantes.

Viewpoint Resolution in Requirements Elicitation (Ph.D. Thesis)

http://requirementsviewpoints.googlepages.com/Viewpoint.pdf

http://requirementsviewpoints.googlepages.com/Viewpoint.pdf

©jcspl

Qualidade através de Transparência(Premissa)

Entendendo Transparente e Explícito como

conjuntos ordenados de graus de transparência e

graus de explicitude, a função que relaciona valores

entre esses conjuntos é uma função crescente.

Observe que no lema acima:

• os adjetivos explícito e transparente são usados

substantivamente,

• os adjetivos são definidos como conjuntos onde

existem gradações de sua forma substantiva,

• essas gradações, chamados graus, podem ser

mapeados em valores no campo dos reais.

2014 33

©jcspl

Qualidade através de Transparência(Premissa)

2014 34

©jcspl

©jcspl 2010 36

Security versus Transparency (Adapted from (Cappelli et al. 2010))

©jcspl 37

Transparency Network

Dependency

©jcspl

Afinal o que é Transparência? • Qualidade, depende de onde é aplicada, por quem e

para quem.

• Transparência, vai além de acessibilidade: muitos

olhos só funcionam se outras qualidades tiverem

associadas, tais como: usável, informativo, entendível,

auditável.

• Mas o que são cada uma dessas qualidades

(acessibilidade, usabilidade, informativo,

entendimento, auditabilidade) no contexto de

transparência (informação livre)?

• Um rede de qualidades, que ajudam (help), que a

qualidade Transparência seja atingida no maior grau.

©jcspl 39

Os próximo slides são resultados da

tese de Doutorado de Eduardo

Kinder Almentero: “Dos Requisitos

ao Código: Um Processo para

Desenvolvimento de Software mais

Transparente”, PUC-Rio, 2013

©jcspl 40

RNF Pattern Dependency

Initial Result

Refinement Rules

Software Transparency Alternative Pattern

R1: QuestionAnswering(The internal

dependencies of each part has been

identified?, [Perform GROUP

activity, Help, Dependability[Software]])

Coupling

R1 R2

Dependability

[Software]

The internal

dependencies of each

part has been identified?

The external



Scenario

clusterizationA

nsw

er

Dependability

[Software]

R1: QuestionAnswering(The external




Transparency

[Software]

Understandability

[Software]

Help

He

lp

He

lp

Answ

er

Perform GROUP

activity

And

Scenario

integration

And

Dependency

Dependency

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Requirements Driven Process

Requirements scenario

MVC Framework

View

Controller

Model

Modularization Architecture definition

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Requirements scenarios Software

Modularization

Modularizaçao dos cenários de requisitos

Ab

stra

ctio

n le

vel

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Mo

du

le

a M

od

ule

b

. . .

Mo

du

le

k

Model

View Controller

S1.m

S2.m

S3.m

S4.m

S5.m

S6.m

S7.m

S8.m

S9.m

S10.m

S11.m

S12.m

S13.m

Sn1.m

Sn2.m

Sn3.m

Sn4.m

Sn5.m

Sa.c

Sb2.c

Sb.c

Sk.c

Sk2.c

S1

S2

S3

S8

S5

S6

S4

S7

S10

S15

S16

S14

S11

S12

S13

S9

Sn1

Sn2

Sn6

Sn4

Sn5

Sn3

Sn6.m

S14.m

S15.m

S16.m

S2.v

S3.v

S7.v

S8.v S9.v

S10.v

S12.v

Sn1.v

Sn4.v

S4.m

Sn3.m

S15.v

S5

Requirements scenario

Architecture scenario


MVC Framework


Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl 44

Does “Scenario clusterization” and “Scenario integration” operationalize Dependency?

Initial Result

Refinement Rules

Software Transparency Alternative Pattern

R1: QuestionAnswering(The internal




Coupling

R1 R2

Dependability

[Software]

The internal



The external



Scenario

clusterization

Answ

er

Dependability

[Software]

R1: QuestionAnswering(The external




Transparency

[Software]

Understandability

[Software]

Help

He

lp

He

lp

Answ

er

Perform GROUP

activity

And

Scenario

integration

And

Dependency

Dependency

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Does “Scenario clusterization” and “Scenario integration” operationalize Dependency? • An experiment was planned inspired on Alexander Egyed and

Patrick Mader. 2012. Assessing the effect of requirements

traceability for software maintenance. In Proceedings of the 2012

IEEE International Conference on Software Maintenance

(ICSM) (ICSM '12)

• Two software that implement the C&l editor were used. A Php

version and a Lua version.

• Evolution Tasks based on Barbara A. Kitchenhamet al. (Towards an

Ontology of software maintenance. Journal of Software

Maintenance 11, 6 (November 1999), 365-389) were defined and

12 people performed 4 tasks divided in two groups

45

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Tarefas • Tarefa 1: Os usuários do sistema C&L estão reportando um

erro ao cadastrar um símbolo no sistema. Segundo as

mensagens, quando um símbolo é cadastrado no sistema, o

nome informado pelos usuários não é considerado. Todos os

símbolos estão sendo cadastrado com a string “nome” no

lugar do nome.

• Tarefa 2: Para tornar a visualização dos sinônimos de um

símbolo mais clara, um dos desenvolvedores sugeriu que

eles sejam exibidos um em baixo do outro, no formato de

lista, ao invés de lado a lado e separados por vírgula.

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Tarefas • Tarefa 3: Um dos stakeholders do software C&L deseja a

adição de uma nova funcionalidade. O software deve

permitir que o usuário importe cenários para um projeto

específico a partir de arquivos externos. Neste caso, o

usuário precisa selecionar o arquivo, que deve seguir um

padrão específico

• Tarefa 4: Houve uma mudança nos requisitos do software

C&L. Agora, durante o cadastro de um novo usuário, o

sistema deve exibir um campo para que o usuário informe a

idade. Este novo dado deve ser armazenado no banco de

dados do sistema, junto com os demais dados do usuário.

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Estudo de dependência

• Perfil dos participantes

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Gráfico de tarefas corretas

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Percentual de tarefas corretas executadas

C&L PHP

(não satisfaz dependência)

C&L Lua (satisfaz dependência)

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Tempo de execução das tarefas

Ed

ua

rdo

Kin

de

r A

lme

nte

ro:

“D

os R

eq

uis

ito

s a

o C

ód

igo

: U

m P

roc

es

so

para

D

ese

nvo

lvim

en

to

de S

oft

wa

re m

ais

Tra

nsp

are

nte

”, P

UC

-Rio

, 2

01

3

©jcspl

Modelo de Maturidade (UNIRIO)

• Porque de um selo de transparência?

• Para que um selo de transparência?

• Como “medir” transparência?

• Como “medir” o progresso no sentido da

transparência?

• Transparência como base para processos

colaborativos.

Exemplo:

©jcspl 2014 54

Para os Curiosos

• Equipe do grupo de ER (Transparência) da PUC-

Rio (http://transparencia.inf.puc-

rio.br/wiki/index.php/Integrantes)

• Artigos recentes sobre o tema

(http://scholar.google.com/citations?user=ZHyci

AQAAAAJ) ; ordenar por ano.

• Catálogo de Transparência de Software

(http://transparencia.inf.puc-

rio.br/wiki/index.php/Cat%C3%A1logo_Transpar

%C3%AAncia)

• WTranS (http://wtrans.inf.puc-

rio.br/WTRANSartigos/index.lp)

http://transparencia.inf.puc-rio.br/wiki/index.php/Integrantes



http://scholar.google.com/citations?user=ZHyciAQAAAAJ





Evolução de Software - PUC-Rio

Documents

Transcript of Evolução de Software - PUC-Rio