NBR ISO/IEC 12207 – Processos de Ciclo de Vida de Software

A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foi criada em 1995 com o objetivo de fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum. Esta linguagem comum é estabelecida na forma de processos bem definidos. Esses processos são classificados em três tipos: fundamentais, de apoio e organizacionais representado na Ffgura abaixo. Todos esses processos, executados durante o projeto de software, conduzem a qualidade tanto do produto quanto do processo. Devido à própria evolução da área de engenharia de software e da necessidade sentida por vários usuários da Norma, está sendo disponibilizado em 2001 um anexo que atualizará a Norma incluindo e expandido processos.

Enjoy!

Dificuldades com seus Projetos de IHC?

http://www.labiutil.inf.ufsc.br/ergolist/

Enjoy!

Mecanismos Arquiteturais

Example Architectural Mechanisms

Architectural Mechanism	Description
Availability	The percentage of time that the system must be available for use, including planned outages.
Archiving	Provides a means to move data from active storage when it has reached a specific state.
Auditing	Provides audit trails of system execution.
Communication	A mechanism for handling inter-process communication.
Debugging	Provides elements to support application debugging.
Disaster Recovery	Provides facilities to recover systems, application, data and networks.
Error Management	Allows errors to be detected, propagated, and reported.
Event Management	Supports the use of asynchronous events within a system.
Graphics	Supports user interface services, such as 3D rendering.
Information Exchange	Supports information interchange accross technical and organisational boundaries, with appropriate semantic and format translations.
Licensing	Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as part of authorising corporate bodies.
Localisation / Internationalisation	Provides facilities for supporting multiple human languages and rendering the language preffered by the user.
Mail	Services that allow applications to send and receive electronic mail.
Mega-data	Support for handling very large amounts of data.
Memory Management	Services for abstracting how memory is allocated and freed.
Meta-data	Supports the runtime introspection of components and data.
Online help	Provides online help capability
Persistence	Services to handle the reading and writing of stored data.
Printing	Provides facilities for interfacing with printers.
Process Management	Provides support for the management of processes and threads.
Reporting	Provides flexible reporting facilities
Resource Management	Provides support for the management of expensive resources, such as database connections.
Scheduling	Provides the ability to execute tasks at a specified time.
Security	Provides services to protect access to certain resources or information.
System Management	Services that facilitate management of applications in an operational environment.
Time	Services to synchronise time on a network, and to translate times into different time zones.
Transaction Management	A mechanism for handling ACID transactions.
Workflow	Support for the movement of documents and

Podem possuir 3 estados:

 Enjoy!

PO Darth Vader

Em projetos Ágeis o ScrumMaster é responsável por garantir o processo e que as práticas Scrum sejam seguidas. Já o ProductOwner(PO) é responsável pelo produto e pelo ROI do projeto, isto faz que o papel de PO seja um fator critico de sucesso. O PO deve trabalhar totalmente alinhado e integrado com o time para que o ROI seja alcançado.

Principais características desejáveis e as indesejáveis:

Desejáveis (obrigatórias)

- Saber entender a necessidade do cliente e usuários;

- Ter habilidade para criar, manter e comunicar a visão do produto;

- Entender o que é valor para o cliente;

- Ser Líder e Facilitador;

- Ter poder decisão sobre o projeto;

- Ser comprometimento com cliente, projeto e com a equipe;

- Manter um bom relacionamento com stakeholder;

Indesejáveis: 

- Ser uma pessoa sem tempo; 

- Ser adepto do micro-gerenciamento (comando controle) (Darh Vader);

- Não conhecer o produto ou negócio;

- Falta de coragem para tomar decisão sobre o projeto;

- Inabilidade técnica;

- Falta de conhecimento do SCRUM;

- Visão mal definida ou incompleta;

- Ter um ProductBacklog mal priorizado;

Enjoy!

Som de Algoritmos de Ordenação

Agora sei o que o R2D2 falava!

Enjoy!

Scrum - Product Backlog

Scrum é um framework (e não metodologia) interativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

O product backlog é o coração do Scrum. É aqui que tudo começa. O product backlog é basicamente uma lista de requisitos, estórias, Coisas que o cliente deseja, descritas utilizando a terminologia do cliente. Nós as chamamos de estórias, ou algumas vezes apenas de itens do backlog. Nossas estórias incluem os seguintes campos:
 * ID – Uma identificação única, apenas um número com autoincremento. Isso é para evitar que percamos o controle sobre as estórias quando nós mudamos seus nomes.
 * Nome – Um nome curto e descritivo para a estória. Por exemplo, “Ver o histórico de transações”. Suficientemente claro para que os desenvolvedores e o product owner entendam mais ou menos sobre o que estamos falando, e claro o bastante para distingui-la das demais estórias. Normalmente de 2 a 10 palavras.
 * Importância – a pontuação de importância dessa estória para o product owner. Por exemplo 10. Ou 150. Mais pontos = mais importante. Eu tento evitar o termo “prioridade” já que prioridade 1 é tipicamente interpretado como “prioridade mais alta”, o que fica feio se mais tarde você decidir que algo é ainda
mais importante. Qual pontuação de prioridade esse item deveria receber? Prioridade 0? Prioridade -1?
 * Estimativa inicial – As estimativas iniciais da equipe sobre quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal.
1. Pergunte à equipe “se vocês puderem ter o número ideal de pessoas para esta estória (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma sala cheia de comida e trabalharem sem distúrbio algum, após quantos dias vocês apresentarão uma implementação pronta, demonstrável e testada? Se a resposta for “com 3 pessoas trancados em uma sala levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória. 

2. O importante não é ter estimativas absolutamente precisas (por exemplo, dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim obter estimativas relativas corretas (por exemplo, dizer que uma estória com 2 pontos gastará cerca da metade de uma estória com 4 pontos).
 * Como demonstrar – Uma descrição em alto nível de como a estória será demonstrada na apresentação do sprint. Isso é simplesmente uma simples especificação de teste. “Faça isso, então faça aquilo e então isso deverá acontecer.” o Se você pratica TDD (desenvolvimento orientado a testes) essa descrição pode ser usada como pseudocódigo para o seu código de teste de aceitação. 

 * Notas – quaisquer outras informaçòes, esclarecimentos, referências a outras fontes de informação, etc.   Normalmente agil bem breve.

Como todos os demais aterfatos, coloque no repositório de versionamento.

Enjoy!

Gerenciamento de Projetos

Ronnie Maschk sobre gerenciamento de projetos.

Enjoy!

O que é Análise de Negócio (segundo o Guia BABok) ?

“Análise de Negócio é o conjunto de tarefas e técnicas utilizadas para o trabalho como um elo de ligação entre todas as partes interessadas (stakeholders), a fim de compreender a estrutura, as políticas e operações de uma empresa e para recomendar soluções que permitam a empresa a alcançar seus objetivos”.
Análise de Negócio envolve entendimento de como as organizações realiza os seus propósitos e definindo as capacidades que uma empresa requer para fornecer produtos e serviços para seus os clientes (ou stakeholders externos). Inclui a definição de metas, o modo como esses objetivos conectam com objetivos mais específicos, a determinação dos planos de ação que uma organização tem de comprometer-se para atingir esses objetivos e metas e estabelecer a forma como as diferentes unidades de negócio e as partes interessadas internas e externas (stakeholders internos e externos), se interagem. Análise de Negócio pode ser feita para entender o cenário atual de empresa ou servir como base para identificação das necessidades de negócio. Em muitas casos, porém, Análise de Negócio, é feita para definir e validar as soluções que satisfaçam as necessidades de negócio, metas ou objetivos. Análise de Negócio deve avaliar e sintetizar as informações que são fornecidas por todas as pessoas que interagem com o negócio, tais como clientes, pessoal de Staff, fornecedores, pessoal de TI, executivos e etc. O Analista de Negócio é responsável por obter as reais necessidades das partes interessadas, não apenas os seus desejos expressos. Em muitos casos, o Analista de Negócio atuará como facilitador da comunicação entre as unidades de negócio. Um exemplo de atuação do Analista de Negócio como facilitar, é no alinhamento das necessidades das unidades de negócio com os serviços entregues pela TI (Tecnologia da Informação). Análise de Negócio pode ser feita para entender o cenário atual de empresa ou servir como base para identificação das necessidades de negócio. Em muitas casos, porém, Análise de Negócio, é feita para definir e validar as soluções que satisfaçam as necessidades de negócio, metas ou objetivos. Um Analista Negócio é qualquer pessoa que exerça atividades de Análise de Negócio, não importando qual seja seu cargo, função ou papel. A Análise de Negócio profissional não incluem apenas as pessoas com o cargo Analista de Negócios, ela também pode incluir Analista de Sistemas, Analista de Requisitos, Engenheiro de Sistemas Corporativo, Analista de Processo, Analista de Produto, Gerente de Produto, Product Owner (SCRUM), Arquitetos de Solução Corporativa, Consultores de Gestão ou qualquer outra pessoa que execute as tarefas descritas no Guia BABok® , incluindo aqueles que exercem também disciplinas relacionadas, tais como Gerenciamento de Projeto, Desenvolvimento de Software, Garantia de Qualidade e etc.

Enjoy!

O Relojoeiro Cego

"Por razões que não me são inteiramente claras, o darwinismo parece ter maior necessidade de defesa do que outras verdades igualmente bem estabelecidas de outros ramos das ciências. Muitos de nós não entendemos nada de física quântica ou das teorias de Einstein sobre relatividade especial e geral, mas isso não nos leva a fazer oposição a essas teorias! Mas o darwinismo, ao contrário do "einsteinismo" parece ser visto como legítimo saco de pancadas por críticos de todos os graus de ignorância. Suponho que um dos problemas do darwinismo, como bem observou Jacques Monod, é que todos pensam entendê-lo. Com efeito, tratase de uma teoria notavelmente simples - pensando bem, até mesmo infantil em comparação com quase todas as teorias da física e da matemática. Essencialmente, ela se resume à idéia de que a reprodução não aleatória, conjugada à variação hereditária, terá conseqüências de grande alcance uma vez que estas tenham tempo para ser cumulativas. Mas temos boas razões para crer que essa simplicidade é enganadora. Vale lembrar que, por mais simples que ela pareça, ninguém pensou nessa teoria antes de Darwin e Wallace, em meados do século XIX, quase duzentos anos depois dos Princípios de Newton e mais de 2 mil anos depois que Eratóstenes mediu a Terra. Como é possível que uma idéia tão simples não tenha sido descoberta por pensadores do calibre de Newton, Galileu, Descartes, Leibniz, Hume e Aristóteles? Por que ela teve de esperar por dois naturalistas vitorianos? O que havia de errado com os filósofos e matemáticos que a deixaram escapar? E como pode ser que uma idéia tão poderosa ainda seja tão estranha aos olhos do grande público? É quase como se o cérebro humano tivesse sido especificamente concebido para não entender o darwinismo, para achá-lo inacreditável. Tome-se como exemplo a questão do "acaso", tantas vezes melodramaticamente adjetivado como acaso cego. A maioria das pessoas que atacam o darwinismo agarra-se com avidez indecorosa à idéia errônea de que nele tudo é acaso e aleatoriedade. Uma vez que a complexidade dos seres vivos encarna a própria antítese do acaso, obviamente quem pensar que o darwinismo se resume ao acaso não terá dificuldade em refutá-lo! Uma das minhas tarefas será destruir o mito sofregamente acalentado de que o darwinismo é uma teoria do "acaso". Outro fator que talvez nos predisponha a não acreditar no darwinismo está em nosso cérebro, que foi feito para lidar com eventos em escalas de tempo radicalmente diferentes daquelas que caracterizam a mudança evolutiva. Estamos equipados para observar processos que se desenrolam em segundos, minutos, anos ou, no máximo, décadas. O darwinismo é uma teoria de processos cumulativos tão lentos que se desenrolam ao longo de milhares e milhões de anos. Todos os nossos juízos intuitivos sobre o que é provável mostram-se errados por larga margem. Nosso refinado instrumental de ceticismo e teoria da probabilidade subjetiva erra tanto o alvo justamente por ser calibrado - ironicamente, pela própria evolução para atuar no âmbito de algumas décadas. Escapar da prisão dessa escala de tempo familiar requer um esforço de imaginação."

- Richard Dawkins

Enjoy!

Abordagem Orientada a Modelos de Processos de Negócio

Abordagem Convencional

A engenharia de requisitos consiste em “um processo sistemático de desenvolvimento de requisitos através de um processo iterativo de análise do problema, documentação das observações resultantes e verificação acerca da precisão de entendimento” [1]. É uma atividade cujo sucesso depende diretamente da realização de uma comunicação eficaz. Diante disto, consideramos a modelagem de processos de negócio como técnica para facilitar a comunicação entre clientes e analistas. Abordagem Convencional de Engenharia de Requisitos A primeira técnica empregada na elicitação de requisitos é denominada abordagem convencional neste artigo, pois não emprega a modelagem de processos como ferramenta. Esta técnica descrita a seguir é embasada por referências pertencentes à documentos privados da companhia na qual a experiência desenvolveu-se. A tabela 1 mostra as fases deste processo, assim como os produtos gerados ao término de cada uma.

Abordagem Orientada a Modelos de Processos de Negócio

A abordagem de engenharia de requisitos orientada a modelos de processos de negócio se diferencia da abordagem denominada convencional pela inclusão de uma etapa de formalização explícita dos processos de negócios que serão apoiados ou geridos pelo sistema em desenvolvimento. Esta etapa visa facilitar a compreensão do ambiente organizacional no qual o sistema será usado e fornece subsídios para a adequação dos requisitos com os objetivos organizacionais.
A técnica de modelagem de processos empregada inicia-se pelo mapeamento da cadeia de valor organizacional que representa todos os macro-processos realizados para a concretização das estratégias organizacionais. O refinamento de macro-processos leva a cadeias de processos que representam os procedimentos coorporativos. Quando os processos atingem seu maior nível de refinamento, é possível a construção do modelo de atividades. No modelo de atividades, é possível então atribuir recursos próprios à execução destas ações atômicas.

Engenharia de Requisitos Orientada a Modelos de Processos de Negócio

Após a etapa de formalização dos processos de negócio, a etapa de engenharia de requisitos utiliza os modelos para a geração de seus respectivos requisitos de sistema. Na análise do processo podem ser identificados três conjuntos de atividades. O primeiro conjunto consiste nas atividades não passíveis de automatização, tais como certas atividades operacionais exclusivamente realizadas por atores humanos. O segundo conjunto consiste nas atividades que podem ser apoiadas por sistemas, enquanto o terceiro conjunto refere-se àquelas totalmente automatizáveis, ou seja, que podem ser realizadas por sistemas sem intervenção humana. A distribuição das atividades nos três grupos acima citados é realizada conjuntamente entre o cliente e o analista de sistemas e deve levar em consideração uma série de fatores dentre os quais podemos citar políticas da organização, leis, restrições tecnológicas, restrições de segurança, dentre outros. Dessa forma, deste ponto de vista, a utilidade do modelo de processos do negócio reside no fato de que ele é fonte de subsídios para descoberta dos serviços a serem prestados pelo sistema. A figura abaixo representa esquematicamente a relação entre um modelo de processos e uma gama de conjuntos de requisitos para sistemas que podem suportar este processo, cada conjunto de requisitos correspondendo um diferente conjunto de escolhas de nível de automatização das atividades deste processo. Nesta figura o modelo de processos é considerado o ponto de partida para o esforço de engenharia de requisitos, que envolve os stakeholders do sistema. A partir do mesmo modelo de processos é possível obter um conjunto de requisitos R1 para um sistema S1 que irá apoiá-lo, ou ainda obter um conjunto de requisitos R2 para um sistema S2 que possui um nível maior de automatização. Caminhando-se na escala de soluções, no limite da automatização, a escolha do conjunto de requisitos RN referente ao sistema SN também é viável e consiste no maior nível de automatização para o processo. A escolha de qual sistema será utilizado deve ser uma decisão consciente na qual considerado o equacionamento de fatores diversos tais como segurança, custo de desenvolvimento do sistema, dentre outros. Cabe ressaltar que a menção do termo nível de automatização, no texto, refere-se às atividades que podem ter sua execução suportada por certos sistemas que lhes provêem mecanismos de acompanhamento ou podem ser atividades cuja automatização é totalmente realizada por sistemas.

Neste momento, após a escolha mais adequada do sistema no suporte do processo e a divisão das atividades nas três categorias acima mencionadas, os requisitos podem ser elicitados a partir das atividades previamente escolhidas. Todo o procedimento acima descrito corresponde à fase de análise de requisitos e de regras relacionados ao processo e pode ser executado a partir da metodologia acima descrita. Neste momento, ocorre a transição dos modelos conceituais (relacionados com os processos em alto nível) para os modelos lógicos (relacionados com o projeto do sistema). As funcionalidades providas pelos sistemas às atividades são consideradas requisitos funcionais destes sistemas e são mapeadas nos casos de uso correspondentes. Os requisitos não funcionais que estão relacionados à qualidade dos serviços providos pelo sistema tais como desempenho, segurança e disponibilidade, são geralmente propriedades ou características de vários casos de uso.

Enjoy!

O modelo de design hierárquico

O modelo de rede hierárquico é uma ferramenta útil de alto nível para projetar uma infra-estrutura de rede confiável. Ele fornece uma exibição modular de uma rede, o que facilita o projeto e a criação de uma rede escalável.

O modelo de rede hierárquico divide uma rede em três camadas:

Camada de acesso – concede acesso ao usuário a dispositivos de rede. Em um campus de rede, a camada de acesso costuma incorporar dispositivos de rede local comutados com portas que fornecem conectividade a estações de trabalho e servidores. No ambiente WAN, ele pode fornecer a funcionários remotos ou sites remotos o acesso à rede corporativa em toda a tecnologia WAN.

Camada de distribuição – agrega os wiring closets, utilizando switches para dividir os grupos de trabalho em segmentos e isolar problemas de rede em um ambiente de campus. Da mesma forma, a camada de distribuição agrega conexões WAN na borda do campus e fornece conectividade baseada na política.

Camada do núcleo (também conhecida como o backbone) – um backbone de alta velocidade projetado para comutar pacotes o mais rápido possível. Como o núcleo é essencial para conectividade, ele deve fornecer um alto nível de disponibilidade e se adaptar a alterações muito rapidamente. Ele também fornece escalabilidade e convergência rápida.

A figura representa o modelo de rede hierárquico em ambientes de campus. O modelo de rede hierárquico fornece uma estrutura modular que garante flexibilidade no projeto de rede e facilita a implementação e a solução de problemas na infra-estrutura. No entanto, é importante compreender que a infra-estrutura de rede só é a base de uma arquitetura mais ampla. As tecnologias de networking avançaram consideravelmente nos últimos anos, o que resulta em redes cada vez mais inteligentes. Os elementos de rede atuais têm mais características de tráfego, podendo ser configurados para fornecer serviços especializados com base em coisas como os tipos de dados transportados, a prioridade dos dados e até mesmo as necessidades de segurança. Embora grande parte desses serviços de infra-estrutura estejam fora do escopo desse curso, é importante compreender que eles influenciam o projeto da rede. No próximo tópico, iremos explorar a arquitetura corporativa Cisco, que expande o modelo hierárquico, utilizando a inteligência de rede para abordar a infra-estrutura de rede.

Enjoy!

Wide Area Network - Redes de Grande Distância

O que é uma WAN?

WAN é uma rede de comunicação de dados que funciona além do escopo geográfico de uma rede local.  As WANs são diferentes das redes locais em vários aspectos. Enquanto uma rede local conecta computadores, periféricos e outros dispositivos em um único prédio ou outra área geográfica menor, uma WAN permite a transmissão dos dados em distâncias geográficas maiores. Além disso, uma empresa deve contratar um provedor de serviço WAN para utilizar os serviços de rede dessa operadora. As redes locais costumam ser da companhia ou organização que as utilizam. As WANs utilizam instalações fornecidas por um provedor de serviços ou operadora, como uma companhia telefônica ou empresa de cabeamento, para conectar os locais de uma organização aos locais de outras organizações, a serviços externos e a usuários remotos. As WANs normalmente transportam vários tipos de tráfego, como voz, dados e vídeo.

Aqui estão as três principais características das WANs:

As WANs normalmente conectam dispositivos separados por uma área geográfica maior do que a que pode ser atendida por uma rede local.
As WANs utilizam os serviços das operadoras, como companhias telefônicas, empresas de TV a cabo, sistemas de satélites e provedores de rede.
As WANs utilizam conexões seriais de vários tipos para fornecer acesso à largura de banda em grandes áreas geográficas.

Por que as WANs são necessárias?

As tecnologias de rede local fornecem velocidade e economia na transmissão de dados em organizações em áreas geográficas relativamente pequenas. No entanto, há outras necessidades de negócios que precisam de comunicação entre locais remotos, inclusive as seguintes: As pessoas no escritório regional ou nas filiais de uma organização precisam ser capazes de se comunicar e compartilhar dados com o local central. As organizações normalmente desejam compartilhar informações com outras organizações em grandes distâncias. Por exemplo, fabricantes de software sempre comunicam informações sobre produtos e promoções aos distribuidores que vendem seus produtos para usuários finais. Os funcionários que viajam a negócios sempre precisam acessar informações presentes em suas redes corporativas. Além disso, os usuários de computadores domésticos precisam enviar e receber dados em distâncias cada vez maiores. Aqui estão alguns exemplos: Agora é comum em muitas residências que os clientes se comuniquem com bancos, lojas e vários fornecedores de mercadorias e serviços via computadores. Os alunos realizam pesquisas relativas às aulas acessando índices de bibliotecas e publicações localizados em outras partes do país, além de outras partes do mundo. Como obviamente não é possível conectar computadores em um país ou em todo o mundo da mesma forma que os computadores são conectados em uma rede local com cabos, surgiram tecnologias diferentes para atender a essa necessidade. Cada vez mais, a Internet está sendo utilizada como uma alternativa barata à utilização de uma WAN corporativa em alguns aplicativos. Há novas tecnologias disponíveis para as empresas fornecerem segurança e privacidade em suas comunicações e transações na Internet. As WANs utilizadas por elas mesmas, ou em conjunto na Internet, permitem a organizações e indivíduos atender a suas necessidades de comunicação remota.

Enjoy!

Otimizar a performance do MySQL em Linux

Uma das componentes mais importantes na optimização do desempenho de um ambiente LAMP (Linux, Apache, MySQL, PHP/Perl) é definitivamente a componente base de dados, ou seja, o MySQL. É o componente onde a sua correcta configuração pode fazer a maior diferença entre um servidor que fica de rastos com um pequeno pico no tráfego ou um que aguenta incólume.

É possível tornar o MySQL mais rápido de 3 formas:

   1. Hardware mais potente.Aumentar a capacidade do hardware é a mais fácil de todas, mas também a mais dispendiosa e menos eficiente.
   2. Correcta afinação dos parâmetros do MySQL (my.cnf). A correcta definição dos parâmetros permite que a memória disponível no servidor seja distribuída da melhor forma, tentamos pois minimizar que o processo mysqld tenha aceda ao disco. Também informamos a base de dados acerca do tipo de carga a esperar para que o MySQLprepare os seus recursos da forma mais eficiente.
   3. Otimização das consultas SQL. É de extrema importância que as tabelas tenham os índices bem definidos, entre outros aspectos.

Neste artigo mostro uma forma simples e expedita de saber quais os parâmetros e que valores aplicar no my.cnf (ficheiro de configuração do MySQL).


Aplicar o my.cnf mais apropriado ao sistema

Juntamente com todas as instalações do MySQL, vem um conjunto de ficheiros modelo de configuração para vários tipos de servidor. Devemos escolher aquele que é mais indicado para o nosso caso específico.

Os ficheiros modelo são os seguintes:

    * my-huge.cnf (enorme capacidade)
    * my-large.cnf (grande capacidade)
    * my-medium.cnf (média capacidade)
    * my-small.cnf (pequena capacidade)

As definições que vêm por defeito no my.cnf são para um servidor com capacidades muito reduzidas, isto para que, por defeito, o MySQL possa correr em qualquer servidor. Devemos por isso substituir esses parâmetros pelos encontrados num dos ficheiros modelo mais adequado ao nosso tipo de sistema.

Caso não saiba onde se encontram esses ficheiros no sistema pode aplicar o seguinte comando para descobrir a sua localização.

find / -name my-*.cnf

Depois de feitas as alterações deve reiniciar o MySQL e esperar até que ele tenha pelo menos 48 horas de carga.


Instalar e correr o MySQL Performance Tuning Primer Script

Fazer o download do scrip

wget http://day32.com/MySQL/tuning-primer.sh

Tornar o script executável

chmod +x ./tuning-primer.sh

Correr o script

./tuning-primer.sh


Exemplo do relatório para um caso real


-- MYSQL PERFORMANCE TUNING PRIMER --
     - By: Matthew  Montgomery -
MySQL Version 4.1.22-standard-log i686

Uptime = 2 days 7 hrs 2 min 31 sec
Avg. qps = 332
Total Questions = 65843202
Threads Connected = 44

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/4.1/en/server-sys
tem-variables.html
Visit  http://www.mysql.com/products/enterprise/a
dvisors.html
for info about MySQL's Enterprise Monitoring and
 Advisory Service

SLOW QUERIES
Current long_query_time = 5 sec.
You have 1942348 out of 65843325 that take longer
than 5 sec. to complete
The slow query log is enabled.
Your long_query_time seems to be fine

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 7
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 47
Historic max_used_connections = 101
The number of used connections is 101% of  the
configured maximum.
You should raise max_connections

MEMORY USAGE
Max Memory Ever Allocated : 1 G
Configured Max Per-thread Buffers : 1 G
Configured Max Global Buffers : 426 M
Configured Max Memory Limit : 1 G
Physical Memory : 5.94 G
Max memory limit seem to be within
acceptable norms

KEY BUFFER
Current MyISAM index space = 179 M
Current key_buffer_size = 384 M
Key cache miss rate is 1 : 62678
Key buffer fill ratio = 23.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 14 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 44.98 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger
than  query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current record/read_rnd_buffer_size = 7 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 766426 queries where a join could
not use an index properly
You have had 501 joins without keys that check
for key  usage after each row
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query
log.
If you are unable to optimize your queries you
may want to increase your
join_buffer_size to accommodate larger joins
in one pass.
Note! This script will still suggest raising
the  join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 4166 files
The open_files_limit should typically be set
to at  least 2x-3x
that of table_cache if you have heavy MyISAM usage.
You currently have open more than 75% of your
open_files_limit
You should set a higher value for open_files_limit
in  my.cnf

TABLE CACHE
Current table_cache value = 2028 tables
You have a total of 1652 tables
You have 2028 open tables.
Current table_cache hit rate is 14%,  while 100%
of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 793662 temp tables, 17% were created on disk
Effective in-memory tmp_table_size is limited to 
max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 69 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 44
You may benefit from selective use of InnoDB.
If you have long running SELECT's against
MyISAM tables and perform
frequent updates consider setting
'low_priority_updates=1'



O relatório está dividido em várias secções. No final de cada secção é feita a sugestão se algo deve ser alterado ou se os parâmetros definidos estão corretos.

Finalmente devemos aplicar as sugestões e analisar o comportamento do sistema. Este script poupa muito tempo de análise e interpretação dos imensos parâmetros passíveis de optimização. Este processo deve ser revisto regularmente, principalmente se acontecerem mudanças na quantidade de tráfego a chegar ao sistema.

Alternativa mais demorada

Também é possível fazer este trabalho de otimização de uma forma não automática. Para este efeito recomendo a instalação do mysqlreport e leitura do manual de interpretação do relatório.

Enjoy!

Flexibilidade dos Softwares

Vários autores comentam que muitos dos sistemas de TI (incluindo alguns ERP's) possuem a flexibilidade (melhor seria fluidez) de "concreto líquido" antes da implantação, quando tudo é possível, qualquer forma é factível de se adaptar; porém, após a implantação, transforma-se em "concreto endurecido", dificílimo de ser alterado: qualquer alteração é custosa e demorada e transformações contínuas podem implicar em ter de alterar toda a estrutura inicial. Infelizmente nossos softwares não são tão "soft" assim.

Enjoy!

Visão geral das tecnologias WAN e Computadores

Uma WAN é uma rede de comunicações de dados que opera além da abrangência geográfica de uma rede local. Uma das principais diferenças entre uma WAN e uma rede local é que uma empresa ou organização precisa ser assinante de um provedor de serviços WAN para poder usar os serviços de rede da operadora. Uma WAN usa os enlaces de dados fornecidos pelas operadoras para prover o acesso à Internet, a conexão entre as diversas localidades de uma organização e a conexão com as redes de outras organizações, possibilitando ainda, a oferta de serviços externos e o acesso de usuários remotos. WANs geralmente transportam vários tipos de tráfego, como voz, dados e vídeo. Os serviços telefônicos e de dados são os serviços WAN mais comumente usados. Os dispositivos que ficam nas instalações do assinante são chamados CPE (customer premises equipment).  O assinante é dono do CPE ou o aluga do provedor de serviços. Um cabo de cobre ou fibra conecta o CPE à central da operadora (CO – Central Office). Esse cabeamento geralmente é chamado de loop local ou "last mile". Uma chamada discada é conectada a outros loops locais na mesma região através da própria central da operadora, ou a outros em regiões mais distantes através de um tronco com uma central principal. Em seguida, ela vai até uma central seccional e segue para uma central regional ou internacional da operadora, ao longo do trajeto até seu destino. Para que o loop local transporte dados, é necessário um dispositivo (por exemplo, um modem) que prepare os dados para transmissão. Os dispositivos que colocam dados no loop local são chamados de equipamentos de terminação do circuito de dados, ou equipamentos de comunicações de dados (DCE – Data Communications Equipment). Os dispositivos do cliente que passam os dados para o DCE são chamados de equipamentos terminais de dados (DTE – Data terminal Equipment).  A principal função do DCE é fornecer ao DTE uma interface com o enlace de comunicação que o conecta à nuvem WAN. A interface DTE/DCE usa vários protocolos de camada física, tais como HSSI (High-Speed Serial Interface – Interface Serial de Alta Velocidade) e V.35. Esses protocolos estabelecem os códigos e os parâmetros elétricos usados pelos dispositivos para se comunicarem. Os enlaces WAN são fornecidos em diversas velocidades, medidas em bits por segundo (bps), quilobits por segundo (kbps ou 1000 bps), megabits por segundo (Mbps ou 1000 kbps) ou gigabits por segundo (Gbps ou 1000 Mbps). Geralmente, os valores bps são full duplex. Isso significa que uma linha E1 pode transportar 2 Mbps ou que uma linha T1 pode transportar 1,5 Mbps em cada direção ao mesmo tempo.

O interessante é que pelas mesmas linhas telefônicas que antes levavam apenas vozes estáticas passam hoje ordens de compra, grandes somas de dinheiro, plantas de projetos de produtos, material de propaganda, reuniões e conferências. Os computadores, que a princípio automatizavam cálculos, hoje aconselha aos responsáveis por decisões, e até mesmo toma essas decisões, recolhe e coloca à disposição um grande volume de texto, números, imagens, siumula uma imensa variedade de processos e ambientes (inclusive aspectos limitados, mascrescentes da "realidade") e acompanha e controla o desempenho de vários aparelhos que vão de naves espaciais a corações artificiais.

Enjoy!

Cadeia de valor de Porter

Uma cadeia de valor representa o conjunto de atividades desempenhadas por uma organização desde as relações com os fornecedores e ciclos de produção e de venda até à fase da distribuição final. O conceito foi introduzido por Michael Porter em 1985. Ao decompor uma organização nas suas atividades de relevância estratégica, torna-se possível analisar o comportamento dos custos e as fontes existentes assim como potenciais de diferenciação em cada processo de negócio, otimizando o valor final que o seu produto representa para o cliente. A liderança de custo e a diferenciação pela qualidade acrescem valor ao produto e proporcionam vantagem competitiva à organização no contexto da indústria em que se insere. A cadeia de valor de uma organização insere-se num contexto mais amplo de atividades, ela constitui um sistema de valores onde estão integradas também as cadeias de valor de fornecedores e de distribuidores. Quando não temos um modelo especializado da organização para mapeamento de processos, a cadeia de valor de Porter torna-se um excelente ponto de partida.

Enjoy!

Algumas Falácias

Um pouco de arte!

Enjoy!

A Relação Entre TDD e Qualidade de Software

TDD é uma prática que visa aumentar a velocidade da entrega de produtos através da simplificação das atividades de desenho de software. [Koskela 2008] resume a filosofia do TDD em uma frase -- somente escreva código para fazer um teste falho passar. Enquanto isso, [Astels 2003] define o TDD como sendo um estilo de desenvolvimento onde:

    * Uma suíte exaustiva de testes de programadores é mantida;
    * Nenhum código entra em produção a não ser que tenha testes associados;
    * Os testes são escritos antes;
    * Os testes determinam que código precise ser escrito.

Qualidade não pode ser alcançada através da avaliação de um produto já feito. O objetivo, portanto, é prevenir defeitos de qualidade ou deficiências em primeiro lugar, tornando os produtos avaliáveis através de medidas de garantia de qualidade [Lewis 2004]. [Beck 1999] cita alguns exemplos de riscos relacionados ao desenvolvimento de software. Dos riscos citados, dois estão diretamente ligados a qualidade de software e podem ser tratados através da utilização de TDD:

    * Taxa de defeitos -- o software é colocado em produção mas a taxa de defeitos é tão alta que ele acaba não sendo utilizado. TDD eleva a validação de um software a um patamar superior, testando-o função por função;
    * Deterioração do sistema -- o software é colocado em produção com sucesso, porém após algum tempo o custo de se fazer modificações ou a taxa de defeitos aumenta tanto que o sistema precisa ser substituído. TDD mantém o programador focado na solução, de forma que o software não fica carregado de códigos desnecessários, duplicados ou de difícil manutenção, impedindo a deterioração do sistema.

Nesta mesma obra, [Beck 1999] elaborou três frases de impacto, que servem como um ponto de partida para entendermos como o TDD afeta a qualidade de um software:

    * Toda vez que alguém toma uma decisão e não a testa, existe uma grande probabilidade de que esta decisão esteja errada;
    * Funcionalidades de software que não podem ser demonstradas através de testes automatizados simplesmente não existem;
    * Testes nos dão à chance de pensar sobre o que queremos, independente da forma como a solução será implementada.

Ao utilizar TDD, devemos escrever testes para cada solução implementada. Dessa forma, diminuímos a probabilidade de tomarmos uma decisão errada. Ao mesmo tempo, temos a oportunidade de experimentar várias implementações diferentes para o mesmo problema e escolher aquela mais limpa, elegante e que apresente o melhor desempenho.

Desenho Simplificado e Evolucionário

Escrevendo somente o necessário para os testes e removendo toda a duplicação, você automaticamente obtém um desenho que é perfeitamente adaptado para os requisitos atuais e igualmente preparado para todas as futuras funcionalidades [Beck 2002]. Design simplificado reduz os custos porque ao escrever menos código para atender os requisitos, menos código existirá para ser mantido no futuro. Design simplificado é mais fácil de se construir, manter e entender.

Refatoração

Os testes lhe dão a confiança de que grandes refatorações não mudarão o comportamento do sistema, o que se conclui que, quanto maior a confiança, mais agressivamente você poderá conduzir refatorações em larga escala que estenderão a vida de seu sistema. A refatoração torna a elaboração dos próximos testes muito mais fácil [Beck 2002]. Custos são reduzidos porque a refatoração contínua evita que o desenho se degrade com o passar do tempo, assegurando que o código continue fácil de ser entendido, mantido e modificado.

Feedback Constante

[Beck 2002], no último capítulo de sua publicação, afirma que TDD o ajuda a dar atenção aos problemas certos na hora certa, de forma que o desenho do software fica mais limpo e com muito menos defeitos. O TDD faz com que o programador ganhe confiança sobre seu código com o passar do tempo, isto é, à medida que os testes vão se acumulando (e melhorando), ele ganha confiança no comportamento do sistema. E ainda, à medida que o desenho é refinado, mais e mais mudanças se tornam possíveis. Outra vantagem do TDD que [Beck 2002] acredita poder explicar seus efeitos positivos, é a forma como ele encurta o ciclo de feedback sobre as decisões de desenho. Ele dura apenas segundos ou minutos, e é seguido pela reexecução dos testes dezenas ou centenas de vezes por dia. Ao invés de se projetar um desenho e então esperar semanas ou meses para outra pessoa sentir as dores ou glórias de sua consequência, o feedback emerge em segundos ou minutos, enquanto você tenta traduzir suas idéias em interfaces plausíveis.

Suíte de Testes (Regressão)

Usando TDD, os testes unitários são criados num momento onde a funcionalidade a ser implementada está mais bem definida na mente do programador, e depois podem e devem ser utilizados para fazer testes de regressão. Uma suíte de testes automáticos feita por programadores reduz os custos de um software funcionando como uma rede de segurança de testes que capturam defeitos, problemas de comunicação e ambigüidades antes e permitem que o desenho possa ser modificado de forma incremental. Esta suíte de testes gerada pelo TDD é fundamental para viabilizar procedimentos de Integração Contínua.

Documentação Para Programadores

A suíte de testes serve como uma documentação voltada para o programador que tem um entendimento mais rápido e facilitado do que uma parte do código faz através do código que o testa. Cada teste unitário especifica o uso apropriado de uma classe de produção [Langr 2005].

Conclusões

Esta técnica de desenvolvimento   produz desenhos menos acoplados que são mais fáceis de manter, reduz altamente a quantidade de defeitos, e reforça a construção e manutenção apenas do que é realmente necessário. Finalmente, testes bem escritos atuam como um tipo de requisitos “executáveis” que ajudam a manter o entendimento compartilhado da equipe de desenvolvimento, sobre como o sistema de software representa os problemas do mundo real. Por outro lado, o fato de se ter um grande número de testes unitários passando com sucesso, pode passar uma falsa sensação de segurança, resultando na implementação de menos atividades de garantia de qualidade, como testes de integração e testes de conformidade. É importante ressaltar também que, esta técnica não garante a obtenção de níveis aceitáveis em certos aspectos do software final, como usabilidade e desempenho. Além disso, TDD não consegue mitigar riscos relacionados com a falta de requisitos ou com requisitos erroneamente definidos.

Referências

Astels, D. (2003). Test-Driven Development: A Practical Guide. Prentice Hall PTR.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison Wesley.
Beck, K. (2002). Test-Driven Development By Example. Addison Wesley.
Koskela, L. (2008). Test Driven: Pratical TDD and Acceptance TDD for Java Developers.Manning.
Langr, J. (2005). Agile Java Crafting Code with Test-Driven Development. Prentice Hall PTR.
Lewis, W. E. (2004). Software Testing and Continuous Quality Improvement. Auerbach, 2 edition.

Arquitetura de Software

Os sistemas de software vêm se tornando cada vez mais essenciais à sociedade e às organizações. Dentre os fatores que impulsionaram este fato estão a evolução do hardware nas últimas décadas e a explosão do uso da Internet. Software representa atualmente um fator de competitividade para as empresas, as quais apresentam uma demanda crescente por sistemas e uma exigência de prazo e qualidade cada vez maiores. Com tudo isso, o perfil do desenvolvimento de software vai se modificando, com o foco migrando para sistemas distribuídos, mais complexos e com uma produção em grande escala. Para suportar este novo perfil do desenvolvimento de software, uma disciplina vem emergindo e ganhando importância: a arquitetura de software. A arquitetura enfatiza a organização global do sistema, definindo a sua topologia e permitindo que desenvolvedores voltem a sua atenção para os requisitos funcionais e não-funcionais que precisam ser atendidos, antes de se aterem ao projeto das estruturas de dados e algoritmos. Em outras palavras, projetar a estrutura global de um sistema emerge como um problema novo: o desenvolvimento de software orientado para arquitetura (MENDES, 2002). Diversas definições são dadas para arquitetura de software na literatura. Dentre elas, destacam-se: “Descrição dos elementos a partir dos quais os sistemas são construídos (componentes), interações entre estes elementos (conectores), padrões que guiam sua composição, e restrições sobre estes padrões” (SHAW e GARLAN, 1996). “A estrutura de componentes de um programa/sistema, seus relacionamentos, princípios e diretrizes que governam seu projeto e evolução ao longo do tempo” (GARLAN e PERRY, 1995). “A arquitetura de um sistema consiste da(s) estrutura(s) de suas partes (incluindo as partes de software e hardware envolvidas no tempo de execução, projeto e teste), da natureza e das propriedades relevantes que são externamente visíveis destas partes (módulos com interfaces, unidades de hardware, objetos), e dos relacionamentos e restrições entre elas” (D’SOUZA e WILLS, 1999). A arquitetura desempenha um papel ainda mais importante nas abordagens de engenharia de software voltadas à reutilização, como a ED, onde ela estabelece a estrutura na qual os componentes reutilizáveis do domínio são conectados e instanciados, e para a qual os novos componentes das aplicações devem apresentar compatibilidade. Neste contexto, torna-se cada vez mais evidente a necessidade do projeto arquitetural nos processos de engenharia de software.

Enjoy!

O Teste Do Joel

   1. Você usa controle de código?
   2. Você pode compilar em somente um passo?
   3. Você faz compilações diárias?
   4. Você tem uma base de dados de bugs?
   5. Você corrige os bugs antes de escrever código novo?
   6. Você tem um cronograma atualizado?
   7. Você tem uma especificação?
   8. Os programadores tem condições de trabalho tranqüilas?
   9. Você usa as melhores ferramentas que o dinheiro pode comprar?
  10. Você tem testadores?
  11. Novos candidatos escrevem código durante a entrevista?
  12. Você faz testes de usabilidade de corredor?

Extraído de [http://brazil.joelonsoftware.com/Articles/TheJoelTest.html]

Enjoy!

Os programadores têm condições de trabalho tranqüilas?

Existe uma extensa documentação sobre ganhos de produtividade obtidos ao dar aos profissionais do conhecimento espaço, quietude e privacidade. O livro clássico de gerenciamento de software Peopleware documenta extensamente estes benefícios de produtividade.

Eis o problema. Todos nós sabemos que estes profissionais trabalham melhor entrando no "fluxo", também conhecido como "estar na zona", onde eles estão completamente concentrados em seu trabalho e totalmente desligados de seu ambiente. Eles perdem a noção do tempo e produzem grandes coisas através da concentração absoluta. Escritores, programadores, cientistas e mesmo jogadores de basquete podem te dizer algo sobre "estar na zona".

O problema é que entrar no "fluxo" não é fácil. Quando você tenta medí-lo, parece que leva uma média de 15 minutos para se começar a trabalhar na produtividade máxima. Às vezes, se você está cansado ou já fez uma porção de trabalho criativo naquele dia, você simplesmente não consegue entrar em transe e gasta o resto de seu dia de trabalho com besteiras, navegando na web, jogando Tetris.

O outro problema é que é muito fácil sair do transe. Barulho, chamadas telefônicas, sair para almoçar, dirigir 5 minutos até a Casa do Pão de Queijo para um café e interrupções de colegas de trabalho -- principalmente interrupções de colegas de trabalho -- tiram você do transe. Se um colega de trabalho te faz uma pergunta, causa 1 minuto de interrupção, mas tira-lhe do transe e faz com que você leve uma meia hora para estar produtivo novamente, e sua produtividade geral está em sérios problemas. Se você está em um ambiente de baias barulhento como o tipo que as cafeinadas empresas pontocom adoram criar, com caras do marketing gritando no telefone perto de programadores, sua produtividade será desperdiçada, assim como a do profissional do conhecimento que é interrompido de tempos em tempo e nunca entra "na zona".

Com programadores, é especialmente difícil. Produtividade depende de ser capaz de manipular uma série de pequenos detalhes em um curto espaço de memória tudo de uma vez. Qualquer tipo de interrupção pode causar a dispersão destes detalhes. Quanto você retoma o trabalho, você não pode se lembrar de cada um dos detalhes (como nomes de variáveis locais que estava usando ou onde você estava na implementação daquele algoritmo de busca) e você tem que lembrar estas coisas, o que o retarda um bocado até que você volta à velocidade original.

Eis a matemática. Digamos (como a evidência sugere) que se nós interrompermos um programador, mesmo que por um minuto, estaremos realmente desperdiçando 15 minutos de produtividade. Para este exemplo, vamos tomar dois programadores, João e Manoel, em baias abertas próximas no padrão Dilbert de fazenda de engorda de gado. Manoel não consegue lembrar o nome da versão Unicode da função strcpy. Ele pode procurá-la, o que leva 30 segundos, ou pode perguntar ao João, o que leva 15 segundos. Uma vez que ele está sentado ao lado do João, ele pergunta ao João. João se distrai e perde 15 minutos de produtividade (para economizar 15 segundos do Manoel).

Agora vamos colocá-los em escritórios separados com paredes e portas. Agora quando Manoel não lembrar o nome daquela função, ele pode procurar, o que ainda leva 30 segundos, ou ele pode perguntar ao João, o que agora leva 45 segundos e envolve se levantar (uma tarefa difícil, dada a forma física média de programadores!). Então ele procura. Agora Manoel perdeu 30 segundos de produtividade, mas nós salvamos 15 minutos do João. Ahhh

Áreas de Conhecimento segundo o SWEBOK

O SWEBOK é um guia de uso e aplicação das melhores práticas de Engenharia de Software, informado, sensato e razoável. Ele foi desenvolvido com conhecimentos
recolhidos no período de 4 décadas e revisado por inúmeros profissionais de diversos países envolvidos com a Engenharia de Software. Seu principal objetivo foi estabelecer um conjunto apropriado de critérios e normas para a prática profissional da Engenharia de Software. Neste guia, a Engenharia de Software foi dividida em 10 áreas de conhecimentos, também conhecidas por KAs (Knowledge Areas), que serão descritas na seqüência (SWEBOK, 2004).

1 Requisitos de Software
Os requisitos expressam a necessidade e restrições colocadas sobre o produto de software que contribuem para a solução de algum problema do mundo real. Esta área envolve elicitação, análise, especificação e validação dos requisitos de software (SWEBOK, 2004).
Segundo Breitman e Sayão (2005), os requisitos de software são classificados em:
· Requisitos funcionais: correspondem a funcionalidade do software e o que o sistema deve fazer;
· Requisitos não funcionais: expressam restrições e características que o software deve atender ou ter;
· Requisitos inversos: definem estados e situações que nunca podem acontecer.
Pressman (2002) cita que “se você não analisa, é altamente provável que construa uma solução de software muito elegante que resolve o problema errado”. Esta
atitude pode resultar em perda de tempo e dinheiro, pessoas frustradas e clientes insatisfeitos.

2 Design de Software
Segundo o SWEBOK (2004), esta área envolve definição da arquitetura, componentes, interfaces e outras características de um sistema ou componente. Visualizado como um processo, esta área é uma etapa do ciclo de vida da Engenharia de Software, onde os requisitos são analisados para produzir uma descrição da arquitetura do software. Para Pressman (2002), design de software "é um processo iterativo através do qual os requisitos são traduzidos num documento para construção do software."

3 Construção de Software
Refere-se a implementação do software, verificação, testes de unidade, testes de integração e debugging. Esta área está envolvida com todas as áreas de conhecimento, porém, está fortemente ligada às áreas de Design e Teste de Software, pois o processo de construção abrange significativamente estas duas áreas (SWEBOK, 2004). As áreas correlatas à construção de software, segundo o SWEBOK (2004) são:

· Fundamentos: minimizar a complexidade, antecipar mudanças, construir para verificar e padrões de construção;
· Gerenciamento da construção: modelos, planejamento e métricas;
· Considerações práticas: design, linguagens, codificação, testes, reutilização, qualidade e integração.

É importante que as funcionalidades do software sejam testadas durante todo o processo de desenvolvimento, não deixando apenas para a etapa de testes.

4 Teste de Software
Teste de software é uma atividade executada para avaliar a qualidade do produto, buscando identificar os defeitos e problemas existentes (SWEBOK, 2004).
Para Pressman (2002), "teste de software é um elemento crítico da garantia de qualidade de software e representa a revisão final da especificação, projeto e geração de código."
Segundo Coelho (2005) os tipos de teste são:
· Teste funcional: verifica as regras de negócio, condições válidas e inválidas;
· Teste de recuperação de falhas: as falhas são provocadas diversas vezes a fim de verificar a eficiência da recuperação;
· Teste de desempenho: verifica o tempo de resposta e processamento para configurações diferentes;
· Teste de segurança e controle de acesso: verifica a funcionalidade dos mecanismos de proteção de acesso e de dados;
· Teste de interfaces com o usuário: verifica navegação, consistência e padrões;
· Teste de volume: verifica até aonde o software suporta.
A etapa de teste de software é relevante para que os erros possam ser encontrados e corrigidos antes que o software seja entregue ao cliente.

5 Manutenção de Software
Esta área de conhecimento é definida como a totalidade das atividades requeridas para fornecer suporte custo-efetivo a um sistema de software, que pode ocorrer antes ou depois da entrega. Antes da entrega do software são realizadas atividades de planejamento e depois, modificações são feitas com o objetivo de corrigir falhas, melhorar o desempenho ou adaptá-las a um ambiente externo (SWEBOK, 2004). Os tipos de modificações durante a fase de manutenção, segundo Pressman (2002) são:
· Manutenção corretiva: modifica o software para corrigir erros;
· Manutenção adaptativa: altera o software para acomodar mudanças no seu ambiente externo;
· Manutenção perfectiva: aprimora o software (solicitações do cliente);
· Manutenção preventiva (reengenharia): modifica o software a fim de torná-los mais fáceis de serem corrigidos, adaptados e melhorados.

Em torno de 60% do esforço despendido por uma organização de desenvolvimento é referente à manutenção de software. Este percentual continua
crescendo à medida que mais softwares são produzidos. Manutenção de software não é só concertar erros. Apenas 20% do trabalho de manutenção é referente à correção de falhas e, os outros 80% refere-se à adaptações ao ambiente externo e a melhorias solicitadas pelos usuários (PRESSMAN, 2002).

6 Gerenciamento de Configuração de Software
Conforme Cunha et al (2004), o GCS (Gerenciamento de Configuração de Software) é um processo que provê recursos para a identificação, controle da evolução e auditagem dos artefatos de software criados durante o desenvolvimento do projeto. De grosso modo, é o controle de versões do software. A finalidade do GCS é estabelecer e manter a integridade dos produtos de software durante todo seu ciclo de vida (SWEBOK, 2004):
· Identificar a configuração do software em um dado momento;
· Controlar sistematicamente as mudanças de configuração;
· Manter a integridade e a rastreabilidade da configuração ao longo do ciclo de vida do software;
· Controlar a integridade dos artefatos compostos, levando em conta cada um dos componentes do software;
· Registrar e controlar o estado do processo de alteração.

Porém, sua aplicação em empresas de desenvolvimento de software é complexa, e às vezes inviabilizada pelos gastos. Uma forma de contornar isso é desenvolver uma metodologia de gerenciamento de configuração que leve em conta somente aspectos relevantes para a realidade da empresa, descartando aqueles que são menos utilizados.

7 Gerenciamento de Engenharia de Software
Segundo SWEBOK (2004), Gerenciamento de Engenharia pode-se definir como a aplicação das atividades de gerenciamento: planejamento, coordenação, medição,
monitoração, controle e documentação, garantindo que o desenvolvimento e a gerência de software sejam sistemáticos, disciplinados e qualificados.
O Gerenciamento de Engenharia é tratado sob dois aspectos:
· Engenharia de Processo: refere-se às atividades empreendidas para geração de políticas, padrões e objetivos organizacionais consistentes;
· Engenharia de Mensuração: refere-se à atribuição de valores e rótulos às atividades referentes à Engenharia de Software.

O gerenciamento de processo e a mensuração são importantes em todas as área de conhecimento, mas o Gerenciamento de Engenharia trata esses aspectos de forma
mais direta. Um grande aliado desta área de conhecimento é o Gerenciamento de Projetos, que pode ser visto a seguir.

7.1 Gerenciamento de Projetos de Software
Projeto é um empreendimento temporário, de elaboração progressiva e com o objetivo de criar um produto ou serviço único (PMBOK, 2004).
· Temporário: o projeto possui início e fim bem definidos e pode ser de curta ou longa duração. O projeto chega ao fim quando os seus objetivos são atingidos;
· Elaboração progressiva: o desenvolvimento ocorre em etapas e continua por incrementos;
· Produto ou serviço único: cada projeto é exclusivo.

Segundo o PMBOK (2004), o gerenciamento de projetos "é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de
atender aos seus requisitos". É realizado através de cinco grupos de processos: iniciação, planejamento, execução, monitoramento e controle, e encerramento.
Para Pressman (2002), “a gestão do projeto envolve o planejamento, a monitoração e controle do pessoal, processo e eventos que ocorrem à medida que o
software evolui de um conceito preliminar para uma implementação operacional". O gerenciamento de projetos auxilia as organizações a atenderem as
necessidades de seus clientes, padronizando tarefas do dia a dia e reduzindo o número de tarefas, que muitas vezes são esquecidas (PMI-SC, 2006).
Por fim, gerenciar projetos é manter o equilíbrio entre escopo, qualidade, custos, recursos e tempo (PMBOK, 2004). É papel do gerente de projetos avaliar os riscos e impactos associados a qualquer mudança em um desses fatores.

8 Engenharia de Processo de Software
A Engenharia de Processo pode ser interpretada como uma visão geral sobre questões relacionadas ao processo de Engenharia de Software, principalmente as atividades relacionadas à definição, implementação, avaliação, mensuração, gerenciamento, mudanças e melhorias do processo de ciclo de vida de software (SWEBOK, 2004). O objetivo da Engenharia de Processo de Software é implementar processos novos e melhores, seja no escopo individual, de projeto ou organizacional.

9 Ferramentas e Métodos de Software
Ferramentas de desenvolvimento de software são ferramentas criadas para auxiliar no ciclo de vida do software. Essas ferramentas normalmente automatizam algumas atividades do processo de desenvolvimento, fazendo com que o analista concentre-se nas atividades que exigem maior trabalho intelectual (SWEBOK, 2004). Métodos de Engenharia de Software impõe estrutura sobre a atividade de desenvolvimento e manutenção de software com o objetivo de torná-la sistemática e mais propensa ao sucesso (SWEBOK, 2004). Esta área de conhecimento tem como objetivo pesquisar ferramentas e métodos que aumentem a produtividade dos desenvolvedores enquanto reduzem a ocorrência de falhas no desenvolvimento (FERNANDES, 2003).

10 Qualidade de Software
A qualidade de software não pode ser entendida como perfeição. Qualidade é um conceito multidimensional, realizado por um conjunto de atributos, representando vários aspectos relacionados ao produto: desenvolvimento, manutenção e uso. Qualidade é algo factível, relativo, dinâmico e evolutivo, adequando-se ao nível dos objetivos a serem atingidos (SIMÃO, 2002). Um dos principais objetivos da Engenharia de Software é melhorar a qualidade
dos produtos de software, ela visa estabelecer métodos e tecnologias para construir produtos de software de qualidade dentro dos limites de tempo e recursos disponíveis. A qualidade de software está diretamente ligada com a qualidade do processo através do qual o software é desenvolvido, portanto, para se ter qualidade em um produto de software é necessário ter um processo de desenvolvimento bem definido, que deve ser documentado e acompanhado (SWEBOK, 2004).
A avaliação da qualidade de produtos de software normalmente é feita através de modelos de avaliação de qualidade. Esses modelos descrevem e organizam as
propriedades de qualidade do produto em avaliação. Os modelos de avaliação mais aceitos e usados no mercado são:
· CMMI (Capability Maturity Model Integration), proposto pelo CMM (Capability Maturity Model);
· Norma ISO/IEC 9126, proposta pela ISO (International Organization for Standardization).

As organizações desenvolvedoras desses modelos de qualidade fornecem selos de qualidade para as empresas que se submetem à avaliações e estiverem dentro dos
padrões propostos. Esses selos são muito valorizados pelas empresas que compram software, e representam um diferencial competitivo no mercado. Porém, nem todas as empresas têm condições financeiras de bancar os custos de uma aquisição de um selo de qualidade, pois implantar um processo de qualidade em uma empresa envolve custos elevados. Contudo, é possível implantar boas práticas e desenvolver um processo de desenvolvimento organizado adaptando modelos de desenvolvimento conhecidos, despendendo menos recursos e provendo um mínimo de sistematização no desenvolvimento de software, a fim de se ter maior qualidade.

Enjoy!

SWEBOK, PMBOK, BABOK & Outros BOKs

A área de TI cada dia conta com mais (e melhores) corpos de conhecimento para vários papéis de engenharia de software, gerência e outras áreas. Compilo aqui um conjunto de BOKs de renome reconhecido e de grande valor para projetos de TI.

    * PMBOK: Clássico corpo de conhecimento do PMI. Atualmente em sua terceira edição (inclusive em português), compila as melhores práticas para a gerência de projetos para as áreas de gerência integrada, de escopo, qualidade, custo, prazo, recursos humanos, aquisições, riscos e comunicações. Outros excelentes corpos de conhecimento do PMI incluem o corpo de conhecimento para gerência de portfólios de projetos e o corpo de conhecimento para gerência de programas (conjunto de projetos relacionados em um tema).

    * SWEBOK: Iniciativa de grande qualidade do IEEE, traz um excelente conjunto de referências para informações primárias sobre requisitos, desenho, construção, implementação, qualidade de software, gerência de projeto, processos de software, ferramentas e métodos.
 

    * BABOK: Corpo de conhecimento para modelagem de processos de negócio do Instituto Internacional de Analistas de Negócio.
 

    * EABOK: Corpo de conhecimento de arquiteturas corporativos do MITRE. Outros corpos de conhecimento sobre arquitetura corporativa incluem o DODAF (do Departamento de Defesa Americano), MODAF (Governo Inglês), o SEI Feature Oriented Domain Analysis, o TOGAF ( do Open Group) e talvez o mais conhecido deles, o Zachman Framework.
 

    * Usability Body of Knowledge: Corpo de conhecimento de usabilidade da associação de professionais de usabilidade.

Enjoy!

Software

Para que se possa obter a compreensão do que é software (e, em última análise, uma compreensão da engenharia de software), é importante examinar as características do software que o tornam diferente das outras coisas que os seres humanos constroem. Quando o hardware é construído, o processo criativo humano (análise, projeto, construção e teste) é imediatamente traduzido numa forma física. Se construimos um novo computador, nossos esboços iniciais, desenhos de projeto formais e protótipo em forma de breadboard (arranjo experimental de circuitos eletrônicos) evoluem para um produto físico (chips VLSI, placas de circuito, fontes de energia etc.). O software é um elemento de sistema lógico, e não físico. Portanto, o software tem características que são consideravelmente diferentes das do hardware.

1. O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico

Não obstante existam algumas semelhanças entre o desenvolvimento de software e a manufatura de hardware, as duas atividades são fundamentalmente diferentes. Em ambas atividades, a alta qualidade é obtida mediante um bom projeto, mas a fase de manufatura do hardware pode introduzir problemas de qualidade que inexistem (ou são facilmente corrigidos) para o software. Ambas atividades dependem de pessoas, mas a relacão entre as pessoas envolvidas e o trabalho executado é inteiramente diferente. Ambas atividades exigem a construção de um "produto", mas as abordagens são muito diferentes. Os custos do software estão concentrados no trabalho de engenharia. Isto significa que os projetos de software não podem ser geridos como se fossem projetos de manufatura. No decorrer da década passada, o conceito de "fábrica de software" foi discutido na literatura [1,2]. Torna-se importante observar que este termo não implica que a manufatura de hardware e o desenvolvimento de software sejam equivalentes. Ao contrário, o conceito de fábrica de software recomenda o uso de ferramentas automatizadas para o desenvolvimento de software.

2. O software não se "desgasta"

A Figura 1 mostra o índice de falhas como uma função do tempo para o hardware. A relação, muitas vezes chamada "curva da banheira", indica que o hardware exibe índices de falhas relativamente elevados logo no começo de seu ciclo de vida (estas falhas frequentemente são atribuídas a defeitos de projeto e manufatura); os defeitos são corrigidos e o indice de falhas cai para um nível estável (esperançosamente, muito baixo) durante certo período de tempo. À medida que o tempo passa, entretanto, o índice de falhas eleva-se novamente conforme os componentes de hardware sofrem os efeitos cumulativos de poeira, vibração, abuso, temperaturas extremas e muitos outros males ambientais. Colocado de maneira simples o hardware começa a se desgastar.

O software não é sensível aos problemas ambientais que fazem com que o hardware se desgaste. Teoricamente, portanto, a curva do índice de falhas para o software assumiria a forma representada na Figura 2. Defeitos não descobertos provocarão elevados índices de falhas no começo da vida de um programa. Porém esses são corrigidos (espera-se que novos erros não sejam introduzidos) e a curva achata-se, como mostra a Figura 2. Esta figura representa de forma grosseira e simplificada os modelos de falhas reais para o software. Entretanto fica claro que o software não se desgasta. Todavia se deteriora!

Esta aparente contradição pode ser mais bem explicada considerando a Figura 3. Durante sua vida, o software enfrentará mudancas (manutenção). Quando estas são feitas, é provável que novos defeitos sejam introduzidos, fazendo com que a curva do índice de falhas apresente picos, como mostrado na Figura 3:

Outro aspecto do uso ilustra a diferença entre o hardware e o software. Quando se desgasta, um componente de hardware é substituído por uma "peça de reposição. Não existem peças de reposição para o software. Toda falha de software indica um erro de projeto ou no processo por meio do qual o projeto foi traduzido em código executável por máquina. Portanto a manutenção do software envolve consideravelmente mais complexidade do que a manutenção de hardware.

3. A maioria dos software é feita sob medida em vez de ser montada a partir de componentes existentes.

Consideremos a maneira segundo a qual o hardware de controle para um produto baseado em microprocessadores é projetado e construído. O engenheiro de projetos desenha um esquema simples do circuito digital, faz algumas análises fundamentais para garantir que a função adequada seja conseguida e depois vai a estante onde existm catálogos de componenentes digitais. Cada circuito integrado (CI ou chip) tem uma numeração de peça, uma função definida e validada, uma interface bem definida e um conjunto padrão de diretrizes de integração. Depois que cada componente é escolhido, o hardware pode ser encomendado. Infelizmente, os projetistas de software não podem permitir-se ao que acabamos de descrever. Com poucas exceções, não existem catálogos de componentes de software. É possível encomendar software não destinado à publicação, mas somente como uma unidade completa, não como componente que possa ser montado novamente em novos programas, embora esta situação esteja em mudança com a difusão do uso de programação orientada a objeto, cujo resultado são as "CIs de Software". Ainda que muita coisa tenha sido escrita sobre reusabilidade de software, somente agora começam a aparecer as primeiras tentativas bem sucedidas.

COMPONENTES DO SOFTWARE

O software de computador é uma informação que existe em duas formas básicas: componentes não executáveis em máquina e componentes executáveis em máquina. Para o propósito de nossa discussão aqui, somente os componenentes de software que levam diretamente a instruções executáveis em máquina serão apresentados. Os componentes de software são criados por meio de uma série de conversões que mapeiam as exigências de clientes para código executável em máquina. Um modelo (ou protótipo) das exigências é convertido num projeto. O projeto de software é convertido em uma linguagem que especifica a estrutura de dados do software, os atributos procedimentais e os requisitos relacionados. A forma de linguagem é processada por um tradutor que a converte em instruções executáveis em máquina. A reusabilidade é uma caracerística importante de um componente de software de alta qualidade [3]. Ou seja, o componente deve ser projetado e implementado de forma que possa ser reusado em muitos programas diferentes. Na década de 1960, foram construídas bibliotecas de sub-rotinas científicas que eram reusáveis num amplo conjunto de aplicações científicas e de engenharia. Estas bibliotecas de sub-rotinas reusavam algoritmos bem definidos efetivamente, mas tinham um domínio de aplicação limitado. Atualmente ampliamos nossa visão do reuso a fim de envolver não apenas algoritmos mas também estruturas de dados. Um componente resusável na década de 1990 engloba tanto dados como processamento num único pacote (às vezes chamado classe ou objeto), possibilitando que o engenheiro de software crie novas aplicações a partir de partes reusáveis. Por exemplo as interfaces interativas de hoje frequentemente são construídas utilizando-se componentes reusáveis que possibilitam a criação de janelas gráficas, menus pull-down e uma ampla variedade de mecanismos de interação. As estruturas de dados e detalhes de processamento exigidos para se construir a interface com os usuários estão contidas numa biblioteca de componentes reusáveis pra construção de interfaces.

Os componentes de software são construídos usando uma linguagem de programação que tem um vocabulário limitado, uma gramática explicitamente definita e regras de sintaxe e semântica bem formadas. Esses atributos são essenciais para a tradução por máquina. As formas de linguagem em uso são linguagens de máquina, linguagens de alto nível e linguagens não-procedimentais. A linguagem de máquina é uma represetação simbólica do conjunto de instruções da Unidade Central de Processamento (CPU - Central Processing Unity). Quando um bom desenvolvedor de software produz um programa bem documentado, capaz de sofrer manutencção, a linguagem de máquina pode fazer um uso extremamente eficiente da memória e otimizar a velocidade de execução do programa. Quando um programa é projetado pobremente e tem pouca documentação, a linguagem de máquina é um pesadelo. As linguagens de alto nível permitem que o desenvolvedor de software e o programa sejam independentes da máquina. Quando é usado um tradutor mais sofisticado, o vocabulário, a gramática, a sintaxe e a semântica de uma linguagem de alto nível podem ser muito mais sofisticados do que as linguagens de nível de máquina. De fato, os compiladores e os interpretadores de linguagem de alto nível produzem como saída uma linguagem de máquina. Não obstante centenas de linguagens de progamação estejam em uso atualmente pouco mais do que 10 linguagens de programação de alto nível são amplamente usadas na indústria. Linguagens tais como o COBOL e FORTRAN continuam tendo um uso generalizado quase 30 anos depois de sua introdução. Linguagens de programação modernas tais como Pascal, C e Ada estão sendo amplamente usadas. Linguagens orientadas a objetos, tais como C++, Object Pascal, Eiffel e outras estão conquistando entuasiásticos seguidores. Linguagens especializadas tais como APL, LISP, OPS5, Prolog e linguagens descritivas podem para redes neurais artificiais estão conquistando maior aceitação à medida novas abordagens de aplicação saem do laboratório para o uso prático. As linguagens de máquina, as linguagens montadoras (Assembly) e as linguagens de programação de alto nível frequentemente são citadas como "as tres primeiras gerações" das linguagens de computador. Com todas estas linguagens, o programador deve preocupar-se tanto com a especificação da estrutura de informações como com o controle do programa em si. Daí as linguagens das três primeiras geracões serem domiadas linguagens procedimentais. No decorrer da última década, um grupo de linguagens de quarta geração, ou não-procedimentais, foi introduzida. Em vez de exigir que o desenvolvedor de software especifique detalhes de procedimentos, a linguagem nao-procedimental subentendo um programa "especificando o resultado desejado, em vez de especificar a ação exigida para se conseguir esse resultado" [4]. O software de apoio converte a especificação do resultado numprogram executável em máquina.

Texto extraído com pequenas adaptações de:

Presman, R.S.; Engenharia de Software, Makron books, S.P., 1995, pags. 13-19