Você está na página 1de 12

CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 1

Mdulo 01 - Introduo
Os computadores se tornaram elementos chaves em nossas vidas. Aos poucos, assumiram muitas das
funes que nos afetam de maneira decisiva. Hoje eles controlam a maioria das transaes monetrias,
linhas de produo, transporte, comunicao, sistemas de defesa, sistemas de controle de processo
etc.

Os computadores j so encontrados em quase todas as casas e, em algumas delas, j controlam a


utilizao de todos os aparelhos eletrnicos, coisa vista apenas em filmes, at h um tempo atrs.

No entanto, computadores sozinhos so mquinas (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 to importante, uma
pequena falha tanto no hardware quanto no software pode levar a consequncias desastrosas.

Infelizmente, embora haja processos bem definidos, baseados em fundamentos tericos para garantir
a confiabilidade do hardware, no se pode dizer a mesma coisa sobre software.

Embora ainda no exista uma teoria para desenvolvimento de software, necessrio que o ele se
comporte de maneira previsvel, mesmo em situaes imprevistas. Por essa razo, existe uma
necessidade de gerenciar seu desenvolvimento por meio de um processo bem definido e sistemtico.

A antiga abordagem "codificar e testar" (code & test) no ser suficiente. Ela pode ser boa para
problemas mais simples. No entanto, o software precisa ser projetado de forma a lidar com situaes
extremamente complexas.

Os aspectos cruciais para o sucesso de um projeto de software so:

Esforo de Equipe
Qualquer esforo para o desenvolvimento de softwares exige uma equipe de especialistas. Por
exemplo, a equipe pode ser composta por especialistas em domnios, projetos, codificao, testes
e hardware.
Cada grupo de especialistas deve se concentrar em um aspecto especfico do problema e
apresentar uma soluo adequada. No entanto, nenhum grupo pode trabalhar isoladamente, pois
a interao entre os membros das equipes importantssima.

Metodologia
Existem dois tipos de metodologias de desenvolvimento:
Voltada ao procedimento
Voltada ao objeto
Embora, teoricamente, ambas possam ser usadas em qualquer situao de problema, uma delas
deve ser selecionada antecipadamente.

Documentao
Uma documentao clara, objetiva e precisa dos componentes do processo de desenvolvimento,
crucial para o sucesso de qualquer projeto de software.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 2

Comunicao verbal e desenhos do pacote no so suficientes para se entender tal processo. Por
exemplo, a documentao essencial para a aprovao do cliente em vrias etapas do processo.
Uma vez desenvolvido, o software cria vida. Entretanto, durante sua vida, ele passar por vrias
mudanas e uma documentao bem-feita essencial para a realizao dessas alteraes de
forma mais eficaz.

Planejamento
Assim que o desenvolvimento do software ocorrer de acordo com os requisitos especificados pelo
cliente, necessrio que todo o esforo seja adequadamente estimado para atender as restries
de prazo e custo.

Garantia de Qualidade
Os clientes esperam retorno financeiro com a implantao do software.
Alm de atender s necessidades do cliente, o software deve, necessariamente, atender aos
padres de qualidade que podem ser em relao a desempenho, segurana etc.

Usurios Leigos
Usurios leigos so aqueles que no dominam computao, portanto, o software deve ter uma
interface grfica que favorea seu manuseio.

Ferramentas de Software
A documentao importante para um projeto de desenvolvimento de software, mas uma
tarefa onerosa e muitos desenvolvedores desistem de faz-la.
Existem ferramentas que so conhecidas como ferramentas de Engenharia de Software Assistida
por Computador (Computer Aided Software Engineering CASE) que simplificam o processo da
documentao.

Conformidade com os Padres


Os padres so necessrios para garantir uma documentao clara, objetiva e sem ambiguidades.
Por exemplo, padres IEEE para especificaes de requisitos, projetos etc.
Tambm possvel que um cliente especifique os padres a serem usados.

Reutilizao
O esforo de desenvolvimento pode ser otimizado, reutilizando-se componentes j testados,
como por exemplo, bibliotecas matemticas, kits de ferramentas de interface grficas etc.

Manuteno de Software
Todo software precisa ser modificado periodicamente, de acordo com as solicitaes dos clientes
e do uso de novas tecnologias.
A equipe de desenvolvimento pode no estar disponvel para realizar a manuteno do pacote.
Portanto, uma equipe de suporte dever ser reunida, sempre que necessrio, para garantir que o
software continue a fornecer os servios necessrios.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 3

Gerenciamento de Alteraes
Sempre que uma alterao deva ser realizada, necessrio estudar seu impacto sobre os vrios
componentes do software.
Por exemplo, ao modificar o tipo da varivel denominada Global, toda funo 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 Verso
O software est propenso a frequentes alteraes durante seu desenvolvimento. Portanto,
importante que o usurio obtenha a verso mais recente.
No caso de falhas, ser possvel recorrer s verses anteriores.

Gerenciamento de Riscos
Todo esforo de desenvolvimento de software est sujeito a riscos. Por exemplo,
indisponibilidade de especialistas, tecnologia, recursos etc.
necessrio, portanto, avaliar constantemente os riscos e criar medidas para reduzi-los.

Mdulo 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 vrias maneiras, como por exemplo:

Adequao ao propsito
Zero defeito
Conformidade e segurana
Atendimento necessidade definida e implcita do cliente

Alguns dos atributos importantes que podem ser usados para medir a qualidade do software so:

Preciso
O software deve atender s necessidades do cliente.

Confiabilidade
O software deve se comportar sempre de maneira previsvel, mesmo quando entradas
equivocadas/aleatrias so dadas.

Usabilidade
Facilidade para se usar. Um software com uma boa interface grfica, deixa o usurio mais
vontade para utiliz-lo.

Portabilidade
A facilidade com a qual um software pode ser movido de uma plataforma para outra.

Eficincia
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 4

Utilizao ideal de recurso (memria e tempo de execuo).

Manuteno
Facilidade com a qual o software pode ser modificado.

Flexibilidade
Facilidade com a qual o software pode ser adaptado para uso em diferentes contextos.

Segurana
Preveno de acesso no autorizado.

Interoperabilidade
A capacidade de integrao do software com sistemas existentes.

Desempenho
A capacidade do software de fornecer os resultados com diferentes restries como tempo,
preciso, uso de memria.

De todos atributos apresentados acima, a Preciso o mais importante.

Um software deve ser preciso, mesmo que outros atributos possam ser vlidos em graus que variam.
Por exemplo, um aplicativo no fundamental pode deixar de garantir 100% de confiabilidade, como
um processador de texto. J para um sistema de monitoramento de sade, 100% de preciso
necessria.

No entanto, a deciso final do cliente.

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

Pode-se recorrer ao uso de recursos dependentes em um sistema de maneira a melhorar a eficincia,


mas apenas a custo da portabilidade. Nos bons e velhos tempos, quando o DOS dominava o mundo,
era possvel acessar a arquitetura interna diretamente, de modo a melhorar o desempenho. No
entanto, para suportar esse programa em qualquer outra plataforma, eram necessrias mudanas
drsticas.

Mdulo 03 O que um Processo?


Vamos tentar um pequeno exerccio:

Comece a ler a passagem na figura abaixo. Conforme voc a l, conte as ocorrncias da letra 'F'.
Uma vez terminada a leitura, coloque a quantidade de ocorrncias na caixa.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 5

Neste exerccio, o PROCESSO era perguntar para Codificar e Testar.

Agora vamos definir um PROCESSO que REPETVEL e MENSURVEL.

Comece a ler a primeira linha da passagem, contando as ocorrncias da letra F na referida linha e
insira a quantidade de ocorrncias 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 repetvel porque o mesmo usado para todas as linhas,
podendo ser usado em situaes similares. Ele tambm mensurvel porque possvel parar a
contagem em qualquer ponto e descobrir o quanto trabalho foi concludo e quanto ainda precisa ser
feito.

Assim, temos que um processo uma srie de tarefas definveis, repetveis e mensurveis que levam
a um resultado til.

Um processo bem definido possui muitas vantagens, so elas:

Facilita a visualizao de um projeto, auxiliando nas correes peridicas.


Ajuda os desenvolvedores a eliminar problemas no momento de sua implantao, evitando,
assim, efeitos cascata.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 6

Ajuda a organizar o fluxo de trabalho e os resultados para maximizar a utilizao de recursos.


Define de maneira clara e objetiva papis e responsabilidades individuais.
Aumenta a produtividade individual devido aos papis bem definidos, considerando que a
produtividade da equipe aumenta com uma boa coordenao.

Um bom processo de desenvolvimento de software deve:

Considerar o desenvolvimento de software como uma atividade de negcios de valor agregado e


no meramente como uma atividade tcnica.
Garantir que haja uma adio de valor definida para todos os produtos.
Se resguardar contra perda de valor, uma vez que o produto esteja completo.
Fornecer informaes 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 transies intra e interfaces.
Usar tcnicas 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,


verificao, enquanto o processo de checar se o resultado da execuo do algoritmo a soluo do
problema, validao.

As fases genricas que normalmente so usadas em um processo de desenvolvimento de software


so:

Anlise
Nesta fase, as necessidades do usurio so reunidas e convertidas em requisitos de software. Por
exemplo, se o usurio precisa gerar a trajetria de um mssil, um requisito de software resolver
as equaes regentes. Essa fase deve responder pergunta: O que precisa ser feito para atender
s necessidades do usurio?

Projeto
Esta fase responde pergunta: O que precisa ser feito para atender s necessidades do usurio?
Com relao ao exemplo anterior, o projeto consiste na tomada de decises sobre o algoritmo a
ser usado para solucionar as equaes regentes. Essa escolha depende dos objetivos do projeto,
como tempo de execuo, preciso etc. Nessa fase ns decidimos sobre a organizao dos vrios
mdulos do sistema de software.

Construo
Codificao e teste do mdulo so as principais atividades nesta fase.

Teste
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 7

Existem trs categorias de teste: de unidade, de integrao 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 lgica interna de vrios mdulos.

Implementao
Esta fase consiste em entregar o software aos clientes (de instalao e operacionalizao).

Mdulo 04 Modelos de Ciclos de Vida


Na prtica, so usados dois tipos de modelos de ciclo de vida de software, so eles:

Sequencial
Interativo

Modelo sequencial
Tambm 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 sequncia de fases, exigindo que uma
fase especfica seja concluda antes da prxima ser iniciada.
Devido ao reconhecimento de fases e sequenciamento, ele ajuda na finalizao do contrato com
referncia a entrega e planos de pagamento.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 8

Na prtica, difcil usar este modelo como ele , devido incerteza nos requisitos de software, que
a priori, so difceis de prever.
Se um erro no entendimento dos requisitos for detectado durante a fase de codificao, o
processo todo dever ser reiniciado. Uma verso de trabalho do software no estar disponvel
at o final do ciclo de vida do projeto. Logo, a iterao 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 verso de trabalho do software seja desenvolvida
logo no incio de projeto. Existem dois tipos de prototipagem, so eles:
o Prottipo descartvel
O objetivo do prottipo descartvel entender os requisitos e as melhores metodologias de
soluo. A essncia velocidade. Desta forma, recorre-se a uma abordagem de
desenvolvimento rpida e especfica sem nfase na qualidade. semelhante ao codificar e
testar. No entanto, uma vez tendo atingido o objetivo, o cdigo descartado e um novo
desenvolvimento iniciado, garantindo que os padres de qualidade sejam atendidos. Uma
vez bem entendidos os requisitos, pode-se usar a abordagem sequencial.
o Prottipo evolutivo
No prottipo evolutivo, os requisitos so priorizados e o cdigo desenvolvido inicialmente
para os mais importantes, sempre com foco na qualidade. O software constantemente
refinado em forte colaborao com o cliente.
Finalmente, a principal vantagem dos prottipos est no fato de que o cliente consegue ter uma
viso do produto logo no incio do ciclo de vida do projeto.
Como podemos ver, a prototipagem evolucionria um modelo iterativo. Um modelo como esse
pode ser caracterizado por fazer anlise mnima, projeto, cdigo, teste e por repetir o ciclo at a
concluso do produto.

Modelo Espiral
Barry Boehm sugeriu um modelo iterativo chamado Modelo Espiral. como uma estrutura que
precisa ser adaptada a projetos especficos.
Ele permite a melhor combinao de vrias abordagens e se concentra na eliminao antecipada
de erros e alternativas inviveis. Uma caracterstica importante deste modelo , no entanto, a
nfase em anlise de risco.
Uma vez identificados os objetivos, alternativas e restries de uma fase, os riscos envolvidos na
sua execuo so avaliados, resultando em uma deciso "ir, no ir".
Para fins de avaliao, se pode usar prototipagem, simulaes etc. Esse modelo mais adequado
para projetos que envolvam o desenvolvimento de novas tecnologias. Especializao em anlise
de risco mais importante para esses projetos.
Veja na ilustrao a seguir.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 9

Modelo ETVX
A IBM lanou o modelo ETVX (durante os anos 80) para documentar seus processos. E so os
critrios de entrada que precisam ser satisfeitos antes da execuo de um conjunto de tarefas, T
o conjunto de tarefas a serem executadas, V o processo de verificao para garantir que as
tarefas sejam executadas corretamente e X so os critrios de sada ou os resultados das tarefas.
Se uma atividade falhar na checagem de verificao, uma ao 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 necessrio, 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 considerao. um modelo iterativo
que captura muitas das melhores prticas do moderno desenvolvimento de software.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 10

Modelo de Processo Unificado Racional (RUP)


Todas as metodologias descritas anteriormente so baseadas na premissa de que qualquer
processo de desenvolvimento de software deve ser previsvel e repetvel. Uma das crticas contra
essas metodologias que:
o H nfase sobre procedimentos e preparao da documentao.
o So consideradas pesadas ou rigorosas.
o Enfatizam excessivamente a estrutura.
Por exemplo, o conjunto de todos os requisitos de software no pode ser conhecido no incio do
projeto, nem pode permanecer esttico. Se o modelo no puder lidar com este dinamismo, pode
haver muita perda de esforo ou o produto final pode no 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 variaes em processos e entradas. O modelo deve, portanto, ser
flexvel o bastante para lidar com as variaes.
Deste modo, as metodologias geis defendem o princpio da construo curta, construo
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 utilizveis. Os subprojetos so escolhidos
para que tenham ciclos de entrega curtos, geralmente da ordem de 3 a 4 semanas. A equipe de
desenvolvimento tambm recebe feedback constante.
Uma srie de metodologias geis foram propostas. As mais populares entre elas so:
o SCRUM: Estrutura de gerenciamento de projeto. Ela divide o desenvolvimento em ciclos curtos
chamados de ciclos rpidos nos quais um conjunto especfico de recursos fornecido. Ela
defende reunies dirias de equipe para coordenao e integrao.
o MTODO DE DESENVOLVIMENTO DE SISTEMAS DINMICOS (DYNAMIC SYSTEMS
DEVELOPMENT METHOD DSDM): caracterizado por nove princpios:
Envolvimento ativo do usurio
Fora de equipe
Entrega frequente de produtos
Adequao para o propsito do negcio
Desenvolvimento iterativo e incremental
Todas as mudanas durante o desenvolvimento so reversveis
Base de exigncias a um alto nvel
Teste integrado
Colaborao e cooperao entre interessados
o MTODOS CRYSTAL: conjunto de metodologias configurveis. Elas focam nos aspectos de
desenvolvimento das pessoas. A configurao executada com base no tamanho, urgncia e
objetivos do projeto. Alguns dos nomes usados para as metodologias so Claro (Clear),
Amarelo (Yellow), Laranja (Orange), Orange web, Vermelho (Red) etc.
o DESENVOLVIMENTO VOLTADO A RECURSO: estrutura curta de iterao para desenvolvimento
de software. Ela foca na construo de um modelo de objeto, lista de recurso de construo,
plano, projeto e construo por recurso.
o DESENVOLVIMENTO ENXUTO (LEAN DEVELOPMENT LD): esta metodologia deriva de
princpios de produo enxuta, a reestruturao da indstria manufatureira automobilstica
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 11

japonesa que ocorreu na dcada de 80. Ela se baseia nos seguintes princpios do pensamento
enxuto:
Eliminar desperdcios
Ampliar o aprendizado
Decidir o mais tarde possvel
Entregar o mais rpido possvel
Capacitar a equipe
Construir a integridade
Enxergar o todo
o PROGRAMAO EXTREME (EXTREME PROGRAMMING XP): esta metodologia
provavelmente a mais popular entre as metodologias geis. Ela se baseia em trs princpios
importantes: testar primeiro, reestruturar continuamente e programar em par.
Um dos conceitos mais importantes popularizados pela Programao Extreme (XP) a
programao em par. O cdigo sempre desenvolvido em pares. Enquanto uma pessoa insere
o cdigo, a outra revisa. Este site dedicado programao em par. O trabalho por Laurie
Williams et al., demonstra a eficcia da programao em par.

Mdulo 05 Como escolher um Processo


Entre a abundncia de processos disponveis, como podemos escolher um? No h uma nica resposta
para essa pergunta. Provavelmente, a melhor maneira de resolver este problema olhando para os
requisitos de software.

Definio de problema Processo recomendado


Estvel e bem compreendido Modelo Cachoeira
Estvel, mas no claro Prottipo descartvel
Requisitos em mudana Prottipo evolutivo
Requisitos ligados aos processos de negcios
Espiral de Boehm (RUP)
adjacentes, que esto passando por mudanas
Ambiente de negcios dinmicos, onde o
"tempo de mercado" crtico e o tamanho do Metodologia gil
projeto relativamente pequeno.

Estas so apenas diretrizes. Muitas organizaes escolhem um modelo e o adaptam s suas exigncias
de negcios. Por exemplo, algumas organizaes usam o modelo Cachoeira modificado para incluir
iteraes dentro de fases.

Concluso
A lio 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 negcios adjacentes, da estrutura organizacional e
do ambiente de negcios prevalecente.
CURSO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 12

Referncias

"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.

"Agile Software Development Ecosystems", de Jim Highsmith, Addison-Wesley Publishing Company.