1. Replicação, distribuição e manutenção
1.1. Replicação
1.1.1. Randell
1.1.1.1. Se custos de replicação software fossem iguais aos de replicação de hardware não haveria incentivo para os fabricantes
1.1.1.2. Problemas com produção em massa de cópias de software
1.1.2. Galler
1.1.2.1. Verificar o correto funcionamento do processo de replicação e distribuição através do "Echo-checking"
1.1.2.1.1. Quem replica deve ser cadastrado na biblioteca do programa
1.2. Distribuição
1.2.1. Köhler
1.2.1.1. Distribuição é um problema de organização
1.2.1.2. Centros de Distribuição precisam ter equipes de suporte. É necessária mão de obra qualificada.
1.2.2. Nash
1.2.2.1. Delay entre lançamento do sistema e instalação do usuário
1.2.2.2. Causas do Delay
1.2.2.2.1. Quantidade de réplicas
1.2.2.2.2. Tempo de transporte
1.2.3. Randell
1.2.3.1. Os problemas de distribuição de software são divididos entre três categorias
1.2.3.1.1. Versão inicial
1.2.3.1.2. Correção de erros
1.2.3.1.3. Extensões
1.2.4. Dijkstra
1.2.4.1. A divulgação maciça de softwares carregados de erros é assustador
1.2.4.2. Difusão de conhecimento é o principal objetivo da distribuição.
1.3. Manutenção
1.3.1. Köhler
1.3.1.1. Manutenção e distribuição são interdependentes
1.3.1.2. O teste de campo é bem sucedido quando os programas que são testados tem um número razoável de falhas
1.3.1.3. Duração do teste de campo
1.3.1.3.1. Quantidade de tempo da máquina
1.3.1.3.2. Frequência da máquina
1.3.1.3.3. Complexidade do programa
1.3.2. Gillette
1.3.2.1. Processo de manutenção
1.3.2.1.1. Código de correção
1.3.2.1.2. Melhorias
1.3.2.1.3. Código extenso
1.3.3. Babcock
1.3.3.1. Preocupação com a divisão da responsabilidade pela manutenção entre o usuário e o fabricante
2. Sistema de avaliação
2.1. Teste de Aceitação
2.1.1. Llewelyn e Wickens
2.1.1.1. Grandes organizações deveriam testar os softwares em suas instalações antes de comprá-los
2.1.2. Kolence
2.1.2.1. Os usuários devem receber as especificações antes mesmo destes serem implementados
2.1.3. Opler
2.1.3.1. O plano de teste deve ser desenvolvido considerando todos os elementos da especificação escrita
2.1.3.1.1. Hardware
2.1.3.1.2. Linguagem de programação
2.1.3.1.3. Facilidades do sistema
2.1.3.1.4. Documentação
2.1.3.1.5. Desempenho
2.1.3.1.6. Confiabilidade
2.1.4. Dijkstra
2.1.4.1. O teste é uma forma muito ineficiente de se convencer sobre a correção de um sistema
2.1.5. Llewelyn
2.1.5.1. O teste é um dos alicerces de toda empresa científica
2.1.6. Galler
2.1.6.1. O usuário não deve pagar por um software que não funciona
2.1.7. Babcock
2.1.7.1. São necessárias métricas de software análogas às métricas de hardware
2.2. Monitoramento de desempenho
2.2.1. Gillette
2.2.1.1. Monitoramento de desempenho é usado como ferramenta de manutenção para encontrar gargalos e deficiências
2.2.2. Perlis
2.2.2.1. Os sistemas deveriam acumular arquivos com informações de desempenho que seriam enviados para análise do fabricante
2.2.3. Kolence
2.2.3.1. Quase todos os programas podem ser melhorados (entre 10 e 20 por cento), sem mudanças no projeto, em um ou dois dias
2.2.4. Smith
2.2.4.1. Monitores de desempenho podem levar a melhorias incrementais desnecessárias
2.2.5. Gries
2.2.5.1. Monitores de desempenho opcionais devem fazer parte de compiladores, para que estejam disponíveis aos usuários
2.2.6. Galler
2.2.6.1. Monitores de desempenho devem ser parte do sistema, e não de compiladores individuais
3. Feedback dos usuários para os fabricantes
3.1. Haller
3.1.1. Correção de um sistema
3.1.1.1. Grupo de manutenção
3.1.1.2. Resposta em uma semana
3.1.2. Sobre o desempenho do sistema
3.1.2.1. Grupo de produção
3.1.2.2. Resposta em um mês
3.1.3. Pedidos de facilidades extras
3.1.3.1. Grupo de design
3.1.3.2. Resposta em um ano
3.2. Hastings
3.2.1. O usuário precisa de um meio rápido para obter correção de bugs
3.3. Buxton
3.3.1. O melhor método de feedback é o lucro
3.4. Galler
3.4.1. O usuário não está na posição de rejeitar um sistema importante produzido por um grande fabricante
4. Documentação
4.1. Selig
4.1.1. Documentação é essencial
4.1.1.1. Economizar dinheiro
4.1.1.2. Evitar o caos
4.2. Letellier
4.2.1. Manuais devem ser de dois tipos
4.2.1.1. Introdução geral para a solução do problema
4.2.1.2. Manual técnico que forneça os serviços disponíveis e regras exatas de funcionamento
4.3. Gillette
4.3.1. A manutenção da documentação deve ser automatizada
4.4. Gries
4.4.1. A documentação do OS/360 é automatizada através da utilização de um sistema de editor de texto
5. Reprogramação
5.1. Babcock
5.1.1. Conversão
5.1.1.1. Custo elevado
5.1.1.1.1. Aumento do hardware ou troca de máquina
5.1.2. Reescrita
5.1.2.1. Linguagens de mais alto-nível
5.1.2.2. Necessária para que novos sistemas lidem com mais aplicações e mais rápido
5.1.2.3. É o mais caro dos três
5.1.3. Futuras tendências
5.1.3.1. Integração de software e hardware
5.1.3.2. Hardware e software têm de lidar com problemas de transporte
5.1.3.3. Portabilidade e independência de software e hardware
5.1.3.3.1. Baratear o custo
6. Introdução
6.1. Estabelecendo metas realistas
6.1.1. Opler
6.1.1.1. Sistemas com grande complexidade e tamanho = crescimento de erros
6.1.2. Dijkstra
6.1.2.1. Nem sempre os fabricantes são os culpados
6.1.2.2. Eles merecem mais compreensão dos usuários
6.1.3. Llewelin
6.1.3.1. São necessárias estimativas de entrega mais realistas dos fabricantes
6.1.3.2. Dinheiro e tempo são perdidos no planejamento
6.1.4. Randell
6.1.4.1. Os usuários devem exigir garantias contratuais
6.2. Qualidade dos lançamentos iniciais de sistemas
6.2.1. Babcock
6.2.1.1. A versão inicial de um sistema deve funcionar bem, ainda que com recursos limitados
6.2.1.2. Filosofias básicas devem ser implementadas para possíveis evoluções
6.2.2. Genuys
6.2.2.1. São necessárias versões de pré lançamento do sistema, esteja elas funcionando bem ou não
6.2.3. Galler
6.2.3.1. Os fabricantes não devem entregar um sistema se ele não estiver funcionando bem, embora não precise estar totalmente isento de bugs
6.2.4. David
6.2.4.1. Projetar o sistema em módulos para que possam ser feitos, testados e modificados de forma independente
6.2.5. Kolence
6.2.5.1. Grandes sistemas devem evoluir ao invés de serem produzidos de uma só vez
6.2.5.2. Deve existir um pequeno núcleo inicial do sistema que funcione muito bem
6.2.6. Randell
6.2.6.1. Os usuários são tão culpados por aceitarem o sistema prematuramente quanto os fabricantes por liberarem prematuramente
6.2.7. Samelson
6.2.7.1. O verdadeiro problema está no usuário, pois, como ele precisa do software, quer levá-lo mesmo que não esteja correto
6.2.8. Glennie
6.2.8.1. Clientes não devem ser usados como meios para testes
6.3. Frequência de versões do sistema
6.3.1. Babcock
6.3.1.1. Menos lançamentos com principais melhorias são melhores do que lançamentos frequentes com pequenas melhorias
6.3.1.2. Para ter um sistema de sucesso é preciso nunca fazer uma mudança nele, porém isso não é prático
6.3.2. Gillette
6.3.2.1. Usuários lidam mais facilmente com o recebimento de atualizações mensais com pequenas mudanças incrementais
6.3.3. Opler
6.3.3.1. Clientes precisam que erros sejam corrigidos e que a frequência de liberação não seja muito demorada
6.3.4. d'Agapeyeff
6.3.4.1. Utilizar versões antigas para implementar novas versões
6.3.5. Pinkerton
6.3.5.1. Versões menos frequentes causam
6.3.5.1.1. Mais estabilidade
6.3.5.1.2. Mais feedback do usuário
6.4. Responsabilidade por sistemas modificados
6.4.1. Babcock
6.4.1.1. Quando não existe modificações pelos usuários, os fabricantes devem ser responsáveis por toda a manutenção e melhorias do sistema
6.4.2. Paul
6.4.2.1. Difícil definir as fronteira entre as partes afetadas e não afetadas do sistema
6.4.3. Galler
6.4.3.1. Fabricantes querem absolver-se da responsabilidade sob o sistema após qualquer mudança que o usuário faz
6.4.4. Naur
6.4.4.1. Se deseja modificar um sistema, é melhor escolher um fabricante e um sistema que permita isso
6.4.5. Bemer
6.4.5.1. Melhorar os meios de especificar interfaces dos programas
6.4.6. Berghuis
6.4.6.1. Nenhum fabricante é responsável por qualquer modificação feita pelo usuário
6.4.6.1.1. ECMA
7. Personalidades
7.1. Alan Perlis
7.1.1. Nasceu em 1922
7.1.2. Morreu em 1990
7.1.3. Natural dos Estados Unidos
7.1.4. Cientista da computação conhecido por seu trabalho pioneiro em linguagens de programação
7.1.5. Primeiro a receber o Prêmio Turing
7.1.5.1. ALGOL
7.1.6. Publicações
7.1.6.1. Um curso introdutório de programação de computadores
7.1.6.2. Uma visão de linguagens de programação
7.1.6.3. Introdução à Ciência da Computação
7.1.6.4. Métricas de Software: uma análise e avaliação
7.2. Brian Randell
7.2.1. Nasceu em 1936
7.2.2. Natural do Reino Unido
7.2.3. Cientista da computação, especialista em tolerância a falhas em software e confiabilidade
7.2.4. Publicações
7.2.4.1. Implementação em Algol 60
7.2.4.2. As origens dos computadores digitais: trabalhos selecionados
7.2.4.3. Máquina analítica de Ludgate de 1909
7.2.4.4. Alan Turing e as origens dos computadores digitais
7.2.4.5. Engenharia de Software em 1968
7.2.4.6. Da máquina analítica até a eletrônica do computador digital: as contribuições de Ludgate, Torres e Bush
7.2.4.7. Memórias das Conferências de Engenharia de Software da OTAN
7.3. Ken W. Kolence
7.3.1. Fundou a Boole & Babbage em 1967
7.3.1.1. Primeira empresa de software no Vale do Silício
7.3.2. Recebeu seu diploma de Mestre em Matemática, com um "especializada em computadores digitais", da Universidade de Illinois
7.3.3. Um pioneiro da indústria de software e executivo computador, ele era a manutenção e operações na cabeça do UNIVAC para a Marinha