3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

“É mais fácil escrever um programa incorreto do que entender um correto.” [Alan Perlis]

“Um processo define quem está fazendo o quê, quando e como para alcançar um certo objetivo.” [Ivar Jacobson, Grady Booch e James Rumbaugh]

“Se o processo for fraco, o produto final sofrerá inevitavelmente, mas uma ênfase exagerada no processo também é perigosa.” [Roger Pressman, 2006]

3.1 P

ANORAMA SOBRE

P

ROCESSO DE

S

OFTWARE

Origem: Engenharia de Software, Roger Pressman, 2006

• O que é? Quando você elabora um produto ou sistema é importante percorrer uma série de passos previsíveis – um roteiro que o ajuda a criar a tempo um resultado de alta qualidade. O roteiro que você segue é chamado de Processo de Software;

• Quem faz? Os engenheiros de software e seus gerentes adaptam o processo a suas necessidades e depois o seguem. Além disso, o pessoal que solicitou o software tem um papel a desempenhar no processo de definí-lo, construí-lo e testá-lo;

• Por que é importante? Porque fornece estabilidade, controle e organização para uma atividade que pode, se deixada sem controle, tornar-se bastante caótica. No entanto, uma abordagem moderna de engenharia de software precisa ser “ágil”. Precisa exigir apenas aquelas atividades, controles e documentação adequados à equipe de projeto e ao produto que deve ser produzido;

• Quais são os passos? Em nível de detalhe, o processo adotado depende do software que você está construindo. Um processo poderia ser apropriado à criação de softwares para o sistema de aviônica de uma aeronave, enquanto um processo inteiramente diferente seria indicado para a criação de um site;

• Qual é o produto do trabalho? Do ponto de vista de um engenheiro de software, os produtos do trabalho são os programas, documentos e dados produzidos em consequência das atividades e tarefas definidas pelo processo;

• Como tenho certeza de que fiz corretamente? Existem diversos mecanismos de avaliação do processo de software que permitem às organizações determinar a “maturidade” do seu processo de software. Todavia, a qualidade, pontualidade e viabilidade a longo prazo do produto que você constrói são os melhores indicadores da eficácia do processo usado.

3.2 O

QUE É

P

ROCESSO

?

Sobre o Processo de Software, Shari L. Pfleeger (2004) destaca os seguintes itens: • Conjunto de tarefas ordenadas;

• Uma série de etapas que envolvem atividades, restrições e recursos para alcançar a saída desejada;

• Descreve a ‘vida’ do produto de software desde a concepção até a implementação, entrega, utilização e manutenção.

Há autores que defendem, no entanto, que o ciclo de vida é uma parte de um processo de desenvolvimento de software, focado nas atividades e na sequência em que elas devem ser executadas. E que o processo apresenta outros itens, como ferramentas e pessoal envolvido. Considerando a farta variedade de problemas que podem ser resolvidos através da elaboração de um software, diferentes processos de desenvolvimento podem ser aplicados. Para contemplar essa situação, diferentes Modelos de Processo de Desenvolvimento de Software estão disponíveis na literatura, servindo como base para que uma organização elabore o seu próprio modelo, mais adequado às suas características individuais.

3.3 A

TIVIDADES

T

ÍPICAS DO

P

ROCESSO DE

S

OFTWARE

Diferentes autores consideram diferentes atividades como sendo básicas para a definição de um processo. Porém, mesmo que se considerem diferentes nomeclaturas e divisões, elas contém essencialmente a mesma idéia, quando consideradas em conjunto.

Um exemplo bastante comum, de grupo de atividades básicas é o seguinte:

• Desenvolvimento – Análise, Design e Implementação. As funcionalidades e as restrições são especificadas e o software é produzido;

• Validação & Verificação – O software é testado. Observação: Verificação x Validação.

Verificação – Checar se realizou todas as atividades (Fazendo certo a coisa). Validação – Checar se o artefato está correto (Fazendo a coisa certa); • Manutenção – O software sofre correções, adaptações e ampliações.

Já Pressman (2006) destaca o seguinte conjunto de atividades genéricas de um processo:

• Comunicação – Essa atividade envolve alta comunicação e colaboração com o cliente (e outros

stakeholders) e abrange o levantamento de requisitos e outras atividades relacionadas;

• Planejamento – Essa atividade estabelece um plano para o trabalho de engenharia de software. Descreve as tarefas técnicas a serem conduzidas, os riscos prováveis, os recursos que serão necessários, os produtos de trabalho a serem produzidos e um cronograma de trabalho;

• Modelagem – Essa atividade inclui a criação de modelos que permitam ao desenvolvedor e ao cliente, entender melhor os requisitos do software e o projeto que vai satisfazer a esses requisitos;

• Construção – Essa atividade combina geração de código (manual ou automática) e os testes necessários para revelar erros no código;

• Implantação – O software é entregue ao cliente, que avalia o produto e fornece feedback.

Pressman (2006) complementa que as atividades genéricas são complementadas por uma série de atividades guarda-chuva, entre as quais podem ser citadas:

• Acompanhamento e controle de projeto de software; • Gestão de risco;

• Garantia de qualidade de software; • Revisões técnicas formais;

• Medição;

• Gestão de configuração de software; • Gestão de reusabilidade;

• Preparação e produção do produto do trabalho.

O mesmo autor ainda comenta o seguinte:

“Toda organização de Engenharia de software deveria descrever um conjunto específico de atividades de arcabouço para o(s) processo(s) de software que adota. Deveria preencher cada atividade de arcabouço com um conjunto de ações de engenharia de software e definir cada ação em termos de um conjunto de tarefas que identifique o trabalho (e produtos de trabalho) a ser realizado para satisfazer às metas de desenvolvimento. Deveria, então, adaptar o modelo de processo resultante para acomodar a natureza específica de cada projeto, o pessoal que vai fazer o trabalho e o ambiente no qual o trabalho vai ser conduzido. Independentemente do modelo de processo que seja selecionado, os engenheiros de software tem tradicionalmente escolhido um arcabouço de processo genérico que inclui as seguintes atividades de arcabouço: comunicação, planejamento, modelagem, construção e implantação.”

3.4 C

ICLO DE

V

IDA DE

S

OFTWARE

Como todo produto industrial o software tem um ciclo de vida: • Ele é concebido a partir da percepção de uma necessidade;

• É desenvolvido, transformando-se em um conjunto de itens entregue a um cliente;

• Entra em operação, sendo usado dentro de algum processo de negócio e sujeito a atividades de manutenção, quando necessário;

Assim pode-se fazer a seguinte definição para Ciclo de Vida: O ciclo de vida do software é uma sequência de diferentes atividades executadas ao longo da existência do software.

Cada fase do ciclo de vida tem divisões e subdivisões. É interessante destacar que a fase de codificação, que representa a escrita final de um programa em forma inteligível para um computador, é apenas uma pequena parte do ciclo de vida. Para a maioria das pessoas, inclusive muitos profissionais, essa ainda parece ser a única tarefa de um produtor de software.

Segue abaixo um esquema simplificado de Ciclo de Vida de Software.

Ciclo de Vida Percepção da Necessidade Operação Retirada Concepção Elaboração Transição Desenho Arquitetônico Testes de Aceitação

Desenvolvi-mento _{Construção Liberação}

Desenho detalhado

Codificação

Teste De Unidade

Assim, pode-se dizer que o ciclo de vida básico do software: • Começa na concepção do problema;

• Termina quando o sistema sai de uso.

A seguir está disponibilizada uma lista das atividades mais comumente realizadas durante o ciclo de vida de um software.

• Estudo de Viabilidade: Determina se o desenvolvimento proposto é viável; • Análise de Mercado: Determina se existe mercado potencial para o produto;

• Levantamento de Requisitos: Determina quais funcionalidades o software deve ter; • Elicidação dos Requisitos: Obtém os requisitos do usuário;

• Análise de Domínio: Identifica e caracteriza o ambiente (domínio) no qual está o problema que o software pretende solucionar;

• Planejamento de Projeto: Determina como desenvolver o software; • Análise de Custos: Determina a estimativa dos custos;

• Elaboração de Cronograma: Identifica o cronograma para o desenvolvimento;

• Garantia da Qualidade de Software: Determina atividades irão ajudar a garantir a qualidade do produto;

• Definição da Estrutura de Decomposição do Trabalho: Determina as sub-tarefas necessárias para o desenvolvimento do produto;

• Elaboração do Design: Determina como o software deverá prover as funcionalidades (características técnicas/tecnológicas);

• Elaboração do Design Arquitetural: Projeta a estrutura do sistema;

• Elaboração do Design de Interface: Especifica as interfaces entre as partes do sistema; • Elaboração do Design Detalhado: Projeta os algoritmos e estrutura de dados para cada

componente;

• Elaboração do Design de Banco de Dados: Especifica o(s) modelo(s) de banco de dados;

• Implementação: Construção do software;

• Teste: Execução do software com dados para ajudar a garantir que o software funciona corretamente;

• Teste de Unidade: Teste do desenvolvedor original;

• Teste de Integração: Teste durante a integração do software;

• Teste do Sistema: Teste do software em um ambiente semelhante ao ambiente operacional; • Teste Alpha: Teste pelo cliente no ambiente do desenvolvedor;

• Teste Beta: Teste pelo cliente no seu ambiente; • Teste de Aceitação: Teste para satisfazer o cliente;

• Teste de Regressão: Teste de armazenamento da versão anterior para garantir que a nova versão possui todas as capacidades anteriores;

• Entrega: Provê o cliente com uma solução de software eficiente;

• Implantação: Torna o software disponível no ambiente operacional do cliente; • Treinamento: Ensina o usuário como operar o software;

• Help desk: Responde a questões do usuário;

3.5 M

ODELOS DE

P

ROCESSO DE

S

OFTWARE

Conforme destaca Pressman (2006): “... A aplicação inteligente de qualquer modelo de processo de software deve reconhecer que a adaptação (ao problema, ao projeto, à equipe e à cultura organizacional) é essencial para o sucesso. Mas os modelos de processo diferem fundamentalmente:

• No fluxo geral de atividades e tarefas e interdependências entre atividades e tarefas;

• No grau em que as tarefas de trabalho são definidas dentro de cada atividade de arcabouço; • No grau em que os produtos do trabalho são identificados e solicitados;

• Na maneira como as atividades de garantia de qualidade são aplicadas;

• No modo como o monitoramento de projeto e as atividades de controle são aplicadas; • No grau geral de detalhes e rigor em que o processo é descrito;

• No grau em que clientes e outros interessados estão envolvidos no projeto; • No nível de autonomia da equipe de projeto de software;

• No grau em que a organização da equipe e os papéis são prescritos.

Modelos de processo que enfatizam a definição, identificação e aplicação detalhada de atividades e tarefas de processo têm sido aplicados na comunidade de engenharia de software durante os últimos trinta anos. Quando esses Modelos Prescritivos de Processo são aplicados, o objetivo é melhorar a qualidade do sistema para tornar os projetos mais gerenciáveis, as datas de entrega e os custos mais previsíveis e para guiar equipes de engenheiros de software à medida que eles realizam o trabalho necessário para construir um sistema. Infelizmente, tem havido épocas em que esses objetivos não têm sido alcançados. Se os modelos prescritivos forem aplicados dogmaticamente e sem adaptação, eles podem aumentar o nível de burocracia associado à construção de sistemas baseados em computador e, inadvertidamente, criar dificuldades para desenvolvedores e clientes. Modelos de processo que enfatizam a agilidade do projeto e seguem uma série de princípios que levam a uma abordagem mais informal (mas, segundo seus proponentes, não menos efetiva) do processo de software foram propostos nos últimos anos. Esses Modelos de Processo Ágil enfatizam a manobrabilidade e a adaptabilidade. Eles são adequados a muitos tipos de projeto e são particularmente úteis quando aplicações Web passam por engenharia.

Que filosofia de processo de software é melhor? Essa questão tem provocado um debate emocional entre engenheiros de software [...]. Por hora, é importante notar que essas duas filosofias de processo têm objetivo comum – criar softwares de alta qualidade que satisfaçam às necessidades do cliente -, mas abordagens diferentes.”

3.5.1 S

ELECIONANDO UM

M

ODELO DE

P

ROCESSO

“[...] Cada ação de engenharia de software é representada por um número diferente de conjuntos de tarefas – cada um como uma coleção de tarefas de trabalho de engenharia de software, produtos de trabalho relacionados, pontos de garantia de qualidade e marcos de projeto. O conjunto de tarefas escolhido é o que melhor acomoda as necessidades do projeto e as características da equipe. Isso implica que uma ação de engenharia de software (por exemplo, o projeto) pode ser adaptada às necessidades específicas do projeto de software e às características da equipe do projeto.”

No que se refere diretamente aos modelos de processo, Pressman ainda complementa: “[...] Um conjunto de elementos de processo – atividades de arcabouço, ações de engenharia de software, tarefas, produtos de trabalho, mecanismos de garantia de qualidade e de controle de modificações

para cada projeto. Cada modelo de processo também prescreve um fluxo de trabalho – isto é, a maneira como os elementos do processo se inter-relacionam uns com os outros.”

Origem: Wikipedia

Os modelos existentes possuem diferentes graus de sofisticação e complexidade. Para projetos que envolvem uma equipe de desenvolvimento pouco numerosa e experiente, o mais adequado será provavelmente um processo simples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de elementos e milhares de utilizadores, um processo simples não é suficiente para oferecer a estrutura de gestão e disciplina necessárias à engenharia de um bom produto de software. Desta forma, é necessário algo mais formal e disciplinado. É importante fazer notar que isto não significa que se perca em inovação ou que se põe entraves à criatividade. Significa apenas que é utilizado um processo bem estruturado para permitir a criação de uma base estável para a criatividade.

Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto é, de fato, uma versão simplificada da realidade. É suposto ser uma abstração e, tal como todas as boas abstrações, apenas a quantidade de detalhe necessária ao trabalho em mãos deve ser incluída. Qualquer organização que deseje pôr um modelo de ciclo de vida em prática irá necessitar de adicionar detalhes específicos para dadas circunstâncias e diferentes culturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipe e ao mesmo tempo tornar possível o desenvolvimento de grandes e complexos produtos de software.

Dependendo do tipo de sistema em desenvolvimento pode não ser completamente possível ou até apropriado seguir os modelos rigorosamente.

3.5.2 R

ESUMINDO

• Sobre Modelos de Processo:

o Especificam as atividades que, de acordo com o modelo, devem ser executadas, assim como a ordem em que devem ser executadas;

o Produtos de software podem ser construídos utilizando-se diferentes modelos de processo;

o Alguns modelos são mais adequados que outros para determinados tipos de aplicação;

o A opção por um determinado modelo deve ser feita levando-se em consideração o produto a ser desenvolvido, as pessoas envolvidas, os recursos disponíveis, e vários outros parâmetros;

• Objetivos:

o Auxiliar no processo de produção → Produtos de alta qualidade, produzidos mais rapidamente e a um custo cada vez menor;

o Atributos: complexidade, visibilidade, aceitabilidade, confiabilidade, manutenibilidade, segurança, etc;

o Possibilitam:

Ao gerente: controlar o processo de desenvolvimento de software;

Ao desenvolvedor: obter a base para produzir, de maneira eficiente, software que satisfaça os requisitos pré-estabelecidos.

3.5.3 P

ANORAMA SOBRE

M

ODELOS

P

RESCRITIVOS DE

P

ROCESSO

• O que é? Modelos prescritivos de processo definem um conjunto distinto de atividades, ações, tarefas, marcos e produtos de trabalho que são necessários para fazer engenharia de software com alta qualidade. Esses modelos de processo não são perfeitos, mas efetivamente fornecem um roteiro útil para o trabalho da engenharia de software;

• Quem faz? Engenheiros de software e seus gerentes adaptam um modelo de processo prescritivo a suas necessidades e depois o seguem. Além disso, o pessoal que solicitou o software tem um papel a desenvolver à medida que o modelo de processo é seguido;

• Por que é importante? Porque fornece estabilidade, controle e organização a uma atividade que pode, se deixada sem controle, tornar-se bastante caótica. Alguns têm-se referido a modelos prescritivos de processo como “modelos de processo rigorosos”, porque eles frequentemente incluem as capacitações sugeridas pelo CMMI. No entanto, cada modelo de processo deve ser adaptado para que seja usado efetivamente em um projeto de software específico;

• Quais são os passos? O processo dirige uma equipe de software por meio de um arcabouço de atividades guarda-chuva que são organizadas em um fluxo de processo que pode ser linear, incremental ou evolutivo. A terminologia e os detalhes de cada modelo de processo diferem, mas as atividades genéricas de arcabouço permanecem razoavelmente consistentes;

• Qual é o produto do trabalho? Do ponto de vista de um engenheiro de software, os produtos de trabalho são os programas, documentos e dados que são produzidos em consequência das atividades e tarefas definidas pelo processo;

• Como tenho certeza de que fiz corretamente? Existem diversos mecanismos de avaliação de processo de software que permitem às organizações determinar a “maturidade” do seu processo de software. Todavia, a qualidade, pontualidade e viabilidade no longo prazo do produto que você constrói são os melhores indicadores da eficácia do processo usado.

Ainda sobre Modelos de processos prescritivos o autor destaca o seguinte:

“Se os modelos prescritivos de processo buscam estrutura e ordem, serão apropriados ao mundo do software que busca modificações? No entanto, se rejeitarmos modelos de processos convencionais (e a ordem que eles implicam) e os substituirmos por algo menos estruturado, tornamos impossível obter coordenação e coerência no mundo de software?

Não há respostas fáceis para essas questões, mas existem alternativas disponíveis para os engenheiros de software.”

A seguir serão apresentados alguns dos modelos prescritivos de processo mais conhecidos.

3.5.4 C

ODE AND

F

IX

(C

ONSTRÓI E

C

ONSERTA

)

O code-and-fix não é um modelo prescritivo de processo, mas uma primeira ideia de um “processo” de software.

O produto é construído sem qualquer especificação ou design. Não existe um roteiro definido de atividades, simplesmente vai-se se implementando à medida que o contato com o cliente vai identificando novas necessidades. O produto é refeito quantas vezes forem necessárias para satisfazer o cliente.

Este modelo pode funcionar razoavelmente para micro projetos. No entanto para projetos maiores ele é inadequado. A Figura a seguir caracteriza o modelo.

3.5.5 C

LÁSSICO

/

E

M

C

ASCATA

Este modelo é classificado como sendo um Modelo Prescritivo de Processo.

Apesar de todos os seus problemas, o modelo em cascata é utilizado há muitos anos, além de ser o mais antigo dos modelos. Atualmente, devido à complexidade cada vez maior dos sistemas, ele é pouco utilizado.

Suas principais características:

• Método sistemático e sequencial;

• O resultado de uma fase se constitui na entrada de outra - Cada atividade é uma fase distinta. Só após o seu total término é que a próxima atividade começa;

• O nível de abstração vai diminuindo à medida que se avança no processo enquanto o formalismo aumenta;

• Cada fase é estruturada como um conjunto de atividades que podem ser executadas por pessoas diferentes;

• Os requisitos do problema devem estar bem compreendidos.

Diferentes autores podem considerar diferentes atividades a serem trabalhadas (mesmo que elas tenham características em comum). No entanto o que está acima descrito se aplica a qualquer conjunto de atividades consideradas. Pressman (2006), por exemplo, ao invés das atividades que estão abaixo identificadas trabalha com as atividades que chama de arcabouço, e que já foram previamente citadas.

Atividades do Ciclo de Vida Clássico

Alguns problemas do Ciclo de Vida Clássico:

• Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe. Alguma iteração sempre ocorre e traz problemas na aplicação do paradigma;

• Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente. O ciclo clássico tem dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos;

• Uma versão de trabalho do(s) programa(s) só estará disponível em um ponto muito tardio do cronograma do projeto. O cliente deve ter paciência;

• No modelo em cascata os subprocessos são executados em estrita sequência, o que permite demarcá-los com pontos de controle bem definidos. Essa característica facilita a gestão dos projetos. Por outro lado, se interpretado literalmente, é um processo rígido e burocrático, em que as atividades devem ser muito bem dominadas, pois não são permitidos erros (retornar após uma etapa ter sido concluída);

• “[...] A natureza linear do modelo em cascata leva a ‘estados de bloqueio’ nos quais alguns membros da equipe de projeto precisam esperar que outros membros completem as tarefas dependentes.”

Realimentação entre fases

Na prática, é sempre necessário permitir que, em fases posteriores, haja revisão e alteração de resultados das fases anteriores. Por exemplo, os modelos e documentos de projeto podem ser alterados durante a implementação, à medida que os problemas vão sendo descobertos. Uma variante que permite superposição entre fases e a realização de correções é um modelo mais realista, com realimentação entre as fases. Esta realimentação dificulta gerenciar projetos baseados neste modelo de processo.

3.5.6 I

NCREMENTAL

Este modelo é classificado como sendo um Modelo Prescritivo de Processo.

O modelo incremental e iterativo foi proposto como uma resposta aos problemas encontrados no modelo em cascata. Um processo de desenvolvimento segundo essa abordagem divide o desenvolvimento de um produto de software em ciclos, com o software sendo desenvolvido em partes (incrementos). Em cada ciclo de desenvolvimento, podem ser identificadas todas as fases do projeto. Essa característica contrasta com a abordagem clássica, na qual as fases do projeto são realizadas uma única vez.

Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desenvolvimento. No próximo ciclo, um outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior.

Assim, o desenvolvimento evolui em versões, através da construção incremental e iterativa de novas funcionalidades até que o sistema completo esteja construído. Vale destacar que apenas uma parte dos requisitos é considerada em cada ciclo de desenvolvimento. Na verdade, um modelo iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvido em incrementos e cada incremento é desenvolvido em cascata (figura abaixo).

A abordagem incremental e iterativa somente é possível se existir um mecanismo para dividir os requisitos do sistema em partes, para que cada parte seja alocada a um ciclo de desenvolvimento. Essa alocação é realizada em função do grau de importância atribuído a cada requisito.

3.5.7 RAD

(R

APID

A

PPLICATION

D

EVELOPMENT

)

Este modelo é classificado como sendo um Modelo Prescritivo de Processo, e incremental.

O desenvolvimento rápido de aplicação é um modelo de processo de desenvolvimento de software incremental que enfatiza um ciclo de desenvolvimento extremamente curto (por exemplo, de 60 a 90 dias). É uma adaptação do modelo cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes, requerendo que os requisitos sejam bem compreendidos, os objetivos propostos e haja diferentes equipes de desenvolvimento envolvidas. (PRESSMAN, 2006).

Pressman (2006) ainda destaca os possíveis problemas de tal abordagem:

• Aumento da necessidade de recursos humanos (tamanho das equipes), a medida que o escopo do problema aumenta;;

• Necessidade de maior envolvimento e comprometimento, para cumprir os prazos curtos; • O problema precisa ser adequadamente modularizado, para que haja atuação das diferentes

equipes;

• Em projetos de alto desempenho, com interfaces de módulos muito interligadas, há maior probabilidade de erros;

• Pode não ser a abordagem mais adequada quando os riscos técnicos são altos, como por exemplo, na utilização de uma nova tecnologia.

3.5.8 M

ODELOS

E

VOLUCIONÁRIOS

Sobre modelos de processo evolucionários Pressman (2006) destaca o seguinte: “O software, como todo sistema complexo, evolui com o passar do tempo. Os requisitos do negócio e do produto mudam frequentemente à medida que o desenvolvimento prossegue, dificultando um caminho direto para um produto final; prazos reduzidos de mercado tornam impossível completar um produto de software abrangente, mas uma versão reduzida pode ser elaborada para fazer frente à competitividade ou às pressões do negócio; um conjunto de requisitos básicos de um produto ou sistema é bem entendido, mas os detalhes das extensões do produto ou sistema ainda precisam ser definidos. Nesse caso, e em situações semelhantes, os engenheiros de software precisam de um modelo de processo que tenha sido explicitamente projetado para acomodar um produto que evolui com o tempo.”

O mesmo autor ainda prossegue, destacando a necessidade dos modelos evolucionários: “[...] o software de computador moderno é caracterizado por modificações contínuas, prazos muito curtos e por uma enfática necessidade de satisfação do cliente/usuário. Em muitos casos, o período até a colocação no mercado é o requisito gerencial mais importante. Se um nicho de mercado é perdido, o projeto de software em si pode ser insignificante.”

Pressman (2006) destaca também alguns problemas que esse tipo de modelo acarreta:

• Dificulta o planejamento de projeto, pois há um número incerto de ciclos para construir o produto;

• A velocidade da evolução pode acarretar problemas no próprio produto;

• São processos focados na flexibilidade e extensibilidade, em detrimento de outros critérios de qualidade.

3.5.8.1

Prototipagem

A prototipagem pode ser considerada como um modelo de processo de desenvolvimento de software, mas que pode funcionar concomitantemente com qualquer outro tipo de modelo. No desenvolvimento de um software, a prototipagem é um esboço de uma parte do sistema.

Protótipos são construídos para telas de entrada, de saída, para subsistemas ou mesmo para todo um sistema. A construção de protótipos costuma utilizar as denominadas linguagens de programação visuais. Exemplos são o Delphi , o PowerBuilder e o Visual Basic que costumam ter ambientes com facilidades para a construção da interface gráfica (telas, formulários etc.). Além disso, alguns sistemas gerenciadores de bancos de dados também fornecem ferramentas para a construção de telas de entrada e saída de dados.

Coleta e Refinamento dos Requisitos Fim Início Engenharia do Produto Refinamento do Protótipo Avaliação do Protótipo pelo Cliente Construção do Protótipo Projeto Rápido

Esse modelo constrói uma versão descartável (ou protótipo). Esse protótipo visa a testar conceitos e requisitos e será usado para demonstrar o comportamento aos clientes. Após a concordância dos clientes, o software é desenvolvido seguindo as mesmas fases do modelo clássico, ou de algum outro modelo que seja adotado. O esforço despendido no protótipo geralmente é compensado pelo não desenvolvimento de características desnecessárias.

Pode assumir 3 formas:

(1) Um protótipo em papel ou automatizado;

(2) Um protótipo de trabalho que implementa algum subconjunto da função exigida do software desejado;

(3) Um programa existente que executa parte ou toda a função desejada.

O funcionamento básico é o seguinte: A prototipação inicia-se com a coleta dos requisitos. O desenvolvedor e o cliente reúnem-se e definem os objetivos globais para o software. Ocorre então a elaboração de um “design rápido”. O design rápido leva a construção de um protótipo que é avaliado pelo cliente/usuário e é usado para refinar os requisitos para o software a ser desenvolvido.

Idealmente, o protótipo serve como um mecanismo para identificar os requisitos de software, quando há muitas dúvidas entre estes. A prototipação é fundamental à medida que cresce a importância da interface com o usuário.

O protótipo pode servir como “o primeiro sistema” – sistema esse que recomenda-se seja jogado fora. O problema é que alguns usuários tendem a encarar o protótipo como algo já confiável, ou seja, como se já fosse parte do software real.

Na maioria dos projetos, o primeiro sistema construído, se for via protótipo, dificilmente é usável. Ele pode ser muito lento, muito grande, desajeitado em uso, ou todos os três. Não resta outra alternativa senão começar tudo de novo, mas com mais habilidade técnica. O desenvolvedor pode não utilizar as técnicas de programação adequadas, pensando apenas na rapidez. Um protótipo normalmente preocupa-se apenas com a interface, não tratando dos algoritmos e regras de negócio. Esse é, portanto mais um motivo para que ele seja descartado, ao invés de servir de base para o software final.

Ainda que possam ocorrer problemas, a prototipação é um paradigma eficiente da engenharia de software. A chave é definir-se as regras do jogo logo no começo, ou seja, o cliente e o desenvolvedor devem ambos concordar que o protótipo seja construído para servir como um mecanismo afim de definir os requisitos. Ele será depois descartado (pelo menos em parte) e o software real será projetado.

3.5.8.2

Espiral ou Evolutivo

Este modelo é classificado como sendo um Modelo Prescritivo de Processo, e evolucionário.

Planejamento Análise dos Riscos

Avaliação do

Cliente Engenhari

a

Análise dos riscos baseada nos requisitos iniciais Análise dos riscos baseada na reação do cliente Decisão de Prosseguir ou não Na direção de um sistema concluido

Coleta inicial dos Requisitos e Planejamento do Projeto Planejamento baseado nos comentários do cliente Avaliação do cliente

Protótipo de Software inicial

Protótipo de nível seguinte Sistema construido pela engenharia

Este é um modelo que atende os seguintes casos:

• O problema a ser resolvido não está totalmente entendido;

• A realidade pode mudar enquanto o sistema está sendo desenvolvido; • A própria solução adotada pode ter algum efeito colateral desconhecido;

• A preocupação está centrada mais na qualidade e funcionalidade do que se produz.

O modelo espiral para a engenharia de software foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico (no que se refere a sistematização e controle) como da prototipação (no que se refere a iteratividade), acrescentando, ao mesmo tempo, um novo elemento – a análise dos riscos – que falta a esses paradigmas. O modelo, representado pela espiral, define quatro importantes atividades representadas pelos quatro quadrantes da figura, sendo elas:

1. Planejamento: determinação dos objetivos, alternativas e restrições.

2. Análise dos riscos: análise de alternativas e identificação/resolução dos riscos. 3. Engenharia: desenvolvimento do produto no “nível seguinte”.

4. Avaliação pelo cliente: avaliação dos resultados da engenharia.

No modelo em Espiral o produto é desenvolvido em uma série de iterações. Cada nova iteração corresponde a uma volta na espiral. Isso permite construir produtos em prazos curtos, com novas características e recursos que são agregados à medida que a experiência descobre sua necessidade. As atividades de avaliação são usadas para identificar problemas. Seus registros fornecem dados para definir os requisitos das próximas liberações. As versões progressivamente mais completas do software são construídas ao longo de cada iteração da espiral.

Durante o início do giro, os objetivos, alternativas e restrições são definidos, e os riscos são identificados e analisados. A conclusão da análise dos riscos resulta numa decisão de “prosseguir ou não”. Se os riscos forem muito grandes, o projeto pode ser encerrado. Há o desenvolvimento de parte do programa, que é disponibilizado para testes. Então o cliente avalia o trabalho de engenharia e apresenta sugestões para modificações.

Cada passagem pela região de planejamento resulta em ajustes no plano de projeto. O custo e o cronograma são ajustados com base no feedback derivado do cliente após a entrega. Além disso, o gerente do projeto ajusta o número planejado de iterações necessárias para completar o software (Pressman, 2006).

Deve-se notar que o número de atividades de desenvolvimento que ocorre no quadrante inferior direito eleva-se à medida que as atividades se afastam do centro da espiral. O paradigma do modelo espiral usa a prototipação como um mecanismo de redução dos riscos, possibilitando que o desenvolvedor aplique a abordagem de prototipação em qualquer etapa da evolução do produto. O modelo espiral exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemáticos. Ele exige considerável experiência na avaliação dos riscos e fia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, indubitavelmente ocorrerão problemas.

O principal problema do ciclo de vida em espiral é que ele requer gestão muito sofisticada para ser previsível e confiável. E pode ser difícil convencer os clientes sobre a realização de controle em tal forma de trabalho, visto os constantes ajustes que são realizados.

Vale destacar que o modelo em espiral pode ser continuamente utilizado, após a conclusão inicial do software, para a realização das manutenções que o mesmo deverá sofrer ao longo do tempo.

3.5.8.3

Concorrente

Este modelo é classificado como sendo um Modelo Prescritivo de Processo, e evolucionário.

O modelo concorrente é representado através de uma série de atividades e seus estados correspondentes.

Sobre ele pode ser dito o seguinte:

• As atividades podem ocorrer 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 cascata, ele define uma rede de atividades; • Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de

como está o estado do projeto.

3.5.9 D

ESENVOLVIMENTO BASEADO EM

C

OMPONENTES

É um modelo desenvolvido para apoiar a reusabilidade, necessária ao atual desenvolvimento de software, por suas principais consequências: redução de prazo e custo.

Tal modelo se utiliza de componentes de software comercial de prateleira, isto é, componentes que apresentam funcionalidade e interface bem definidas e que podem ser utilizados integrados no software em desenvolvimento.

Incorpora muitas das características do modelo espiral. É um modelo evolucionário por natureza, demanda uma abordagem iterativa.

Normalmente, apresenta os seguintes passos:

• Pesquisa e avaliação de componentes disponíveis no mercado; • Análise das necessidades de integração/implementação;

• Projeto da arquitetura de software, considerando os componentes; • Integração e Implementação que for necessária;

• Validação rigorosa. Under review Baselined Done Under revision Await ing changes Under development none Modeling act ivit y

represents the state of a software engineering activity or task

3.5.10

O

MODELO DE

M

ÉTODOS

F

ORMAIS

Os modelos de métodos formais abrangem um conjunto de atividades que levam à especificação matemática formal do software de computador.

São modelos que se apóiam na aplicação de uma rigorosa notação matemática.

Tem ganhado adeptos quando há necessidade do desenvolvimento de softwares críticos em termos de segurança, devido à sua promessa de um produto livre de erros.

• Vantagens: Ambiguidades, inconclusões e inconsistências podem ser descobertas e corrigidas mais facilmente, por meio de análise matemática;

• Problemas:

o O desenvolvimento de modelos formais é atualmente muito lento e dispendioso; o Como poucos desenvolvedores de software têm o preparo necessário para aplicar

métodos formais, torna-se necessário um treinamento extensivo;

o É difícil usar os modelos como um mecanismo de comunicação, com clientes despreparados tecnicamente.

3.5.11

D

ESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS

Certas preocupações transversais cobrem toda a arquitetura de um sistema, não sendo exclusivas de uma funcionalidade, característica ou informação. Por exemplo: segurança, tolerância a falhas, transações, geração de logs. Assim, pode-se definir:

Aspectos: mecanismos que transcendem subrotinas e herança para localizar a expressão de uma preocupação transversal, afetando toda a arquitetura de software.

Não existe ainda processo orientado a aspectos que seja considerado suficientemente maduro, mas é provável que adote características tanto do modelo de processo espiral quanto do concorrente. Alguns termos que começam a se tornar conhecidos:

• POA – Programação Orientada a Aspectos;

3.5.12

P

ROCESSO

U

NIFICADO

(PU)

Origem: http://paginas.terra.com.br/negocios/processos2002/processo_unificado_e_rup.htm

Engenharia de Software, Roger Pressman, 2006

Engenharia de Software, Notas de Aula, prof. Ricardo de Almeida Falbo, UFES

De acordo com Pressman (2006), o PU é uma tentativa de apoiar-se nos melhores recursos e características dos modelos convencionais de processo de software, mas caracterizá-los de um modo que implemente os melhores princípios de desenvolvimento ágil de softwares.

O Processo Unificado é um processo de engenharia de software desenvolvido por três dos principais gurus da indústria de software: Ivar Jacobson, James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos de experiência acumulada. É o primeiro processo de desenvolvimento a explorar integralmente as capacidades do padrão UML e baseia-se nas práticas comuns aos projetos de software com mais alto ROI do mercado.

Processo de Software Unificado (Rational Unified Process) = Processo + Métodos + Linguagem (UML)

Histórico:

O desenvolvimento de sistemas seguindo o RUP é um processo: • Dirigido por casos de uso (use cases);

• Centrado na arquitetura; • Iterativo e incremental.

O RUP trata um conjunto de atividades: • Bem definidas;

• Com responsáveis;

• Com artefatos de entrada e saída;

• Com dependências e ordem de execução; • Com modelo de ciclo de vida;

• Com uma descrição sistemática de como executá-las; • Usando linguagem UML.

Conceitos-chave do RUP:

fonte:http://www.dei.unicap.br/~sergio/es/aulas/09-IntroducaoRUP.pdf

O Processo Unificado proposto pela Rational (Rational Unified Process – RUP) foi criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemática para se obter reais vantagens no uso da Linguagem de Modelagem Unificada (Unified Modeling Language – UML). De fato, ele não é exatamente um processo: é uma infraestrutura genérica de processo que pode ser especializada para uma ampla classe de sistemas de software, para diferentes áreas de aplicação, tipos de organização, níveis de competência e tamanhos de projetos.

O RUP está fundamentado em três princípios básicos: orientação a casos de uso, arquitetura e iteração. Ele é dito dirigido a casos de uso, pois são os casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, são criados uma série de modelos de análise, design e implementação, que realizam estes casos de uso. É centrado em arquitetura, pois defende a definição de um esqueleto para a aplicação (a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP é iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em porções menores ou mini-projetos. Esses três conceitos são igualmente importantes. A arquitetura provê a estrutura para guiar o desenvolvimento do sistema em iterações, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iteração. O ciclo de vida adotado no RUP é tipicamente evolutivo. Contudo, uma forma de organização em fases é adotada para comportar os ciclos de desenvolvimento, permitindo uma gerência mais efetiva de projetos complexos. Ao contrário do tradicionalmente definido como fases na maioria dos modelos de ciclo de vida – planejamento, levantamento de requisitos, análise, projeto, implementação e testes, são definidas fases ortogonais a estas, a saber:

• Concepção: nesta fase, é estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a precisão necessária para se proceder estimativas de prazos e custos. As estimativas devem

ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sobre o planejamento e, por conseguinte, é necessário levantar requisitos do sistema e preliminarmente analisá-los. Ao término dessa fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento;

• Elaboração: o propósito desta fase é analisar mais refinadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos de projeto que oferecem maior risco. Embora o processo deva sempre acomodar alterações, as atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis e que os riscos estão suficientemente mitigados, de modo a se poder prever com precisão os custos e prazos para a conclusão do desenvolvimento.

• Construção: durante esta fase, um produto completo é desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transição à comunidade usuária.

• Transição: nesta fase, o software é disponibilizado à comunidade usuária. Após o produto ter sido colocado em uso, naturalmente surgem novas considerações que vão demandar a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou concluir algumas características que foram postergadas. É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 1 abaixo, em que a cor preta indica grande ênfase, enquanto a cor branca indica muito pouca ênfase.

Na fase de concepção, o foco principal recai sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem dos requisitos (levantamento de requisitos e análise), ainda que algum trabalho de projeto e implementação seja realizado para prototipar a arquitetura, evitando certos riscos técnicos. Na fase de construção, o enfoque concentra-se no projeto e na implementação, visando evoluir e rechear o protótipo inicial, até obter o primeiro produto operacional. Finalmente, a fase de transição concentra-se nos testes, visando garantir que o sistema possui o nível adequado de qualidade. Além disso, usuários devem ser treinados, características ajustadas e elementos esquecidos adicionados.

Além dos conjuntos de iterações em cada fase, as fases em si podem ocorrer de forma iterativa. Como mostra a figura 2, elas não necessariamente têm a mesma duração. O esforço realizado em cada uma varia fortemente em função das circunstâncias específicas do projeto.

Autor: RICARDO DE ALMEIDA FALBO (fonte: http://www.inf.ufes.br/~falbo/download/pub/Simpros2000.pdf)

Pressman (2006) destaca que as fases propostas no PU podem ser encaradas da mesma forma que as atividades de arcabouço por ele propostas, conforme destacado na figura abaixo:

Processo de Engenharia de Software na visão do RUP

Um processo é um conjunto de passos ordenados com a intenção de atingir uma meta. Em engenharia de software, a meta é criar um software ou aperfeiçoar um existente; em engenharia de processos, a meta é desenvolver ou aperfeiçoar um processo. No RUP, eles são organizados em um conjunto de disciplinas para posteriormente definirem os fluxos de trabalho e outros elementos do processo.

Em termos de modelagem de negócios, o processo de desenvolvimento de software é um processo de negócios, e o Rational Unified Process (RUP) é um processo de negócios genérico para engenharia de software orientada a objetos. Ele descreve uma família de processos de engenharia de software relacionados, que compartilham uma estrutura comum, uma arquitetura de processos comum. Ele proporciona uma abordagem disciplinada para a atribuição de tarefas e de responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários, dentro de uma programação e um orçamento previsíveis. O RUP captura muitas das melhores práticas do desenvolvimento de software moderno, de forma que possam ser adaptadas para uma grande variedade de projetos e de organizações.

Quando um sistema de software é desenvolvido começando do zero, o desenvolvimento é o processo de criação de um sistema a partir dos requisitos. Porém, depois que os sistemas tiverem tomado forma (ou seja, tiverem passado pelo ciclo de desenvolvimento inicial), os desenvolvimentos subsequentes serão o processo de adaptação do sistema aos requisitos novos ou modificados. Isso se aplica durante todo o ciclo de vida do sistema.

Pressman (2006) destaca que nem toda tarefa identificada para um fluxo de trabalho do PU é conduzida para qualquer projeto de software. A equipe adapta o processo (ações, tarefas, subtarefas e produtos de trabalho) para satisfazer às suas necessidades.

3.6 D

ESENVOLVIMENTO

Á

GIL

3.6.1 P

ANORAMA SOBRE

D

ESENVOLVIMENTO

Á

GIL

• O que é? A engenharia de software ágil combina uma filosofia e um conjunto de diretrizes de desenvolvimento. A filosofia encoraja a satisfação do cliente e a entrega incremental de software logo de início; equipes de projeto pequenas, altamente motivadas; métodos informais; produtos de trabalho de engenharia de software mínimos e simplicidade global de desenvolvimento. As diretrizes de desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto (apesar dessas atividades não serem desencorajadas) e a comunicação ativa e contínua entre desenvolvedores e clientes;

• Quem faz? Engenheiros de software e outros interessados no projeto (gerentes, clientes e usuários finais) trabalham juntos em uma equipe ágil – uma equipe que é auto-organizada e controla seu próprio destino. Uma equipe ágil enfatiza a comunicação e a colaboração entre todos que a compõe;

• Por que é importante? O ambiente moderno de negócios que cria sistemas baseados em computador e produtos de software é apressado e sempre mutável. A engenharia ágil de software representa uma alternativa razoável para a engenharia de software convencional para certas categorias de software e certos tipos de projeto de software. Tem sido demonstrado que ela entrega rapidamente sistemas bem-sucedidos;

• Quais são os passos? O desenvolvimento ágil poderia ser melhor denominado “pequena engenharia de software”. As atividades básicas de arcabouço – comunicação com o cliente, o planejamento, a modelagem, construção, entrega e avaliação – permanecem. Mas elas são

reduzidas a um conjunto mínimo de tarefas que leva a equipe de projeto à construção e entrega (alguns alegariam que isso é feito à custa da análise do problema e projeto da solução);

• Qual é o produto do trabalho? Clientes e engenheiros de software que têm adotado a filosofia ágil têm a mesma impressão – o único produto de trabalho realmente importante é um “incremento de software” operacional que é entregue ao cliente na data de entrega combinada; • Como tenho certeza de que fiz corretamente? Se a equipe ágil concordar que o processo

funciona e produz incrementos de software em condições de serem entregues e que satisfaçam ao cliente, você fez corretamente.

Comentários:

• Os modelos de processo ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e reais da engenharia de software convencional;

• Pode fornecer importantes benefícios, mas ele não é aplicável a todos os projetos, produtos, pessoas e situações;

• Não é contrário à sólida prática de engenharia de software, prevalecendo como uma filosofia sobre o trabalho de software;

• Os engenheiros de software devem ser ágeis o suficiente para responder a um ambiente de negócios mutante. E a engenharia de software está evoluindo para se adaptar a essa nova necessidade de agilidade.

Pressman (2006) apresenta ainda o “Manifesto do Desenvolvimento Ágil de Software”, onde é declarado:

“Estamos descobrindo melhores modos de desenvolvimento de software, fazendo-o e ajudando outros a fazê-lo. Por meio desse trabalho passamos a valorizar:

Indivíduos e interações em vez de processos e ferramentas. Softwares funcionando em vez de documentação abrangente. Colaboração do cliente em vez de negociação de contratos. Resposta a modificações em vez de seguir um plano.

Isto é, ainda que haja valor nos itens à direita, valorizamos mais os itens à esquerda.”

3.6.2 O

QUE É AGILIDADE

Pressman (2006) destacou que não se deve cometer o erro de considerar que agilidade dá ao engenheiro de software a licença de improvisar soluções. A agilidade está relacionada a:

• Capacidade de responder rapidamente a mudanças;

• Estruturas e atitudes de equipe que tornam a comunicação mais fácil; • Entrega rápida de software operacional;

• Menos importância para produtos de trabalho intermediários; • Adoção dos clientes como parte da equipe de desenvolvimento;

• Planejamento em um mundo incerto tem limites e um plano de projeto deve ser flexível.

O mesmo autor ainda destaca 12 princípios (propostos pelo Manifesto Ágil) que devem ser seguidos para se alcançar agilidade, sendo eles:

• A mais alta prioridade é a satisfação do cliente, por meio da liberação mais rápida e contínua de software de valor;

• Receba bem as mudanças de requisitos, mesmo em estágios tardios do desenvolvimento. Processos Ágeis devem admitir mudanças que trazem vantagens competitivas para o cliente; • Libere software frequentemente (em intervalos de 2 semanas até 2 meses), dando

preferência para uma escala de tempo mais curta;

• Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhando juntos a maior parte do tempo do projeto;

• Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado;

• O método mais eficiente e efetivo para repassar informações entre uma equipe de desenvolvimento é pela comunicação face-a-face;

• Software funcionando é a principal medida do progresso de um projeto de software;

• Processos ágeis promovem desenvolvimento sustentado. Assim, patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente;

• A atenção contínua para a excelência técnica e um bom projeto (design) aprimoram a agilidade;

• Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial, devendo ser assumida em todos os aspectos do projeto;

• As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas; • Em intervalos regulares, as equipes devem refletir sobre como se tornaram mais efetivas, e

então refinarem e ajustarem seu comportamento de acordo.

3.6.3 O

QUE É UM PROCESSO ÁGIL

Qualquer processo ágil é caracterizado de modo que atenda a três suposições-chave:

• É difícil prever antecipadamente quais requisitos de software vão persistir e quais serão modificados. É igualmente difícil prever como as prioridades do cliente serão modificadas à medida que o projeto prossegue;

• O projeto e a construção são intercalados, isto é, as duas atividades devem ser realizadas juntas de modo que os modelos de projeto sejam comprovados à medida que são criados. É difícil prever o quanto de projeto é necessário antes que a construção seja usada para comprovar o projeto;

• Análise, projeto, construção e testes não são tão previsíveis (do ponto de vista do planejamento) como gostaríamos.

Pergunta: Como criar um processo que possa gerenciar a imprevisibilidade?

Resposta: Um processo ágil deve ser adaptável e ser adaptado incrementalmente, com base no feedback do cliente.

3.6.4 P

OLÍTICA DE

D

ESENVOLVIMENTO ÁGIL

Ninguém é contra a agilidade (defensores de cada categoria de modelos de processo), o que se tem são respostas diferentes para as seguintes perguntas:

• Qual o melhor modo de alcançar a agilidade?

• Como construir softwares que satisfaçam às necessidades do cliente atual e exiba características de qualidade que lhe permitam ser estendido e ampliado para satisfazer às necessidades do cliente no longo prazo?

Não há respostas absolutas para as perguntas acima lançadas. Há muito a ser ganho considerando o que houver de melhor em cada abordagem.

3.6.5 F

ATORES

H

UMANOS

Origem: Engenharia de Software, Roger Pressman, 2006

O desenvolvimento ágil enfoca os talentos e habilidades dos indivíduos, moldando o processo a pessoas e equipes específicas.

Características-chave que devem existir entre as pessoas de uma equipe ágil e na equipe entre si: • Competência;

• Foco comum; • Colaboração;

• Capacidade de tomada de decisão - autonomia; • Habilidade de resolver problemas vagos; • Respeito e confiança mútua;

• Auto-organização. A equipe serve como sua própria gerência. o A equipe ágil organiza-se para o trabalho a ser feito;

o A equipe organiza o processo para melhor acomodar seu ambiente local;

o A equipe organiza o cronograma de trabalho para conseguir melhor entrega do incremento de software.

Alguns modelos ágeis de processo que podem ser destacados são os seguintes:

3.6.6 E

XTREME

P

ROGRAMMING

(XP)

Origem: Wikipédia, a enciclopédia livre.

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software.

Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.

Práticas

Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes de outras.

• Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.

• Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.

• Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

• Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada, sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom andamento do XP. Código fácil deve ser identificado e substituído por código simples.

• Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de desenvolvimento.

• Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores, para aceitar um determinado requisito do sistema.

• Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40 horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em harmonia.

• Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.

• Posse Coletiva (Collective Ownership): O código-fonte não tem dono e ninguém precisa solicitar permissão para poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.

• Programação em Pares (Pair Programming): é a programação em par/dupla num único computador. Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor. Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e diminuindo assim a possibilidade de erros (bugs). Com isto busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado.

• Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código-fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.

• Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

• Refatoração (Refactoring): É um processo que permite a melhoria contínua da programação, com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza (leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de código-fonte.

• Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código-fonte. Integrar de forma contínua permite saber o status real da programação.

Origem: Engenharia de Software, Roger Pressman, 2006

O XP usa uma abordagem orientada a objetos como seu paradigma de desenvolvimento preferencial. A metodologia do Extreme Programming possui 4 atividades de arcabouço:

• Planejamento:

o Criação de um conjunto de histórias que descrevem as características e funcionalidades requeridas.

o O cliente atribui uma prioridade para cada história, com base no valor de negócio global da história.

o Membros da equipe atribuem um custo às histórias – medido em semanas de desenvolvimento.

o Se uma história precisar de mais de 3 semanas, pede-se ao cliente para dividir a história em histórias menores.

o Novas histórias podem ser escritas a qualquer momento.

o A equipe e o cliente reúnem-se para agrupar as histórias na versão seguinte e identificar o modo como elas serão desenvolvidas.

o Calcula-se a velocidade de projeto – quantidade de histórias implementadas na primeira versão – para ajudar a estimar datas futuras e verificar comprometimento com as histórias.

• Projeto:

o Segue rigorosamente o princípio KIS (keep it simple – mantenha simples), fornecendo apenas diretrizes de implementação.

o Encoraja o uso de cartões CRC (Classe-Responsabilidade-Colaboração) para identificar e organizar as classes orientadas a objetos que são relevantes para o incremento.

o Se um problema de projeto difícil é encontrado, recomenda-se a criação imediata de um protótipo operacional, denominado Solução de Ponta.

o Encoraja-se a refabricação – processo de modificar um sistema de tal modo que ele não altere o comportamento externo do código, mas aperfeiçoe a estrutura interna. o O projeto é visto como um artefato provisório, continuamente modificado.

• Codificação:

o Desenvolvimento de testes unitários das histórias antes da codificação, exercitando a interface, as estruturas de dados e a funcionalidade do componente e possibilitando um feedback mais rápido quando o código é concluído.

o Programação em pares. Os focos são um pouco diferentes, poderia-se ter um programador pensando nos detalhes do código e outro no atendimento das normas de programação.

o Integração diária dos códigos desenvolvidos pelos pares de programadores. • Teste:

o Testes de regressão com os testes unitários gerados anteriormente. o Teste de integração.

o Teste de validação.