Unidade II - Processos de Software
Unidade II - Processos de Software
Unidade II - Processos de Software
Material Teórico
Processos de software
Revisão Textual:
Prof.ª Me. Luciene Oliveira da Costa Santos
Processos de software
• Introdução
Organize-se de forma a não deixar para o último dia a realização das atividades (AS e AP), pois
podem ocorrer imprevistos. Lembre-se de que, após o encerramento da Unidade, encerra-se a
possibilidade de obter a nota relativa a cada atividade.
Para ampliar seu conhecimento, bem como aprofundar os assuntos discutidos, pesquise, leia e
consulte os livros indicados nas Referências e/ou na Bibliografia.
As Referências estão indicadas ao final dos textos de conteúdo de cada Unidade.
A Bibliografia Fundamental para esta Disciplina é: SOMMERVILLE, Ian. Engenharia de Software. 9.
ed.São Paulo: Pearson, 2011. A Bibliografia Complementar está indicada em item específico, em cada
unidade.
Caso ocorram dúvidas, contate o professor tutor por meio do Fórum de Dúvidas, local ideal para
esclarecê-las, pois assim a explicação poderá ser compartilhada por todos.
Existe, ainda, a possibilidade de contatar o professor pelo link mensagens, caso seja algum assunto relativo
somente a você, e não uma dúvida sobre a matéria, que pode ser também dúvida de outros alunos.
Fique atento(a) quanto a possíveis dúvidas e problemas, lembrando-se de que o professor tutor está
à sua disposição para resolver assuntos pedagógicos, isto é, dúvidas quanto ao conteúdo da matéria.
Se suas dúvidas ou problemas se referirem ao sistema, aos programas etc., contate o Suporte ou
procure auxílio de um monitor no webclass de seu campus.
5
Unidade: Processos de software
Contextualização
6
1. Introdução
ware
Um processo de soft
é um conjunto de
as
atividades relacionad
ão de
que levam à produç
are
um produto de softw
11, p. 33).
(SOMMERVILLE, 20
Glossário
Cliente: “[...] é a empresa, organização ou pessoa que está pagando para o sistema de software
ser desenvolvido”. (PFLEEGER, 2004, p. 11)
Não existe, segundo Pressman (2006, p. 27), uma única abordagem ou método de produção
de software mágico, que funcione para todos os tipos, o que existe é uma combinação de
métodos abrangentes a todas as etapas relacionadas.
Além disso, é importante e desejável que esses métodos sejam suportados por um conjunto
de ferramentas que permita automatizar o desenrolar das etapas, juntamente com uma definição
clara de critérios de qualidade e produtividade de software. São esses aspectos que caracterizam
de maneira mais influente a disciplina de Engenharia de Software.
7
Unidade: Processos de software
Assim, podemos relembrar com propriedade que Engenharia de Software é uma disciplina
que reúne procedimentos (metodologias), métodos e ferramentas a serem utilizados,
desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser
operacional (existir), visando resolver problemas inerentes ao processo de desenvolvimento e ao
produto de software (PFLEEGER, 2004).
Glossário
Processo de Software: “[...] um arcabouço para as tarefas que são necessárias para construir
softwares de alta qualidade”. (PRESSMAN, 2006, p. 16)
8
2. Modelos de desenvolvimento de software, chamados também
de modelos de processo de software ou paradigmas de software
Glossário
Paradigma da Engenharia de Software: “[...] representa a abordagem ou filosofia em particular
para a construção de software”. (PFLEEGER, 2004, p. 3) Segundo Pressman (1996, p. 33): “[...]
a engenharia de software compreende um conjunto de métodos, ferramentas e procedimentos [...]
estas etapas são muitas vezes citadas como paradigmas de engenharia de software”.
9
Unidade: Processos de software
Na nossa disciplina, por uma questão de tempo, não veremos todos os modelos, mas apenas
os que estão marcados com asteriscos. Por isso é importante que você faça uma pequena
pesquisa sobre outros modelos para conhecê-los.
Ele é o modelo mais antigo e o mais amplamente usado da Engenharia de Software por ter
sido modelado em função do ciclo da Engenharia convencional.
O modelo Cascata, por ter uma ordenação linear nas etapas de desenvolvimento, apresenta
características úteis no processo de desenvolvimento de software, particularmente em razão da
definição de um ordenamento linear das etapas de desenvolvimento.
Como forma de identificar o fim de uma etapa e o início da próxima, existem mecanismos
implementados ao final de cada etapa que serve como balizador para início da próxima. Isso
é feito normalmente através da aplicação de algum método de validação ou verificação, cujo
objetivo é garantir que a saída de uma dada etapa seja coerente com a sua entrada (a qual já é
a saída da etapa precedente).
Isso significa que, ao final de cada etapa realizada, deve existir um resultado (ou saída) a qual
possa ser submetida à atividade de certificação.
10
Segundo Pressman (2006, p. 67), duas diretivas que norteiam o desenvolvimento, segundo
o modelo Cascata, são:
1. Todas as etapas definidas no modelo devem ser realizadas, isto porque, em projetos de grande
complexidade, a realização formal delas vai determinar o sucesso ou não do desenvolvimento.
2. A ordenação das etapas na forma como foi apresentada deve ser rigorosamente respeitada.
Temos sempre que lembrar que os resultados de um processo de desenvolvimento de produto
de software não é apenas o programa executável, mas também toda documentação associada.
Cada fase mostrada na Figura 1 pode gerar resultados que devem ser documentados (processo
e resultados). Alguns desses documentos são: de especificação de requisitos, de projeto do
sistema, de plano e relatório de testes, de codificação ou implementação, de utilização, relatórios
de revisões etc.
Todo modelo tem suas vantagens e desvantagens na sua utilização, e no modelo Cascata não
seria diferente. Vejamos algumas limitações desse modelo:
• Nenhum modelo segue rotinas tão sequenciais quanto almeja.
• No início do processo, não temos todos os requisitos mapeados ou definidos.
• No começo dos projetos, sempre existe uma incerteza. O cliente deve ter paciência, pois
uma versão final do produto só fica pronta e disponível no final do processo.
11
Unidade: Processos de software
Esse modelo tem como objetivo entender os requisitos do usuário para, assim, obter uma
melhor definição dos requisitos do sistema e possibilitar que o desenvolvedor crie um modelo
(protótipo) do software que deve ser construído.
É apropriado para quando o cliente já definiu um conjunto de objetivos gerais para o software,
mas não identificou detalhadamente esses requisitos.
Após criar o protótipo, ele é colocado à disposição do cliente, que vai ajudar na melhor
compreensão do que será o sistema desenvolvido. Além disso, através da manipulação desse
protótipo, é possível validar ou reformular os requisitos para as etapas seguintes do sistema.
Segundo Pressman (2006), o modelo ilustrado na figura 1 apresenta algumas características
interessantes, tais como:
* Através da construção de um protótipo do sistema, é possível demonstrar a
reuzabilidade do mesmo.
* É possível obter uma versão, mesmo que simplificada, do que será o sistema, com um
pequeno investimento inicial.
12
Contribuições:
• Ainda que possam ocorrer problemas, a prototipação é um ciclo de vida eficiente.
• A chave é definir todas as regras (requisitos, processos, métodos, técnicas etc.) logo no
começo do desenvolvimento.
• O cliente e o desenvolvedor devem concordar que o protótipo seja construído para servir
como um mecanismo a fim de definir os requisitos.
• A experiência adquirida no desenvolvimento do protótipo vai ser de extrema utilidade nas
etapas posteriores do desenvolvimento do sistema real, permitindo reduzir certamente o
seu custo, resultando também num sistema melhor concebido.
13
Unidade: Processos de software
Uma das vantagens dessa abordagem é a facilidade em testar o sistema durante cada uma
das fases de desenvolvimento.
Um aspecto interessante desse modelo é a criação de uma lista de controle de projeto. Ela
deve conter todas as etapas a serem realizadas, da concepção à obtenção do sistema final. Ela
vai servir também para medir, num dado nível, o quão distante está da última versão aquela que
será disponibilizada ao cliente.
Esta lista de controle de projeto gerencia todo o desenvolvimento, definindo quais tarefas devem ser
realizadas a cada iteração. Na lista de tarefas, podemos, inclusive, inserir as redefinições de componentes
já implementados, em razão de erros ou problemas detectados numa eventual etapa de análise.
Exemplo:
• O sistema pode exigir a disponibilidade de um hardware que está em desenvolvimento e
cuja data de liberação é incerta.
• Podem ser planejadas pequenas versões de modo a evitar o uso desse hardware.
• O software com funcionalidade parcial pode ser liberado para o cliente.
14
Figura 4 - Modelo Incremental, com a exemplificação das atividades paralelas.
Explore
Faça uma pesquisa em algum dicionário sobre a diferença entre interação e iteração. O conhecimento
e reconhecimento dessa diferença, para você que está estudando sobre Engenharia de Software, é
muito importante.
15
Unidade: Processos de software
16
Observações sobre esse modelo, segundo Sommerville (2006, 2001) e Pfleeger (2004):
• Cada loop no espiral representa uma fase do processo de software. O mais interno está
concentrado nas possibilidades do sistema.
• O próximo loop está concentrado na definição dos requisitos do sistema.
• O loop um pouco mais externo está concentrado no projeto do sistema.
• Engloba as melhores características do ciclo de vida Clássico e da Prototipação,
adicionando um novo elemento: a Análise de Risco.
• Esse modelo segue a abordagem de passos sistemáticos do Ciclo de Vida Clássico,
incorporando-os numa estrutura iterativa que reflete mais claramente o mundo real.
• Usa a Prototipação, em qualquer etapa da evolução do produto, como mecanismo de
redução de riscos.
• É, atualmente, a abordagem mais realística para o desenvolvimento de software em
grande escala.
• Usa uma abordagem que capacita o desenvolvedor e o cliente a entender, perceber e
resolver os riscos em cada etapa evolutiva.
• Pode ser difícil convencer os clientes de que uma abordagem evolutiva é controlável.
• Exige considerável experiência na determinação de riscos e depende dessa experiência
para ter sucesso.
Uma característica importante desse modelo é o fato de que cada ciclo é encerrado por uma
atividade de revisão, na qual todos os produtos do ciclo são avaliados, incluindo o plano para
o próximo passo (ou ciclo).
17
Unidade: Processos de software
Glossário
Métodos de engenharia de software: Segundo Pressman (1996, p. 31): “[...] proporcionam
detalhes de ‘como fazer’ para construir o software. Os métodos envolvem um grande número de
tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos de software e de
sistema, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento,
codificação, teste e manutenção.”
Entretanto, foi percebido que essa abordagem pesada de desenvolvimento, num ambiente
dinâmico e conectado não era adequada. Muito tempo era gasto no processo de planejamento e
análise de requisitos e isso prejudicava algumas etapas, sem contar o atraso no prazo de entrega.
A insatisfação com essa abordagem na década de 1990 foi tão grande que um grupo de
engenheiros de software idealizou uma nova abordagem, a qual foi chamada de Métodos Ágeis.
Esses métodos permitiram que a equipe de desenvolvimento focasse no software em si e não
na documentação do processo. Assim, esse modelo mostrou-se adequado para aqueles cujos
requisitos mudam constantemente durante o processo de desenvolvimento.
Com esse método foi possível executar a entrega de sistemas complexos em tempos menores.
Além disso, quaisquer novos requisitos solicitados têm a possibilidade de inclusão como
alterações de sistema, o que significa a entrega de uma nova versão com tais adequações.
Segundo Sommerville (2011), práticas ágeis enfatizam a importância de se escrever códigos
bem estruturados e investir na sua melhoria. A falta de documentação não deve ser um problema
na manutenção do sistema por meio de uma abordagem ágil.
Entretanto, talvez esse seja o principal problema dessa abordagem, pois manutenção, testes e alterações
de sistemas se tornam extremamente complexos quando não existem documentações disponíveis.
À medida que as características dos softwares, dos desenvolvedores e dos clientes mudam, a
Engenharia de Software procura adaptar seus modelos à nova realidade.
A metodologia Extreme Programming, também conhecida como XP, ou Programação
Extrema, proposta por Kent Beck, em 1998 (TELES, 2004), é um dos mais novos métodos
da Engenharia de Software e é um exemplo de metodologia ágil para desenvolvimento de
software. Por ser um modelo novo e bastante aceito, vejamos a seguir alguns de seus detalhes:
18
O ciclo de vida do XP tem quatro atividades básicas: codificar, testar, escutar e modelar,
demonstradas através de quatro valores: a comunicação, a simplicidade, o feedback e a
coragem (SOMMERVILLE, 2006).
A prática do XP tem comunicação contínua entre o cliente e a equipe, com o objetivo
de criar o melhor relacionamento entre o cliente e desenvolvedor, dando preferência às
conversas pessoais em vez de manter contato através de outros meios. É incentivada também
a comunicação intensa entre desenvolvedores e gerente do projeto. Essa comunicação entre o
cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a
agilidade que merecem, ou seja, a equipe pode codificar uma funcionalidade preocupando-se
apenas com os problemas de hoje e deixar os problemas do futuro para o futuro.
A simplicidade foca sempre no mais simples que possa funcionar, visando minimizar o
código, desprezando funções consideradas necessárias. O importante é ter em mente que os
requisitos são mutáveis. Sendo assim, o interessante no XP é implementar apenas o que é
estritamente necessário.
O contato incessante com o cliente a respeito do projeto é o que se pode chamar de feedback
constante. As informações sobre o código são dadas por teste periódico, os quais indicam erros
tanto individuais quanto do software integrado. O cliente terá sempre uma parte do software
funcional para avaliar.
A grande maioria dos princípios do XP corresponde a práticas de senso comum e que fazem
parte de qualquer processo disciplinado. Por exemplo, simplicidade significa foco nas partes do
sistema que são de alta prioridade e, somente depois, pensar em soluções para problemas que,
até então, não são relevantes (e talvez nunca sejam devido às grandes modificações no sistema),
pois o cliente aprende com o sistema que utiliza e reavalia as suas necessidades, gerando o
feedback para a equipe de desenvolvimento.
As equipes XP acreditam que errar é natural e que falhas no que estava funcionando acontecem
cedo ou tarde. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em
confiança nos seus mecanismos de proteção. A coragem encaixa-se na implantação dos três
valores anteriores. São necessários profissionais comunicativos e com facilidade de se relacionar. A
coragem auxilia a simplicidade, quando a possibilidade de simplificar o software é detectada. Desse
modo, a coragem é necessária para garantir que o feedback do cliente ocorra com frequência, pois
essa abordagem implica a possibilidade de mudanças constantes do produto.
Enfim, no sistema desenvolvido de forma incremental, a equipe está continuamente fazendo a
manutenção do software e criando novas funcionalidades. Por isso a equipe precisa ser corajosa
e acreditar que, utilizando práticas e valores do XP, será capaz de fazer o software evoluir com
segurança e agilidade.
A abordagem tradicional é mais arriscada que a do XP, pois os usuários não têm a chance de
avaliar o software sempre, e o projeto só começa a gerar receita após a conclusão.
Segundo Brooks (1995), é comum o cliente fazer um grande investimento na construção
de um software e este não atender às suas necessidades, levando a um novo projeto para a
construção de outro software que atenda aos anseios dos usuários.
19
Unidade: Processos de software
Por todas essas razões, os projetos em XP trabalham com releases de, no máximo, dois meses.
Isso permite incorporar uma boa quantidade de funcionalidade em cada release e permite que
os usuários aprendam com o software com bastante frequência.
O XP é aplicado em larga escala em vários projetos no mundo todo, mas ainda há muito
a evoluir em sua compreensão e aplicação. Notamos isso principalmente em pontos polêmicos
como testes unitários, programação em dupla, rodízio de pessoas, propriedade coletiva do código
e otimização de jornadas, práticas que, se mal utilizadas, podem realmente trazer aumentos no
custo e no prazo de projetos. Ou seja, é de extrema importância que entendamos bem a essência
em XP e, principalmente, que tenhamos disciplina e criatividade, duas qualidades básicas em
quem pretende desenvolver projetos. Somente a partir de uma visão criativa sobre a metodologia
e disciplina para cumprimento de tarefas é que todos poderão usar e ter benefícios em XP.
20
Nas nossas próximas unidades, abordaremos vários dos itens existentes em cada uma das fases.
Explore
Dica: visite sempre o site: http://www.devmedia.com.br/revista-engenharia-de-software-magazine.
Essa revista sobre Engenharia de Software apresenta relatos, casos e aplicações práticas dos assuntos
abordados nesta disciplina.
21
Unidade: Processos de software
Material Complementar
O objetivo do material complementar é lhe ajudar a entender, sob uma ótica diferente daquela
da professora conteudista, assuntos abordados nas unidades teóricas.
É fundamental a leitura deste material para o melhor entendimento sobre o assunto.
Explore
Como nesta unidade abordamos os conceitos gerais da Engenharia de Software, nossa sugestão de
material complementar é o capítulo intitulado Processo de software, no seguinte livro:
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011. p. 18-37.
22
Referências
Bibliografia Fundamental
Bibliografia Básica
LAUDON, K. C.; LAUDON, J. P. Sistemas de Informação. 4. ed. Rio de Janeiro: LTC, 1999.
PFLEEGER, S. L. Engenharia de Software: teoria e prática. São Paulo: Prentice Hall, 2004.
SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, 2005.
Bibliografia Complementar
ALCADE, E.; GARCIA, M.; PENUELAS, S. Informática Básica. São Paulo: Makron Books, 1991.
MICHAELIS. Moderno dicionário da língua portuguesa. São Paulo: Cia. Melhoramentos, 1998.
23
Unidade: Processos de software
24
Anotações
25
26
www.cruzeirodosulvirtual.com.br
Campus Liberdade
Rua Galvão Bueno, 868
CEP 01506-000
São Paulo SP Brasil
Tel: (55 11) 3385-3000