Modelos Ágeis

As definições modernas de desenvolvimento de software ágil evoluíram a partir de meados de 1990 como parte de uma reação contra métodos caracterizados por uma regulamentação complexa e rígida e contra a regimentação e o sequenciamento usado no modelo em cascata. O objetivo era desburocratizar os procedimentos que tornavam as etapas dos processos lentas, o que era contrário ao modo de trabalho usual dos engenheiros de software.

Inicialmente, os métodos ágeis foram denominados de “métodos leves”. Em 2001, Kent Beck e 16 outros notáveis profissionais da área de Engenharia de Software se reuniram, adotaram o nome métodos ágeis e publicaram o Manifesto Ágil, documento que reúne os princípios e práticas desta metodologia de desenvolvimento. Esses veteranos formaram a Agile Alliance,ou Aliança Ágil, uma organização não lucrativa que promove e fomenta o desenvolvimento ágil. (BECK, 2001)

 

 

 

Agilidade.
Fonte: kentoh/shutterstock

Os membros da Aliança Ágil, declararam assim os princípios da metodologia em seu manifesto:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Fonte: SOMMERVILLE (2011, p. 40)

Os principais modelos baseados na concepção de Desenvolvimento Ágil incluem o Scrum, criado em 1986, o ASD – Adaptive Software Development, o FDD – Feature Driven Development, o DSDM – Dynamic Systems Development Method de 1995, o Crystal e a XP – eXtremeProgramming ou Programação Extrema, criados em 1996.

O Desenvolvimento Ágil de Software - Agile Software Development, envolve uma metodologia que visa minimizar os riscos por meio de desenvolvimentos em curtos períodos ou iterações, como mostra a figura (que é baseada no Scrum). A iteração típica envolve o desenvolvimento em fases curtas, de 1 a 4 semanas, envolvendo todas as tarefas necessárias para implantar uma funcionalidade. Considerando-se o período curto de cada iteração, a comunicação mantida entre os stakeholders é em tempo real sendo, preferencialmente, tratada por meio verbal (embora documentada), ou face a face, visando minimizar entendimentos parciais ou errôneos. Para tanto é necessário estabelecer um local físico (uma sala) onde toda a equipe necessária ficará focada no projeto.

Alguns críticos do processo ágil afirmam que o maior risco deste tipo de abordagem é a baixa qualidade ou mesmo inexistência de documentação do projeto por causa da interação humana face a face que, se por um lado traz agilidade na comunicação, por outro traz a informalidade nas definições. Assim sendo, é necessário um bom acompanhamento do gestor do projeto para garantir a qualidade dos trabalhos, independente do processo utilizado.

Etapas do Desenvolvimento Ágil (Scrum)

Fonte: http://www.sstecnologia.com.br/

De uma forma geral, os processos ágeis atendem aos projetos de software que, normalmente, apresentam:

• Dificuldade em prever com antecedência quais requisitos vão persistir e quais serão modificados, bem como prever quais prioridades dos clientes sofrerão mudanças ao longo do projeto;
• Intercalação das etapas de projeto e construção, que vão sendo realizadas juntas de modo que os modelos de projeto vão sendo comprovados na medida em que são criados;
• Análise, projeto, construção e testes não são tão previsíveis, do ponto de vista do planejamento, como seria desejado.

A metodologia ágil vem gerando grande debate, fazendo muitos desenvolvedores apaixonados e muitos outros críticos ferrenhos. Mas temos que manter a imparcialidade profissional e questionarmos o que realmente tem que ser observado, como:

• Qual é a melhor forma de se alcançar a agilidade nos processos e práticas do desenvolvimento de software?
• Como construir softwares que satisfaçam as necessidades do cliente e possua características de qualidade que permitam sua extensão e ampliação para satisfazer as necessidades do cliente no longo prazo?

Aconteceu

O que são essas tais de metodologias Ágeis?

Adotar uma metodologia ágil pode trazer muitos benefícios, mas nós costumamos dizer que o ágil não é a bala de prata, ou seja, apenas aplicar por exemplo o SCRUM ou algumas de suas práticas ágeis por si só não vai resolver os seus problemas, mas evidenciar suas fraquezas para que você possa identificar e atuar sobre elas. Cabe, então, à equipe atuar de forma proativa e desejar as mudanças para que os benefícios que o ágil pode proporcionar possa valer de verdade.

 Dentre as principais causas de falha na adoção de uma metodologia ágil estão:

• Filosofia ou a cultura da empresa que conflitam com os valores e princípios do agile;
• Falta de suporte gerencial para apoiar as mudanças; É preciso desejar as mudanças;
• Falta de experiência ou treinamento insuficiente no novo processo; É preciso tornar-se capaz de trabalhar de maneira ágil;
• Boicote, falta de comprometimento da própria equipe. É preciso reconhecer que há espaço para melhorias e desejá-las;

Aplicar o ágil não é uma tarefa fácil. Exige determinação e disciplina.

É UMA MUDANÇA DE COMPORTAMENTO.

Leia o artigo completo em: <www.ibm.com>

Modelo de Métodos Formais

Os métodos formais são técnicas baseadas em formalismos matemáticos que podem ser usados para a especificação, desenvolvimento e verificação de sistemas de software. Seu uso para o desenvolvimento de software é motivado pela base que fornecem garantindo confiabilidade e robustez a um projeto, uma vez que executam análises matemáticas apropriadas. No entanto, o alto custo do uso de métodos formais restringe o seu uso ao desenvolvimento de sistemas de alta integridade, no qual há alta probabilidade das falhas conduzirem à perda de vidas ou sérios prejuízos (como nas missões espaciais e no controle de voos, por exemplo). 

Ônibus espacial

Exemplo de sistema crítico. Fonte: Everett Historical/shutterstock

No modelo de Métodos Formais, também conhecido como Engenharia de Software Cleanroom (Sala Limpa), uma questão fundamental é garantir que o software é realmente uma solução para o problema proposto. Para realizar tal tarefa deve-se primeiro construir um modelo da solução (especificação) utilizando uma linguagem formal. (FACIN, 2002). Tendo este modelo formal como base, o método permite:

• realizar provas matemáticas que garantem que este modelo possui as propriedades requisitadas (verificação);
• analisar se a solução proposta é aceitável do ponto de vista de desempenho, indicando quais as melhores estratégias para implementação a serem seguidas;
• validar o modelo através de simulações;
• realizar o desenvolvimento do software, sendo possível provar que a implementação está correta (geração de código correto).

Dentre os vários métodos de especificação formal existentes, destacam-se o método Z, que já foi utilizado em várias aplicações práticas, e o método de gramáticas de grafos, por possuir uma linguagem visual de representação e descrever com naturalidade fenômenos de sistemas concorrentes.

De uma maneira mais abrangente, podemos caracterizar assim o modelo de Métodos Formais:

• Permite especificar, desenvolver e verificar um software através de uma rigorosa notação matemática;
• Fornece um mecanismo para eliminar muitos problemas encontrados nos outros modelos, como ambiguidade, incompletude e inconsistência, que podem ser descobertos e corrigidos mais facilmente através de análise matemática;
• Promete o desenvolvimento de software livre de defeitos;
• Consome muito tempo de desenvolvimento e é muito caro.

Como poucos desenvolvedores possuem o conhecimento necessário para utilizá-lo, são requeridos muitos cursos e treinamentos. É difícil usar tais modelos matemáticos formais como meio de comunicação com a maioria dos clientes. Assim, como já dissemos, sua área de aplicação é muito restrita, abrangendo, principalmente, aplicações críticas.

Modelos de Processo – Parte 2

Os Modelos de Processo Especializados que consideram as características de um ou mais modelos: o Desenvolvimento Baseado em Componentes, o Método Formal, o Processo Unificado, e faremos uma descrição geral dos Métodos Ágeis de Desenvolvimento.

Desenvolvimento Baseado em Componentes

O Desenvolvimento Baseado em Componentes ou CBD – Component-Based Development, também é conhecido como Component-Based Software Engineering (CBSE) ou simplesmente como Componente de Software. Os desenvolvedores costumam utilizar componentes de software que são encontrados em bibliotecas de uso gratuito, mas alguns também utilizam componentes que ficam disponíveis para compra. Estes componentes são conhecidos como COTS – Commercial-Off-The-Shelf, ou Software Comercial de Prateleira. Geralmente estes componentes oferecem funcionalidades com interfaces bem definidas, que podem ser facilmente integrados no software sendo desenvolvido.

 

 

 

Desenvolvimento basedo em componentes. Fonte: Sentavio/shutterstock

O método de Desenvolvimento Baseado em Componentes incorpora as características de construção de componentes de biblioteca ao Modelo Espiral. De natureza evolucionária, adota uma abordagem iterativa para a criação de software. Assim, o modelo constrói aplicações a partir de componentes de software previamente preparados. As atividades de modelagem e construção começam com a identificação de componentes candidatos. Esses componentes podem ser projetados como módulos de software convencional ou como classes, ou pacotes de classes, orientadas a objeto.

No paradigma orientado a objetos uma classe encapsula dados e algoritmos, que também podem ser utilizados para manipular os dados. Através desta abordagem uma biblioteca de classes pode ser construída com as classes identificadas no desenvolvimento do software, e a partir de então toda iteração da espiral deverá verificar o conteúdo da biblioteca que pode ser reutilizado.

De acordo com Pressman (2011, p. 69), o modelo de Desenvolvimento Baseado em Componentes leva ao reuso de software, e a reusabilidade fornece aos engenheiros vários benefícios, como redução no tempo do ciclo de desenvolvimento e dos custos do projeto.

Modelos Incrementais de Processo

Há diversas situações em que os requisitos iniciais do software estão razoavelmente bem definidos, mas o escopo global do processo de desenvolvimento claramente elimina uma abordagem puramente linear ou sequencial. Adicionalmente pode haver a necessidade de se fornecer rapidamente um conjunto limitado de funcionalidades do software aos usuários e depois refinar, melhorar e expandir aquela funcionalidade em versões mais avançadas do software. Nestes casos, os modelos de processo que produzem software em incrementos são os mais indicados.

Os processos incrementais que discutiremos aqui incluem o Modelo Incremental e o Modelo RAD – Rapid Application Development (Desenvolvimento Rápido de Aplicação), com base em Pressman (2011).

Modelo Incremental

O modelo incremental aplica elementos do modelo em cascata, mas de forma interativa. Este modelo, assim como a prototipagem, é incremental, mas o que o diferencia da prototipagem é o fato de ele ter como objetivo apresentar um produto operacional a cada incremento realizado. Este processo pode ser visto na figura.

Modelo de Processo Incremental. Fonte: baseado em (PRESSMAN, 2010)

Esse modelo é muito útil quando a empresa não possui mão de obra disponível, em um dado período, para uma implementação completa, dentro do prazo estipulado.

De uma forma geral, o Modelo Incremental apresenta as características:

• Combina elementos do Modelo em Cascata (aplicado repetitivamente) com a filosofia iterativa da Prototipação;
• Aplica sequências lineares de uma forma racional à medida que o tempo passa;
• Cada sequência linear produz um incremento do software e pode gerar uma entrega parcial do produto;
• Os primeiros incrementos são versões simplificadas do produto final;
• O primeiro incremento é chamado de “núcleo do produto” (core).

Um exemplo clássico de aplicação do Modelo Incremental é o desenvolvimento de um processador de texto. Para este projeto as etapas incrementais poderiam ser assim definidas:

1. Primeiro Incremento: poderia efetuar as funções de controle de versões de arquivos, edição e produção de documentos.
2. Segundo Incremento: adicionaria capacidade de edição e de produção de documentos mais sofisticados.
3. Terceiro Incremento: incluiria a verificação sintática e gramatical.
4. Quarto Incremento: adicionaria a capacidade avançada de disposição de página.

Note que todo o processo pode se repetir até que um produto completo seja produzido.

Modelo RAD - Rapid Application Development

O modelo RAD – Rapid Application Development (Desenvolvimento Rápido de Aplicação) é uma adaptação do modelo em Cascata, mas que enfatiza um desenvolvimento extremamente rápido. A alta velocidade é conseguida por meio de uma abordagem de construção baseada em componentes, ou seja, o sistema é modularizado.

Se os requisitos forem bem definidos e o objetivo do projeto for restrito, a equipe pode criar um sistema plenamente funcional em pouco tempo.

O RAD se enquadra no modelo de atividades de arcabouço do Modelo em Cascata:

• Comunicação: atividade em que se entende o problema de negócio, as características das informações e é realizado o levantamento de requisitos.
• Planejamento: atividade essencial. Várias equipes trabalham em paralelo em diferentes funções.
• Modelagem: estabelece representações de projeto que servem como base para a atividade de construção. Abrange três fases:
1. Modelagem de negócio
2. Modelagem de dados
3. Modelagem de processo
• Construção: faz uso de componentes de software preexistentes e geração de códigos.
• Emprego (ou implantação): estabelece a base para iterações subsequentes, se necessárias.

A figura apresenta a representação esquemática do modelo RAD em relação ao modelo sequencial tradicional.

Modelo RAD x Modelo Tradicional. Fonte: http://www-old.novulo.com/Rad.aspx

As situações de desenvolvimento mais adequadas para se utilizar o Modelo RAD incluem:

• Projetos em que os requisitos estão bem definidos, o objetivo do sistema é restrito e se deseja criar um “sistema plenamente funcional” dentro de períodos muito curtos (por exemplo, de 60 a 90 dias);
• Projetos em que há fortes restrições de tempo impostas pelo cliente;
• Aplicações que podem ser modularizadas de forma que cada função principal possa ser completada em menos de 3 meses;
• Projetos em que cada função principal possa ser alocada para uma equipe distinta e depois integradas para formar o todo do produto.

Mas a utilização do modelo RAD também pode implicar em problemas. Para projetos grandes, mas mensuráveis, o RAD requer um número elevado de recursos humanos que sejam suficientes para criar um número adequado de equipes. Além disso, o RAD requer um comprometimento entre desenvolvedores e clientes para que as atividades possam ser realizadas rapidamente e o sistema seja concluído em um tempo curto. Se o comprometimento for abandonado por qualquer das partes, o projeto falhará. O uso do RAD também não é apropriado quando os riscos técnicos são grandes (por exemplo, quando a aplicação faz uso de uma nova tecnologia).

Modelos Evolucionários de Processo

São modelos que consideram a natureza evolutiva do software. Os modelos evolucionários são iterativos. São implementados de forma a permitir o desenvolvimento de versões cada vez mais completas do software. Suas características incluem:

• São usados quando o deadline (limite de tempo) não é adequado para o desenvolvimento do software, ou seja, a data de término não é realística (por exemplo, prazos reduzidos de mercado por causa da competitividade).
• Uma versão limitada pode ser introduzida para atender a essa competitividade e às pressões do negócio.
• São liberados produtos core (núcleo dos produtos) ao longo do desenvolvimento.
• Os detalhes e extensões do projeto são definidos ao longo do desenvolvimento.

Os modelos que são agrupados nesta categoria são: Prototipação, Modelo Espiral e Modelo Concorrente, que são apresentados a seguir.

Prototipação

É um modelo de processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. Idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos do software. É apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.

Envolve o desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos. Este processo permite a descoberta de falhas difíceis de serem encontradas na comunicação verbal, servindo de apoio à fase de levantamento de requisitos prevenindo as possíveis falhas no sistema.

O objetivo principal de um protótipo é simular a aparência e funcionalidade do software, permitindo que os clientes, analistas, desenvolvedores e gerentes compreendam plenamente os requisitos do sistema interagindo, avaliando, alterando e aprovando as características mais relevantes que o produto deve ter. A figura ilustra este processo.

Modelo de Prototipação.
Fonte: baseado em PRESSMAN (2011, p. 63)

Certamente a redução de custos no desenvolvimento é um dos grandes ganhos da prototipação, pois envolve diretamente o usuário final permitindo um desenvolvimento mais próximo dos desejos do cliente e priorizando a facilidade de uso. Assim, pode-se obter um nível de satisfação maior em função do menor número de erros ou falhas de desenvolvimento comuns na passagem de informação entre o analista (que fez o levantamento de requisitos) e o desenvolvedor (equipe de desenvolvimento).

Um dos riscos envolvidos neste modelo é o descomprometimento com a análise do produto, visto que os envolvidos podem se apoiar totalmente no modelo prototipado gerando uma expectativa muitas vezes irrealista de desempenho, em função do protótipo ser muito mais enxuto do que o produto final e estar em um ambiente controlado.

Além disso, o cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade em longo prazo. Ele pode, também, não aceitar facilmente a ideia de que a versão final do software está sendo construída e tentar forçar a utilização do protótipo como produto final.

Outro risco deste modelo é que o desenvolvedor frequentemente faz uma implementação comprometida (utilizando partes de programas existentes, geradores de relatórios, geradores de janelas) com o objetivo de produzir rapidamente um protótipo executável. Depois de um tempo ele se familiariza com essas escolhas, e pode se esquecer que elas não são apropriadas para o produto final.

Embora não seja livre de problemas, a prototipação é um modelo eficiente, pois cada protótipo é construído a partir de um acordo entre o cliente e o desenvolvedor. Deve estar claro para ambos que o protótipo é utilizado como um mecanismo que permite a definição dos requisitos do projeto. A figura  traz outra visão deste processo.

 

Outra visão do Modelo de Prototipação.
Fonte: www.ebah.com.br

Modelo Espiral

O modelo espiral foi desenvolvido para abranger as melhores características do Modelo em Cascata e da Prototipação, acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos. Foi desenvolvido por Barry Boehm (1988) em seu artigo intitulado “A Spiral Model of Software Development and Enhancement”. Este modelo foi o primeiro a explicar o porquê do modo iterativo e elencar suas vantagens.

As iterações têm uma duração típica de seis meses a dois anos. Cada fase inicia-se com um objetivo esperado e termina como uma revisão, pelo cliente, do progresso (que deve ser interna) e assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, tendo sempre o foco no objetivo do projeto. A figura ilustra este processo.

Modelo Espiral. Fonte: baseado em PRESSMAN (2011, p. 65)

As principais características deste modelo são:

• Engloba a natureza iterativa da Prototipação com os aspectos sistemáticos e controlados do Modelo em Cascata;
• Fornece potencial para o desenvolvimento rápido de versões incrementais do software;
• O processo se inicia com a equipe de desenvolvimento movendo-se em volta da espiral, no sentido horário, a partir do centro;
• O primeiro circuito em torno da espiral pode resultar na especificação do produto;
• Nas primeiras iterações, a versão incremental pode ser um modelo em papel ou um protótipo;
• Nas iterações mais adiantadas são produzidas versões incrementais mais completas e melhoradas.

É uma abordagem realística para o desenvolvimento de software de grande porte. Como o software evolui na medida em que o processo avança, o cliente e o desenvolvedor entendem melhor e reagem aos riscos em cada nível evolucionário. Para pequenos projetos, os conceitos de desenvolvimento de software ágil tornam-se uma alternativa mais viável.

Como vantagens deste modelo, podemos citar: estimativas realísticas dadas à identificação de problemas importantes logo no início do processo; versatilidade para lidar com mudanças (quando inevitáveis); desenvolvimento antecipado por parte dos engenheiros de software, que têm visibilidade das necessidades por fases; e uso da prototipagem (em qualquer estágio de evolução do produto) como mecanismo de redução de risco.

No entanto, o uso do modelo Espiral exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso. Além disso, pode ser difícil convencer os clientes que uma abordagem “evolutiva” é controlável.

Modelo de Processo Concorrente

De acordo com Pressman (2011, p. 67), o modelo de Desenvolvimento Concorrente, também chamado de Engenharia Concorrente, pode ser representado, esquematicamente, como uma série de atividades de arcabouço, ações e tarefas da Engenharia de Software e seus estados associados.

Um exemplo do uso deste modelo pode ver visto na figura. A figura traz a atividade “Modelagem” do modelo Espiral (mostrado na figura anterior), espelhada no modelo Concorrente.

Transições de Estado no Modelo de Processo Concorrente. Fonte: baseado em PRESSMAN (2011, p. 67)

No modelo Concorrente, uma atividade pode estar em qualquer um dos estados apresentados na figura 17 (em desenvolvimento, sob inspeção ou em exame, aguardando modificações etc.) a qualquer tempo. O modelo define uma série de eventos que vão disparar transições de um estado para outro, para cada uma das atividades, ações ou tarefas da Engenharia de Software. Por exemplo, suponha que durante os estágios da etapa de projeto, descobre-se uma inconsistência no modelo de análise. Isso geraria o evento “correção no modelo de análise”, que, por sua vez, implicaria na passagem da atividade de análise do estado “pronto” para o estado “aguardando modificações”.

De forma geral, as principais características deste modelo são:

• Todas as atividades ocorrem em paralelo, mas estão em diferentes estados;
• O modelo define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades;
• Em vez de usar uma sequência como o modelo em cascata, ele define uma rede de atividades;
• Eventos gerados dentro de certa atividade ou em algum outro lugar da rede de atividades disparam transições entre estados de uma atividade;
• Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de como está o estado do projeto;
• Em vários projetos pode existir uma simultaneidade (concorrência) entre as várias atividades de desenvolvimento e de gestão de projetos;
• É representado como uma série de grandes atividades técnicas, tarefas e seus estados associados (fornece um panorama preciso do estado atual do projeto).

Modelos Prescritivos de Processo

Processos prescritivos, segundo Pressman (2011, p. 58), “prescrevem um conjunto de elementos de processo- atividades metodológicas, ações de engenharia de software, tarefas, produtos de trabalho, garantia da qualidade e mecanismos de controle de mudanças para cada projeto”. Cada processo também prescreve um fluxo de trabalho, que define a forma pela qual os elementos do processo se inter-relacionam.

Enquanto um modelo descritivo retrata como um processo é executado, um modelo prescritivo retrata como um processo deveria ser executado. Assim, um modelo prescritivo é uma recomendação que pode ser adaptada ou melhorada pela empresa/equipe de software que for adotá-la.

Os instrumentos prescritivos do processo de planejamento estratégico explicitam o que deve ser feito pela organização para se direcionar o esforço de desenvolvimento de software. Um modelo prescritivo de processo atua como complemento com conjuntos explícitos de tarefas explícitas para o desenvolvimento. Cada modelo prescritivo de processo também prescreve um fluxo de trabalho ou maneira como os elementos se inter-relacionam.

Há vários modelos que são classificados nesta categoria e vamos estudá-los com base em Pressman (2011):

• Modelo em Cascata
• Modelos Evolucionários
  • Modelo de Prototipagem
  • Modelo Espiral
  • Modelo Concorrente
• Modelos Incrementais
  • Modelo RAD
  • Modelo Incremental

Modelo em Cascata

No modelo em cascata, também conhecido como ciclo de vida clássico, o processo de desenvolvimento de software é visto como uma abordagem sistemática e sequencial que começa com a especificação dos requisitos do cliente e progride seguindo as etapas de planejamento, modelagem, construção e implantação do sistema, culminando na manutenção progressiva do produto entregue, conforme ilustra a figura.

Modelo em Cascata. Fonte: baseado em PRESSMAN (2011, p. 60)

Este modelo é o paradigma mais antigo da Engenharia de Software e é bastante criticado em função dos problemas encontrados nos projetos em que é aplicado. A realidade tem mostrado que em um projeto raramente se segue o fluxo sequencial que o modelo propõe, gerando problemas futuros que oneram os custos e prazos. Uma das causas mais comuns deste problema é a dificuldade do cliente em declarar claramente todas as suas necessidades e expectativas, ou seja, de definir todos os requisitos inicialmente. O foco incorreto ou não claro pode gerar uma distorção que reflete diretamente na percepção de qualidade por parte do próprio cliente. Isso pode levar a entregas parciais do produto, o que exige que o cliente tenha muita paciência durante os aceites parciais que são formalizados em um Documento de Encerramento do Projeto com observações no campo Restrições, “Entrega Parcial de Projeto”, que contém detalhes quanto à aceitação condicional do projeto por parte do cliente.

Os trabalhos de desenvolvimento de software atuais seguem ritmos muito rápidos, sujeitos a diversas modificações, o que torna o modelo em cascata inadequado para esses tipos de projeto. Mas, cumpre ressaltar, caro aluno, que embora o Modelo em Cascata ou Ciclo de Vida Clássico tenha fragilidades, ele é significativamente melhor do que uma abordagem casual para o desenvolvimento de software.

Modelos de Processo - Parte 1

Descreveremos o que é um processo de software e elencaremos os principais modelos de processo que apoiam o desenvolvimento de software e são classificados como prescritivos. Aqui vamos estudar o Modelo em Cascata, os Modelos Evolucionários (Modelo de Prototipagem, Modelo Espiral e Modelo Concorrente) e os Modelos Incrementais de Processo (Modelo RAD e Modelo Incremental).

Modelo de processo

Fonte: NicoElNino/shutterstock

Processo de software e suas fases

Todo projeto de software se inicia a partir de alguma necessidade do negócio. Assim que esta necessidade é identificada, costuma ser expressa de forma informal, por meio de uma conversa. Mas esta informalidade deve parar por aí. Até mesmo a especificação da necessidade do cliente é abrangida pelos métodos e técnicas da Engenharia de Software. Este é um processo bastante complexo, então vamos começar a entendê-lo, conhecendo exatamente do que se trata um processo de software.

Para que as necessidades da empresa ou de um cliente possa se transformar em uma solução de software, todo o diálogo e a interação entre usuários, projetistas, ferramentas de desenvolvimento e tecnologias devem ser transformados em um processo.

Assim, processo de software é, segundo Pressman (2006), um arcabouço (framework) das tarefas requeridas para se construir um software de alta qualidade.

Mas, você pode estar se perguntando: processo e engenharia de software são a mesma coisa? A resposta é “sim” e “não”. Processo de software define a abordagem que é adotada quando o software é elaborado. A Engenharia de Software engloba também as tecnologias que constituem um processo, como métodos, técnicas e ferramentas de desenvolvimento. Assim, a Engenharia de Software engloba os processos de software.

Curiosidade

 

Antes mesmo de existir o primeiro computador, já havia a programação. Foi percebendo um padrão de movimento no tear para fabricar tecidos que o francês Joseph-Marie Jacquard criou o tear mecânico, que possibilitava a modificação dos desenhos no tecido por meio de cartões perfurados – considerado por muitos o primeiro programa.

https://www.bpiropo.com.br/fpc20060821.htm

Para que a Engenharia de Software possa ser aplicada como uma abordagem disciplinada para o desenvolvimento, operação e manutenção de um software, um processo deve ser definido.

Sommerville (2011, p. 18) afirma que um processo de software, em geral, inclui quatro fases: Especificação do software; Projeto e Implementação do software; Validação do software; e Evolução do software.

Processo de Software. Fonte: adaptado de SOMMERVILLE (2011)

Requisitos de sistema. Fonte: Scott Maxwell LuMaxArt/shutterstock

Fase de Especificação: esta fase se concentra no “quê” o sistema de software irá realizar, isto é, identifica:

• que informação deve ser processada;
• que função e desempenho são desejados;
• que comportamento deve ser esperado do sistema;
• que interfaces devem ser estabelecidas;
• que restrições de projeto existem;
• que critérios de validação são necessários.

Nessa fase, os requisitos-chave do sistema são identificados e suas funcionalidades e as restrições ao seu funcionamento são definidas. Esta fase engloba etapas importantes:

1. Engenharia de sistemas ou de informação;
2. Planejamento do projeto;
3. Análise de requisitos.

Fase de Projeto e Implementação: esta fase focaliza “como” o projeto de desenvolvimento será realizado, isto é, define:

• como os dados devem ser estruturados;
• como as funções devem ser implementadas;
• como os detalhes procedimentais devem ser implementados;
• como as interfaces devem ser caracterizadas;
• como o projeto deve ser traduzido em uma linguagem de programação.

Nesta fase, as seguintes etapas técnicas ocorrerão:

1. Projeto e arquitetura do software;
2. Geração de código.

Fase de Validação: esta fase busca verificar se o sistema atende aos requisitos do cliente e deve ser, para isso, validado. As estratégias de teste são definidas e as atividades ligadas ao teste são realizadas. Aqui ocorre a verificação e a validação, que são atividades que se destinam a mostrar que o sistema está de acordo com a especificação e que atende às expectativas de clientes e usuários. A validação visa assegurar que o programa está fazendo o que foi definido na sua especificação. A verificação visa certificar se o programa está correto, isto é, se não possui erros de execução e está fazendo de forma correta suas funcionalidades. Existem diferentes formas de verificação e validação. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, podem ser usados para avaliar diversos fatores de qualidade a partir da execução do software.

Nesta fase, ocorrem as seguintes etapas técnicas:

1. Teste de software
2. Homologação do sistema

Fase de Evolução: esta fase tem como alvo gerenciar as modificações e manutenções que o software sofrerá de forma a atender as necessidades evolutivas dos clientes. Quatro tipos de modificações podem ocorrer:

• Manutenção Corretiva: modifica o software para corrigir defeitos.
• Manutenção Adaptativa: modifica o software para acomodar mudanças no seu ambiente externo (processador, sistema operacional etc.).
• Manutenção de Aperfeiçoamento: aprimora o software além dos requisitos funcionais originais (cliente/usuário reconhece e solicita funcionalidades adicionais que trarão benefícios, à medida que o software é usado).
• Manutenção Preventiva: faz modificações nos programas de modo que eles possam ser mais facilmente corrigidos, adaptados e melhorados.

Estas quatro fases são complementadas por atividades “guarda-chuva”, como:

•  Controle e Rastreamento do Projeto;
• Gestão de Riscos;
• RevisõesTécnicas Formais;
• Garantia de Qualidade;
• Gestão de Configuração de Software;
•  Produção e Preparação de Produtos do Trabalho (documentos);
• Gestão de Reusabilidade;
• Medição.

Essas atividades são aplicadas ao longo do processo de software.

Ciclo de vida do software.

Fonte: Skynavin/shutterstock

O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até a descontinuidade de seu uso.

Para que você entenda melhor as fases do ciclo de vida, caro aluno, considere as elencadas no modelo em cascata, que são consideradas como referência.

O conceito de ciclo de vida de um software é muitas vezes confundido com o de modelo de processo, mas são conceitos bem diferentes.

Sommerville (2011, p. 19) define modelo de processo como

“uma representação simplificada de um processo de software. Cada modelo representa uma perspectiva particular de um processo. Você pode vê-los como frameworks de processos que podem ser ampliados e adaptados para criar processos de software mais específicos.”

Como vimos, a Engenharia de Software é uma disciplina que integra processo, métodos e ferramentas para o desenvolvimento de projetos de software. Há diversos modelos de processo, mas todos possuem algumas características em comum, definindo um conjunto de atividades de arcabouço, uma coleção de tarefas para que se consiga realizar as atividades, produtos de trabalho produzidos nas tarefas e um conjunto de atividades guarda-chuva que apoiam as atividades de todo o processo.

Software x Hardware

De acordo com Pressman (2011, p. 32-33), comparar o software com produtos de hardware auxilia na compreensão das diferenças existentes entre eles e enfatiza as características inerentes a um software. O processo de desenvolvimento do software apresenta diferenças fundamentais em relação ao hardware:

• O processo criativo do hardware gera algo físico (por exemplo, placas de circuitos). O desenvolvimento de software resulta em um elemento pertencente a um sistema lógico, intangível;
• O software geralmente é desenvolvido sob medida, ao contrário do hardware, no qual o projetista tem acesso a componentes existentes que executam tarefas definidas. O projetista do software nem sempre terá acesso a módulos prontos para utilização e quando o faz, pode elevar o risco do produto devido a questões de segurança;
• Os custos do software estão concentrados no desenvolvimento e não no processo de manufatura, logo, não pode ser gerido como projeto de manufatura;
• Ao longo do tempo, o produto de software não se desgasta, mas se deteriora em função da introdução de erros oriundos de atividades de manutenção ou evoluções implícitas no processo que devem ser reconsideradas no modelo original.

Software x Hardware

Fonte: Moon Light PhotoStudio/shutterstock

Desta forma, o software sofre deterioração ocasionada por diversos fatores sendo uma característica peculiar do produto. Ainda segundo Pressman (2011), no caso do hardware, temos um alto índice de falhas no início do seu ciclo de vida ocasionado por defeitos de fabricação e projeto. Posteriormente os defeitos são corrigidos, dando estabilidade nas falhas ou mantendo-a em um nível muito baixo e suportável para a estrutura. Já no final do ciclo de vida do produto podem surgir problemas relacionados ao envelhecimento, acúmulo de poeira, vibração, abuso, temperaturas extremas, entre outros. Este processo pode ser visto no gráfico apresentado na figura.

Curva de falhas do hardware. Fonte: PRESSMAN (2011, p. 32)

Diferentemente da curva teórica de falhas do hardware, a de software leva em conta que o software não sofre processos de envelhecimento como o hardware, pois o software não é algo físico. No início do ciclo de vida do software, teremos problemas (bugs) que serão ajustados no decorrer do desenvolvimento e se estabilizarão, gerando uma tendência de achatamento da curva, conforme pode ser visto na figura.

Curva de falhas do software.

Fonte: PRESSMAN (2011, p. 33)

Notemos que esta é apenas uma teoria, já que a curva real do índice de falhas de um software considera o processo de manutenção e mudanças. Durante o processo de refinamento do produto ou mudanças a probabilidade de inserção de novos erros aumenta consideravelmente, gerando picos na curva de falhas. As sucessivas alterações do software tendem a introduzir mais erros antes da estabilização dos erros de alterações anteriores, ocasionando a tendência crescente do índice de falhas.

Isso nos remete a uma realidade bastante complicada em relação ao software: ele é um produto que quanto mais se conserta, pior fica. Um software em constante manutenção pode ser tornar uma espécie de “colcha de retalhos”, gerando pontos de falhas diversos, difíceis de se identificar e de se ajustar. O melhor modelo é o desenvolvimento de um novo produto após o tempo de vida útil do anterior, considerando-se as novas necessidades e tecnologias disponíveis.

Quando o hardware é projetado e construído, os componentes digitais são inseridos em catálogos. A cada circuito integrado ou componente é assinalado um código, uma função definida e validada, uma interface especificada e um conjunto padrão de integração. Uma vez escolhido no catálogo, o componente desejado pode ser adquirido e utilizado em diferentes projetos de hardware, com alta confiabilidade.

No mundo do software, isso é algo que está apenas começando a ser utilizado em uma escala mais ampla, apesar de existirem alguns casos antigos de reuso, como as bibliotecas de subrotinas científicas. Atualmente, a visão de reuso foi ampliada para abranger não apenas algoritmos consagrados, mas também estruturas de dados, interfaces gráficas e diferentes classes e componentes orientados a objetos.

Definições e Conceitos de Software e Engenharia de Software

Engenharia de Software é uma disciplina da Engenharia que cuida de diversos aspectos do trabalho de desenvolvimento de sistemas de software, envolvendo todas as etapas do ciclo do projeto, desde a definição de requisitos até a sua manutenção, que ocorre após a entrega do produto e o início de sua operação. Seu principal objetivo é fornecer uma estrutura metodológica para a construção de software com alta qualidade.

Podemos definir Engenharia de Software como um processo que envolve a criação e a utilização de sólidos princípios de engenharia a fim de obter software com as características:

• que possua alta qualidade;
• que seja produzido de maneira econômica;
• que seja confiável;
• que trabalhe eficientemente em máquinas reais;
• que seja entregue no prazo;
• que satisfaça o cliente.

De acordo com Pressman (2011, p. 3), a Engenharia de Software é uma tecnologia em camadas, apoiada fundamentalmente em um compromisso organizacional com a qualidade, como mostra a figura. Nesta abordagem, podemos observar que o alicerce da Engenharia de Software é a camada de processo, que funciona como um adesivo que mantém unidas as camadas ligadas à tecnologia.

Engenharia de Software: uma tecnologia em camadas. Fonte: baseado em PRESSMAN (2011, p. 39)

O processo forma uma base que mantém unidas as camadas de tecnologia, permitindo o desenvolvimento de software com qualidade. Define o arcabouço que garante a efetiva utilização das técnicas de Engenharia de Software.

Os métodos fornecem as técnicas de “como fazer” a construção de software. Abrangem um amplo conjunto de tarefas que incluem comunicação, análise de requisitos, modelagem de projeto, construção de programas, testes e manutenção.

As ferramentas fornecem apoio automatizado ou semi-automatizado para o processo e seus métodos.

Fonte: PRESSMAN (2011, p.40)

Em função de sua indiscutível importância, caro aluno, as técnicas e métodos da Engenharia de Software são atualmente muito usadas, mas ainda não são usadas por todos e nem usadas da maneira correta.

Não podemos prosseguir falando da Engenharia de Software sem antes entendermos o software e seus fundamentos. Assim, os conceitos de software são apresentados aqui como uma referência inicial para o estudo do software, propriamente dito e de seus processos de desenvolvimento.

Pressman (2006, p. 4) conceitua o software como:

(1) Instruções (programas de computador) que, quando executadas, produzem a função e o desempenho desejados;

(2) Estruturas de dados que possibilitam que os programas manipulem adequadamente a informação;

(3) Documentos que descrevem a operação e o uso dos programas.

As normas de gestão de qualidade e garantia da qualidade apresentam definições de software e seus componentes e processos. De acordo com a norma NBR ISO 9000-3, que é uma interpretação da norma de garantia de qualidade ISO 9001 para aplicação aos produtos de software, há as seguintes definições:

• Software: Criação intelectual compreendendo os programas, procedimentos, regras e qualquer documentação correlata à operação de um sistema de processamento de dados.
• Produto de software: Conjunto completo de programas de computador, procedimentos e documentação correlata, assim como dados designados para entrega a um usuário.
• Item de software: Qualquer parte identificável de um produto de software em etapa intermediária ou na etapa final de desenvolvimento.
• Desenvolvimento: Todas as atividades a serem realizadas para a criação de um produto de software.
• Fase: Segmento definido do trabalho.

Como podemos observar, o conjunto de conceitos apresentados deixa claro que o software é um produto complexo que exige cuidados constantes, não podendo o controle da qualidade ser uma atividade secundária, devendo estar presente desde o início de seu desenvolvimento até a análise final de entrega.

O Chaos Report

Em 1995 a organização The Standish Group (1995) publicou um estudo analisando as estatísticas sobre sucesso e fracasso dos projetos de desenvolvimento de software: o Chaos Report. Neste estudo foi revelado que:

• quase 84% dos projetos de software eram mal-sucedidos, sejam por serem cancelados ou apresentarem falhas críticas (dentre elas conclusão fora do tempo previsto, gastos fora do orçamento previsto ou produto com menos funcionalidades do que o planejado);
• 31,1% dos projetos eram cancelados antes de serem concluídos;
• 52,7% dos projetos apresentavam custo real 189% maior que o estimado e o tempo de conclusão 222% maior que o previsto;
• 16,2% dos projetos eram concluídos dentro de prazo, custo e escopo estimados;
• estimou-se que, naquele ano, as agências governamentais e companhias privadas americanas teriam gasto US$ 81 bilhões apenas em projetos cancelados, e mais US$ 59 bilhões em projetos concluídos fora do tempo previsto.

O Standish Group continuou publicando regularmente seu relatório nos anos seguintes e, apesar de 29% dos projetos de software iniciados em 2015 terem obtido sucesso (successful), ainda é preocupante saber que 19% de todos eles fracassaram, não foram finalizados ou nunca foram usados (failed) e 52% sofrem com algum problema de atraso, extrapolam o orçamento e/ou não atendem aos requisitos, conforme indicam os dados da figura.

Resultados do Chaos Report até 2015

	2011	2012	2013	2014	2015
Successful	29%	27%	31%	28%	29%
Chalenged	49%	56%	50%	55%	52%
Failed	22%	17	19%	17%	19%

Fonte: www.infoq.com

Observando estes números, fica claro que, de 1960 até hoje, mais de 50 anos de experiência no desenvolvimento de software não bastaram para melhorar efetivamente a qualidade do software, a despeito da evolução ocorrida na área de Engenharia de Software e do ferramental disponível.

Grady Booch, um dos criadores da UML (Unified Modeling Language), resumiu a história dizendo que uma “doença” que dure tanto tempo quanto esta deveria ser chamada de “anormalidade” (BOOCH; RUMBAUGH; JACOBSON, 2006).

Grady Booch

Tradução: “A função de um bom software é fazer o complexo parecer ser simples.” Grady Booch. Fonte:www.azquotes.com

Fundamentos da Engenharia de Software

Para entendermos melhor os conceitos fundamentais que envolvem a área de Engenharia de Software, vamos fazer um breve histórico dos principais fatos que ocorreram no mundo da tecnologia que justificaram a criação deste ramo da computação. É interessante vocês notarem que algumas décadas atrás não se tinha ideia da importância que os computadores e, em especial, o software, iriam ter e como iriam afetar profundamente a vida de todos nós. 

Ferramentas de Engenharia de software

Fonte: Moon Light PhotoStudio/shutterstock

A Crise do Software e a Engenharia de Software

O termo “Engenharia de Software” foi criado no início da década de 1960, tendo sido utilizado oficialmente em 1968 na NATO Conference on Software Engineering (Conferência da OTAN sobre Engenharia de Software), que aconteceu na cidade de Garmisch, Alemanha. Nesta ocasião, todos estavam preocupados em contornar os efeitos da crise do software e buscar maneiras de dar um tratamento de engenharia, ou seja, mais sistemático e controlado, ao desenvolvimento de sistemas de software complexos.

NATO Software Engineering Conference, 1968

Fonte: homepages.cs.ncl.ac.uk

Sistemas de software complexos apresentam, de forma geral, componentes heterogêneos e em grande número, com alto grau de interconexões, relações e dependência entre si. Esta heterogeneidade pode surgir, em parte, como resultado da evolução do sistema e sua adaptação a novas condições de contorno. Os sistemas também podem se tornar complexos na medida em que novas versões são criadas.

Como o principal objetivo dessa conferência foi estabelecer práticas mais maduras para o processo de desenvolvimento de software, esta conferência é considerada como o evento que deu origem à disciplina de Engenharia de Software.

Spector e Gifford (1986, p. 268-273) realizaram um famoso estudo no qual comparavam a construção de pontes ao desenvolvimento de software. Os autores partiam da premissa que as pontes normalmente eram construídas no tempo planejado, com gastos dentro do orçamento, e nunca caíam. Já os softwares nunca ficavam prontos dentro do prazo e do orçamento planejados, e, além disso, quase sempre apresentavam problemas.

Aconteceu

A Crise do Software

A crise do software foi um termo criado para descrever as dificuldades enfrentadas no desenvolvimento de software no final da década de 1960. O aumento da complexidade dos problemas, aliado à inexistência de técnicas bem estabelecidas e à crescente demanda por novas aplicações, indicavam que medidas sérias deveriam ser tomadas. Essa crise teve como origem a introdução de computadores “mais poderosos”. O advento deste hardware com mais recursos tornava viáveis softwares bem maiores e mais complexos que os sistemas existentes. A experiência inicial de construção desses sistemas mostrou que uma abordagem informal de desenvolvimentode software não era suficiente. Projetos importantes sofriam atrasos (às vezes, de alguns anos). Os custos eram muito maiores do que os inicialmente projetados. As soluções de software não eram confiáveis. Os programas eram de difícil manutenção. Novas técnicas e novos métodos eram necessários para controlar a complexidade inerente aos grandes sistemas de software.

Vantagens e desvantagens do uso do BSC

Como vantagens da implantação do BSC, as organizações podem:

• esclarecer e traduzir a missão e a visão, iniciando com um trabalho de equipe que traduza a estratégia da organização em objetivos estratégicos específicos;
• comunicar e associar objetivos e mensurações estratégicas, que são transmitidos aos colaboradores por meio de boletins informativos, quadros de avisos e e-mails;
• planejar, estabelecer metas e alinhar iniciativas estratégicas, já que são traçadas conjuntamente metas para atingir os objetivos com três a cinco anos de antecedência, as quais, uma vez alcançadas, permitem a evolução da organização.

No entanto, existem algumas críticas à metodologia do BSC, fundamentadas no fato de que alguns usuários confundem os fins com os meios. O BSC é um meio de promover a estratégia, não uma estratégia em si.

Outro problema muito comum é a falta de coordenação entre áreas fins e meio ou mesmo entre as diversas áreas de uma organização. Uma situação negativa que exemplificaria esse problema seria um cenário em que a área de recursos humanos, por exemplo, obedecesse ao “seu plano” ou àquilo que considerasse prioritário, enquanto a área de logística atuasse também em função de seus interesses, e a mesma atitude fosse seguida por outros setores da empresa, como marketing, TI etc.

Cada um agir de acordo com suas próprias orientações, mesmo que com base nas quatro perspectivas do BSC, mas sem integração em prol do direcionamento comum à organização, configura-se como uma situação indesejada. Na verdade, a metodologia age no sentido de evitar tal fragmentação de gestão.

Podemos citar como principais pontos fracos do BSC:

• relações de causa e efeito unidirecionais e muito simplistas;
• não separa causa e efeito no tempo;
• ausência de mecanismos para validação;
• vínculo entre estratégia e a operação insuficiente;
• muito internamente focado;
• ausência de uma base histórica suficiente para análise de um indicador pode levar a conclusões imprecisas.

É importante lembrar que o BSC se encontra hoje incorporado à gestão de organizações públicas ou privadas, de pequeno ou grande porte, de natureza comercial, industrial ou de serviços e de diferentes setores da economia (financeiro, saúde, varejo, eletromecânico etc.). Os profissionais da organização, principalmente aqueles voltados para planejamento e controle, precisam avaliar a viabilidade e os possíveis ganhos decorrentes da implementação do BSC em suas organizações.

Gerenciamento com BSC

Existe um grande desafio nas organizações para definir objetivos e metas visando alcançar os resultados esperados. Mas como mensurar esses objetivos e saber se uma empresa está no caminho certo?

Além de definir objetivos que traduzam a estratégia, é importante incluir outros elementos na gestão capazes de orientar a organização quanto ao alcance dos resultados e os possíveis riscos decorrentes de diversos fatores internos e externos.

De acordo com Pereira (2009), o BSC possui uma estrutura lógica que inter-relaciona objetivos estratégicos por meio de perspectivas da organização, lançando mão desses elementos gerenciáveis para serem analisados e controlados no decorrer do ciclo de gestão estratégica. 

O BSC diferencia-se de outros modelos de gestão porque pode agregar todos os modelos de controle financeiro e não financeiro que existem, desde que propiciem à organização uma forma de indicador de desempenho.

De acordo com Silva Netto e Oliveira (2012), para as organizações utilizarem o BSC em sua gestão, propõem-se as seguintes etapas de modelagem:

• Arquitetura do programa de medição: o objetivo dessa etapa é promover uma compreensão e uma análise crítica dos direcionadores de negócio e da visão de futuro. Um objetivo secundário é resgatar as diretrizes estratégicas, analisando sua coerência com os direcionadores de negócio e visão de futuro.
• Inter-relacionamento de objetivos estratégicos: as atividades dessa etapa implicam alocar os objetivos estratégicos nas quatro dimensões do BSC, correlacionando-as entre si. Nesse processo, poderão ou não surgir lacunas no inter-relacionamento, que deverão ser eliminadas ou preenchidas a partir de novas discussões e análises do planejamento estratégico da organização.
• Escolha e elaboração dos indicadores: o objetivo essencial da seleção de indicadores específicos para o BSC é a identificação daqueles que melhor comuniquem o significado da estratégia que foi estabelecida.
• Elaboração do plano de implementação: uma vez definidos os indicadores associados aos diferentes objetivos estratégicos, definem-se metas, planos de ação e responsáveis a fim de direcionar a implementação da estratégia.

De acordo com Melo (2012), a abstração mais simples para entender o BSC é enxergá-lo como uma biblioteca de melhores práticas para elaboração de um painel de medição de desempenho da estratégia empresarial (dashboard): sua principal função é comunicar a estratégia de forma clara e objetiva e gerenciar sua implantação. A figura xx ilustra um dashboard criado com base nas perspectivas do BSC.

Parte-se da premissa de que o funcionamento do mercado na era da informação exige necessidade de inovação, globalização dos negócios e conhecimento tácito substituindo a força braçal como contribuição principal da força de trabalho para direcionar uma atitude mais moderna na gestão estratégica.

Reunir as pessoas da organização em torno dos objetivos e alcançar as metas estabelecidas necessita de recursos simples e de fácil leitura para a tomada de decisão. O BSC é um modelo sistematizado e testado experimentalmente para:

• simplificar a estratégia corporativa;
• ligar a estratégia ao orçamento anual da empresa;
• comunicar a estratégia em toda a organização;
• alinhar a organização com a estratégia;
• medir a eficácia da estratégia.

As linhas estratégicas definidas pela empresa são orientadoras do seu percurso e de sua atividade para o curto-médio prazo, devendo deter a possibilidade prática do ajustamento às diferentes realidades pelas quais vai passando a organização.

Outra característica importante do BSC é o seu foco numa estratégia amarrada desde o objetivo puramente financeiro até o indicador relacionado ao desenvolvimento do funcionário.

Kaplan e Norton (1997) dizem que a estratégia é um conjunto de hipóteses que contam uma história de sucesso a realizar. As relações causais fortalecem a história como um todo e promovem uma sinergia virtuosa entre os objetivos estratégicos. A perseguição e a realização de um contribui automaticamente para os demais, otimizando esforço e resultado.

Segundo Kraemer (2005), um projeto típico de formulação e implantação de um BSC pode durar 16 semanas, porém nem todo esse tempo é ocupado com as atividades do scorecard: grande parte do tempo é determinada pela disponibilidade dos executivos para entrevistas, workshops e reuniões.

A figura ilustra um projeto de implantação baseado no BSC. 

Evolução da construção de um projeto baseado no BSC
Fonte: Baseado em Kraemer (2005).

Aconteceu

O BSC é uma ferramenta útil para dirigir empresas de forma proativa no curto e no longo prazo. Sua eficácia está na correta compreensão dos seus fundamentos, na sua aplicação completa que implique na mudança da gestão da empresa. Medir a estratégia permite que a organização confirme ou rejeite as ações de causa e efeitos assumidos quando aquela foi estabelecida (MELO, 2012).

A ideia do gerenciamento com base no BSC é que a organização parta dos objetivos traçados para dar um salto de competitividade na organização para os próximos dois, cinco ou dez anos e derive indicadores para medir se empresa está caminhando corretamente para a realização dos objetivos e, finalmente, se eles foram alcançados.