Sunday, June 02, 2013

Especificação e Análise de Requisitos de Software

“A parte individual mais difícil da construção de um sistema de software é decidir o que construir. Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita errado. Nenhuma outra parte é mais difícil de consertar depois” [Fred Brooks]

“Uma das principais medidas do sucesso de um software é o grau no qual ele atende aos objetivos e requisitos para os quais foi construído. De forma geral, a Engenharia de Requisitos de Software é o processo de identificar todos os envolvidos, descobrir seus objetivos e necessidades e documentá-los de forma apropriada para análise, comunicação e posterior implementação [4]” [Ricardo Falbo, notas de Aula, Engenharia de Software, 2005]


Love, Reign O'er Me- Pearl Jam



Good songs can be found everywhere and anytime. Please do yourself a favor. Search the original.

Tuesday, May 28, 2013

Equipes de alto desempenho: utopia ou possibilidade?

Uma das maiores utopias empresariais refere-se à formação das chamadas equipes de alta performance. É mais do que natural que, em uma época onde o trabalho em equipe está tão divulgado, se busque um discurso que, além de atender às demandas do mercado, ainda consiga maximizar seus resultados.
Antes de se discutir performance, é necessário discutir o conceito de equipe que, apesar de ser uma palavra de aparente fácil definição, pode trazer dúvidas.
Existe vasta literatura sobre o processo de formação de equipe e de liderança. Durante anos, a formação de um líder foi a menina dos olhos dos programas de MBA no mundo todo. Drucker definiu três possíveis equipes, usando sempre a referência ao esporte como exemplo:
- a equipe de beisebol, semelhante a uma equipe cirúrgica ou a uma linha de montagem: tarefas independentes fazendo parte de um todo;
- a equipe de futebol, semelhante a uma equipe de projeto: trabalhos semelhantes, com funções ligeiramente diferentes e ocorrendo em paralelo;
- uma dupla de tênis, semelhante a um conjunto de jazz: trabalhos absolutamente interdependentes.
A grande maioria das equipes que encontramos nas organizações funciona na prática como grupos de trabalho, ou seja, membros dividem informação e práticas, além de tomarem decisões para ajudar cada um a desenvolver tarefas de sua área de responsabilidade. São equipes de beisebol ou no máximo de futebol.
Mas, por que é tão difícil formar equipes?
Em minha opinião, em primeiro lugar, existe uma grande contradição inicial. Somos uma sociedade toda voltada ao desempenho individual, desde o colégio até os planos de metas e objetivos das grandes empresas. Isso causa um conflito natural, tão relevante como o conflito que já discuti antes aqui, entre chefes e comandados. Nenhum programa de distribuição de lucros global paga mais do que o desenvolvimento pessoal individual, seja por meio de promoção, seja por bônus.
Além disso, as estruturas organizacionais ainda são fortemente baseadas no modelo Taylorista-Fordista, que vigorou por muito tempo como modelo de sucesso e organização. Isso fez com que o foco na figura do chefe, do líder e dos processos firmes fosse sempre o primordial. E isso é bem distante do conceito de formação de equipe.
Resumindo, há evidente conflito natural entre os interesses coletivos e os individuais. Pessoas educadas em princípios individualistas precisam renunciar a eles ao menos temporariamente em prol do trabalho coletivo.
O que se busca numa equipe é sinergia, sempre. O objetivo de uma equipe é que seus talentos individuais se somem de forma que o resultado dessa soma seja superior à simples soma de suas partes. Dois mais dois tem que ser mais do que quatro.
Mas muitas empresas adotam as teorias de trabalho em equipe apenas para predispor maior cooperação entre funcionários, sem fazer esforço algum para a construção da equipe. Pior ainda, assumem que o ato de juntar as pessoas fará com que elas aprendam a interagir produtivamente de forma instantânea.
E o desafio para montar essa equipe se inicia no processo seletivo, coordenando três fatores: habilidades técnicas, habilidades interpessoais e aderência das pessoas à missão da equipe. Ou seja, lembre-se bem que não necessariamente uma equipe de pessoas iguais a você lhe trará o melhor resultado. É provável que não traga…
Partindo do processo seletivo chega-se à mentalidade, agora em novos três fatores: missão do time, objetivos do time e regras. Os famosos “por quê, para quê e como”.
Resumindo:
Picture2
E esse é o primeiro passo para que você possa, antes de pensar em performance, pensar em formar a equipe com a correta indução de comportamento dos seus membros.
Feito isso, pode-se pensar em buscar uma performance acima dos padrões normais dos grupos que são montados como equipes. Com as pessoas certas e a mentalidade adequada você terá a chance de buscar o que quer, embora isso não baste.
Uma performance acima da média se obtém com a tarefa contínua de se relembrar os objetivos, medir resultados, discutir de forma clara e direta o que precisa ser melhorado e ter velocidade para remodelar quando necessário.
Para finalizar, deixo alguns conselhos de fatores que nunca podem ser esquecidos no processo:
- Não se esquecer que trabalho em equipe não é algo natural e demanda tempo
- É fundamental eliminar formalidades e aquele espírito colegial de falsa camaradagem
- Lembrar-se sempre que buscar a harmonia a qualquer custo é um dos grandes inimigos de uma performance alta
- Ter tolerância a erros. Medo de errar impede inovação
Vitor Roma
(@vromaCS)
Fontes: DYER, W. Team Building. New York: Addison-Wesley Publishing Company, Inc. 1995
DRUCKER, P.F. Administrando em tempos de grandes mudanças. São Paulo: Editora Pioneira, 2011

Check List para o Mapeamento de Processos

Check List para o Mapeamento de Processos


Introdução:Post de referência: O que é Mapeamento de Processos ?

Quando estamos trabalhando um projeto BPM, precisamos garantir que todas as atividades de uma fase estejam completas para irmos para a fase seguinte. Aqui discutiremos sobre o final da fase de Mapeamento e inicio da fase de Modelagem de Processos.

Questão-chave: Como sabemos que fase de Mapeamento terminou ?
Podemos imaginar o seguinte: Todas as atividades foram feitas. Ok, isso é pode ser um indicador para passarmos para frase próxima fase (Modelagem de Processos).
Entretanto, contudo, todavia, porém (ficou exagerado...mas este é objetivo), vamos refazer a  questão-chave: Será que temos informações suficiente para irmos para fase de Modelagem ?
Agora sim, temos uma dúvida.

Importante:
  As fases não são lineares, elas são iterativa e incrementais, mas toda vez que  começamos uma fase sem terminar a outra, será necessário retroceder a fase anterior, isto feito com frequência, dispara um sinal de alerta, pois pode comprometer a produtividade e causar danos ao progresso do projeto BPM.

Check List para o Mapeamento de Processos:
Para esclarecer a dúvida sobre o final da fase de Mapeamento de Processos e também facilitar o trabalho do Analista de Negócio, desenvolvemos ao longo do tempo, resultado de experiência prática,  um pequeno Check List, que ajuda aumentar a certeza que a fase de Mapeamento foi finalizada com sucesso, ou seja, com informações suficientes para iniciar a fase de Modelagem de Processos, próxima fase.

Check List:
1 - Quais são o eventos que iniciam o processo ?
2 - Quando o processo acaba, quais são os resultados esperados ?
3 - Quem são as partes interessadas ?
4 - Quais são as funções de negócios (áreas ou departamentos) que estão envolvidas com o processo?
5 - Quem é dono do processo (responsável pelo processo)?
6 - Quais são as exceções ?
7 - Quais sãos as metas do processo ?
8 - Quais são os indicadores de desempenho ?
9 - 
Quais são as métricas ?
10 - Quais são os recursos necessários para execução do processo ?
11 - Quais são os documentos associados ao processo ?
12 - Quais são as principais atividades ?
13 - Quem executa essas atividades ?
14 - Quais são as principais interfaces com outros processos ?
15 - Quais são os sistemas informatizados ou aplicações que dão suporte ao processo?
16 - Quais são as regras de negócio ?
17 - Qual o volume / quantidade / frequência de execução do processo ?
18 - Quais são as restrições ?
19 - Quais são os riscos ?  
20 - Qual o tipo de processo: negócio ou suporte ?

Observações:
- Quando estamos mapeando o modelo AS-IS, algumas perguntas do Check list podem ficar sem resposta, pois temos que mapear o cenário (situação) atual e algumas tais resposta não existem.


Thursday, May 23, 2013

Sistemas

Um sistema é algo que mantém a sua existência e funciona com um todo através da interação de suas partes. Sistemas têm propriedades emergentes que não são encontradas em suas partes. Você não pode predizer as propriedades de um sistemas completo considerando partes e analisando estas partes.



Se você dividir um sistema em partes ele perde as propriedades. Análise é o nome que se dá para dividir alguma coisa em suas partes para ver como ela funciona. Isto é muito útil para certos tipos de problemas, ou para ver como um sistema grande é feito de pequenos subsistemas. Você ganha conhecimento através da análise. Entretanto, você não pode compreender as propriedades do sistema todo, dividindo o sistema em suas partes constituintes. O complemento da análise é a síntese – construindo as partes em um todo. Você ganha compreensão através da síntese. O único modo de descobrir como um sistema funciona e quais são suas propriedades emergentes, é vê-lo em ação como um todo.

Fonte: The Art of to Systems Thinking ( Joseph O ́Connor & Ian McDermott) Ed Thorsons . 1997.

Sunday, May 19, 2013

Planet of the Apes



Conceito de Otimalidade de Pareto

“Uma sociedade se encontra em um estado ótimo se nenhuma pessoa desta sociedade pode melhorar sua situação sem que piore a situação de alguma outra pessoa da mesma sociedade”.

Vilfredo Pareto


Saturday, April 27, 2013

Apollo: Bringer Of Wisdom

"I bring truth and understanding,
I bring wit and wisdom fair,
Precious gifts beyond compare.
We can build a world of wonder,
I can make you all aware.
I will find you food and shelter,
Show you fire to keep you warm
Through the endless winter storms.
You can live in grace and comfort
In the world that you transform."


A Farewell To Kings

When they turn the pages of history
When these days have passed long ago
Will they read of us with sadness
For the seeds that we let grow?
We turned our gaze
From the castles in the distance
Eyes cast down
On the path of least resistance


Cities full of hatred, fear and lies
Withered hearts and cruel, tormented eyes
Scheming demons dressed in kingly guise
Beating down the multitude and
Scoffing at the wise

The hypocrites are slandering
The sacred Halls of Truth
Ancient nobles showering
Their bitterness on youth
Can't we find the minds that made us strong?
Can't we learn to feel what's right
And what's wrong?
What's wrong?

Stranger In A Strange Land

Was many years ago that I left home and came this way,
I was a young man full of hopes and dreams,
But now it seems to me that all is lost and nothing gained,
Sometimes things ain't what they seem,
No brave new world, no brave new world.


Watchmaker

"In a young man's quest to follow his dreams, he is caught between the grandiose forces of order and chaos. He travels across a lavish and colorful world of steampunk and alchemy, with lost cities, pirates, anarchists, exotic carnivals, and a rigid Watchmaker who imposes precision on every aspect of daily life."

Cândido, Voltaire, 1759


Monday, April 15, 2013

Decision Support System

A Decision Support System (DSS) is a collection of integrated software applications and hardware that form the backbone of an organization’s decision making process. Companies across all industries rely on decision support tools, techniques, and models to help them assess and resolve everyday business questions. The decision support system is data-driven, as the entire process feeds off of the collection and availability of data to analyze. Business Intelligence (BI) reporting tools, processes, and methodologies are key components to any decision support system and provide end users with rich reporting, monitoring, and data analysis.


Sunday, April 14, 2013

The Garden

Long ago I read a story from another timeline about a character named Candide. He also survived a harrowing series of misadventures and tragedies, then settled on a farm near Constantinople. Listening to a philosophical rant, Candide replied, "That is all very well, but now we must tend our garden."

I have now arrived at that point in my own story. There is a metaphorical garden in the acts and attitudes of a person's life, and the treasures of that garden are love and respect. I have come to realize that the gathering of love and respect - from others and for myself - has been the real quest of my life.

"Now we must tend our garden."


Rush - The Garden




The treasure of a life is a measure of love and respect
The way you live, the gifts that you give
In the fullness of time
Its the only return that you expect

Introduction to Scrum - CollabNet Scrum Training

Filosofia

No começo de uma vida podemos fazer tudo, mas sabemos muito pouco. No final sabemos muito, mas não podemos fazer nada.  (Anônimo)

Sunday, April 07, 2013

Couch potato


Ann Marie Calhoun - Deathless Dance

Steve Vai - In My Dreams With You

Quem nunca jogou?


Definição de Arquitetura de Software por Perry e Wolf

Perry e Wolf introduziram sua definição para arquitetura de software em seu artigo seminal Foundations for the Study of Software Architecture. A definição que eles propõem consiste na Fórmula abaixo e na explicação de seus termos:

Arquitetura={Elementos,Organização,Decisões}

De acordo com essa definição, a arquitetura de software é um conjunto de elementos arquiteturais que possuem alguma organização. Os elementos e sua organização são definidos por decisões tomadas para satisfazer objetivos e restrições. São destacados três tipos de elementos arquiteturais:

Elementos de processamento: : são elementos que usam ou transformam informação;
Elementos de dados: : são elementos que contêm a informação a ser usada e transformada; e
Elementos de conexão: : são elementos que ligam elementos de qualquer tipo entre si.
Já a organização dita as relações entre os elementos arquiteturais. Essas relações possuem propriedades e restringem como os elementos devem interagir de forma a satisfazer os objetivos do sistema. Adicionalmente, essas relações devem ser ponderadas de modo a indicar sua importância no processo de seleção de alternativas.


Arquitetura de Software em Camadas


Arquitetura de Software

Comecemos com algumas definições conceituais sobre Arquitetura de Software, segundo David Garlan e Mary Shawn:
“arquitetura de software é um nível de design voltado para questões que vão: além dos algoritmos e das estruturas de dados da computação. A projeção e a especificação da estrutura geral do sistema emergem como um novo tipo de problema. As questões estruturais incluem organização total e estrutura de controle global; protocolos de comunicação, sincronização e acesso a dados; atribuição de funcionalidade a elementos de design; distribuição física; composição de elementos de design; escalonamento e desempenho; e seleção entre as alternativas de design.”
No RUP temos a seguinte definição:
“a arquitetura de um sistema de software (em um determinado ponto) é a organização ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com elementos constituídos de componentes e interfaces sucessivamente menores.”
Existem diversos padrões de arquitetura de software, abaixo uma lista de alguns separados por sua forma:
  • Estrutura: Camadas, Pipes e Filtros, Quadro-negro
  • Sistemas Distribuídos: Broker
  • Sistemas Interativos: Modelo-Visão-Controlador (MVC), Apresentação-Abstração-Controle
  • Sistemas Adaptáveis: Reflexo, Microkernel
Partindo desta lista podemos perceber que de acordo com nossa necessidade e contexto, nossos aplicativo, ou partes dele, pode ser projetado de diferentes formas arquiteturais. No decorrer do texto falaremos mais do padrão arquitetural em Camadas.

Visões de Arquitetura:

Ao projetar a arquitetura de um software, podemos visualizar sua estrutura por vários “ângulos”. Estas diferentes visões de arquitetura podem ser divididas em:
  • Visão de Casos de Uso,  que contém casos de uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes ou riscos técnicos. Ela é um subconjunto do modelo de casos de uso.
  • Visão Lógica, que contém as classes de design mais importantes e sua organização em pacotes e subsistemas, e a organização desses pacotes e subsistemas em camadas. Ela contém algumas realizações de caso de uso. É um subconjunto do modelo de design.
  • Visão de Implementação, que contém uma visão geral do modelo de implementação e sua organização em termos de módulos em pacotes e camadas. A alocação de pacotes e classes (da Visão Lógica) nos pacotes e módulos da Visão de Implementação também é descrita. Ela é um subconjunto do modelo de implementação.
  • Visão de Processos, que contém a descrição das tarefas (processo e threads) envolvidas, suas interações e configurações, e a alocação dos objetos e classes de design em tarefas. Essa visão só precisará ser usada se o sistema tiver um grau significativo de simultaneidade.
  • Visão de Implantação, que contém a descrição dos vários nós físicos da maior parte das configurações comuns de plataforma e a alocação das tarefas (da Visão de Processos) nos nós físicos. Essa visão só precisará ser usada se o sistema estiver distribuído. Ela é um subconjunto do modelo de implantação.

 Arquitetura de Software em Camadas

Contexto

Um sistema grande que requer decomposição.

Problema

Um sistema que deve resolver as questões em diferentes níveis de abstração.  Por exemplo: as questões de controle de hardware, as questões de serviços comuns e as questões específicas de domínio. Seria extremamente indesejável escrever componentes verticais que lidem com essas questões em todos os níveis. Uma mesma questão deveria ser resolvida (possivelmente de maneira inconsistente) várias vezes em diferentes componentes.

Força

  • As partes do sistema devem ser substituíveis.
  • As alterações efetuadas nos componentes não devem ser irregulares
  • Responsabilidades similares devem ser agrupadas juntas
  • Tamanho dos componentes: componentes complexos talvez precisem ser decompostos

Solução

Estruture os sistemas em grupos de componentes que formem camadas umas sobre as outras. Faça com que as camadas superiores utilizem os serviços somente das camadas abaixo (nunca das camadas acima). Tente não usar serviços que não sejam os da camada diretamente abaixo (não pule camadas, a menos que as camadas intermediárias somente adicionem componentes de acesso).

Abordagens Comuns

A divisão em camadas representa um agrupamento ordenado de funcionalidades, sendo que:
  1. a funcionalidade específica de aplicativo está localizada nas camadas superiores,
  2. a funcionalidade que abrange os domínios de aplicativos se encontra nas camadas intermediárias e
  3. a funcionalidade específica do ambiente de implantação está nas camadas inferiores.
O número e a composição das camadas dependem da complexidade do domínio do problema e do espaço para solução:
  1. Em geral, há apenas uma única camada específica de aplicativo.
  2. Nos domínios em que sistemas anteriores foram desenvolvidos ou sistemas de grande porte são compostos de sistemas interoperacionais menores, há uma grande necessidade de compartilhar as informações entre as equipes de design. Conseqüentemente, para maior clareza, é provável que a camada específica de negócios exista parcialmente e esteja estruturada em várias camadas.
  3. Os espaços para solução que são suportados por produtos de middleware e nos quais o software de sistema complexo desempenha um papel importante terão camadas inferiores bem desenvolvidas, talvez com várias camadas de middleware e software de sistema.

Exemplos

Camadas genéricas


Arquitetura de software - camadas genéricas
Arquitetura de Software – Camadas genérricas

Camadas de sistemas de negócios

Arquitetura de software - camadas de negócios
Arquitetura de software – camadas de negócios

 Quatro camadas

Arquitetura de software - quatro camadas
Arquitetura de software – quatro camadas
  • A camada superior, camada de aplicativo, contém serviços específicos de aplicativo.
  • A camada seguinte (camada específica de negócios) contém componentes específicos de negócios, usados em diversos aplicativos.
  • A camada de middleware contém componentes como construtores GUI, interfaces para sistemas de gerenciamento de banco de dados, serviços de sistemas operacionais que não dependem de plataforma e componentes OLE, como planilhas e editores de diagramas.
  • A camada inferior (camada de software de sistema) contém componentes como sistemas operacionais, bancos de dados, interfaces para hardware específico, etc.

Diretrizes da divisão


  • Visibilidade: Os subsistemas só podem depender de subsistemas na mesma camada e na camada inferior seguinte.
  • Volatilidade:
    • Nas camadas superiores, insira elementos que variam quando os requisitos de usuário são alterados.
    • Nas camadas inferiores, insira elementos que variam quando a plataforma de implementação (hardware, idioma, sistema operacional, banco de dados, etc.) é alterada.
    • Entre essas camadas, insira elementos que geralmente se aplicam a diversos tipos de sistemas e ambientes de implementação.
    • Acrescente camadas quando partições adicionais nessas categorias amplas ajudarem a organizar o modelo.
  • Generalidade: Elementos abstratos do modelo costumam ser inseridos em camadas inferiores no modelo. Se não forem específicos da implementação, ficarão geralmente próximos das camadas intermediárias.
  • Número de Camadas: (não gosto desta diretriz, apresento por constar na literatura) Para um sistema pequeno, três camadas são suficientes. Para um sistema complexo, cinco a sete camadas costumam ser suficientes. Para qualquer grau de complexidade, o uso de mais de dez camadas deve ser visto com suspeita, que deverá aumentar com o número de camadas. Algumas regras práticas são: de 0 a 10 classes – 0 camadas; de 10 a 50 classes – 2 camadas; de 25 a 150 classes – 3 camadas; de 100 a 1000 classes – 4 camadas

Padrões de particionamento

Nas camadas superiores do sistema, partições adicionais podem ajudar a organizar o modelo. As seguintes diretrizes para particionamento apresentam questões distintas a serem consideradas:
  • Organização do usuário: Os subsistemas podem ser organizados em linhas que refletem a organização da funcionalidade na organização de negócios
  • Áreas de competência e/ou habilidades: É possível organizar subsistemas de modo que particionem responsabilidades de partes do modelo entre grupos distintos da organização de desenvolvimento. Em geral reflete a necessidade de especialização de habilidades durante o desenvolvimento e o suporte da tecnologia de infra-estrutura complexa. Exemplos: o gerenciamento de distribuição e rede, o gerenciamento de banco de dados, o gerenciamento de comunicação, o controle de processos, etc.
  • Distribuição do sistema: Em qualquer uma das camadas do sistema, é possível particioná-las “horizontalmente” para refletir a distribuição física da funcionalidade. O particionamento para refletir a distribuição pode ajudar a visualizar a comunicação de rede que ocorrerá assim que o sistema for executado.
  • Áreas de sigilo: Alguns aplicativos, principalmente aqueles que exigem autorização de segurança especial para serem desenvolvidos e/ou suportados, requerem partições adicionais nas linhas de privilégio de acesso à segurança.
  • Áreas de variabilidade: A funcionalidade que tende a ser opcional e, portanto, liberada apenas em algumas variantes do sistema, deve ser organizada em subsistemas independentes que são desenvolvidos e apresentados sem depender da funcionalidade obrigatória do sistema.

Conclusões

Com estes direcionamentos fica claro de que aplicações, por mais simples que sejam, devem ser divididas por um conceito básico na análise orientada à objetos: divisão de responsabilidades.
Seguindo estas diretrizes tenho certeza que os projetos de software podem ser melhor organizados diminuindo complexidades, principalmente na manutenção de código e escalabilidade durante sua vida de utilização.

Árvores de utilidades são nossas amigas

Esta árvore de utilidades pode tanto ser definida colaborativamente entre stakeholders de negócio e técnicos quanto pode ser também preparada para servir de base para discussão dos arquitetos.

Em um workshop, stakeholders técnicos e de negócio atribuem métricas a cada cenário, que podem tratar da importância do cenário e da complexidade da sua implementação. Ambos critérios, em conjunto, ajudam a priorizar os cenários. Obviamente, um cenário de alta importância que é de difícil implementação deve ter prioridade maior que um cenário com baixa relevância para o negócio.

Os nós localizados diretamente abaixo da raiz da árvore de utilidades são tipicamente os atributos de qualidade de alto nível, tais como disponibilidade ou facilidade de manutenção. Os nós intermediários na árvore representam as facetas previamente apresentadas para desempenho, enquanto as folhas são os cenários.


Friday, March 22, 2013

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

Thursday, March 21, 2013

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.

Tuesday, March 19, 2013

Black Sabbath - Headless Cross

Método ou metodologia?

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

Saturday, March 16, 2013

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.


Saturday, March 02, 2013


"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