Engenharia de Software I

(1)

Engenharia de Software I

CURSO DE SISTE MAS DE INFORMAÇÃO

K A R L A D O N ATO F O O K DA N I E L L I M A G O M ES J Ú N I O R D ES U / D CO M P

2017

Engenharia de Software

“Disciplina de engenhara relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção”

(2)

Princípios

3

Formalidade Abstração Decomposição

Generalização Flexibilização

Maior confiabilidade durante o processo. Efeitos benéficos durante a manutenção, reutilização,

portabilidade e entendimento do software.

Princípios

Processo de identificação dos aspectos importantes de um problema no qual os pontos irrelevantes devem ser ignorados

(3)

Princípios

5

Forma de diminuir a complexidade. Subdivisão de processos em atividades específicas.

Princípios

A generalização da solução do problema tem maior potencial para permitir reutilização.

(4)

Princípios

7

Aplica-se tanto ao processo quanto ao produto. O último sofre mudanças e o processo deve ser flexível para

assimilá-las.

Paradigmas ou Modelos de Processos

Especificam atividades que devem ser executadas, bem como a ordem de execução

Alguns modelos são mais adequados que outros para determinados tipos de aplicação

◦A opção por um determinado modelo deve ser feita considerando-se o produto a ser desenvolvido

(5)

Processo de Software

Conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software.

Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento,

as ferramentas e os procedimentos necessários e a habilidade, o treinamento e a motivação do pessoal envolvido.

9

Falbo, 2005

Processo de Software

Atividades genéricas podem ser organizadas de diferentes maneiras descritas em diferentes níveis de detalhamento para diferentes tipos de software

O uso de um processo de software inadequado pode ◦Reduzir a qualidade ou a utilidade do produto de

software a ser desenvolvido e/ou

(6)

Processo de Software

São, geralmente, decompostos em diversas fases, etapas ou atividades:

1. Planejamento

2. Análise e Especificação de Requisitos 3. Projeto 4. Implementação 5. Testes 6. Entrega e Implantação 7. Operação 8. Manutenção 11 Falbo, 2005

Processo de Software

Atividades de apoio que se encontram no entorno das atividades principais:

1. Acompanhamento e controle do projeto de software

2. Gestão de risco

3. Garantia da qualidade 4. Revisões Técnicas Formais

5. Medição

6. Gestão de configuração de software 7. Gestão de reusabilidade

8. Preparação e produção do produto de trabalho

(7)

Modelos de Processos de Software

Descrição simplificada do processo de software Incluem atividades que fazem parte do processo de

software, os produtos de software e os papéis das pessoas envolvidas na engenharia de software

13

Modelos de Processos de Software

Modelos Prescritivos

◦Modelo Cascata

◦Modelos de Processo Incremental

◦Modelos de Processo Evolucionário

◦Prototipagem

◦Modelo Espiral

Modelos de Processo Especializado

◦Engenharia de software baseada em componentes (CBSE –

Component Based Software Engineering)

(8)

Modelos de Processos de Software

Processo Unificado

Modelos de Processo Pessoal e de Equipe

15

Modelo Cascata

É o paradigma mais antigo e o mais amplamente usado da Engenharia de Software

Também conhecido como “Ciclo de Vida de Software”

Desenvolvimento Sequencial, embora se possa retornar para fase anterior

◦Depois que cada estágio é concluído, o desenvolvimento prossegue para o estágio seguinte

(9)

Modelo Cascata

Considera as atividades apresentadas anteriormente e as representa como fases separadas do processo

◦Planejamento ◦Análise ◦Projeto

◦Implementação

Cada fase produz como resultado um ou mais documentos

17

(10)

Modelo Cascata

19

Os serviços, restrições e objetivos do sistema são definidos por meio de consultas aos usuários do sistema.

Modelo Cascata

(11)

Modelo Cascata

21

O processo de projeto de sistema divide os requisitos em sistemas de hardware ou de software. Ele estabelece

uma arquitetura geral do sistema.

Envolve a identificação e a descrições das abstrações fundamentais do sistema de software e suas relações.

Modelo Cascata

Nesta etapa, o projeto é realizado como um conjunto de programas ou unidades de programa.

Os programas são integrados e testados como um sistema completo para garantir que os requisitos de software

foram atendidos.

(12)

Modelo Cascata

23

Doc. de Especificação de Requisitos Doc. de Especificação de Projeto Coleção de Programas Implementados e Testados Doc. com informações

iniciais do Sistema

Modelo Cascata

Limitações

◦Os projetos reais raramente seguem o fluxo sequencial (e “top-down”) que propõe o modelo

◦ Sempre ocorrem interações e às vezes existem problemas na aplicação do paradigma

◦ É difícil tanto para o cliente como para o analista estabelecer no principio, explicitamente, todos os requisitos

◦ Ciclo de vida clássico tem dificuldades em expressar possíveis incertezas do cliente e do analista

◦A versão funcional da aplicação somente estará disponível nas etapas finais do desenvolvimento do projeto

(13)

25

Modelo Cascata

Deve ser usado apenas quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o desenvolvimento do sistema

Reflete o tipo de modelo de processo usado em outros projetos de engenharia

Variantes do Modelo Cascata

Há duas variantes

◦Desenvolvimento Paralelo ◦Modelo V

(14)

Desenvolvimento Paralelo

27

Desenvolvimento Paralelo

Um projeto geral (ou concepção) é criado e dividido em uma série de subprojetos distintos que pode ser concebidos e em paralelo

Após a conclusão destes, há a integração final do das partes separadas

(15)

Desenvolvimento Paralelo

Vantagem

◦ Reduz o tempo de distribuição do sistema

◦Diminui as chances de as alterações que ocorrem no ambiente da empresa causarem retrabalho

Limitações

◦ Problemas ocasionados pelos volumosos produtos resultantes

◦ Se os projetos não forem completamente independentes, as decisões de concepção (design) tomadas em um subprojeto pode afetar outro

◦Isto dificulta a integração dos subprojetos

29

Modelos de Processo

Incremental

Clientes identificam os serviços mais e menos importantes, definindo um número de entrega de incremento

Serviços de mais alta prioridade são entregues primeiro O primeiro incremento é um produto essencial, onde os requisitos básicos são atendidos

(16)

Modelos de Processo

Incremental

31 INCREMENTAL

Modelos de Processo

Incremental

Após a conclusão e entrega de um incremento, este é posto em operação  clientes podem experimentar parte da funcionalidade do sistema de software

Isto ajuda a conhecer os requisitos dos incrementos posteriores e das versões posteriores da atual

(17)

Modelos de Processo

Incremental

Vantagens

1. Clientes não precisam esperar até a entrega do sistema inteiro para se beneficiar dele.

◦ O 1º incremento satisfaz os requisitos mais críticos 2. Clientes podem usar os incrementos iniciais como

protótipos e ganhar experiência

33

Modelos de Processo

Incremental

Vantagens (cont.)

3. Existe um risco menor de falha geral do projeto

4. Como os serviços de prioridade mais alta são entregues primeiro, e os incrementos posteriores são integrados a eles, os sistemas mais importantes recebem mais testes ◦ os clientes têm menos probabilidade de de encontrar

(18)

Modelos de Processo

Incremental

Desvantagens

1. Os incrementos devem ser relativamente pequenos (ter

menos que 20 mil linhas de código)

2. Cada incremento deve entregar alguma funcionalidade do

sistema de software

◦ Difícil mapeamento

3. Pode ser difícil identificar os recursos comuns a todos os

incrementos

35

Modelos de Processo

Evolucionário

Baseiam-se no desenvolvimento e implementação de um produto inicial, que é submetido aos comentários e críticas do usuário

O produto vai sendo refinado através de múltiplas versões, até que o produto de software almejado seja desenvolvido

(19)

Modelos de Processo

Evolucionário

As atividades de desenvolvimento e validação são

desempenhadas paralelamente, havendo feedback entre elas

O sistema pode ser entregue ou reimplementado utilizando uma abordagem mais estruturada, para produzir um

sistema mais robusto e mais fácil de ser mantido

Em Geral, é mais efetivo que o Ciclo de Vida Clássico, mas apresenta problemas de gerenciamento

37

Modelos de Processo

Evolucionário

Descrição do esboço Versão inicial Versões intermediárias Especificação Desenvolvimento

(20)

Modelos de Processo

Evolucionário

Desenvolvimento Exploratório

◦O objetivo do processo é trabalhar com o cliente para explorar seus requisitos e entregar um sistema final ◦Se inicia com as partes do sistema que são

compreendidas

◦O sistema evolui com o acréscimo de novas características, conforme o cliente

39

Modelos de Processo

Evolucionário: Prototipagem

• Executa o processo a fim de desenvolver rápido uma versão simplificada do sistema. • O protótipo é uma versão rápida e mal feita que fornece uma quantidade mínima de recursos.

(21)

Modelos de Processo

Evolucionário: Prototipagem

41

Prototipagem throwaway ou Protótipos descartáveis

Modelos de Processo

Evolucionário: Prototipagem

 O objetivo do processo é compreender os requisitos do cliente  O protótipo se concentra em Prototipagem throwaway ou Protótipos descartáveis

(22)

43

Modelos de Processo Evolucionário:

Prototipagem

Problemas

◦Cliente enxerga protótipo como produto final ◦Prototipação é eficiente?

Modelos de Processo

Evolucionário: Considerações

O processo não é visível

◦ Documentos necessários para medir o progresso no desenvolvimento deixam de ser produzidos em virtude da velocidade de elaboração de versões do produto

Em geral, os sistemas são mal estruturados

◦ As estruturas são prejudicadas pelas mudanças constantes

O desenvolvedor pode assumir como definitivas escolhas feitas como temporárias

◦ Um Sistema Operacional inapropriado pode ser usado porque é conhecido, ou algoritmos ineficientes podem ser implementados para demonstrar possibilidades do Sistema

(23)

Modelos de Processo

Evolucionário: Modelo Espiral

Desenvolvimento do sistema evolui em uma espiral para fora a partir de um esboço inicial, em direção ao sistema final

desenvolvido

Proposto por Boehm (1988)

Foi desenvolvido para englobar as melhores características do ciclo de vida clássico e do paradigma evolutivo, adicionando ainda um novo elemento, a análise de risco

Não existem fases fixas neste paradigma

45

Modelos de Processo

Evolucionário: Modelo Espiral

Trabalha com risco

Risco

◦circunstância adversa que pode atrapalhar o processo de desenvolvimento e a qualidade do produto a ser

(24)

Modelos de Processo

Evolucionário: Modelo Espiral

47

Modelos de Processo

Evolucionário: Modelo Espiral

(25)

Modelos de Processo

Evolucionário: Modelo Espiral

49 Análise de alternativas e identificação/resolução dos riscos

Modelos de Processo

Evolucionário: Modelo Espiral

(26)

Modelos de Processo

Evolucionário: Modelo Espiral

51 Traça os planos para a próxima fase do projeto

Modelos de Processo

Evolucionário: Modelo Espiral

A decisão de como estruturar o processo de desenvolvimento de Software em fases é tomada durante o Planejamento

A principal diferença entre este modelo e os demais é o reconhecimento explícito do risco

Exemplo

◦Se a intenção for usar uma nova Linguagem de Programação,

um risco é que os compiladores disponíveis não sejam confiáveis ou não produzam código-objeto suficientemente eficaz

(27)

53

Modelos de Processo Evolucionário:

Modelo Espiral

Problemas

◦Difícil de convencer o cliente da abordagem evolutiva ser controlável

◦Exige experiência na avaliação dos riscos

Vantagens ◦Abordagem realística ◦Abordagem evolucionária ◦Prototipação ◦Interativa ◦Redução de riscos

CBSE – Component Based Software

Engineering

Engenharia de software baseada em componentes ◦Baseia-se na existência de um número significativo de

componentes reusáveis

◦O processo de desenvolvimento concentra-se na integração desses componentes, em vez de desenvolvê-los a partir do zero

(28)

CBSE – Component Based Software

Engineering

55

Especificação

de requisitos _componentesAnálise de _{de requisitos}Modificação

Projeto de sistema

com reuso Desenvolvimento_{e integração} _{de sistema}Evolução

CBSE – Component Based Software

Engineering

Especificação

Projeto de sistema

Dada uma especificação de requisitos, uma busca pelos componentes para implementar essas especificações é feita.

Não existe correspondência exata e os componentes que podem ser usados fornecem apenas uma parte

(29)

CBSE – Component Based Software

Engineering

57

Especificação

Projeto de sistema

Os requisitos são analisados usando as informações sobre os componentes encontrados. Eles são modificados

para refletir os componentes disponíveis. Quando as modificações são impossíveis, a atividade de análise de componentes pode ser novamente realizada para buscar

soluções alternativas.

CBSE – Component Based Software

Engineering

Especificação

Projeto de sistema

O framework do sistema é projetado ou um framework existente é reusado. Os projetistas levam em consideração os componentes reusados, organizando o framework para eles.

Pode ser necessário projetar algum software novo caso os componentes reusáveis não estejam disponíveis.

(30)

CBSE – Component Based Software

Engineering

59

Especificação

Projeto de sistema

O software que não pode ser adquirido externamente é desenvolvido e os componentes e os sistemas COTS (Commercial Off-The-Shelf Systems) são integrados para criar o novo sistema. A integração de sistema, neste modelo, pode ser

parte do processo de desenvolvimento, em vez de ser uma atividade separada.

CBSE – Component Based Software

Engineering

Vantagens

◦Reutilização de código

◦Reduz a quantidade de software a ser desenvolvido e, consequentemente, reduz custos e riscos

◦Leva a entrega mais rápida do software Desvantagens

◦Indisponibilidade de código fonte

◦Algum controle sobre a evolução do sistema será perdido se novas versões dos componentes reusáveis não

(31)

Modelos de Processos

Embora não exista um processo de software ideal, existe espaço para aprimoramento do processo de software em várias organizações

Os processos de software podem ser aprimorados por meio da padronização de processo, na qual a diversidade é reduzida

61

Modelos de Processos

Os modelos apresentados não são mutuamente exclusivos e podem ser utilizados em conjunto, especialmente se o sistema é de grande porte

Outras variações desses modelos genéricos foram propostos O desenvolvimento formal de sistemas, no qual é criado um modelo matemático formal de um sistema

(32)

Qual Modelo de Processo ?

Critérios para Seleção



Relacionados aos usuários e à equipe

Experiência dos usuários no Domínio da Aplicação Facilidade de expressão dos usuários

Experiência da equipe no Domínio da Aplicação Experiência da equipe em Engenharia de Software Disponibilidade de recursos humanos para a equipe



Relacionados ao produto

Tamanho e complexidade da Aplicação

Grau de importância dos requisitos de interface

63

Qual Modelo de Processo ?

Critérios para Seleção



Relacionados ao problema

Grau de maturidade no Domínio da Aplicação Complexidade do problema

Frequência e complexidade das mudanças nos requisitos Modularidade do problema



Relacionados ao desenvolvimento

Necessidade de entrega de produtos intermediários Grau de riscos técnicos

(33)

Qual Modelo de Processo ?

65

Processo de desenvolvimento

na realidade

(34)

Atividades em comum em

processos de software

67

Atividades em comum em processos de software

Validação Especificação

Desenvolvimento

(35)

69

Atividades em comum em processos de software

Desenvolvimento

Evolução

Fase de Especificação

A funcionalidade do software e as restrições sobre sua operação devem ser definidas

O quê?

◦Que dados tem que ser processados?

◦Que função e desempenho são desejados?

◦Que interfaces devem ser estabelecidas?

◦Que restrições?

(36)

71

Atividades em comum em processos de software

Validação Especificação Desenvolvimento Evolução

Fase de Desenvolvimento

Projeto e Implementação

É o processo de conversão de uma especificação de sistema em um sistema executável

Como?

◦Como a estrutura de dados e arquitetura de software são projetadas?

(37)

73

Projeto

Engloba a descrição

◦da estrutura de software a ser implementada

◦dos dados que são parte do sistema

◦das interfaces entre os componentes

◦dos algoritmos usados (às vezes)

Envolve a inclusão de formalidades e detalhes

Pode envolver o desenvolvimento de vários modelos do sistema em diferentes níveis de abstração

Implementação

Desenvolvimento dos programas do sistema Atividade pessoal e, em geral, não segue processo

Uso de ferramentas CASE para geração de esqueleto do programa com base no projeto

(38)

Atividades da fase de Desenvolvimento

75

Projeto de

arquitetura Especificação_abstrata Projeto de_interface

Projeto de

componente _{Estrutura de dados}Projeto de Projeto de_algoritmo

Arquitetura

de sistema Especificaçãode software Especificação_{de interface}

Especificação

de componente Especificaçãode estrutura de dados

Especificação de algoritmo

Atividades da fase de Desenvolvimento

Codificação

Programas

... Codificação

(39)

77

Atividades em comum em processos de software

Desenvolvimento

Evolução

Fase de Validação

O software deve ser validado para garantir que ele faça o que o cliente deseja

Como os testes serão realizados? Etapas

◦Codificação

◦Realização de testes unitários

(40)

Fase de Validação

79 Teste de

componente Teste de_sistema _aceitaçãoTeste de

Fase de Validação

Teste de

componente Teste de_sistema _aceitaçãoTeste de

(41)

Fase de Validação

Geralmente, o desenvolvimento e teste de componentes são intercalados

No caso da abordagem incremental, cada incremento deve ser testado à medida que é incrementado

81

Atividades em comum em processos de software

(42)

83

Fase de Evolução

Mudanças geram manutenções

◦Correção de erros ◦Adaptação ◦Ampliação

Fase de Evolução

Tipos de manutenção ◦Corretiva ◦Adaptativa ◦Perfectiva ◦Preventiva

(43)

85

Fase de Evolução

Trata de problemas decorrentes de defeitos. À medida que falhas ocorrem, elas são relatadas à

equipe de manutenção, que se encarrega de encontrar o defeito que causou a falha e faz as

correções (nos requisitos, análise, projeto ou implementação), conforme o necessário. Esse reparo inicial pode ser temporário, visando manter o sistema funcionando. Quando esse for

o caso, mudanças mais complexas podem ser implementadas posteriormente. Falbo, 2009

Fase de Evolução

Às vezes, uma mudança no ambiente do sistema, incluindo hardware e software de apoio, pode

(44)

87

Fase de Evolução

Consiste em realizar mudanças para melhorar algum aspecto do sistema, mesmo quando nenhuma das mudanças for consequência de defeitos. Isso inclui a adição de novas capacidades

bem como ampliações gerais.

Falbo, 2009

Fase de Evolução

Consiste em realizar mudanças a fim de prevenir falhas.

Geralmente ocorre quando um mantenedor descobre um defeito que ainda não causou falha e decide corrigi-lo antes que ele gere uma falha.

(45)

89

Fase de Evolução

(Sommerville, 2007)

A distinção entre o desenvolvimento e manutenção tem se tornado cada vez mais irrelevante

Modelagem do

(46)

Porque modelar o Processo de

Software?

A importância em descrever o processo de software tem sido discutida na literatura de engenharia de software como uma das formas de suporte

◦À qualidade do produto de software

◦À sistematização das práticas empregadas durante o desenvolvimento,

◦Para aumentar a maturidade do processo de software ◦estabelecer uma baseline para avaliação e melhoria ◦...

91

Modelagem do Processo

A descrição de processo de software permite

◦detalhar o processo de software real executado em organizações de desenvolvimento

◦possibilitar que falhas no processosejam detectadas e corrigidas

(47)

Modelagem do Processo

A descrição de processos contribui sob vários aspectos no processo de desenvolvimento

◦A padronização do processo é necessária para permitir o treinamento, elaboração de guias, gerenciamento, revisão e automação

◦Com a padronização de métodos, cada experiência de projeto pode contribuir para uma melhoria global em uma organização

93

Modelagem do Processo

◦Processos padronizados provêem uma infra-estrutura básica para melhoria, avaliação e mensuração

◦Porque tarefas básicas são comuns em muitos projetos de software, apenas algumas customizações seriam

necessárias para um processo padrão atender à maioria das necessidades de projetos

(48)

Modelagem do Processo

95 Fonte: UFPA

Modelos --- >

Ferramentas ...

(49)

Ferramenta utilizada para

descrever processos de software

Spearmint – Software Process Elicitation, Analysis, Review and Modeling in an Integrated Environment

97

Ferramentas utilizadas para

descrever processos de software

Spearmint – Software Process Elicitation, Analysis, Review and Modeling in an Integrated Environment

(50)

Ferramenta utilizada para

descrever processos de software

Promodeller (Ebert, 2009) – UFPE

99

Ferramenta utilizada para

(51)

Propriedades desejáveis das ferramentas e

técnicas para modelagem de processos

Facilitar o entendimento humano e a comunicação Apoiar a melhoria do processo

Apoiar o gerenciamento do processo

Fornecer orientação automatizada para a utilização do processo Apoiar a execução automatizada do processo