Prévia do material em texto

Engenharia de Software
Prof. Me. Müller Miranda
02
Processos de Software
Processos de Software
Um processo de software é um conjunto de atividades relacionadas que 
levam à produção de um produto de software.
Existem muitos processos de software diferentes, mas todos devem incluir 
quatro atividades fundamentais para a engenharia de software:
1. Especificação de software. A funcionalidade do software e as restrições a 
seu funcionamento devem ser definidas.
2. Projeto e implementação de software. O software deve ser produzido para 
atender às especificações. 
Processos de Software
3. Validação de software. O software deve ser validado para garantir que 
atenda às demandas do cliente.
4. Evolução de software. O software deve evoluir para atender às 
necessidades de mudança dos clientes.
São atividades complexas em si mesmas, que incluem subatividades como 
validação de requisitos, projeto de arquitetura, testes unitários etc.
Processos de Software
Os processos de software, às vezes, são categorizados como dirigidos a 
planos ou processos ágeis. 
Processos dirigidos a planos são aqueles em que todas as atividades são 
planejadas com antecedência. Em processos ágeis, o planejamento é 
gradativo, e é mais fácil alterar o processo de maneira a refletir as 
necessidades de mudança dos clientes.
Modelos de processo de software
Um modelo de processo de software ou paradigma de processo é uma 
representação simplificada de um processo de software. 
Ou seja, nós vemos um framework do processo, mas não vemos os detalhes 
de suas atividades específicas. 
O modelo em cascata
O modelo em cascata é um exemplo de um processo dirigido a planos — em 
princípio, você deve planejar e programar todas as atividades do processo 
antes de começar a trabalhar nelas.
O modelo cascata
O modelo em cascata
Em princípio, o resultado de cada estágio é a aprovação de um ou mais 
documentos (‘assinados’). O estágio seguinte não deve ser iniciado até que a 
fase anterior seja concluída. Em princípio, o modelo em cascata deve ser 
usado apenas quando os requisitos são bem 
compreendidos e pouco provavelmente venham a ser 
radicalmente alterados durante o desenvolvimento do sistema.
O modelo em cascata
 Só é possível em geral verificar se houve erros nas últimas fases. Em outros 
modelos, os riscos são reduzidos desde as primeiras fases do processo de 
desenvolvimento. 
O modelo cascata
Se eu peço a construção de um carro e você constrói uma moto, o custo para 
corrigir esse erro será altíssimo. 
O modelo cascata
Se o erro ocorreu no início e foi identificado no início, terá baixo custo de 
correção se o erro ocorreu no início e foi identificado no final, terá alto custo 
de correção. 
O modelo cascata
A grande vantagem do Modelo em Cascata é que o desenvolvimento é 
dividido em fases distintas, padronizadas. É possível colocar pessoas com 
perfis específicos para cada fase, quem tem facilidade de se comunicar vai ser 
analista de requisitos, programadores vão fazer a codificação, etc.
A grande desvantagem é que - em projetos complexos – demora-se muito 
para chegar até a fase de testes, sendo que o cliente não vê nada rodando até 
a implantação. 
O modelo em cascata
Vantagens
É simples de entender e fácil de aplicar, facilitando o planejamento;
Fixa pontos específicos para a entrega de artefatos;
Funciona bem para equipes tecnicamente fracas;
É fácil de gerenciar, devido a sua rigidez;
Realiza documentação extensa por cada fase ou estágio;
Funciona bem com projetos pequenos e com requisitos bem conhecidos. 
O modelo cascata
Desvantagens
Divisão inflexível do projeto em estágios distintos; 
Dificuldade em incorporar mudanças de requisitos;
Clientes só visualizam resultados próximos ao final do projeto;
Atrasa a redução de riscos;
Apenas a fase final produz um artefato de software entregável;
Cliente deve saber todos os requisitos no início do projeto;
O modelo em cascata
O Modelo em Cascata é considerado um método tradicional e fortemente 
prescritivo.
Exercício
1- FCC - 2012 -TJ RJ- Analista Judiciário - Análise de Sistemas
Dos diferentes modelos para o ciclo de vida de desenvolvimento de um 
software é correto afirmar que o modelo em cascata é o mais recente e 
complexo. 
2 - FCC - 2009 SEFAZ SP Agente Fiscal de Rendas - Tecnologia da Informação
O processo de engenharia de software denominado ciclo de vida clássico 
refere-se ao modelo incremental.
Exercício
3 - CESPE – 2009 – INMETRO – Analista de Sistemas 
Em uma empresa que tenha adotado um processo de desenvolvimento de 
software em cascata, falhas no levantamento de requisitos têm maior 
possibilidade de gerar grandes prejuízos do que naquelas que tenham 
adotado desenvolvimento evolucionário.
4 - CESPE – 2011 – MEC – Analista de Sistemas
O modelo Waterfall tem a vantagem de facilitar a realização de mudanças 
sem a necessidade de retrabalho em fases já completadas.
Exercício
5 - CESPE – 2008 – TST – Analista de Sistemas
No modelo de desenvolvimento sequencial linear, a fase de codificação é a 
que gera erros de maior custo de correção.
6 - CESPE – 2008 – SERPRO – Analista de Sistemas
O modelo em cascata consiste de fases e atividades que devem ser realizadas 
em sequência, de forma que uma atividade é requisito da outra
Exercício
7 - CESPE – 2005 – AL/ES – Analista de Sistemas
O modelo de desenvolvimento em cascata descreve ciclos sequenciais, 
incrementais e iterativos, possuindo, entre outras, as fases de requisitos e 
implementação.
8 - CESPE – 2008 – TCE/TO – Analista de Sistema
No ciclo de vida em cascata, é possível realizar alternadamente e 
simultaneamente as atividades de desenvolvimento de software. 
Exercício
9 - CESPE – 2009 – TRE/MT – Analista de Sistema
O modelo em cascata é apropriado para software em que os requisitos ainda 
não foram bem compreendidos, pois é focado na criação de incrementos.
10 - CESPE – 2009 – INMETRO – Analista de Sistemas) 
Em um processo de desenvolvimento em cascata, os testes de software são 
realizados todos em um mesmo estágio, que acontece após a finalização das 
fases de implementação. 
Exercício
11 - CESPE – 2008 – MPE/AM – Analista de Sistema
O modelo de desenvolvimento seqüencial linear tem como característica 
principal a produção de uma versão básica, mas funcional, do software desde 
as primeiras fases.
Métodos formais
Esse modelo é utilizado em ambientes extremamente complexos. (Controle 
Controle de tráfego aéreo, sistemas automatizados de terapia a laser, etc.)
Por que métodos formais ?!
Alta probabilidade de as falhas provocarem perda de vidas ou sério prejuízo.
Lançador Ariane - Explodiu 40s após lançamento em 1996 
Mortes e ferimentos graves durante terapia de radiação.
Dezenas de outros acidentes...
Métodos formais
Uma especificação formal é uma descrição matemática de software ou de 
hardware que pode ser utilizada para desenvolver uma implementação.
Os chamados Métodos Formais de Desenvolvimento de Software não são 
amplamente usados no desenvolvimento de software industrial. 
Métodos formais
O desenvolvimento é lento e dispendioso.
Requer treinamento extensivo.
Difícil utilizar os modelos como um mecanismo de comunicação.
Métodos formais
Cleanroom (Sala Limpa)
O objetivo dessa abordagem é o desenvolvimento de um software com 
defeito zero. Este processo é uma filosofia de desenvolvimento de software 
que usa métodos formais para apoiar inspeção rigorosa de software.
Notação Z.
Notação B.
Redes de Petri.
Etc...
Exercício
(CESPE – 2008 – SERPRO – Analista de Sistemas) 
Para a especificação de software e verificação de sistemas, uma alternativa 
que se fundamenta na matemática discreta e na lógica é o modelo 
incremental.Modelo baseado em componentes
Refere-se a uma estratégia de engenharia de software na qual o processo de 
desenvolvimento é voltado à reusabilidade. 
Baseiam seus projetos em componentes exaustivamente testados. 
Os custos de desenvolvimento são menores. 
Pressman afirma que um componente é um bloco de construção 
modular. É uma parte do sistema, executável, implantável, independente, 
padronizada e reutilizável que encapsula a implementação e expõe um 
conjunto de interfaces do sistema.
Modelo baseado em componentes
Para garantir o baixo acoplamento entre o cliente e o componente, a 
implementação deste deve respeitar alguns princípios de desenvolvimento.
Componentes são orientados a interfaces, ou seja, expõem seus serviços para 
que o cliente realize o acesso, mas sem expor a implementação;
Componentes podem ter dependências com outros componentes. Neste caso 
um componente realiza a chamada para a interface de outro componente.
Modelo baseado em componentes
Atividades do desenvolvimento com componentes
Modelo baseado em componentes
Modelo baseado em componentes
Raramente um componente é utilizado como foi originalmente desenvolvido.
Os projetistas não têm condições de prever todos os possíveis usos que um 
componente pode assumir. 
As técnicas de adaptação de componentes podem ser classificadas como 
técnicas de caixa branca e caixa preta. 
Caixa branca: Adaptação de sua estrutura interna.
Caixa preta: Adaptação de sua interface.
Modelo baseado em componentes
É importante não confundir componentes e objetos.
Componentes são independentes de linguagem. 
É possível a construção de um componente tanto em linguagens orientadas a 
objetos, quanto em linguagens não OO. 
Enquanto isso, objetos existem apenas em linguagens OO.
Exercício
1 (CESPE – 2010 – TRE/BA – Técnico Judiciário – Programação de Sistemas) 
Na engenharia de software baseada em componentes, na qual se supõe que 
partes do sistema já existam, o processo de desenvolvimento concentra-se 
mais na integração dessas partes que no seu desenvolvimento a partir do 
início. Essa abordagem é baseada em reuso para o desenvolvimento de 
sistemas de software. 
Exercício
2 - UFBA - 2009 - UFBA - Analista de Tecnologia da Informação 
No processo de software baseado em componentes, cada componente 
projetado para reuso é uma entidade executável independente, que deve 
manipular exceções. 
Exercício
Comentário da questão anterior: Os componentes não devem tratar as 
exceções por si mesmos, pois cada aplicação terá seus próprios requisitos 
para tratamento de exceções.
3 (CESPE – 2008 – SERPRO – Analista de Sistemas) 
O modelo orientado a reuso parte de um software existente para que se crie 
outro, no todo ou apenas em parte de seus componentes.