Serviços

1. Primeiras Idéias

1.1. Estabelecendo Metas Realistas

1.1.1. Opler

1.1.1.1. Empresas x Usuários

1.1.1.2. Programas maiores

1.1.1.3. Mais erros

1.1.2. Dijkstra

1.1.2.1. Empresas precisam de melhores usuários

1.1.3. Llewelyn

1.1.3.1. Dados falsos

1.1.3.2. Perda de tempo e dinheiro

1.1.3.3. Dados mais realistas são necessários

1.1.4. Randell

1.1.4.1. Garantias contratuais

1.2. Versão Inicial do Sistema

1.2.1. Babcock

1.2.1.1. Filosofias básicas do sistema funcionando bem

1.2.1.2. Versão inicial limitada

1.2.1.3. Filosofias básicas implementadas para possíveis evoluções

1.2.2. Genuys

1.2.2.1. Lançamento de pré-versões

1.2.2.2. Funcionando bem ou não

1.2.2.3. Garantir treinamento das equipes

1.2.3. Galler

1.2.3.1. Software tem quem funcionar bem

1.2.3.2. Não precisa ser perfeito

1.2.3.3. Antes disso não entrega nada

1.2.4. David

1.2.4.1. Modularização independete

1.2.4.2. Planejamento de gerenciamento de módulos do sistema

1.2.5. Kolence

1.2.5.1. Grandes sistemas devem evoluir

1.2.5.2. Núcleo inicial funcionando muito bem

1.2.6. Randell

1.2.6.1. Softwares prematuros. Usuários tão culpados quanto fabricantes

1.2.7. Samelson

1.2.7.1. Se o usuário leva o sistema numa versão ruim, ele é o culpado

1.2.8. Glennie

1.2.8.1. Clientes não podem ser usados como testers

1.3. Frequência de Versões

1.3.1. Babcock

1.3.1.1. Menos lançamento, contendo as principais atualizações

1.3.2. Gilette

1.3.2.1. Usa exemplo da atualização do sistema da CDC

1.3.2.2. Testes mostraram que usuários que recebiam atualizações mensais lidavam melhor com pequenas mudanças incrementais

1.3.3. Opler

1.3.3.1. Política da época: Versão nova a cada 90 dias

1.3.3.2. Usuário precisa de atualizações constantes

1.3.3.3. Melhorias em grupo são melhores para sistemas em conjunto

1.3.4. Hastings

1.3.4.1. Maioria dos erros são triviais

1.3.4.2. Erros de documentação

1.3.5. Pinkerton

1.3.5.1. Versões menos frequentes são mais estáveis

1.3.5.2. Faz com que feedback seja melhor

1.3.6. Galler

1.3.6.1. Atualizações frequentes são necessárias

1.3.6.2. Mas a frequência não pode ser grande

1.4. Responsabilidade pelas Modificações no Sistema

1.4.1. Babcock

1.4.1.1. Quando não existe modificação, a empresa é responsável por toda a atualização e melhoria

1.4.2. Paul

1.4.2.1. Partes afetadas e não afetadas pelas modificações estão muito próximas

1.4.2.2. As vezes o usuário não tem escolha entre sistemas abertos ou não

1.4.3. Galler

1.4.3.1. Preocupação de que fabricantes usem essa proximidade e se isentem de responsabilidades

1.4.4. Naur

1.4.4.1. Se for modificar, procure um software livre e que a empresa permita a modificação

1.4.4.2. A maioria dos softwares saem da garantia depois de modificações.

1.4.5. Bemer

1.4.5.1. Melhorar os meios de especificar a interface dos programas

1.4.6. Berghuis

1.4.6.1. Documento escrito pela ECMA

1.4.6.1.1. ECMA: European Computer Manufacturer Association

1.4.6.2. Nenhum fabricante é responsável por qualquer modificação feita pelo usuário

2. Replicação, Distribuição e Manutenção

2.1. Distribuição

2.1.1. Köhler

2.1.1.1. Distribuição é um problema de organização

2.1.1.2. Centros de Distribuição precisam ter equipes de suporte. Mão de obra qualificada é necessária

2.1.2. Nash

2.1.2.1. Delay entre lançamento do sistema e instalação do usuário

2.1.2.2. Causas do delay: Quantidade de réplicas e tempo de transporte

2.1.3. Randell

2.1.3.1. Divisão da Distribuição em 3 categorias

2.1.3.1.1. Versão Inicial

2.1.3.1.2. Correção de Erros

2.1.3.1.3. Extensões

2.1.4. Dijkstra

2.1.4.1. Objetivo principal: Difusão de conhecimento

2.1.4.2. Pior pesadelo: distribuição de softwares carregados de erros

2.2. Replicação

2.2.1. Randell

2.2.1.1. Custos de replicação software e hardware

2.2.1.2. Se fossem iguais, não haveria incentivo para os fabricantes

2.2.1.3. Problemas com produção em massa de cópias do software

2.2.2. Galler

2.2.2.1. Verificação do processo de replicação

2.2.2.2. Echo-Checking

2.2.2.3. Quem replica tem q ser cadastrado na Program Library

2.3. Manutenção

2.3.1. Gillette

2.3.2. Köhler

2.3.3. Babcock

2.3.4. Kolence

3. Evolução Sistêmica

3.1. Testes de Aceitação: Llewelyn x artigo The Testing of Computer Software

3.1.1. Llewelyn e Wickens

3.1.1.1. Grandes organizações deviam testar os softwares em suas instalações antes de comprá-los

3.1.2. Kolence

3.1.2.1. Os usuários devem receber as especificações do sistema antes mesmo destes serem implementados

3.1.3. Opler

3.1.3.1. Um plano de teste deve ser desenvolvida considerando todos os elementos da especificação escrita (hardware, linguagem de programação, facilidade do sistema, documentação, desempenho, confiabilidade, etc.)

3.1.4. Dijkstra

3.1.4.1. O teste é uma forma muito ineficiente de se convencer da exatidão do programa

3.1.5. Llewelyn

3.1.5.1. O teste é um dos fundamentos de toda a empresa científica. Seria bom ter testes independentes de função e desempenho do sistema publicado

3.1.6. Babcock

3.1.6.1. Precisamos de métricas de software análogos as métricas de hardware existentes.

3.1.7. Galler

3.1.7.1. Se o hardware não funciona o usuário não paga

3.2. Monitoramento de Desempenho: Performance de um sistema já instalado

3.2.1. Gillette

3.2.1.1. Ferramenta de manutenção para encontrar gargalos e deficiências

3.2.2. Perlis

3.2.2.1. Sistemas de entrega deverão dispor de instalações para a acumulação de arquivos de informações de desempenho

3.2.2.2. Envio dos relatório de desempenho para análise

3.2.3. Kolence

3.2.3.1. Sobrecarregar o sistema

3.2.3.2. Informação do uso de disco para uma melhor reorganização dos dados

3.2.3.3. Melhorias de 10 a 20% no desempenho sem alterar o projeto

3.2.4. Smith

3.2.5. Gries

3.2.5.1. Monitores de desempenho opcionais devem ser construído em compiladores, de modo a estar disponível para os usuários

3.2.6. Galler

3.2.6.1. Monitores de desempenho devem ser parte do sistema, e não em compiladores individuais.

4. Feedback de Manutenção para Usuários

4.1. Tentativa de classificação das informações que o usuário gostaria de receber dos fabricantes

4.1.1. Haller

4.1.1.1. Três malhas, com diferentes tempo de resposta

4.1.1.1.1. Correção de Erros no sistema

4.1.1.1.2. Feedback de desempenho do sistema

4.1.1.1.3. Especificações extras pedidas pelo usuário

4.1.2. Hastings

4.1.2.1. Usuários precisam de respostas rápidas para correção de bugs

4.1.3. Babcock

4.1.3.1. Diz que o melhor sistema da época é o da IBM, porém é arcaico e falho

4.1.4. Buxton

4.1.4.1. Melhor feedback é o lucro. Se o software não vende, quer dizer que foi rejeitado

4.1.5. Galler

4.1.5.1. Usuários típicos não estão na posição de rejeitar um sistema importante produzido por um grande fabricante.

5. Documentação

5.1. Concepção e produção de documentação

5.1.1. Selig

5.1.1.1. Documentação essencial

5.1.1.2. Evitar Caos

5.1.1.3. Poupar dinheiro

5.1.2. Letellier

5.1.2.1. Manuais devem ser de dois tipos:

5.1.2.1.1. Introdução geral à solução do problema

5.1.2.1.2. Manual técnico

5.1.3. Gillette

5.1.3.1. A documentação da manutenção deve ser automatizada

5.1.4. Gries

5.1.4.1. A manutenção e distribuição da documentação do OS / 360 é automatizada através do uso de um editor de texto do sistema

6. Reprogramação

6.1. Babcock

6.1.1. Único interessado no assunto.

6.1.2. Não houve discussão direta sobre os problemas na reprogramação de sistemas de hardware nem de erros em alterações de usuários

6.1.3. Dividiu o problema em 3 áreas

6.1.3.1. Conversão

6.1.3.1.1. Custo elevado

6.1.3.1.2. Aumento do Hardware ou troca de máquina

6.1.3.2. Re-Escrita dos sistemas e programas

6.1.3.2.1. Necessária para que novos sistemas lidem com mais aplicações e mais rápido

6.1.3.2.2. Mais caro de todos os 3 problemas

6.1.3.3. Tendências futuras

6.1.3.3.1. Hardware e software têm de lidar com problemas de transporte

6.1.3.3.2. Pensamentos sobre portabilidade e independência de hardware

6.1.3.3.3. Achar meios de tornar hardware e software portáteis, para baratear o custo