2. Aula 3 – Processos de
Software
Gestão de Times –
Métodos Ágeis
Prof. David Wilber Silva Daltro
3. Processos de Software
Um processo de software é um conjunto de atividades relacionadas que levam à produção de um sistema
de software.
Existem muitos tipos diferentes de sistemas de software, porém, não há um método universal de
engenharia de software que seja aplicável a todos eles.
Consequentemente, não existem processos de software universalmente aplicáveis. O processo utilizado nas
diferentes empresas depende do tipo de software que está sendo desenvolvido, dos requisitos do cliente e
das habilidades das pessoas que o desenvolvem.
4. Processos de Software
No entanto, embora existam muitos processos de software diferentes, todos eles devem incluir. de alguma
forma. as quatro atividades fundamentais da engenharia de software:
• Especificação - A funcionalidade do software e as restrições sobre sua operação devem ser definidas
• Desenvolvimento - O software deve ser produzido para atender à especificação.
• Validação - O software deve ser validado para garantir que atenda ao que o cliente deseja.
• Evolução - O software deve evoluir para atender às mudanças nas necessidades dos clientes.
5. Processos de Software
Quando descrevemos e discutimos os processos, normalmente falamos sobre as atividades nesses
processos - especificar um modelo de dados e projetar uma interface com o usuário, por exemplo - e sobre
a sequência correta dessas atividades.
Podemos identificar o que as pessoas fazem para desenvolver um software, mas, quando se trata de
processos de software, é importante descrever também quem está envolvido, o que está sendo produzido e
quais condições influenciam a sequência dessas atividades.
6. Processos de Software
Os processos de software são complexos e, como processos intelectuais e criativos, dependem da tomada
de decisão e do julgamento das pessoas. Uma vez que não existe um processo universal que valha para
todos os tipos de software, a maioria das empresas produtoras de software concebeu seus próprios
processos de desenvolvimento.
Estes evoluíram e passaram a aproveitar a capacidade dos desenvolvedores de software em uma
organização e as características dos sistemas que estão sendo desenvolvidos. No caso dos sistemas críticos
em segurança, é necessário um processo de desenvolvimento muito estruturado e que registros
detalhados sejam mantidos. Nos sistemas de negócio, com requisitos que mudam rapidamente, talvez seja
melhor adotar um processo mais flexível e ágil.
7. Processos de Software
Embora não haja um processo de software universal, há espaço para a melhoria dos processos em muitas
organizações. Os processos podem incluir técnicas ultrapassadas ou não tirar proveito da prática mais
recomendada na engenharia de software industrial. Na realidade, durante seus processos de
desenvolvimento, muitas organizações ainda não se valem dos métodos de engenharia de software.
8. Modelos de Processo de
Software
Um modelo de processo de software - às vezes chamado de ciclo de vida do desenvolvimento de software
(ou modelo SDLC, do inglês Software Development Life Cycle) - é uma representação simplificada de um
processo de software. Cada modelo representa um processo a partir de uma perspectiva particular e, desse
modo, fornece apenas informações parciais sobre esse processo.
9. Modelos de Processo de
Software
Por exemplo, um modelo de atividades do processo mostra as atividades e sua sequência, mas não os
papéis das pessoas envolvidas nelas. Veremos uma série de modelos de processo bem genéricos (às vezes
chamados de paradigmas de processo) partindo de urna perspectiva arquitetural, ou seja, vemos a
estrutura do processo, mas não os detalhes de suas atividades.
10. Modelos de Processo de
Software
Os principais modelos genéricos são:
• Modelo em cascata - Representa as atividades fundamentais do processo. como especificação,
desenvolvimento, validação e evolução, na forma de fases de processo distintas, como especificação de
requisitos, projeto de software, implementação e testes
• Desenvolvimento incremental - Intercala as atividades de especificação, desenvolvimento e validação. O
sistema é desenvolvido como uma série de versões (incrementos), com cada uma delas acrescentando
funcionalidade à versão anterior.
• Integração e configuração - Baseia-se na disponibilidade de componentes ou sistemas reusáveis. O
processo de desenvolvimento de sistemas se concentra na configuração desses componentes. para que
sejam utilizados em um novo contexto, e na integração deles em um sistema.
11. Modelos de Processo de
Software
Como dito anteriormente, não existe modelo de processo universal aplicável a todos os tipos de
desenvolvimento de software. O processo correto depende do cliente e dos requisitos que regulam o
software, do ambiente em que esse software será utilizado e do tipo de software que está sendo
desenvolvido.
Os sistemas críticos em segurança, por exemplo, são normalmente desenvolvidos a partir de um processo
em cascata, já que é necessária uma grande quantidade de análise e de documentação antes de começar
sua implementação. Por sua vez, os produtos de software são, atualmente, desenvolvidos a partir de um
modelo de processo incremental. Os sistemas de negócio são desenvolvidos, cada vez mais, por meio da
configuração dos sistemas preexistentes e da integração entre eles, a fim de criar um novo sistema com a
funcionalidade exigida.
12. Modelos de Processo de
Software
Na prática, a maior parte dos processos de software se baseia em um modelo genérico, mas
frequentemente incorpora características de outros modelos. Isso vale particularmente para a engenharia
dos grandes sistemas. Neles, faz sentido combinar algumas das melhores características de todos os
processos genéricos.
13. Modelos de Processo de
Software
É preciso ter informações sobre os requisitos de sistema essenciais para projetar uma arquitetura de
software que apoie esses requisitos, e não dá para desenvolver isso de modo incremental.
Os subsistemas dentro de um sistema maior podem ser desenvolvidos por meio de abordagens diferentes
partes do sistema que sejam bem compreendidas podem ser especificadas e desenvolvidas usando um
processo em cascata ou podem ser adquiridas como sistemas de prateleira para configuração. Outras
partes do sistema, difíceis de especificar antecipadamente, devem ser sempre desenvolvidas a partir de
uma abordagem incremental. Em ambos os casos, os componentes de software provavelmente serão
reusados.
14. Modelos de Processo de
Software
Várias tentativas têm sido feitas para desenvolver modelos de processo "universais" baseados em todos
esses modelos genéricos. Um dos mais conhecidos é o Rational Unified Process - RUP, que foi desenvolvido
pela Rational, uma empresa de engenharia de software norte-americana.
O RUP é um modelo flexível, que pode ser instanciado de diferentes maneiras para criar processos que se
assemelhem a qualquer um dos modelos de processo genéricos discutidos aqui. O RUP foi adotado por
algumas grandes empresas de software (principalmente pela IBM - International Business Machines
Corporation), nas não conquistou uma ampla aceitação.
15. O Modelo em Cascata
O primeiro modelo de processo de desenvolvimento de software a ser publicado é derivado dos modelos
utilizados na engenharia de grandes sistemas militares. Ele apresenta o processo de desenvolvimento de
software como uma série de estágios.
Devido à cascata de uma fase para outra, esse modelo é conhecido como modelo em cascata ou ciclo de
vida do software.
O modelo em cascata é um exemplo de processo dirigido por plano. A principio, pelo menos, é necessário
planejar e criar um cronograma de todas as atividades de processo antes de começar o desenvolvimento
do software.
16. O Modelo em Cascata
A figura a seguir exemplifica o modelo cascata:
17. O Modelo em Cascata
Os estágios do modelo em cascata refletem diretamente as atividades fundamentais do desenvolvimento
de software:
1. Análise e definição dos requisitos - Os serviços. as restrições e as metas do sistema são estabelecidos
por meio de consulta aos usuários. Depois, eles são definidos em detalhes e servem como uma
especificação do sistema.
2. Projeto do sistema e do software - O processo de projeto do sistema reparte os requisitos entre
requisitos de sistemas de hardware e de software, e estabelece uma arquitetura global do sistema. O
projeto de software envolve a identificação e a descrição das abstrações fundamentais do sistema de
software e seus relacionamentos.
18. O Modelo em Cascata
3. Implementação e teste de unidade - Durante essa etapa, o projeto do software é realizado como um
conjunto de programas ou unidades de programa. O teste de unidade envolve a verificação de cada
unidade. conferindo se satisfazem a sua especificação.
4. Integração e teste de sistema - As unidades de programa ou os programas são integrados e testados
como um sistema completo a fim de garantir que os requisitos de software tenham sido cumpridos.
Após os testes, o sistema de software é entregue ao cliente.
5. Operação e manutenção - Normalmente, essa é a fase mais longa do ciclo de vida. O sistema é instalado
e colocado em uso. A manutenção envolve corrigir os erros que não foram descobertos nas primeiras
fases do ciclo de vida, melhorar a implementação das unidades do sistema e aperfeiçoar os serviços do
sistema à medida que novos requisitos são descobertos.
19. O Modelo em Cascata
A principio, o resultado de cada fase no modelo em cascata consiste em um ou mais documentos que são
aprovados. A fase seguinte não deve começar até que a fase anterior tenha terminado. No
desenvolvimento de hardware, que envolve altos custos de produção, isso faz sentido.
No entanto, no desenvolvimento de software, esses estágios se sobrepõem e alimentam uns aos outros
com informações. Durante o projeto (design), são identificados problemas com os requisitos; durante a
codificação, são encontrados problemas com o projeto, e assim por diante. O processo de software, na
prática, nunca é um modelo linear simples, pois envolve feedback entre as fases.
20. O Modelo em Cascata
A necessidade de comprometimento inicial e retrabalho quando as mudanças são feitas significa que o
modelo em cascata é adequado somente para alguns tipos de sistema. tais como:
Sistemas embarcados - nos quais o software deve interagir com sistemas de hardware. Em virtude da
inflexibilidade do hardware, normalmente não é possível postergar as decisões sobre a funcionalidade do
software até que ele seja implementado.
Sistemas críticos - nos quais há necessidade de ampla análise da segurança (safety) e segurança da
informação (security) da especificação e do projeto do software. Nesses sistemas, os documentos de
especificação e de projeto devem estar completos para que a análise seja possivel. Geralmente, é muito
caro corrigir, durante a fase de implementação, os problemas relacionados à segurança na especificação e
no projeto.
21. O Modelo em Cascata
Grandes sistemas de software - que fazem parte de sistemas de engenharia mais amplos, desenvolvidos
por várias empresas parceiras. O hardware nos sistemas pode ser desenvolvido a partir de um modelo
similar, e as empresas preferem usar um modelo comum para o hardware e o software. Além disso, quando
várias empresas estão envolvidas, podem ser necessárias especificações completas para permitir o
desenvolvimento independente dos diferentes subsistemas.
22. O Modelo em Cascata
Podemos concluir que o modelo em cascata não é recomendado para situações em que a comunicação
informal do time é possível e nas quais os requisitos de software mudam rapidamente Para esses sistemas,
o desenvolvimento iterativo e os métodos ágeis são melhores.
23. Desenvolvimento Incremental
O desenvolvimento incremental se baseia na ideia de desenvolver uma implementação inicial, obter
feedback dos usuários ou terceiros e fazer o software evoluir através de várias versões, até alcançar o
sistema necessário. As atividades de especificação, desenvolvimento e validação são intercaladas, em vez
de separadas, com feedback rápido ao longo de todas elas.
25. Desenvolvimento Incremental
O desenvolvimento incremental, em alguma de suas formas, é atualmente a abordagem mais comum para
o desenvolvimento de aplicações e produtos de software. Essa abordagem pode ser dirigida por plano ou
ágil; na maioria das vezes, uma mistura de ambas. Em uma abordagem dirigida por plano, os incrementos
do sistema são identificados antecipadamente; se for adotada uma abordagem ágil, os incrementos iniciais
são identificados, mas o desenvolvimento dos incrementos finais depende do progresso e das prioridades
do cliente.
26. Desenvolvimento Incremental
O desenvolvimento incremental de software, que é parte fundamental dos métodos ágeis, é melhor do que
urna abordagem em cascata para os sistemas cujos requisitos estão propensos a mudar durante o
processo de desenvolvimento. É o caso da maioria dos sistemas de negócio e dos produtos de software.
O desenvolvimento incremental reflete a maneira como solucionamos os problemas: raramente
elaboramos uma solução completa para os problemas com antecedência: em vez disso, caminhamos para
uma solução em uma série de passos, retrocedendo quando percebemos que cometemos um erro. Ao
desenvolver um software de modo incremental, é mais barato e fácil fazer alterações nele durante o
processo de desenvolvimento.
27. Desenvolvimento Incremental
Cada incremento ou versão do sistema incorpora parte da funcionalidade necessária para o cliente.
Geralmente, os incrementas iniciais incluem a funcionalidade mais importante ou a mais urgente. Isso
significa que o cliente ou usuário pode avaliar o sistema em um estágio relativamente precoce no
desenvolvimento para ver se ele entrega o que é necessário Se não entrega, então o incremento atual
precisa ser alterado e, possivelmente, uma nova funcionalidade deve ser definida para os incrementas
posteriores.
28. Desenvolvimento Incremental
O desenvolvimento incremental tem três grandes vantagens em relação ao modelo em cascata:
1. O custo de implementação das mudanças nos requisitos é reduzido. A quantidade de análise e
documentação que precisa ser refeita é significativamente menor do que a necessária ao modelo em
cascata.
2. É mais fácil obter feedback do cliente sobre o trabalho de desenvolvimento. Os clientes podem
comentar as demonstrações de software e ver o quanto foi implementado. Para eles. é mais difícil julgar
o progresso a partir dos documentos do projeto (design) de software.
3. A entrega e a implantação antecipadas de um software útil para o cliente são passiveis, mesmo se toda
a funcionalidade não tiver sido incluída. Os clientes são capazes de usar o software e de obter valor a
partir dele mais cedo do que com um processo em cascata.
29. Desenvolvimento Incremental
Do ponto de vista da gestão, a abordagem incremental tem dois problemas:
1. O processo não é visível. Os gerentes precisam de resultados regulares para medir o progresso_ Se os
sistemas forem desenvolvidos rapidamente, não é econômico produzir documentos que reflitam cada
versão do sistema.
2. A estrutura do sistema tende a se degradar à medida que novos incrementos são adicionados.
Mudanças regulares deixam o código bagunçado, uma vez que novas funcionalidades são adicionadas
de qualquer maneira possível. Fica cada vez mais difícil e caro adicionar novas características a um
sistema. Para reduzir a degradação estrutural e a bagunça generalizada no código. os métodos ágeis
sugerem que se refatore (melhore e reestruture) o software regularmente.
30. Desenvolvimento Incremental
Cada incremento ou versão do sistema incorpora parte da funcionalidade necessária para o cliente.
Geralmente, os incrementas iniciais incluem a funcionalidade mais importante ou a mais urgente. Isso
significa que o cliente ou usuário pode avaliar o sistema em um estágio relativamente precoce no
desenvolvimento para ver se ele entrega o que é necessário Se não entrega, então o incremento atual
precisa ser alterado e, possivelmente, uma nova funcionalidade deve ser definida para os incrementas
posteriores.
31. Desenvolvimento Incremental
Os problemas do desenvolvimento incremental se tomam particularmente críticos nos sistemas grandes.
complexos e de vida longa, nos quais diferentes times desenvolvem partes distintas do sistema. Os
sistemas grandes precisam de um framework ou de uma arquitetura estáveis, e as responsabilidades dos
diferentes times trabalhando no sistema precisam ser claramente definidas em relação a essa arquitetura.
Isso deve ser planejado antecipadamente em vez de desenvolvido de modo incremental.
32. Integração e Configuração
Na maioria dos projetos há algum reuso de software. Com frequência. isso acontece informalmente quando
as pessoas que trabalham no projeto conhecem ou procuram algum código similar ao necessário. Elas
procuram por esse código, modificam-no conforme a necessidade e integram-no ao novo código que
desenvolveram.
33. Integração e Configuração
Esse reuso informal ocorre independentemente do processo de desenvolvimento utilizado. No entanto,
desde os anos 2000. processos de desenvolvimento de software que se concentram no reuso de código
existente passaram a ser amplamente utilizados. As abordagens orientadas ao reuso contam com bases de
componentes de software reusáveis e um framework de integração para a composição desses
componentes.
34. Integração e Configuração
Três tipos de componentes de software são reusados frequentemente:
1. Sistemas de aplicação stand-alone configurados para utilização em um ambiente particular. Esses
sistemas são de uso geral e possuem muitas características, mas precisam ser adaptados para uso em
uma aplicação específica.
2. Coleções de objetos desenvolvidos como um componente ou como um pacote a ser integrado a um
framework de componentes.
3. Web services desenvolvidos de acordo com os padrões de serviço e que estão disponíveis para uso
remoto na internet.
35. Integração e Configuração
A figura abaixo mostra um modelo de processo genérico articulado em torno da integração e da
configuração para o desenvolvimento de software baseado no reuso.
36. Integração e Configuração
Os estágios nesse processo são:
1. Especificação dos requisitos - Os requisitos iniciais do sistema são propostos Eles não precisam ser
elaborados em detalhes. mas devem incluir descrições breves dos requisitos essenciais e das
características de sistema desejáveis.
2. Descoberta e avaliação do software - Com base em uma descrição dos requisitos de software, é feita
uma busca pelos componentes e sistemas que fornecem a funcionalidade necessária. Os candidatos
são avaliados para ver se satisfazem os requisitos essenciais e se são genericamente adequados ao uso
no sistema.
37. Integração e Configuração
3. Refinamento dos requisitos - Nesse estágio, os requisitos são definidos com base nas informações dos
componentes reusáveis e das aplicações que foram descobertas. Os requisitos são modificados para
refletir os componentes disponíveis, e a especificação do sistema é redefinida. Onde as modificações
forem impossíveis, a atividade da análise de componentes pode ser reintroduzida para procurar
soluções alternativas.
4. Configuração da aplicação - Se estiver disponível urna aplicação de prateleira que satisfaça os
requisitos, ela pode ser configurada para utilização a fim de criar o novo sistema.
5. Adaptação e integração dos componentes - Se não houver uma aplicação de prateleira. componentes
reusáveis podem ser modificados ou novos componentes podem ser desenvolvidos. visando a
integração posterior ao sistema.
38. Integração e Configuração
A engenharia de software baseada no reuso, articulada em torno da configuração e da integração, tem a
vantagem óbvia de reduzir a quantidade de software a ser desenvolvido, diminuindo custos e riscos.
Normalmente, isso também leva a uma entrega mais rápida do software.
Entretanto, concessões quanto aos requisitos são inevitáveis, o que pode resultar em um sistema que não
satisfaz as necessidades reais dos usuários. Além disso, parte do controle sobre a evolução do sistema se
perde, já que novas versões dos componentes reusáveis não estão sob o controle da organização que os
utiliza.
