Marino Hilário Catarino

10 de outubro de 2014 1

1. Introdução

2. A Study of Collaboration in Software Design

3. Assessment of a framework to compare software development methodologies

4. Let´s Go to the Whiteboard: How and Why Software Developers Use Drawings

2

Engenharia de Software

FERRAMENTAS: dão suporte automatizado aos métodos.

Existem atualmente ferramentas para sustentar cada um dos métodos

Quando as ferramentas são integradas é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE - Computer Aided Software Engineering

3

PROCEDIMENTOS: constituem a ligação entre os métodos e ferramentas

Seqüência em que os métodos serão aplicados

Produtos que se exige que sejam entregues

Controles que ajudam assegurar a qualidade e coordenar as alterações

Referências que possibilitam administrar o progresso do software.

4

Ciclos de Etapas de Software

Conjunto de etapas que envolve MÉTODOS, FERRAMENTAS e PROCEDIMENTOS.

Alguns ciclos de vida mais conhecidos são:

1. Ciclo de Vida Clássico (Cascata)

2. Prototipação

3. Modelo Espiral

5

James Wu e T.C.N. Graham da Queen’s University , Canada Paul W. Smith da IBM Canada 2003

É um estudo de colaboração em uma empresa de grande porte de design de software. Estudos etnográficos de equipes de desenvolvimento no campo são relativamente raros. A metodologia incluiu: Sombreamento, Entrevistas Registo de eventos de comunicação

6

O objetivo deste estudo foi investigar a colaboração e uso de ferramentas de design de software.

Foi motivado por uma percepção de que existem muitas ferramentas para o suporte de software porém apenas um subconjunto limitado de as tarefas e atividades envolvidas nestas ferramentas.

7

O estudo investiga quatro hipóteses:

1. O projeto de software é um atividade altamente colaborativa em que os membros da equipe freqüentemente se comunicam.

2. Projetistas de software preferem ferramentas informais e não ferramentas específicas, tanto para design e comunicação.

8

3. Os membros da equipe freqüentemente mudam de localização física ao longo do dia.

4. Os membros da equipe freqüentemente mudam a forma com que se comunicam.

9

Bellotti e Bly apresentam um estudo de uma equipe de projeto e destacam a importância da mobilidade no local para design de software colaborativo.

Kraut e Streeter pesquisam as práticas de coordenação em 65 projetos diferentes em uma única empresa de software.

Seaman e Basili abordam os aspectos da produtividade de comunicação ao estudar as características organizacionais e de processos que influenciam em uma empresa de software ao comunicar as atividades.

10

Três métodos principais de coleta de dados:

1. Entrevistas; foram realizadas 17 entrevistas.

2. Sombreamento;

3. Registo de eventos de comunicação.

11

Membros de uma equipe tem um alto grau de interação visando o apoio ao seu trabalho.

São feitas comunicações com freqüência, e muitas vezes alternado entre modalidades de comunicação.

Esses eventos consumiram em média 124 minutos, mais de 2 horas da jornada de trabalho, e envolveu em média 3 pessoas.

12

Preferência marcada para o uso de ferramentas informais, não específicas. Os resultados apresentado nesta seção são de sombreamento e entrevistas;

O design criativo é amplamente apoiada pelo meio de comunicação informal (como papel e quadro branco);

Para as tarefas formais do projeto eram utilizados o IBM Lotus Notes e editores de texto. Isto é em partes devido a cultura interna da empresa em estudo: ◦ a empresa havia padronizado o Lotus Notes para

compartilhamento de documentos.

13

Quadro comparativo:

14

As entrevistas revelaram uma preferência para a comunicação cara a cara na interação síncrona.

Telefone e quadro branco são também muito utilizados.

15

Designers mudam de local com freqüência para interações cara a cara com colegas, ou áreas de encontro em comum;

Em geral as pessoas preferem falar pessoalmente ao invez de usar o telefone, mesmo quando isso implica uma mudança de localização.

16

Na sequência de uma comunicação cara a cara que continua depois com um e-mail implica uma mudança de interação síncrono para assíncrona.

Comunicação:

Síncrona 90 min/dia;

Assíncrona 35 min/dia.

17

1.O projeto de software é um atividade altamente colaborativa em que os membros da equipe freqüentemente se comunicam.

(H1) Os membros da equipe observados eram altamente interativos, gastando em média mais de duas horas por dia em tarefas de comunicação.

2. Projetistas de software preferem ferramentas informais e não ferramentas específicas, tanto para design e comunicação.

(H2) Designers preferem ferramentas leves de uso geral para o projeto contra ferramentas de design de domínio específico. Nos estágios iniciais do projeto foram utilizados papel e quadro branco.

18

3. Os membros da equipe freqüentemente mudam de localização física ao longo do dia. (H3) Os desenvolvedores mudam de local com freqüência a fim de colaborar. Em média, os desenvolvedores ficam em mais de seis locais por dia. 4. Os membros da equipe freqüentemente mudam a forma com que se comunicam. (H4) Designers frequentemente mudar a maneira pela qual eles se comunicam. Verificaram que é típico para os designers participar de uma reunião cara a cara em um tópico e depois seguir com um e-mail para uma pergunta complementar.

19

Uma ferramenta que suporta apenas comunicação assíncrona, via e-mail ou repositório de documento, não aborda as interações predominantemente síncronos. Ignora uma grande parte da atividade diária dos designers;

20

Os designers preferem usar ferramentas de uso geral que se adequam às suas necessidades, seja para o projeto ou a comunicação, ao invés de ferramentas específicas devido a mais sobrecarga em sua tarefa ou interação.

Mudanças na localização física, sincronicidade e modalidade de comunicação são freqüentes, e as ferramentas atuais não são suficientes para suportar tais mudanças.

21

Riaan Klopper, Stefan Gruner e Derrick G. Kourie

University of Pretoria, South Africa

2007

Este artigo avalia o processo de tomada de decisão e a metodologia de desenvolvimento de software em uma empresa de engenharia de software. A estrutura que foi utilizada na empresa para decidir sobre uma metodologia adequado para a análise e o projeto do processos de negócios e sistemas de software.

22

Gregor Snelting criticou fortemente a proliferação inflacionária de "novos" conceitos de engenharia de software e metodologias, especialmente da comunidade acadêmica em nota publicada quase exatamente 10 anos (1997)

Snelting afirmou que os conceitos e metodologias são apenas produzidos por causa da publicação, mas nunca foram sujeitos a qualquer tentativa de avaliação empírica.

Baseado em Snelting, perguntamos qual das metodologias software disponíveis é útil.

23

Tomar uma decisão, a partir de uma perspectiva organizacional para escolher a metodologia de desenvolvimento de software não é tarefa fácil.

O escopo deste artigo inclui, portanto, a avaliação tanto da estrutura como prescrito pelo Avison e Fitzgerald, e o processo que foi usado.

24

É importante compreender os conceitos básicos de uma metodologia de software para avaliar um processo. Isso permite que o leitor coloque o processo e estrutura que é investigada em um contexto melhor, e ajuda na compreensão dos resultados apresentados.

25

Um bom método de software é uma metodologia que: Pode ser descrito quantitativamente como qualitativamente; Pode ser usado repetidamente, cada vez conseguir resultados semelhantes; Pode ser ensinada aos outros dentro de um prazo razoável; Pode ser aplicado por outros com um nível razoável de sucesso; Atingir significativamente, e de forma consistente, resultados melhores do que qualquer outras técnicas, ou uma abordagem ad-hoc; São aplicáveis em uma porcentagem relativamente grande de casos.

26

Argumentos a favor de organizações que usam metodologias de desenvolvimento de software: 1. Metodologias ajudam a lidar com a complexidade do processo de desenvolvimento de software; 2. Metodologias reduzem os riscos e incertezas, tornando as tarefas de desenvolvimento mais transparente e visível; 3. Metodologias podem fornecer uma estrutura para a aplicação de técnicas e recursos em momentos apropriados durante o processo de desenvolvimento; 4. Metodologias ajudam a capacidade de intercâmbio de desenvolvedores de software. Isto é ainda mais importante quando o desenvolvimento trabalho é terceirizado; 5. Certificação (ISO, CMM, TMM, etc) se torna possível para as organizações.

27

Existem várias notações diferentes disponíveis para sistemas de software de modelagem.

Parte dos requisitos organizacionais era ter uma notação padronizada aceita internacionalmente e que pudesse modelar tanto o sistema técnico quanto o processos de negócios.

O UML foi escolhida como a notação.

28

O processo de alto nível que foi seguido para facilitar o processo de tomada de decisão para a seleção de uma metodologia de software foi:

29

Os requisitos organizacionais incluíram o seguinte: A metodologia de software que facilite a comunicação e a compreensão entre as divisões de negócios e de TI; A metodologia de software que iria criar e manter uma biblioteca de processos de negócio em um nível empresarial, que podem ser reutilizados em diferentes projetos estratégicos; A metodologia de software que iria manter um modelo de um sistema de software, a partir da documentação de negócios, onde compreensível, bem como documentação técnica pode ser gerado; A notação comum que pode ser usado para pessoas de negócios e tecnologia da mesma forma; Um ambiente onde as diferentes partes interessadas de um projeto podem colaborar para construir e manter um modelo de software; A metodologia de software que facilite processo de reengenharia de negócios; A metodologia de software que pode integrar com os processos existentes, tais como a metodologia de gerenciamento de projetos, controle de qualidade, controle de mudanças; Um processo padronizado que pode ser repetido para diferentes projetos e ainda produzir "os mesmos" resultados.

30

Strate Ltd. é a Central de Ativos da África do Sul, com cerca de 140 funcionários, a empresa é responsável pela compensação, liquidação e atividades de ações para a maioria dos comércios eletrônicos realizados na Bolsa de Valores de Joanesburgo (JSE).

31

Outro fator que desempenhou um papel importante na escolha da metodologia de software foi a experiência prática que os analistas de negócios já tiveram em trabalhar com ela.

O quadro para a comparação de metodologias de software em nosso estudo piloto continha um conjunto inicial de diferentes critérios de avaliação (parâmetros) para aplicar a cada metodologia.

Os pesos foram atribuídos a cada critério de avaliação para torná-lo mais relevante para as necessidades específicas da organização que foram recolhidos anteriormente.

32

O framework sugerido por Avison e Fitzgerald foi escolhido para auxiliar no processo de tomada de decisão. A principal razão para a escolha deste framework foi o critério de avaliação precisa que ele proporciona para comparar as diferentes metodologias, em contraste com as outras estruturas que foram consideradas como demasiado vago e subjetivo.

A Separação de Projeto Lógico: implica que deve haver

uma separação de requisitos, e como ela é implementada;

As técnicas e ferramentas: são as várias estratégias e tecnologias usadas para apoiar a metodologia. Um exemplo pode ser que RUP usa UML.

33

Os seguintes métodos foram escolhidos para o exercício de comparação:

Aris

RUP

URDAD

34

A pontuação numérica de entre 1 e 5 foi dada a cada critério, com a seguinte interpretação:

1. Muito ruim: "O que não atender a exigência

desse critério"; 2. Ruim: "Dificilmente se encontra a exigência

desse critério"; 3. Média: "Modestamente atende a exigência

desse critério"; 4. Bom: "Atende a exigência desse critério muito

bem"; 5. Muito bom: "Atende a exigência dada

excepcionalmente bem“.

35

Atribuição de Pesos:

A fim de tornar o método mais relevantes para a organização em questão, os requisitos da organização para uma metodologia de desenvolvimento de software também teve de ser integrados nos resultados quantificados.

Os seguintes ponderações foram atribuídos a cada critério de avaliação baseado na relevância para a organização: 0.5 - relevância “Baixa“; 1.0 - relevância "Normal" e 1.5 - relevância “Alta"

36

Tabela com o resultado: Metodologia:

37

A partir de todos os resultados, a metodologia URDAD deve ser a metodologia escolhida para a organização, mas a decisão continua a ser um exercício subjetivo.

38

Mauro Cherubini – École Polytechnique Fédérale de Lausanne

Gina Venolia e Rob DeLine – Microsoft Research

Andrew J. Ko – Carnegie Mellon University

2007

Este artigo trata em como os desenvolvedores de software utilizam as ferramentas para fazer esboços e diagramas, que representam o seu código.

39

Diagramas são importantes ferramentas para todo design e disciplina de engenharia, porém como é o uso de diagramas nas atividades de desenvolvimento de software?

4 questões:

A. Como os engenheiros usam diagramas em seu trabalho? B. Por que os engenheiros usam diagramas em seu trabalho? C. Que convenções gráficas que os engenheiros usam? D. Qual é a cultura em torno desses desenhos?

40

Fizeram uma primeira pesquisa com 350 desenvolvedores da Microsoft, onde 60 retornaram um questionário sobre uso de diagramas. Realizaram entrevistas e refinaram as perguntas em 9 cenários.

Fizeram uma nova pesquisa onde selecionaram 400 pessoas aleatóriamente entre as 8.570 empregados da microsoft.

41

81%

11%

5% 3%

Desenvolvedor Lider de equipe Arquiteto Outros

7% sexo feminino e 85% tinham entre 20 e 39 anos. A médiaéra de 7 anos como desenvolvedor

42

Convenção visual

Caixas para representar desde banco de dados a métodos

Setas para representar relacionamentos

43

Motivações e cenários

Os diagramas são feitos principalmente para: Entendimento; Design e para Comunicação

44

45

Cenários: 1. Entendimento do código existente: Mais

importante, compreensão do código. Uso de quadro branco.

2. Encontro Ad-hoc: Tirar dúvida do desenvolvedor com a equipe.

3. Design/refatoração: Desenvolvedor planeja como irá implementar nova funcionalidade, conserto ou bug. Muito importante.

4. Rever design: Mudança na proposta do design, não é muito frequente.

5. Novo membro na equipe: Para explicar o projeto para um novo integrante.

46

6. Explicando para um participante secundário: Explicar para um participante sem relação com a implementação, por exemplo equipe de testes, gerente de projeto ou cliente interno. Os diagramas são muito importantes

7. Explicando para um cliente: Desenvolvedores com a responsabilidade de explicar o software. Consideram a menos importante. Usam padrões gráficos nos diagramas.

8. Exposição: Como no método ágil, expor a estrutura ou código.

9. Documentação: Muito importante, alto grau de formalidade e refinamento nos diagramas.

47

Nível de investimento ( 4 tipos):

1 - Provisório: um simples desenho, para entendimento do código ou desingn, rapidamente perdendo o valor.

48

2 - Esboço repetitivo: algo provisório foi redesenhado em diferente contexto ou em partes, como em encontros Ad-hoc ou em explicações para outros.

49

3 - Entrega do desenho: Em alguns casos um esboço repetitivo pode ter um investimento de tempo e esforço, assim virando algo permanente. Isto ocorre mais em revisão de design.

50

4 - Arquivando: Quando o diagrama se torna parte do documento.

51

A. Como os engenheiros usam diagramas em seu trabalho?

Desenvolvedores usam meios transitórios para as atividades de exploração e usam soluções permanentes quando se comunicam com outras pessoas ou todo o grupo.

52

B. Por que os engenheiros usam diagramas em seu trabalho?

Três razões principais:

1. Compreender;

2. Projetar;

3. Comunicar.

53

C. Que convenções gráficas os engenheiros usam?

Os desenvolvedores não seguem qualquer padrão gráfico, na maioria dos casos, os desenvolvedores usaram uma linguagem visual simples caixas-e-flechas cujos elementos assumem significados, dependendo do contexto. No entanto, para a documentação, um estilo mais formal foi escolhido, embora os sistemas de notação padrão foram raramente utilizados.

54

D. Qual é a cultura em torno desses desenhos?

Os resultados mostram uma adoção limitada de ferramentas de desenho. Apesar da disponibilidade de editores visuais, tais como ferramentas de UML, os desenvolvedores não utilizam amplamente.

55

1.Captura dos esboços nos quadros brancos;

2.Integrar engenharia reversa e esboços;

3.Nível de abstração;

4.Visualização compartilhada entre a equipe de desenvolvimento.

56

Como e porque os desenvolvedores usam diagramas?

A notação informal foi usada para apoiar a comunicação cara a cara e as ferramentas atuais não foram capazes de suportar essa necessidade, porque não ajudam a exteriorizar os modelos mentais de código.

57

58