Giga Mundo - Computação

Princípios Gerais

Nº

Descrição do princípio

Situação

1

Qualidade em primeiro lugar

2

Qualidade está nos olhos de quem vê, portanto busque compreendê-la sob os diversos pontos de vista envolvidos (cliente, usuário, desenvolvedor, empresa desenvolvedora, etc.)

3

Produtividade e qualidade são inseparáveis: quanto maior a demanda por qualidade, mais baixa será a produtividade e vice-versa

4

Software de alta qualidade é possível, entretanto seu desenvolvimento pode ser muito custoso

5

Não tente inserir qualidade no fim do processo

6

Baixa confiabilidade é pior do que baixa eficiência

7

Dê produtos intermediários ao cliente o quanto antes, isso ajuda a motivá-lo, bem como à equipe de desenvolvimento e consegue-se também o feedback do usuário

8

Comunique-se com clientes e usuários

9

Alinhe incentivos para desenvolvedor e cliente

10

Planeje um protótipo descartável

11

Construa o tipo certo de protótipo (descartável ou evolucionário)

12

Construa as características certas em um protótipo

13

Construa protótipos descartáveis rapidamente

14

Cresça sistemas incrementalmente

15

Quanto mais do sistema for visto, mais será pedido, então se prepare (equipe, artefatos, etc.) para a possível necessidade de atender novas exigências

16

Mudanças durante o desenvolvimento são inevitáveis, então mantenha metodologias e processos flexíveis

17

Se possível, compre em vez de construir, uma vez que o custo para o desenvolvimento pode ser superior e incluir muito mais riscos

18

Construa softwares de tal forma que o manual do usuário seja bem curto, sendo assim, bons projetos de interfaces são essenciais

19

Todo problema, por mais complexo que seja, possui uma solução, mas cuidado com as soluções enganosas que prometem resolver todos os seus problemas facilmente!

20

Registre todas as assunções feitas durante o projeto, por mais banais que elas lhe pareçam – pois elas podem não ser tão banais para outra pessoa, ou mesmo você pode vir a esquecer delas

21

Você pode empregar linguagens diferentes para fases diferentes, isto é, optar por exemplo por linguagens e técnicas que permitam facilmente a criação de um protótipo descartável e, na fase de desenvolvimento, escolher outras mais robustas

22

Opte sempre por adotar as técnicas certas antes de pensar nas ferramentas certas

23

Use ferramentas, mas seja realista: não há ferramentas milagrosas, logo a experiência, documentação e comunicação da equipe serão melhores aliadas do que a escolha de uma boa ferramenta

24

Dê ferramentas de software a bons engenheiros, pois obviamente são eles que saberão fazer melhor uso delas – logo, ferramentas de software em mãos de maus engenheiros não significará necessariamente produtividade

25

Ferramentas CASE são caras, entretanto, começamos a ver algumas opções free ou open source. Leve em consideração o custo das ferramentas em seu projeto!

26

Know when é tão importante quanto know how

27

Pare quando você alcançar seu objetivo, evitando desperdiçar recursos

28

Conheça métodos formais, pois aliados a fortes habilidades matemáticas podem ajudá-lo a descobrir e resolver problemas

29

Alinhe reputação com organização, considerando assim o “como” um engenheiro de sua equipe se sente quando erros são encontrados em seu projeto e quais as repercussões disso para o projeto, a equipe e para a empresa

30

Cuidado quando estiver seguindo determinadas técnicas ou ferramentas porque outros a adotam – elas podem não ser as melhores para o seu projeto

31

Busque conhecer as novas técnicas, tecnologias e ferramentas que aparecem no mercado – é a melhor forma para que mais tarde você possa fazer boas escolhas para o seu projeto

32

Use padrões de documentação, com uma linguagem clara e facilmente referenciável

33

Todo documento precisa de um glossário

34

Todo documento de software precisa de um índice

35

Use o mesmo nome para o mesmo conceito sempre que precisar, não sinônimos, assim ficará mais claro para a equipe o que se deseja

36

Muitas das pesquisas de software / engenharia de software não são facilmente empregadas pelas empresas, por diversas razões, então esteja atento a isso

37

Assuma suas responsabilidades no projeto

Princípios de Engenharia de Requerimentos

Engenharia de requerimentos é o conjunto de atividades que inclui:

· Elicitar ou aprender sobre um problema que precisa de uma solução;

· Especificar o comportamento externo (caixa preta) de um sistema que pode resolver aquele problema;

O produto final da engenharia de requerimentos é a especificação de requerimentos

Nº

Descrição do princípio

Situação

38

Lembre-se de que um mau levantamento de requerimentos leva a estimativas de custos e prazos ruins, sendo as cinco principais causas das estimativas pobres: mudanças de requerimentos freqüentes, requerimentos faltando, comunicação insuficiente com usuários, especificação pobre de requerimentos e análise insuficiente

39

Determine (defina, compreenda) o problema antes de escrever os requerimentos

40

Determine os requerimentos agora, não mais tarde

41

Corrija erros de especificação de requerimentos agora, pois quanto mais tarde for sua correção no processo de desenvolvimento, mais custosa será sua reparação

42

Protótipos reduzem riscos em seleção de interfaces de usuários

43

Registre por que requerimentos foram incluídos

44

Identifique subconjuntos mínimos de requerimentos segundo sua importância

45

Revise os requerimentos

46

Evite tentar projetar na fase de levantamento de requerimentos

47

Use as técnicas corretas, pois cada técnica pode ser melhor empregada em um tipo de aplicação

48

Use múltiplas visões (análise orientada a objetos, máquinas de estados finitos, etc) dos requerimentos, uma para cada parte do problema

49

Organize os requerimentos da melhor forma possível a fim de evidenciar o relacionamento / dependência entre eles, bem como facilitar a compreensão

50

Priorize requerimentos a fim de que se possa conhecer sua ordem de relevância para a aplicação

51

Escreva de forma concisa, coerente e não-ambígua

52

Enumere separadamente cada requerimento, facilitando assim a identificação do mesmo

53

Reduza ambigüidade em requerimentos

54

Aumente, nunca substitua, a linguagem natural – se possível, mantenha lado a lado uma especificação feita em linguagem natural e outra em uma linguagem mais formal, facilitando assim a compreensão por leigos sem prejudicar os detalhes técnicos

55

Escreva em linguagem natural antes de especificar em um modelo mais formal

56

Mantenha a especificação de requerimentos legível

57

Especifique confiabilidade pormenorizadamente a fim de transmitir a real idéia do que significará confiabilidade no software

58

Especifique quando ambiente viola comportamento “aceitável”

59

Crie TBD (to be determined) auto-destrutíveis, ou seja, especificando quem deve resolver o TBD e até quando

60

Armazene requerimentos em uma base de dados, facilitando assim o acesso a informações

Princípios de Design (Projeto)

Design / Projeto é o conjunto de atividades que inclui:

· Definir uma arquitetura para o software que satisfaça os requerimentos;

· Especificar um algoritmo para cada componente de software na arquitetura;

O produto final do design / projeto é a especificação de design / projeto

Nº

Descrição do princípio

Situação

61

A transição de requerimentos para projeto não é fácil

62

Vincule cada requerimento a cada parte do projeto destinada a contribuir direta ou indiretamente

63

Avalie alternativas (escolha de arquiteturas, ferramentas, etc)

64

Projeto sem documentação não é projeto

65

Aplique de forma eficiente o encapsulamento

66

Não reinvente a roda (reaproveite tudo o que é possível)

67

KISS (Keep it simple, stupid)

68

Evite casos especiais numerosos. Se você encontrou muitos casos especiais, você provavelmente adotou uma solução inapropriada. Repense-a e reprojete o algoritmo.

69

Minimize a distância intelectual (distância entre o problema do mundo real e a solução computadorizada para o problema). Quanto menor a distância intelectual, mais fácil será manutenir o software. Abordagens de projeto tais como Projeto Orientado a Objetos visam reduzir a distância intelectual

70

Mantenha projeto sob controle intelectual (um projeto é dito sob controle individual se ele é criado e documentado de tal forma que seus criadores e mantenedores compreendem-no completamente). Geralmente tais projetos são construídos hierarquicamente e com múltiplas visões

71

Mantenha integridade conceitual (emprego de um número limitado de “formas” de projeto a fim de representar de forma mais uniforme).

72

Erros conceituais são mais significantes do que erros sintáticos

73

Use acoplagem (medida que informa quão inter-relacionados dois componentes de software estão) e coesão (medida de quão relacionada as funções realizadas por um componente de software são). O ideal é baixa acoplagem e alta coesão!

74

Projete seu software já prevendo a possibilidade de alterações. Para acomodar mudanças, é importante que o software seja: modular, portável, maleável, de mínima distância intelectual, sob controle intelectual e que exiba integridade funcional.

75

Projete pensando na fase de manutenção, onde os custos são altos (e mais agravados devido a maus projetos)

76

Projete pensando na possibilidade de erros aparecerem (acredite, eles aparecerão!)

77

Construa generalidade em seu software (ou seja, ele é capaz de executar suas funções pretendidas sem quaisquer mudanças em uma variedade de situações)

78

Construa flexibilidade em seu software (de tal forma que o software possa ser facilmente modificável)

79

Use algoritmos eficientes (teoria da complexidade dos algoritmos encontra-se aqui, por exemplo)

80

Especificações de módulos devem prover toda a informação que o usuário necessita e nada mais

81

Lembre-se de que a atividade de projetar é multidimensional, ou seja, há diversas dimensões possíveis (visões) em que podemos trabalhar. Lembre-se de garantir que cada interessado poderá compreender as informações contidas em sua dimensão

82

Grandes projetos vêm de grandes projetistas, então não adianta contratar vários projetistas medíocres ou acreditar que basta adquirirem algumas ferramentas e tudo estará bem

83

Quanto melhor você conhece sua aplicação, melhor será o seu desempenho durante o projeto e a implementação

84

Você pode reusar sem necessitar de grandes investimentos

85

Lixo entra, lixo sai (garbage in, garbage out) – isso não deveria ocorrer em seu programa. Certifique-se de que todas as obras encontram-se alinhadas

86

Confiabilidade de software pode ser alcançada por meio de redundância, assim, caso o servidor principal não funcione, o próprio sistema pode procurar por outros arquivos

Princípios de Codificação

Codificação é o conjunto de atividades que inclui:

· Tradução dos algoritmos especificados durante projeto em programas escritos em uma linguagem de programação;

· Tradução, geralmente automática, dos programas em uma linguagem diretamente executável pelo computador;

O produto final da codificação é uma lista de programas bem documentados

Nº

Descrição do princípio

Situação

87

Evite truques (coisas que funcionam de forma “não-tão-fácil” de entender, dificultando assim sua manutenção)

88

Evite variáveis globais (apesar de fáceis de manipular, elas dificultam na hora de encontrar qual rotina está alterando de forma errônea seu valor)

89

Escreva programas e documentação para leitura “de cima para baixo” (da primeira linha até a última)

90

Evite “efeitos colaterais” (respostas ou comportamentos não esperados que um procedimento têm em alguns casos particulares)

91

Use nomes significativos para as variáveis, métodos, classes, bibliotecas, etc.

92

Escreva programas compreensíveis por qualquer pessoa

93

Use estruturas de dados otimizadas, preferencialmente encapsuladas em um componente, a fim de facilitar possíveis mudanças

94

Faça primeiro direito (respondendo conforme o que o usuário espera), depois torne mais rápido (respondendo dentro do tempo que o usuário espera)

95

Comente antes que finalize seu código

96

Documente antes de começar a codificar

97

Execute testes manualmente sobre cada componente

98

Inspecione Código – isso pode ajudá-lo a encontrar certos erros mais rapidamente do que seria possível por meio de somente testes

99

Você pode usar linguagens não estruturadas

100

Código estruturado não é necessariamente bom código

101

Não escreva códigos absurdamente aninhados (códigos com mais de três níveis de aninhamento dificultam sua compreensão)

102

Use linguagens apropriadas para o seu projeto

103

(Desconhecimento na) linguagem de programação não é desculpa (para má qualidade)

104

Conhecimentos em linguagem não é tão importante – se você é um ótimo programador na linhagem D, também será um ótimo programador na linguagem E, mesmo que ainda não a saiba

105

Formate seus programas (uso de endentação e outros bons princípios para o layout de um programa)

106

Não codifique muito cedo (siga cada etapa do projeto e desenvolvimento de forma coerente)

Princípios de Teste

A fase de Teste é o conjunto de atividades que inclui:

· Realização de testes em componentes de software individualmente (teste de unidade) para concluir que eles estão suficientemente próximos do comportamento como especificado na especificação de projeto de componente;

· Realização de testes em conjuntos de componentes testados individualmente (testes de integração) para concluir que eles comportam-se em conjunto de forma próxima o suficiente do esperado;

· Realização de testes em conjuntos completamente integrados de componentes de software (testes de software a nível de sistema) para concluir que eles comportam-se como um sistema de forma suficientemente próxima do especificado na especificação de requerimentos de software;

· Gerar planos de teste de software a nível de sistema;

· Gerar planos de teste de integração de software;

· Gerar planos de teste de unidade;

· Construir o ambiente de testes;

Nº

Descrição do princípio

Situação

107

Documente quais testes verificam quais requerimentos esperados

108

Planeje testes muito antes da hora de testar

109

Não teste seu próprio software – outra pessoa deve ser encarregada disso

110

Não escreva seus próprios planos de testes

111

Testes devem expor a presença de falhas, mas não provam sua corretude!

112

Sotwares com imensa quantidade de erros são inúteis, mas a ausência de erros não quer dizer que o software funcione da forma desejada

113

Um teste de sucesso deve encontrar erros!

114

Metade dos erros são encontrados em 15% dos módulos, sendo assim, tão logo sejam detectados muitos erros, é interessante uma inspeção e revisão completa dos módulos afetados

115

Use testes caixa-preta (verifica se o programa executado comporta-se da forma esperada) e caixa-branca (verifica se o código do programa produz as respostas esperadas para cada tipo de entrada)

116

Um caso de teste deve incluir os resultados esperados

117

Teste entradas de dados inválidas

118

Sempre efetue “stress tests” (testar software acima do limite esperado)

119

É preferível admitir atrasos a reduzir o tempo de testes

120

Use medição de complexidade Mccabe

121

Use medidas de completude de teste efetivo a fim de saber quando declarar um teste completo

122

Busque cobertura de teste efetiva

123

Não integre antes do teste de unidade

124

Instrumente seu software (ou seja, prepare-o para conseguir o máximo de feedback durante o debug da aplicação). Se o ambiente de desenvolvimento oferecer algo do tipo, use-o

125

Sempre que um erro for encontrado, não busque somente remediá-lo. Estude, analise a causa dos erros

126

Não encare a descoberta de erros como algo pessoal. Erros sempre são possíveis, mas busque corrigi-los!

Princípios de Gerenciamento

O gerenciamento é o conjunto de atividades que inclui planejar, controlar, monitorar e reportar todas as atividades de engenharia que participam do desenvolvimento de um software.

Nº

Descrição do princípio

Situação

127

Bom gerenciamento é mais importante que boa tecnologia

128

Use soluções apropriadas

129

Não acredite em tudo o que você lê: qualquer um que esteja “vendendo” sua tecnologia, técnica ou metodologia de gerenciamento citará maravilhas sobre ela, que nem sempre será a verdade (na verdade, raramente é)

130

Entenda as prioridades dos clientes – comunique-se ao máximo e compreenda o que é essencial, desejável e opcional

131

Pessoas são a chave para o sucesso – então, mesmo que os melhores profissionais sejam mais caros, lembre-se que eles são também os mais produtivos!

132

Algumas poucas pessoas boas são melhores que muitas pessoas menos capacitadas (estas cometem mais erros que aquelas)

133

Ouça sua equipe – este é o primeiro passo para criar uma equipe confiante

134

Confie em sua equipe – crie laços de confiança. Sem confiança, como garantir que todos farão seu trabalho da melhor forma?

135

Espere sempre excelência, pois já é fato que quanto maior as expectativas sobre alguém, melhor é a sua produtividade

136

Habilidades de comunicação são essenciais

137

Trabalhe e esteja do lado deles, inclusive nos momentos mais críticos e exaustivos!

138

Pessoas são motivadas por coisas diferentes – busque compreender o que motiva cada um

139

Mantenha o escritório em silêncio – ruídos e muita conversa podem levar a interrupções e, assim sendo, perda da produtividade

140

Lembre-se: se um projeto de uma pessoa leva seis meses, não quer dizer que o mesmo projeto levado por seis pessoas levará somente um mês!

141

Há grandes diferenças entre engenheiros (sim, há bons engenheiros e engenheiros… nem tanto)

142

Você pode otimizar o quanto quiser, só depende de quais recursos você dispõe e o que você quer otimizar

143

Colete dados de forma não intrusiva e sem atrapalhar as atividades de sua equipe

144

Custos por linha de código não é tão útil, ou seja, quanto menor o número de linhas de código não obrigatoriamente será menor o custo do projeto

145

Não há um jeito perfeito para medir produtividade (os dois métodos mais empregados são a quantidade de linhas de código e o número de pontos de função)

146

Tailorize os métodos de estimativa de custos

147

Não estabeleça deadlines irrealistas

148

Evite o impossível

149

Conheça bem aquilo que você quer contar – não há como traçar estimativas se você desconhece o objeto-alvo

150

Colete dados de produtividade de sua equipe e use-os em suas estimativas

151

Não se esqueça que a produtividade em equipe é diferente da produtividade individual e que a produtividade de uma equipe de N pessoas é diferente da soma da produtividade das mesmas N pessoas individualmente

152

A quantidade de linhas de código produzidas por cada indivíduo é independente da linguagem usada

153

Uma vez que o cronograma estabelecido foi definido e considerado exeqüível, todos devem acreditar nele

154

Nenhuma estimativa de custos é 100% precisa

155

Reavalie cronogramas regularmente – ao menos a cada deadline cumprido!

156

Projetos com deadlines um pouco subestimados nem sempre são ruins – somente não use deadlines irrealistas, o que minará a confiança de sua equipe!

157

Aloque recursos apropriados

158

Planeje um projeto em detalhes – um projeto sem um plano está fora de controle antes mesmo de começar!

159

Mantenha seu plano atualizado

160

Evite planos super-atualizados baseados em promessas de melhores recursos

161

Conheça os dez principais riscos:

· Rotatividade de pessoal / perda de profissionais;

· Cronogramas irrealistas;

· Não compreender os requerimentos;

· Construir uma interface de usuário pobre;

· Tentar a “solução de ouro” quando o usuário não quer isso;

· Não controlar mudanças de requerimentos;

· Falhas / falta de componentes reusáveis ou interfaceados;

· Falhas em tarefas realizadas externamente;

· Tempo de resposta pobre;

· Tentar exceder a capacidade da tecnologia atual.

162

Compreenda os riscos antecipadamente – apesar de impossível prever exatamente o que ocorrerá errado, é importante que desde os primeiros estágios do planejamento os maiores erros sejam delineados e estudados os impactos dos mesmos sobre o projeto caso ocorram

163

Use um modelo de processo apropriado para o seu projeto (cascata, prototipagem descartável, prototipagem evolucionária / desenvolvimento incremental, modelo espiral, prototipagem operacional, etc.)

164

O método não salvará você, então, se a organização falhou em algum projeto anterior, antes de simplesmente querer mudar de método, tente descobrir a causa da falha

165

Sem segredos para aumentos de produtividade milagrosos

166

Saiba como medir corretamente o progresso (leve em consideração o cronograma e o orçamento!)

167

Gerencie de acordo com o plano estabelecido, preocupando-se em reportar as discrepâncias, não o que está indo bem, assim recursos e atenção podem ser aplicados aonde é de interesse

168

Não sobrecarregue seu hardware – se necessário, invista em mais hardware. Desenvolvimento em hardware sobrecarregado tende a custar bem mais!

169

Seja otimista em relação à evolução do hardware

170

Entretanto, seja pessimista em relação à evolução do software

171

Pensar que o desastre é impossível freqüentemente leve ao desastre

172

Faça um postmortem do projeto, relatando “o que deu certo” e “o que deu errado” e por quê

Princípios de Garantia da Qualidade

A garantia da qualidade é o conjunto de atividades que inclui a qualidade do software através de checagens e balanço, incluindo:

· Gerenciamento de configuração de software;

· Garantia da qualidade de software;

· Verificação e validação de software;

· Teste;

Nº

Descrição do princípio

Situação

173

Garantia da qualidade de um produto não deve ser considerado uma luxúria – deve ser planejado e acompanhado desde o início

174

Estabeleça procedimentos de gerenciamento de configuração de software tão cedo quanto for possível

175

Adapte o gerenciamento de configuração de software ao processo de software empregado

176

Organize gerenciamento de configuração de software para ser independente do gerenciamento do projeto

177

Aplique rotatividade periódica entre as pessoas de desenvolvimento e as pessoas de garantia de qualidade de produto

178

Dê a todos os produtos intermediários um nome e uma versão

179

Controle baselines e evite a execução de mudanças de forma descontrolada

180

Salve tudo – cada configuração que empregar

181

Mantenha o rastreamento de cada mudança, seja ela aprovada ou não para ser executada

182

Não desvie o controle de mudanças, evitando que o usuário ou outra pessoa possa ter contato direto com a equipe de desenvolvimento e, assim sendo, solicitando a esta em vez de passar pela aprovação do gerenciamento de configuração de software

183

Avalie, pontue e agende requisições de mudança

184

Use validação e verificação ( V&V ) em grandes desenvolvimentos

Princípios de Evolução

Evolução é o conjunto de atividades que lida com modificação do produto de software para:

· Satisfazer novas funções;

· Trabalhar mais eficientemente;

· Trabalhar corretamente;

Nº

Descrição do princípio

Situação

185

O software continuará a mudar (trata-se da evolução natural do mesmo!)

186

A entropia do software aumenta (custo para a execução de alguma manutenção sobre o mesmo) de acordo com o tempo

187

Se não está quebrado, não conserte, caso contrário você terminará com um problema em algo que antes funcionava corretamente

188

Corrija problemas, não sintomas – quando o software falha, você tem a obrigação de compreender completamente a causa da falha, não apenas fazer uma rápida análise e aplicar um reparo ao que você acha que é a causa

189

Quando todos concordarem com uma alteração no software, a primeira coisa a ser atualizada é a especificação de requerimentos de software

190

Quanto maior a taxa de erros pré-release, maior a taxa de erros pós-release – considere então a possibilidade de reescrever tais componentes completamente a partir do zero

191

Quanto mais velho o programa, mais difícil é manuteni-lo

192

A linguagem selecionada influencia a manutenibilidade

193

Algumas vezes, é melhor começar tudo de novo

194

Renove o que está pior primeiro

195

Lembre-se de que a fase de manutenção causa mais erros do que a fase de desenvolvimento

196

Teste de regressão (teste de todas as características previamente testadas depois que uma mudança é feita) depois de cada mudança

197

Acredite que cada mudança facilmente faz tudo funcionar incorretamente. A fim de evitar isso, certifique-se de que a mudança que você está fazendo está aprovada, foi completamente checada e testes de regressão foram realizados para cada conjunto de mudanças

198

Estruturar código não-estruturado não necessariamente melhora-o

199

Use profilers e outras ferramentas de monitoramento antes de otimizar seu código a fim de descobrir quais rotinas precisam realmente ser otimizadas

200

Conserve a familiaridade – lembre-se, muitas alterações em um software levam à perda da familiaridade que a equipe de desenvolvimento / manutenção tem com aquele software. Busque manter assim a familiaridade a fim de que a manutenção possa ser bem implementada

201

A existência de um software promove a evolução – não importa quão perfeito seja seu software, o simples fato dele existir leva a novas necessidades que requerem mudanças no software ou mesmo o lançamento de uma nova versão