Engenharia deSoftware

Prof. Bacalásbacala@gmail.com

2/34

Engenharia de Software(Def.) Disciplina gerencial e tecnológica que lida com a produção e manutenção sistemática de produtos de software desenvolvidos dentro de estimativas de custo e tempo

Deve-se entender por engenharia a ciência relacionada com o uso prático de conhecimentos científicos

3/34

O que é software? Programas de computador e

documentação associada Produtos de software podem ser

desenvolvidos para um cliente particular ou podem ser desenvolvidos para um mercado geral

4/34

Objetivos de Engenharia de Software Obter software de qualidade Com produtividade no seu desenvolvimento,

operação e manutenção Empregando profissionais que desenvolvam

o software dentro de custos, prazos e níveis de qualidade controlados

E, além disso, que obtenham o melhor custo-benefício possível entre Qualidade Produtividade

5/34

Motivação Desenvolver sistemas de acordo com a

intenção do cliente/usuário Estabelecer noção sobre tempo e

custo de desenvolvimento Elaborar artefatos além do código Analisar artefatos para estabelecer a

qualidade do produto

6/34

Características da Engenharia de Software A Engenharia de Software se refere

a software (sistemas) desenvolvidos por grupos ao invés de indivíduos

usa princípios de engenharia ao invés de arte, e

inclui tanto aspectos técnicos quanto não técnicos

Engenharia de Software Engenharia: aplicar conhecimentos científicos e

empíricos para criação de estruturas, dispositivos e processos.

Engenheiros de Software: Criam e dão suporte ao software de computador.

Engenheiros/Analistas de Requisitos: Analisam e modelam requisitos do sistema de software.

O software é desenvolvido ou passa por um processo de engenharia; ele não é “fabricado” no sentido clássico. Software não “se desgasta”.

Qual a diferença entre Engenharia de Software e Ciência da Computação? Ciência da Computação

foca a teoria e os fundamentos, Eng. de Software

preocupa-se com o desenvolvimento prático do software, sua manutenção e evolução.

O que é um software de qualidade? O software que satisfaz os requisitos solicitados

pelo usuário. Deve ser fácil de manter, ter boa performance, ser confiável e fácil de usar

Alguns atributos de qualidade Manutenibilidade

O software deve evoluir para atender os requisitos que mudam

Eficiência O software não deve desperdiçar os recursos do

sistema Usabilidade

O software deve ser fácil de usar pelos usuários para os quais ele foi projetado

Qualidade de Software (um exemplo para o Varejo) Correto

A loja não pode deixar de cobrar por produtos comprados pelo consumidor

Robusto e altamente disponível A loja não pode parar de vender

Eficiente O consumidor não pode esperar A empresa quer investir pouco em

recursos computacionais (CPU, memória, rede)

Qualidade de Software (um exemplo para o Varejo) Amigável e fácil de usar

A empresa quer investir pouco em treinamento Altamente extensível e adaptável

A empresa tem sempre novos requisitos (para ontem!)

A empresa quer o software customizado do seu jeito (interface, teclado, idioma, moeda, etc.)

Reusável Várias empresas precisam usar partes de um mesmo

sistema

Qualidade de Software (um exemplo para o Varejo) Aberto, compatível, de fácil integração com outros

sistemas A empresa já tem controle de estoque, fidelização,

etc. Portável e independente de plataforma (hw e sw)

A empresa opta por uma determinada plataforma Baixo custo de instalação e atualização

A empresa tem um grande número de PDVs

Produtividade Custo de desenvolvimento reduzido

A empresa consumidora quer investir pouco em software

A empresa produtora tem que oferecer “software barato”

Tempo de desenvolvimento reduzido Suporte rápido às necessidades do

mercado

“Software Barato” Nem tanto resultado de baixos

custos de desenvolvimento, mas principalmente da distribuição dos

custos entre vários clientes.

Reuso, extensibilidade e adaptabilidade são essenciais para viabilizar tal

distribuição.

Importância da Engenharia de Software Qualidade de software e

produtividade garantem: Disponibilidade de serviços essenciais Segurança de pessoas Competitividade das empresas

Produtores Consumidores

Mas, na realidade, temos a Crise de Software... 25% dos projetos são cancelados o tempo de desenvolvimento é bem

maior do que o estimado 75% dos sistemas não funcionam como

planejado a manutenção e reutilização são

difíceis e custosas os problemas são proporcionais a

complexidade dos sistemas

Causas da Crise de Software Essências

Complexidade dos sistemas Dificuldade de formalização

Acidentes Má qualidade dos métodos, linguagens,

ferramentas, processos, e modelos de ciclo de vida

Falta de qualificação técnica

Elementos e Atividades da Engenharia de Software Elementos

Modelos do ciclo de vida do software Linguagens Métodos Ferramentas Processos

Atividades Modelagem do negócio Elicitação de requisitos Análise e Projeto Implementação Testes Distribuição Planejamento Gerenciamento Gerência de Configuração e Mudanças Manutenção

20/45

Ciclo de Vida e Processo de Desenvolvimento de

Software

21/45

O que é um modelo de ciclo de vida de processo de software? Uma representação abstrata e

simplificada do processo de desenvolvimento software, tipicamente mostrando as principais atividades e dados usados na produção e manutenção de software

22/45

Principais Modelos do Ciclo de Vida de Software Cascata Modelo de Desenvolvimento Evolucionário

Programação Exploratória Prototipagem descartável

Modelo de Transformação Formal Modelos Iterativos

Espiral Incremental

23/45

Modelo Cascata(ou clássico) Derivado de modelos existentes em outras

engenharias Sua estrutura é composta por várias etapas

que são executadas de forma sistemática e seqüencial

Na prática, existe uma interação entre as etapas e cada etapa pode levar a modificações nas etapas anteriores

24/45

Modelo CascataDefinição de Requisitos

Projeto do Sistema e do

Software

Implementação e Testes Unitários

Integração e Teste do Sistema

Operação e Manutenção

25/45

Modelo Cascata na PráticaDefinição de Requisitos

Projeto do Sistema e do

Software

Implementação e Testes Unitários

Integração e Teste do Sistema

Operação e Manutenção

26/45

Modelo de Desenvolvimento Evolucionário Programação Exploratória Prototipagem Descartável

Atividades Concorrentes

Especificação

Desenvolvimento

Validação

Esboço de Descrição

Versão Inicial

Versões Intermediárias

Versão Final

27/45

Programação Exploratória Idéia geral:

Desenvolvimento da primeira versão do sistema o mais rápido possível

Modificações sucessivas até que o sistema seja considerado adequado

Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários

Adequado para o desenvolvimento de sistemas onde é difícil ou impossível se fazer uma especificação detalhada do sistema

Principal diferença para os outros modelos é a ausência da noção de programa correto

28/45

Programação Exploratória Tem sido mais usada no desenvolvimento de

sistemas especialistas - geralmente sistemas que tentam emular capacidades humanas

A maioria dos sistemas desenvolvidos com sucesso usando a programação exploratória foi implementada usando pequenos grupos de profissionais altamente qualificados e motivados

29/45

Prototipagem Descartável Como na programação exploratória, a primeira fase

prevê o desenvolvimento de um programa para o usuário experimentar No entanto, o objetivo aqui é estabelecer os

requisitos do sistema O software deve ser reimplementado na fase

seguinte A construção de protótipos com os quais os

usuários possam brincar é uma idéia bastante atrativa: Para sistemas grandes e complicados Quando não existe um sistema anterior ou um

sistema manual que ajude a especificar os requisitos

30/45

Prototipagem Descartável Os objetivos do protótipo devem estar bem claros

antes do início da codificação. Possíveis objetivos: Entender os requisitos dos usuários Definir a interface com os usuários Demonstrar a viabilidade do sistemas para os

gerentes. Uma decisão importante a ser tomada é escolher o

que será e o que não será parte do protótipo Não é economicamente viável implementar todo

o sistema! Os objetivos do protótipo são o ponto de

partida

31/45

Transformação Formal Idéia geral:

Uma especificação formal (definição matemática, não ambígua) do software é desenvolvida e posteriormente “transformada” em um programa através de regras que preservam a corretude da especificação

esp. 2esp. 1 implement.

32/45

Transformação Formal A grande motivação por trás da idéia de

refinamento formal é a possibilidade de gerar automaticamente programas que são corretos por construção O próprio processo de desenvolvimento deve

grantir que o programa faz exatamente o que foi especificado

Este modelo tem sido aplicado ao desenvolvimento de sistemas críticos, especialmente naqueles onde a segurança é um fator crítico (ex: sistema de controle de tráfego aéreo)

33/45

Modelo de Desenvolvimento Baseado em Reuso Baseado no reuso sistemático de componentes

existentes ou sistemas COTS (Commercial-off-the-shelf)

Etapas do processo Especificação dos requisitos Análise de componentes Modificação dos requisitos Projeto de sistema com reuso Desenvolvimento e integração Validação

Esta abordagem está se tornando mais importante, mas há ainda pouca experiência com ela

34/45

Modelo de Desenvolvimento Baseado em Reuso

Especificação de Requisitos

Análise de Componentes

Modificação de Requisitos

Projeto de Sistema com Reuso

Desenvolvimento e Integração

Validação do Sistema

35/45

Modelos Iterativos Requisitos de sistema SEMPRE evoluem

durante curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas

Iterações podem ser aplicadas a quaisquer dos modelos de ciclo de vida

Duas abordagens (relacionadas) Desenvolvimento espiral Desenvolvimento incremental

36/45

Desenvolvimento Espiral Acrescenta aspectos gerenciais ao processo de

desenvolvimento de software. análise de riscos em intervalos regulares do processo de

desenvolvimento de software planejamento controle tomada de decisão

O processo é representado como uma espiral em vez de uma seqüência de atividades

Cada volta na espiral representa uma fase no processo Não há fases fixas como especificação ou projeto -

voltas na espiral são escolhidas dependendo do que é requerido

Riscos são avaliados explicitamente e resolvidos ao longo do processo

37/45

Desenvolvimento Espiral

Determinação dos objetivos, alternativas e restrições

Análise de Riscos

Análise das alternativas e identificação e/ou resolução de riscos

Desenvolvimento e validação da versão corrente do produto

Simulações,modelos e benchmarks

Planejamento

38/45

Desenvolvimento Incremental Em vez de entregar o sistema como um todo, o

desenvolvimento e a entrega são divididos em incrementos, com cada incremento entregando parte da funcionalidade requerida

Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais

Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora os requisitos possam continuar a evoluir para incrementos posteriores

Em certos aspectos é similar à programação exploratória. No entanto, o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento

39/45

Desenvolvimento Incremental

Definiresboço dosrequisitos

Associarrequisitos aincrementos

Projetar aarquitetura dosistema

Desenvolverumincremento

Validar oincremento

Integrar oincremento

Validar osistema

SistemaFinal

40/45

Processo Conjunto de atividades

bem definidas com responsáveis com artefatos de entrada e saída com dependências entre as mesmas e

ordem de execução com modelo de ciclo de vida

41/45

Processo é uma ação regular e contínua (ou sucessão

de ações) realizada de forma bem definida, levando a um resultado

é um conjunto parcialmente ordenado de atividades (ou passos) para se atingir um objetivo

define quem está fazendo o que, quando e como para atingir um certo objetivo

42/45

Processo versus Metodologia Alguns autores consideram que

processos incluem uma metodologia pessoas tecnologia (suporte de ferramentas)

Outros consideram que uma metodologia é a especialização de um processo com um conjunto de métodos

43/45

Método Descrição sistemática de como deve-

se realizar uma determinada atividade ou tarefa

A descrição é normalmente feita através de padrões e guias

Exemplos: Método para descoberta de atores e casos de uso no RUP.

44/45

Modelo de Processo é uma representação de um processo,

usualmente envolvendo atividades a serem realizadas agentes que realizam as atividades artefatos (produtos) gerados recursos necessários (consumidos)

45/45

Modelo de Processo Um modelo é usado para entendimento e

comunicação do processo, e como base para análise, execução, gerência e melhoria do processo

Idealmente a descrição deve ser formal e completa para permitir, por exemplo, automação

A descrição deve ser apresentada em diferentes níveis de abstração

46/45

Modelo de Processo O formalismo utilizado para representar o

processo é o ingrediente mais importante da modelagem

Não parece haver consenso sobre um formalismo ideal Terminologias distintas

Fase, workflow, domínio, disciplina, Atividade Mas há esforço de padronização (SPEM e

BPMN – OMG)

47/45

Exemplos de processos Processos tradicionais (pesados)

RUP, OPEN, Catalysis Processos ágeis (leves)

XP, Agile modeling, Crystal, pragmatic programming, Internet Speed, Scrum, ...

48/45

Exemplos de processos Consenso em torno de

Iteratividade Participação de usuários Flexibilidade de configuração para

projetos específicos Comunicação entre membros da equipe

49/45

Exemplos de processos Divergências em torno de

Detalhamento de atividades a serem seguidas Critério de conclusão da execução das

atividades Arquitetura robusta (RUP) Arquitetura para o contexto da iteração atual (agile

modeling) Rigor na atribuição de tarefas a responsáveis

workers (RUP) alocação sob demanda e interesse (XP)

Artefatos (documentação) gerados Nível de Automação Nível de (im)pessoalidade

50/45

Polêmica Se a tendência é processos leves, afinal o

desenvolvimento de software é Arte+Sociologia+Psicologia+... ou Lógica+Modelos+Engenharia+...???

E todo o esforço de consolidação da Engenharia de Software como uma ciência exata???

Compromisso Balancing agility and discipline

Na prática....

51

52/34

O Início de Tudo...

“A intenção do cliente é...”

53/34

O Mais Importante Aqui é...

A Idéiaé

Viável???

54/34

O Que Devo Fazer Exatamente?

Ou, em outras palavras, quais são os requisitos da aplicação?

55/34

Requisitos O Que devo fazer?

Funcionalidades Há restrições sobre as

funcionalidades? Limites de tempo, memória, etc.?

Há restrições mais amplas? Empresa, Governo, etc.?

56/34

O que faço então?

“O documento de requisitos...”

57/34

Como apresentar ao Cliente?

“O cliente não vai ler

500 páginas de

requisitos!!!”

58/34

Uma Figura Vale Mais Que ...

59/34

Mas Paralelamente ...

“Precisamos saber quanto tempo levaremos para fazer nosso trabalho, quanto isso custará e o que pode nos atrapalhar... Precisamos Planejar!!!”

60/34

Estimando Esforço Modelo de casos de uso pode ser

usado para calcular estimativa Baseia-se em uma série de fatores

que determinam a complexidade da aplicação

Há ferramentas para realizar o cálculo

61/34

Estimando Esforço

X horasF( )

62/34

Estimando Esforço

63/34

Iniciando a Solução...

“Temos que identificar em nossos requisitos, quais são os elementos essenciais para satisfazê-los...”

64/34

Iniciando a Solução...

65/34

Iniciando a Solução...

66/34

Sedimentando a Solução...

“A partir dos elementos essenciais, precisamos definir estratégias para satisfazê-los incluindo suas restrições...”

67/34

Sedimentando a Solução...

68/34

Sedimentando a Solução...

69/34

Sedimentando a Solução...

71/34

Operacionalizando a Solução...

“Com a solução definida, o passo final é operacionalizá-la. Isto é, codificá-la.”

72/34

Classe Account...public class Account { private int balance; ... void debit(int amount) { if(amount<=balance) balance = balance – amount; else throw new AccountException(“...”); }...}

73/34

Funciona???

“Com a implementação feita, podemos então executar os testes!!!”

74/34

Avaliando a qualidadepublic class AccountTest extends TestCase {

void testDebit() { Account acc = new Account(10); acc.debit(10); assertEquals(0, acc.getBalance()); }

}

Referências Básica

Sommerville, I. Software Engineering. Extra

Kruchten, P. The Rational Unified Process: An Introduction. 2nd Ed

Booch, G. et al. The Unified Modeling Language User Guide.

Pressman, R. Software Engineering.