Desenvolvimento Colaborativo de Software

1
Desenvolvimento Colaborativo de Software

• Cleidson de Souza
• Departamento de Informática
• Universidade Federal do Pará
• cdesouza_at_ufpa.br

2
Roteiro

• Desenvolvimento Colaborativo de Software
• Colaboração em Engenharia de Software
• A Importância da Arquitetura de Software
• O Estudo de Caso MCW e BSC
• Desenvolvimento Global de Software
• Definição
• Motivação
• Problemas
• Soluções

3
Desenvolvimento de Software

• Desenvolvimento de software é uma tarefa
  inerentemente colaborativa
• Diferentes habilidades são necessárias
• Analistas tem de compreender o cliente,
  projetistas precisam verificar diferentes
  aspectos (tolerância a falhas, segurança,
  escalabilidade, flexibilidade, etc) e assim por
  diante
• Diferentes reuniões para a coordenação das
  atividades
• Interação com outros sistemas (sociais,
  culturais, e organizacionais)

4
Evidências Empíricas

• Comunicação formal e informal formal exige mais
  de 50 do tempo dos engenheiros de software
  (Perry et. al, 1994)
• Atividades colaborativas de uma maneira geral
  correspondem a 70 do tempo dos desenvolvedores
  de software (Vessey and Sravanapudi, 1995)
• Problemas de comunicação e coordenação são um dos
  3 principais problemas em desenvolvimento de
  software(Curtis et al. 1988).

5
Evidências Empíricas (2)

• Utilização de ferramentas de GCS para coordenação
  (1995)
• Reuso de software (1999)
• Reuso de arquiteturas de software
• Utilização de PowerPoint pelos arquitetos de
  software
• Necessidade de convencer times de
  desenvolvimento, clientes e outros a implementar
  uma arquitetura
• Necessidade de disponibilizar arquiteturas
  através da Web
• Entre outros.

6
Ferramentas de Apoio a Colaboração

• Gerência de configuração
• CVS, Subversion, ClearCase Vários engenheiros de
  software podem fazer modificações no software em
  paralelo
• Processo de software
• RUP, WebAPSEE Estabelece papéis, prazos,
  artefatos a serem empregados na atividade de
  desenvolvimento de software

7
Jazz (IBM)
8
Ariadne
9
Práticas colaborativas

• Programação em Pares, da programação extrema
• Decomposição modular e separação entre
  especificação das interfaces e sua implementação
• Inspeção de software
• Etc.

10
O caso MCW

• Um projeto MCW
• 5 sub-times arquitetos, testes, cliente,
  servidor e infra-estrutura
• A separação entre os times era feita através de
  APIs (interfaces)
• O time servidor implementava as APIs necessárias
  ao time cliente
• O time de infra-estrutura implementava serviços
  comuns à todos

11
O caso MCW (2)

• Ferramentas
• Sistema de gerência de configuração (Grinter,
  1995)
• Quem está alterando que partes do código
• Quem alterou que partes do código
• Lista de emails
• Notificação de modificações nas interfaces
  (APIs)
• Procura de experts em determinados componentes

12
O caso MCW (3)

• A organização adotou um modelo de reuso de
  componentes, portanto os vários subtimes do
  projeto MCW tinham de re-utilizar componentes da
  organização
• Como conseqüência, diversas problemas de
  comunicação
• Times que não estavam cientes de seus clientes,
  dos times que iriam utilizar suas APIs
• Time que não estavam cientes de seus servidores,
  do times que iriam implementar as APIs que eles
  precisavam

13
O caso MCW (4)

• Lição a ser lembrada
• Interação entre os aspectos técnicos (APIs,
  modularidade, arquiteturas de software, etc) e os
  aspectos não-técnicos (organizacionais, sociais,
  etc) necessários a qualquer sistema computacional

14
A Importância da Arquitetura

• Dependências
• Entre os artefatos produzidos durante o processo
  de desenvolvimento e
• Entre as atividades do processo de
  desenvolvimento
• Coordenação pode ser definida como a gerência de
  dependências (Malone e Crowston, 1995).

15
A Importância da Arquitetura (2)

• Modularidade
• a divisão de um sistema em partes para que
  possamos tratar estas partes isoladamente.
• Um mecanismo para lidar com a complexidade no
  desenvolvimento de produtos, não apenas software.
• Um sistema deve ser dividido em módulos para
  facilitar sua construção
• Parnas propôs o princípio de ocultamento da
  informação como um critério indicando como os
  módulos devem ser separados.

16
A Importância da Arquitetura (3)

• Módulos não devem expor as suas partes que podem
  mudar (seus detalhes de implementação) para que
  eles não afetem seus clientes
• Este princípio também facilita a coordenação do
  desenvolvimento de software, porque minimiza a
  necessidade de comunicação entre os
  desenvolvedores

17
A Importância da Arquitetura (4)

• A arquitetura do software define então, não
  somente os aspectos técnicos do software, mas
  também define como a coordenação do software será
  feita
• Se um componente interage com diversos outros
  componentes isto significa que o time que
  implementa este componente terá de interagir com
  diversos outros times
• Times que interagem com freqüência ou que estão
  colocados deveriam implementar módulos que estão
  conectados.

18
A Importância da Arquitetura (5)

• Lição a ser lembrada
• A definição da arquitetura de um software também
  define os padrões de interação e colaboração
  entre os engenheiros de software
• Isto se torna mais importante em projetos
  distribuídos de software

19
Desenvolvimento Distribuído de Software

• Significa que o desenvolvimento de software está
  distribuído em diversos sítios diferentes
  localizados em cidades diferentes
• Porque é interessante?
• Pela dificuldade da coordenação das atividades
• O caso SERPRO
• Clientes em Brasília
• Desenvolvimento em Belém

20
Desenvolvimento Global de Software

• Significa que o desenvolvimento de software está
  distribuído em diversos sítios localizados em
  países diferentes e até mesmo diferentes
  continentes.
• Exemplo
• Lucent tem desenvolvimento nos EUA, Alemanha,
  Inglaterra, Índia e Brasil
• IBM desenvolve nos EUA, Irlanda e Canadá, e testa
  na China
• Motorola desenvolve nos EUA e testa no Brasil
  (Recife)
• Dell desenvolve software nos EUA e no Brasil
  (POA)
• Siemens desenvolve software na Alemanha, Brasil,
  EUA, Polônia, e vários outros países

21
Desenvolvimento Global de Software - Motivação

• Compra de empresas e união (merge) de empresas
  para complementar produtos desenvolvidos por
  companhias
• Para a participação em determinados mercados,
  certas leis requerem o desenvolvimento de certas
  operações localmente
• Partes da organização devem estar perto de onde o
  mercado para elas existe
• Competição por profissionais competentes

22
Desenvolvimento Global de Software - Motivação

• Organizações acreditam que a distribuição possa
  levar a desenvolvimento de software em tempo
  integral (round-the-clock development), o que
  levaria a redução de custos
• Quando alguém pára de desenvolver na California,
  outra pessoa começa a desenvolver na Índia
• Chamado de siga o sol (follow-the-sun)
• Em teoria diminui o tempo de desenvolvimento em
  50

23
Desenvolvimento Global de Software - Problemas
24
Desenvolvimento Global de Software - Problemas

• Diferença em Fusos Horários
• Comunicação
• Informal
• Linguagem
• Coordenação
• Cultura
• Confiança
• Encontrar pessoas (experts)

25
Efeitos da Distância

• Dificuldade na comunicação, através de email ou
  em horários inadequados devido ao fuso horário
• Perda da comunicação informal, que é essencial
  para a coordenação do projeto
• Dificuldade de saber quando contactar uma
  determinada pessoa
• Dificuldade de saber quem é responsável por um
  determinado componente (quem projetou ou
  implementou) para resolver um problema.

26
Desenvolvimento Global de Software - Problemas de
Cultura

• Culturas diferentes geralmente tem comportamento
  diferente
• Alemães ligam para um desenvolvedor e dizem Tem
  um problema no seu código.
• Os ingleses esperam uma abordagem mais educada
  onde uma pessoa sugere problemas no código da
  outra
• Diferenças no idioma e na forma de utilização do
  idioma
• Feriados e normas religiosas são diferentes

27
Desenvolvimento Global de Software - Problemas

• Em resumo
• Desenvolvimento de software distribuído é mais
  lento que desenvolvimento quando colocado
  (Herbsleb e colegas, 2000)
• Mas, é necessário!

28
Desenvolvimento Global de Software - GSP

• Global Software Project (GSP)
• Projeto de desenvolvimento distribuído realizado
  por estudantes de mestrado
• Siemens testa tecnologias, práticas, etc
• Casos de sucesso são replicados na organização

29
Desenvolvimento Global de Software - Soluções
(Carmel)

• Tecnologias Colaborativas e Infra-Estrutura de
  Tele-Comunicações
• Dinâmicas de Grupo para Motivação de Times (team
  building)
• Pessoas que viajam para outros sites com certa
  frequência para servem como ponte para a
  facilitar a colaboração entre os sites
• Ajuda a estabelecer confiança entre os times

30
Desenvolvimento Global de Software - Soluções
(Carmel)

• Lideranças
• Arquitetura do Software e Alocação de Tarefas
• Utilização de Metodologias de Desenvolvimento de
  Software (Processo de Software)

31
Desenvolvimento Global de Software - Soluções
32
Conclusões

• Desenvolvimento de software é uma atividade
  colaborativa que requer ferramentas, abordagens,
  e técnicas para seu sucesso
• Como treinar profissionais?
• Desenvolvimento de software é hoje uma tarefa
  globalizada
• Problemas difíceis, mas as soluções estão sendo
  encontradas
• Excelente Oportunidade de Negócios!

33
Desenvolvimento Global de Software - Para saber
mais

• IEEE Software, vol. 18, Issue 2, March/April
  2001, Special Issue in Global Software
  Development.
• Car, 1999 Carmel, Erran. The explosion of
  global software teams. Computerworld magazine,
  Dec 08, 1997.
• Car, 2001 Carmel, E. Global Software Teams a
  framework for managerial problems and solutions.
  To appear as chapter for the book Global
  Information Technology And Electronic Commerce
  Issues for the New Millenium. Edited by P.
  Palvia, S. Palvia and E. Roche. To be published
  by Ivy League Publishing.
• Conferência sobre o tema http//www.icgse.org

34
Cronograma Atualizado

• 30/01/06 - Considerações Finais
• 01/02/06 - Avaliação. Assunto Todo material
  visto em sala de aula
• Início dos Seminários em 06/02
• Apresentação?