Apostila de Processo de Desenvolvimento de Software

12 

Texto

(1)

Módulo 01 - Introdução

Os computadores se tornaram elementos chaves em nossas vidas. Aos poucos, assumiram muitas das funções que nos afetam de maneira decisiva. Hoje eles controlam a maioria das transações monetárias, linhas de produção, transporte, comunicação, sistemas de defesa, sistemas de controle de processo etc.

Os computadores já são encontrados em quase todas as casas e, em algumas delas, já controlam a utilização de todos os aparelhos eletrônicos, coisa vista apenas em filmes, até há um tempo atrás. No entanto, computadores sozinhos são máquinas (hardware) inofensivas. Com o tipo certo de programa (software), eles podem levá-lo à Lua, literal e figuradamente.

É o software que dá vida a eles. Quando precisam desempenhar um papel tão importante, uma pequena falha tanto no hardware quanto no software pode levar a consequências desastrosas. Infelizmente, embora haja processos bem definidos, baseados em fundamentos teóricos para garantir a confiabilidade do hardware, não se pode dizer a mesma coisa sobre software.

Embora ainda não exista uma teoria para desenvolvimento de software, é necessário que o ele se comporte de maneira previsível, mesmo em situações imprevistas. Por essa razão, existe uma necessidade de gerenciar seu desenvolvimento por meio de um processo bem definido e sistemático. A antiga abordagem "codificar e testar" (code & test) não será suficiente. Ela pode ser boa para problemas mais simples. No entanto, o software precisa ser projetado de forma a lidar com situações extremamente complexas.

Os aspectos cruciais para o sucesso de um projeto de software são: • Esforço de Equipe

Qualquer esforço para o desenvolvimento de softwares exige uma equipe de especialistas. Por exemplo, a equipe pode ser composta por especialistas em domínios, projetos, codificação, testes e hardware.

Cada grupo de especialistas deve se concentrar em um aspecto específico do problema e apresentar uma solução adequada. No entanto, nenhum grupo pode trabalhar isoladamente, pois a interação entre os membros das equipes é importantíssima.

• Metodologia

Existem dois tipos de metodologias de desenvolvimento: Voltada ao procedimento

Voltada ao objeto

Embora, teoricamente, ambas possam ser usadas em qualquer situação de problema, uma delas deve ser selecionada antecipadamente.

• Documentação

Uma documentação clara, objetiva e precisa dos componentes do processo de desenvolvimento, é crucial para o sucesso de qualquer projeto de software.

(2)

Comunicação verbal e desenhos do pacote não são suficientes para se entender tal processo. Por exemplo, a documentação é essencial para a aprovação do cliente em várias etapas do processo. Uma vez desenvolvido, o software cria vida. Entretanto, durante sua vida, ele passará por várias mudanças e uma documentação bem-feita é essencial para a realização dessas alterações de forma mais eficaz.

• Planejamento

Assim que o desenvolvimento do software ocorrer de acordo com os requisitos especificados pelo cliente, é necessário que todo o esforço seja adequadamente estimado para atender as restrições de prazo e custo.

• Garantia de Qualidade

Os clientes esperam retorno financeiro com a implantação do software.

Além de atender às necessidades do cliente, o software deve, necessariamente, atender aos padrões de qualidade que podem ser em relação a desempenho, segurança etc.

• Usuários Leigos

Usuários leigos são aqueles que não dominam computação, portanto, o software deve ter uma interface gráfica que favoreça seu manuseio.

• Ferramentas de Software

A documentação é importante para um projeto de desenvolvimento de software, mas é uma tarefa onerosa e muitos desenvolvedores desistem de fazê-la.

Existem ferramentas que são conhecidas como ferramentas de Engenharia de Software Assistida por Computador (Computer Aided Software Engineering – CASE) que simplificam o processo da documentação.

• Conformidade com os Padrões

Os padrões são necessários para garantir uma documentação clara, objetiva e sem ambiguidades. Por exemplo, padrões IEEE para especificações de requisitos, projetos etc.

Também é possível que um cliente especifique os padrões a serem usados. • Reutilização

O esforço de desenvolvimento pode ser otimizado, reutilizando-se componentes já testados, como por exemplo, bibliotecas matemáticas, kits de ferramentas de interface gráficas etc. • Manutenção de Software

Todo software precisa ser modificado periodicamente, de acordo com as solicitações dos clientes e do uso de novas tecnologias.

A equipe de desenvolvimento pode não estar disponível para realizar a manutenção do pacote. Portanto, uma equipe de suporte deverá ser reunida, sempre que necessário, para garantir que o software continue a fornecer os serviços necessários.

(3)

• Gerenciamento de Alterações

Sempre que uma alteração deva ser realizada, é necessário estudar seu impacto sobre os vários componentes do software.

Por exemplo, ao modificar o tipo da variável denominada Global, toda função que utilizá-la será impactada e, a menos que se tome cuidado para minimizar esse efeito, o software poderá ter seu desempenho comprometido.

• Controle de Versão

O software está propenso a frequentes alterações durante seu desenvolvimento. Portanto, é importante que o usuário obtenha a versão mais recente.

No caso de falhas, será possível recorrer às versões anteriores. • Gerenciamento de Riscos

Todo esforço de desenvolvimento de software está sujeito a riscos. Por exemplo, indisponibilidade de especialistas, tecnologia, recursos etc.

É necessário, portanto, avaliar constantemente os riscos e criar medidas para reduzi-los.

Módulo 02 – Qualidade de Software

A meta de qualquer processo de desenvolvimento é produzir um software de qualidade. Agora, o que é qualidade de software?

Qualidade de software foi definida de várias maneiras, como por exemplo: • Adequação ao propósito

• Zero defeito

• Conformidade e segurança

• Atendimento à necessidade definida e implícita do cliente

Alguns dos atributos importantes que podem ser usados para medir a qualidade do software são: • Precisão

O software deve atender às necessidades do cliente. • Confiabilidade

O software deve se comportar sempre de maneira previsível, mesmo quando entradas equivocadas/aleatórias são dadas.

• Usabilidade

Facilidade para se usar. Um software com uma boa interface gráfica, deixa o usuário mais à vontade para utilizá-lo.

• Portabilidade

A facilidade com a qual um software pode ser movido de uma plataforma para outra. • Eficiência

(4)

Utilização ideal de recurso (memória e tempo de execução). • Manutenção

Facilidade com a qual o software pode ser modificado. • Flexibilidade

Facilidade com a qual o software pode ser adaptado para uso em diferentes contextos. • Segurança

Prevenção de acesso não autorizado. • Interoperabilidade

A capacidade de integração do software com sistemas existentes. • Desempenho

A capacidade do software de fornecer os resultados com diferentes restrições como tempo, precisão, uso de memória.

De todos atributos apresentados acima, a Precisão é o mais importante.

Um software deve ser preciso, mesmo que outros atributos possam ser válidos em graus que variam. Por exemplo, um aplicativo não fundamental pode deixar de garantir 100% de confiabilidade, como um processador de texto. Já para um sistema de monitoramento de saúde, 100% de precisão é necessária.

No entanto, a decisão final é do cliente.

Deve-se ter em mente, ainda, que alguns dos atributos conflitam entre si, por exemplo, portabilidade e eficiência.

Pode-se recorrer ao uso de recursos dependentes em um sistema de maneira a melhorar a eficiência, mas apenas a custo da portabilidade. Nos bons e velhos tempos, quando o DOS dominava o mundo, era possível acessar a arquitetura interna diretamente, de modo a melhorar o desempenho. No entanto, para suportar esse programa em qualquer outra plataforma, eram necessárias mudanças drásticas.

Módulo 03 – O que é um ‘Processo’?

Vamos tentar um pequeno exercício:

• Comece a ler a passagem na figura abaixo. Conforme você a lê, conte as ocorrências da letra 'F'. Uma vez terminada a leitura, coloque a quantidade de ocorrências na caixa.

(5)

Neste exercício, o PROCESSO era perguntar para ‘Codificar e Testar’. Agora vamos definir um PROCESSO que é REPETÍVEL e MENSURÁVEL.

Comece a ler a primeira linha da passagem, contando as ocorrências da letra “F” na referida linha e insira a quantidade de ocorrências na caixa posicionada no final da linha. Repita esse processo para todas as linhas.

Finalmente, some todas as contagens das linhas e insira o total na caixa de resultado.

No segundo caso, alegamos que o processo é repetível porque é o mesmo usado para todas as linhas, podendo ser usado em situações similares. Ele também é mensurável porque é possível parar a contagem em qualquer ponto e descobrir o quanto trabalho foi concluído e quanto ainda precisa ser feito.

Assim, temos que um processo é uma série de tarefas definíveis, repetíveis e mensuráveis que levam a um resultado útil.

Um processo bem definido possui muitas vantagens, são elas:

• Facilita a visualização de um projeto, auxiliando nas correções periódicas.

• Ajuda os desenvolvedores a eliminar problemas no momento de sua implantação, evitando, assim, efeitos cascata.

(6)

• Ajuda a organizar o fluxo de trabalho e os resultados para maximizar a utilização de recursos. • Define de maneira clara e objetiva papéis e responsabilidades individuais.

• Aumenta a produtividade individual devido aos papéis bem definidos, considerando que a produtividade da equipe aumenta com uma boa coordenação.

Um bom processo de desenvolvimento de software deve:

• Considerar o desenvolvimento de software como uma atividade de negócios de valor agregado e não meramente como uma atividade técnica.

• Garantir que haja uma adição de valor definida para todos os produtos. • Se resguardar contra perda de valor, uma vez que o produto esteja completo. • Fornecer informações de gerenciamento para controle no local do processo.

Para definir um processo, como o ilustrado abaixo, os seguintes passos devem ser seguidos: • Identificar as fases de desenvolvimento e as tarefas a serem executadas em cada uma. • Modelar as transições intra e interfaces.

• Usar técnicas para executar as tarefas.

• Verificar e validar cada tarefa e seus resultados.

• Usar habilidades de gerenciamento de processos e projeto. As palavras verificar e validar precisam ser explicadas.

Considerando que VERIFICAR significa checar se a tarefa foi executada corretamente, VALIDAR significa checar se a tarefa correta foi executada.

No contexto de software, o processo de checar se um algoritmo foi implementado corretamente, é verificação, enquanto o processo de checar se o resultado da execução do algoritmo é a solução do problema, é validação.

As fases genéricas que normalmente são usadas em um processo de desenvolvimento de software são:

• Análise

Nesta fase, as necessidades do usuário são reunidas e convertidas em requisitos de software. Por exemplo, se o usuário precisa gerar a trajetória de um míssil, um requisito de software é resolver as equações regentes. Essa fase deve responder à pergunta: O que precisa ser feito para atender às necessidades do usuário?

• Projeto

Esta fase responde à pergunta: O que precisa ser feito para atender às necessidades do usuário? Com relação ao exemplo anterior, o projeto consiste na tomada de decisões sobre o algoritmo a ser usado para solucionar as equações regentes. Essa escolha depende dos objetivos do projeto, como tempo de execução, precisão etc. Nessa fase nós decidimos sobre a organização dos vários módulos do sistema de software.

• Construção

Codificação e teste do módulo são as principais atividades nesta fase. • Teste

(7)

Existem três categorias de teste: de unidade, de integração e de sistema.

Existem dois tipos de teste: da caixa preta e da caixa branca. O teste da caixa preta se concentra em gerar casos de testes com base em requisitos. O teste da caixa branca se concentra em gerar casos de teste com base na lógica interna de vários módulos.

• Implementação

Esta fase consiste em entregar o software aos clientes (de instalação e operacionalização).

Módulo 04 – Modelos de Ciclos de Vida

Na prática, são usados dois tipos de modelos de ciclo de vida de software, são eles: • Sequencial

• Interativo

• Modelo sequencial

Também conhecido como modelo cascata (ou cachoeira), pode ser exibido de forma ilustrativa, como se vê na imagem abaixo:

Ele representa o processo de desenvolvimento como uma sequência de fases, exigindo que uma fase específica seja concluída antes da próxima ser iniciada.

Devido ao reconhecimento de fases e sequenciamento, ele ajuda na finalização do contrato com referência a entrega e planos de pagamento.

(8)

Na prática, é difícil usar este modelo como ele é, devido incerteza nos requisitos de software, que a priori, são difíceis de prever.

Se um erro no entendimento dos requisitos for detectado durante a fase de codificação, o processo todo deverá ser reiniciado. Uma versão de trabalho do software não estará disponível até o final do ciclo de vida do projeto. Logo, a iteração dentro de uma fase e entre fases é uma necessidade.

• Prototipagem

A prototipagem é discutida na literatura como uma abordagem separada do desenvolvimento de software. Como o nome sugere, exige que uma versão de trabalho do software seja desenvolvida logo no início de projeto. Existem dois tipos de prototipagem, são eles:

o Protótipo descartável

O objetivo do protótipo descartável é entender os requisitos e as melhores metodologias de solução. A essência é velocidade. Desta forma, recorre-se a uma abordagem de desenvolvimento rápida e específica sem ênfase na qualidade. É semelhante ao ‘codificar e testar’. No entanto, uma vez tendo atingido o objetivo, o código é descartado e um novo desenvolvimento é iniciado, garantindo que os padrões de qualidade sejam atendidos. Uma vez bem entendidos os requisitos, pode-se usar a abordagem sequencial.

o Protótipo evolutivo

No protótipo evolutivo, os requisitos são priorizados e o código é desenvolvido inicialmente para os mais importantes, sempre com foco na qualidade. O software é constantemente refinado em forte colaboração com o cliente.

Finalmente, a principal vantagem dos protótipos está no fato de que o cliente consegue ter uma visão do produto logo no início do ciclo de vida do projeto.

Como podemos ver, a prototipagem evolucionária é um modelo iterativo. Um modelo como esse pode ser caracterizado por fazer análise mínima, projeto, código, teste e por repetir o ciclo até a conclusão do produto.

• Modelo Espiral

Barry Boehm sugeriu um modelo iterativo chamado Modelo Espiral. É como uma estrutura que precisa ser adaptada a projetos específicos.

Ele permite a melhor combinação de várias abordagens e se concentra na eliminação antecipada de erros e alternativas inviáveis. Uma característica importante deste modelo é, no entanto, a ênfase em análise de risco.

Uma vez identificados os objetivos, alternativas e restrições de uma fase, os riscos envolvidos na sua execução são avaliados, resultando em uma decisão "ir, não ir".

Para fins de avaliação, se pode usar prototipagem, simulações etc. Esse modelo é mais adequado para projetos que envolvam o desenvolvimento de novas tecnologias. Especialização em análise de risco é mais importante para esses projetos.

(9)

• Modelo ETVX

A IBM lançou o modelo ETVX (durante os anos 80) para documentar seus processos. ‘E’ são os critérios de entrada que precisam ser satisfeitos antes da execução de um conjunto de tarefas, ‘T’ é o conjunto de tarefas a serem executadas, ‘V’ é o processo de verificação para garantir que as tarefas sejam executadas corretamente e ‘X’ são os critérios de saída ou os resultados das tarefas. Se uma atividade falhar na checagem de verificação, uma ação corretiva é tomada ou um retrabalho é solicitado. Esse modelo pode ser usado em qualquer processo de desenvolvimento. Cada fase no processo pode ser considerada como uma atividade e estruturada usando o modelo ETVX. Se necessário, as tarefas podem ser subdivididas.

• Modelo de Processo Unificado Racional (RUP)

Entre os modelos modernos de processo, o Processo Racional Unificado (Rational Unified Process – RUP) desenvolvido pela Rational Corporation é digno de consideração. É um modelo iterativo que captura muitas das melhores práticas do moderno desenvolvimento de software.

(10)

• Modelo de Processo Unificado Racional (RUP)

Todas as metodologias descritas anteriormente são baseadas na premissa de que qualquer processo de desenvolvimento de software deve ser previsível e repetível. Uma das críticas contra essas metodologias é que:

o Há ênfase sobre procedimentos e preparação da documentação. o São consideradas pesadas ou rigorosas.

o Enfatizam excessivamente a estrutura.

Por exemplo, o conjunto de todos os requisitos de software não pode ser conhecido no início do projeto, nem pode permanecer estático. Se o modelo não puder lidar com este dinamismo, pode haver muita perda de esforço ou o produto final pode não atender às necessidades do cliente. Um movimento chamado de Movimento de Software Ágil, está questionando essa premissa. Os proponentes argumentam que o desenvolvimento de software, sendo essencialmente uma atividade humana, terá sempre variações em processos e entradas. O modelo deve, portanto, ser flexível o bastante para lidar com as variações.

Deste modo, as metodologias ágeis defendem o princípio da “construção curta, construção frequente”, ou seja, o projeto é dividido em subprojetos e cada subprojeto é desenvolvido e integrado ao sistema já entregue.

Assim, o cliente recebe constantemente sistemas úteis e utilizáveis. Os subprojetos são escolhidos para que tenham ciclos de entrega curtos, geralmente da ordem de 3 a 4 semanas. A equipe de desenvolvimento também recebe feedback constante.

Uma série de metodologias ágeis foram propostas. As mais populares entre elas são:

o SCRUM: Estrutura de gerenciamento de projeto. Ela divide o desenvolvimento em ciclos curtos chamados de ciclos rápidos nos quais um conjunto específico de recursos é fornecido. Ela defende reuniões diárias de equipe para coordenação e integração.

o MÉTODO DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS (DYNAMIC SYSTEMS DEVELOPMENT METHOD – DSDM): é caracterizado por nove princípios:

 Envolvimento ativo do usuário  Força de equipe

 Entrega frequente de produtos

 Adequação para o propósito do negócio  Desenvolvimento iterativo e incremental

 Todas as mudanças durante o desenvolvimento são reversíveis  Base de exigências a um alto nível

 Teste integrado

 Colaboração e cooperação entre interessados

o MÉTODOS CRYSTAL: conjunto de metodologias configuráveis. Elas focam nos aspectos de desenvolvimento das pessoas. A configuração é executada com base no tamanho, urgência e objetivos do projeto. Alguns dos nomes usados para as metodologias são Claro (Clear), Amarelo (Yellow), Laranja (Orange), Orange web, Vermelho (Red) etc.

o DESENVOLVIMENTO VOLTADO A RECURSO: estrutura curta de iteração para desenvolvimento de software. Ela foca na construção de um modelo de objeto, lista de recurso de construção, plano, projeto e construção por recurso.

o DESENVOLVIMENTO ENXUTO (LEAN DEVELOPMENT – LD): esta metodologia deriva de princípios de produção enxuta, a reestruturação da indústria manufatureira automobilística

(11)

japonesa que ocorreu na década de 80. Ela se baseia nos seguintes princípios do pensamento enxuto:

 Eliminar desperdícios  Ampliar o aprendizado  Decidir o mais tarde possível  Entregar o mais rápido possível  Capacitar a equipe

 Construir a integridade  Enxergar o todo

o PROGRAMAÇÃO EXTREME (EXTREME PROGRAMMING – XP): esta metodologia é provavelmente a mais popular entre as metodologias ágeis. Ela se baseia em três princípios importantes: testar primeiro, reestruturar continuamente e programar em par.

Um dos conceitos mais importantes popularizados pela Programação Extreme (XP) é a programação em par. O código é sempre desenvolvido em pares. Enquanto uma pessoa insere o código, a outra revisa. Este site é dedicado à programação em par. O trabalho por Laurie Williams et al., demonstra a eficácia da programação em par.

Módulo 05 – Como escolher um Processo

Entre a abundância de processos disponíveis, como podemos escolher um? Não há uma única resposta para essa pergunta. Provavelmente, a melhor maneira de resolver este problema é olhando para os requisitos de software.

Definição de problema Processo recomendado

Estável e bem compreendido Modelo Cachoeira Estável, mas não claro Protótipo descartável Requisitos em mudança Protótipo evolutivo Requisitos ligados aos processos de negócios

adjacentes, que estão passando por mudanças Espiral de Boehm (RUP) Ambiente de negócios dinâmicos, onde o

"tempo de mercado" é crítico e o tamanho do projeto é relativamente pequeno.

Metodologia ágil

Estas são apenas diretrizes. Muitas organizações escolhem um modelo e o adaptam às suas exigências de negócios. Por exemplo, algumas organizações usam o modelo Cachoeira modificado para incluir iterações dentro de fases.

Conclusão

A lição mais importante deste curso é a de que o desenvolvimento de software deve seguir um processo disciplinado. A escolha do processo, no entanto, dependerá da estabilidade dos requisitos, da integralidade dos requisitos, dos processos de negócios adjacentes, da estrutura organizacional e do ambiente de negócios prevalecente.

(12)

Referências

"An Integrated Approach to Software Engineering", de Pankaj Jalote, Springer-Verlag. "Software Engineering: A Pratictioner's Approach", de Roger S. Pressman, McGraw-Hill, Inc. "Software Engineering", de Ian Sommerville, Addison-Wesley Publishing Company.

"The Rational Unified Process, An Introduction", de Philippe Krutchen, Addison-Wesley Publishing Company.

Imagem

Referências