American English vs Britsh English

Rush - Grace Under Pressure

ISO/IEC 12207

Cenas de uma empresa de software ou do setor de TI

Resist

I can learn to resist
Anything but temptation
I can learn to co-exist
With anything but pain
I can learn to compromise
Anything but my desires
I can learn to get along
With all the things i can't explain
I can learn to resist
Anything but frustration
I can learn to persist
With anything but aiming low
I can learn to close my eyes
To anything but injustice
I can learn to get along
With all the things i don't know

You can surrender
Without a prayer
But never really pray
Without surrender
You can fight
Without ever winning
But never ever win
Without a fight

O velho problema que sempre mata boas ideias

A falta de entendimento e uma execução ruim são as causas de falha no uso de qualquer modelo prescritivo (sequencial, prototipação, incremental, rad, rup, espiral, etc) ou orgânico (xp, scrum, lean, etc). A insistência das empresas transformarem o desenvolvimento de software em uma gincana com todas as firulas desnecessárias e um processo do tipo "entra qualquer bobagem e após uma iteração sai software funcionando do outro lado" é uma falácia.

Excelentes modelos de processo com o RUP, foram "burocratizados" por pura falta de entendimento e falha na execução. A principal dificuldade está em identificar quando usar um processo, ferramenta ou técnica. Outro ponto importante: fazer software de boa qualidade é difícil. Um processo auxília e não substitui gente talentosa. Mais um ponto que atrapalha e muito: qual é o problema principal a ser resolvido: sistemas com zilhões de cadastro não resolvem nada.

O importante de qualquer modelo de processo é o correto entendimento (que nãoa contece simplesmente por ler um tutorial) e a boa execução dos fundamentos (de processo e técnicos).

Pense em especificações como partituras e a execução (construção) como o software. Uma excelente música pode ficar horrível com uma execução ruim.

16 Leis Fundamentais da Engenharia de Software

Lei nº 1 – Lei fundamental da Engenharia de Requisitos
Os requisitos terminam onde começa a liberdade do implementador.

Lei nº 2 – Lei dos 3 éfes da Gestão de Prioridades
1º) Funcionalidade
2º) Fiabilidade
3º) Eficiência

Lei nº 3 – Princípio fundamental da Arquitetura de Software
Qualquer problema de estruturação de software resolve-se introduzindo níveis de indirecção.
Corolário: Qualquer problema de desempenho resolve-se removendo níveis de indirecção.

Lei nº 4 – Lei de Arquimedes da Arquitetura de Software
Um sistema de software fundado numa má arquitectura afundar-se-á sob o peso do seu próprio sucesso.

Lei nº 5 – Princípio fundamental da Desconfiança Homem-Máquina
Inteligência artificial é melhor do que estupidez natural.

Lei nº 6 - Paradoxo da Redundância
A redundância é fonte de erros, mas também permite revelar erros.

Lei nº 7 – Princípio fundamental da Verificação & Validação
Um programa que cumpre perfeitamente uma péssima especificação é um péssimo programa, não um programa perfeito.

Lei nº 8 – Limitação fundamental da  Engenharia de Software
É praticamente impossível provar que um programa está correcto. 
Corolário: Desenvolver software é conjecturar soluções para problemas.

Lei nº 9 – Princípio fundamental da Qualidade de Software
Todo o programa tem erros. Além disso, o número de erros de um programa é dado precisamente pela fórmula n > a, em que a é um inteiro qualquer.

Lei nº 10 – Lema fundamental do Teste de Software
Os bugs escondem-se nos cantos e reúnem-se nas fronteiras.

Lei nº 11 – Princípio da incerteza no Planeamento de Projetos
Não é possível fixar simultaneamente o resultado, custo e duração de um projeto de software.

Lei nº 12 – Dinâmica do Deslizamento de Prazos
Falta cada vez mais tempo para acabar o projecto.

Lei nº 13 – Paradoxo de Zenon do Software
Não basta fazer o que falta fazer para satisfazer o cliente.

Lei nº 14 – Princípio da Conservação da Não-Aceitação
Os X% que falta implementar têm (100-X)% de importância para o cliente.

Lei nº 15 – Lei fundamental da Gestão de Alterações
Fazem-se sempre mais alterações, até não haver mais tempo para fazer alterações.
Corolário: A última alteração é a que deu cabo de tudo.

Lei nº 16 – Responsabilidade social do Engenheiro de Software
O mundo pode acabar devido a uma catástrofe. E é aí que entram os Engenheiros de Software.

Black Sabbath - Headless Cross

Método ou metodologia?

O método da suave dissuasão baseada na psicologia

Com frequência trabalhos de mestrado e mesmo de doutoramento utilizam como se fossem sinónimos os termos método e metodologia. A mesma confusão chega a ver-se igualmente em livros sobre métodos de investigação.

Uma simples consulta ao "Dicionário da Língua Portuguesa", da Porto Editora, mostra claramente que os termos têm significados distintos. A entrada para "Método" define o termo como "programa que antecipadamente regulará uma sequência de operações a executar, com vista a atingir certo resultado; maneira ordenada de fazer as coisas, ordem; estratégia, modo de proceder; esforço para atingir um fim". Já sobre "Metodologia", o mesmo dicionário indica ser um "conjunto de regras ou princípios empregados no ensino de uma ciência ou arte; parte da lógica que estuda os métodos das diversas ciências".

Sobre esta distinção escrevem também alguns autores. Moore (2006, p. 40) refere-se assim a uma secção da proposta de investigação: "The next section deals with the methods to be used. Here it is worth noting that the proper term for this section is 'methods' - 'methodology' is the study of research methods". Também  Maxwell (2005, p137) é muito claro nesta distinção:

The term "methodology" is often used for this section of a proposal. Despite its prevalence, this is an inaccurate and pretentious usage, a good example of what Becker called "classy writing". Methodology is the theory or analysis of methods, not what you actually do in a particular study. The Publication Manual of the American Psychology Association (2001, pp. 17-20), a commonly used guide for both dissertations and research publications, uses the term "method" for this section of a manuscrit, not "methodology". 

Método é pois a estratégia, o modo de proceder de uma determinada investigação. Metodologia é o estudo, ou como indica o próprio sufixo, o conhecimento, se se pudesse dizer, dir-se-ia mesmo que é a ciência que estuda os métodos.

Referências
Maxwell, Joseph A. (2005). Qualitative research design: An interactive approach. Thousand Oaks, Sage
Moore, Nick (2006) How to do research : A\practical guide to designing and managing research projects ( 3rd ed.). London: Facet

Modelos Computacionais

"Um modelo é uma simplificação da realidade que descreve um sistema de um ponto de vista particular."

Por exemplo, um projeto arquitetônico é feito segundo diversas perspectivas: do arquiteto, projeto arquitetônico em si, do engenheiro eletricista, projeto elétrico, do engenheiro civil, projeto hidráulico e estrutural. Construímos modelos de sistemas complexos para melhor compreendê-los.

Abstrair e refinar incrementalmente são palavras-chaves. Em certos momentos, o projetista deve focalizar na interação entre componentes do sistema sem se preocupar com seus detalhes internos de funcionamento, então ele abstrai estes detalhes. Em outros momentos, é preciso detalhar o comportamento dos componentes. Enfim projetar um sistema significa fazer modelos sob diferentes perspectivas e graus de abstração, representando-os por meio de uma notação precisa, refinando-os sucessivamente até transformá-los em algo próximo da implementação lembrando sempre de verificar se os requisitos são satisfeitos.

A modelagem visual (com auxílio de diagramas) ajuda a manter a consistência entre os artefatos (produtos) ligados ao desenvolvimento de um sistema: requisitos, projeto e implementação. Resumidamente, a modelagem visual pode melhorar a capacidade de uma equipe a gerenciar a complexidade de software.

The Doors - Love Street

Culture in Decline | Episode #4 "War On Nature" by Peter Joseph

You waste a lot of time at work

http://t.co/v1Hv8Zudjz

"Quando você perceber que, para produzir, precisa obter a autorização de quem não produz nada; quando comprovar que o dinheiro flui para quem negocia não com bens, mas com favores; quando perceber que muitos ficam ricos pelo suborno e por influência, mais que pelo trabalho, e que as leis não nos protegem deles, mas, pelo contrário, são eles que estão protegidos de você; quando perceber que a corrupção é recompensada, e a honestidade se converte em auto-sacrifício; então poderá afirmar, sem temor de errar, que sua sociedade está condenada".

Ayn Rand