Engenharia SW

Marcio de Carvalho Victorino

Sumrio

Ciclo de vida, processos e qualidade de software. Processo unificado: disciplinas, fases, conceitos bsicos e principais artefatos. Processos geis: XP, Scrum. Engenharia de requisitos. Anlise e projeto orientado a objetos. UML. Arquiteturas de software
2

Engenharia de SW

uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios iniciais de especificao do sistema at a manuteno desse sistema, depois que ele entrou em produo. Sua meta o desenvolvimento de sistemas de Sw com boa relao custo-benefcio.

Engenharia de SW

Evoluo:

Iniciou em 1968: crise do software. Dcada de 1970: Programao Estruturada e Projeto Estruturado. Dcada de 1980: Anlise Estruturada (surgimento de ferramentas CASE). Dcada de 1990: Anlise e Projeto Orientados a Objetos.

Orientao a objetos (OO) um termo geral que inclui qualquer estilo de desenvolvimento de sistemas que seja baseado no conceito de objeto, uma entidade que exibe caractersticas e comportamentos. A estratgia OO pode ser aplicada programao e a anlise e projeto de sistemas.
4

Dcada de 2000: SOA.

Engenharia de SW

Software: so os programas de computador e a documentao associada. Processo de Software: um conjunto de atividades, cuja meta o desenvolvimento ou a evoluo do software. Modelo de Processo de Software: uma representao simplificada de um processo de software, apresentada a partir de uma perspectiva especfica. Mtodos de Engenharia de Software: so abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notaes, regras, recomendaes de projetos e diretrizes de processos.
5

Engenharia de SW

Atributos de um bom software:

proporcionar funcionalidades e desempenho requeridos; passvel de manuteno, confivel e de fcil uso. lidar com sistemas legado; atender crescente diversidade; prazos reduzidos.

Desafios da Engenharia de SW:

Custos da Engenharia de SW:

desenvolvimento 60% testes 40%

Engenharia de SW

Essncia:

Entenda o problema: levantamento de requisitos e anlise. Planeje uma soluo: projeto. Execute o plano: implementao. Examine o resultado quanto a preciso: teste e garantia de qualidade.

Engenharia de SW

Princpios:

Razo por que tudo existe: para fornecer valor aos seus usurios. Mantenha a coisa simples: todo projeto deve ser to simples quanto possvel, mas no mais simples. Mantenha a viso: uma viso clara essencial para o sucesso de um projeto de software. O que voc produz os outros vo consumir: sempre especifique, projete e implemente sabendo que mais algum ter de entender o que voc est fazendo. Esteja aberto para o futuro: nunca projete a si mesmo em um beco sem sada. Planeje com antecedncia o reuso: reduz custo e aumenta o valor dos componentes e do sistema ao qual so incorporados. Pense: raciocinar clara e completamente antes da ao quase sempre produz melhores resultados.
8

Modelo em cascata
Comunicao

Roger Pressman
Planejamento
- estimativas - cronogramao - monitorao

- iniciao do Projeto - levantamento de requisitos

Modelagem
- anlise - projeto

Construo
- codificao - teste

Implantao
- entrega - manuteno - teste

Modelo em cascata
Requisitos do Sistema Requisitos de Software

Edward Yordon

Anlise
Projeto de Programas

Codificao Teste Operaes

10

Modelo em cascata
Requisitos Anlise Projeto Codificao

Eduardo Bezerra

Teste
Implantao

11

Fases clssicas no desenvolvimento de SW

Levantamento de Requisitos: tem por objetivo propiciar que usurios e desenvolvedores tenham a mesma compreenso do problema a ser resolvido. Anlise: tem por objetivo construir modelos que determinam qual o problema para o qual estamos tentando conceber uma soluo de software. Projeto: estgio no qual o modelo de anlise ter de ser adaptado de tal modo que possa servir como base para implementao no ambiente alvo. Codificao (implementao): a codificao do sistema efetivamente executada. Teste: consiste na verificao do software. Implantao: entrada em produo do sistema. 12

Modelo Incremental

Requisitos Anlise

Requisitos Anlise Projeto Codificao Teste

Projeto Codificao Teste Implantao

Implantao

13

Modelo RAD

Rapid Application Development um modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento curto. uma adaptao de alta velocidade do modelo em cascata, no qual o desenvolvimento rpido conseguido com o uso de uma abordagem de construo baseada em componentes. Equipe 1
Comunicao Modelagem
modelagem de negcio modelagem de dados modelagem de processos

Planejamento

Construo

reuso de componentes gerao automtica de cdigo testes Equipe 2

Implantao

Desvantagens: - Projetos grandes precisam de muitas equipes. - Exige comprometimento dos clientes e desenvolvedores. - Sistemas no modularizados so problemticos. - No adequado para projetos com grandes riscos tcnicos.

Modelagem

modelagem de negcio modelagem de dados modelagem de processos

Construo

reuso de componentes gerao automtica de cdigo testes

60 - 90 dias

14

Modelos Evolucionrios

Prototipagem Modelo Espiral Modelo de Desenvolvimento Concorrente

15

Prototipagem

Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construdo quando os requisitos esto confusos. O prottipo serve como um mecanismo para a identificao dos requisitos de software.

Comunicao (Incio)

Plano Rpido Modelagem Projeto Rpido

Implantao Entrega e Feedback

Construo do Prottipo

16

Modelo Espiral

O software desenvolvido nume srie de verses evolucionrias.

Planejamento
estimativa cronograma anlise de risco

Comunicao

Incio

Implantao
entrega feedback

Modelagem
anlise projeto

Construo
Planejamento Anlise dos Riscos

cdigo teste

Avaliao do Cliente

Engenharia

17

Modelos Especializados

Desenvolvimento Baseado em Componentes. Modelo de Mtodos Formais:

baseados em modelos matemticos; lento e dispendioso; necessita treinamento extensivo; clientes despreparados no entendem dificultando a comunicao.

os

modelos,

Desenvolvimento de Software Orientado a Aspectos:

interface com o usurio; gesto de memria; integridade; segurana.

18

Desenvolvimento gil

Agilidade:

capacidade de modificaes:

responder

adequadamente

modificaes no software; modificaes nos membros da equipe; modificaes devido a novas tecnologias; etc.

Processo gil:

Requisitos e prioridades instveis. Projeto e construo so realizados simultaneamente. Anlise, projeto, implementao e testes no so to previsveis (planejamento).
19

Modelos geis

XP - Extreme Programing. ASD - Adaptative Software Development. DSDM - Dynamic Systems Development Methed. Scrum. Crystal. FDD - Feature Driven Development.

20

XP

O manifesto gil
Estamos evidenciando maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a fazlo. Atravs desse trabalho, passamos a valorizar: Indivduos e interao MAIS QUE processos e ferramentas; Software em funcionamento MAIS QUE documentao abrangente; Colaborao com o cliente MAIS QUE negociao de contratos; Responder a mudanas MAIS QUE seguir um plano.

Mesmo tendo valor os itens direita, valorizamos mais os itens esquerda.

21

XP

Metodologia adequada a equipes pequenas (at 10 pessoas), parte do princpio de que a melhor documentao o cdigo fonte: qualquer outra documentao fica logo desatualizada e por isso perde a confiabilidade. Desenvolvida em 1996 por Kent Beck, uma metodologia bastante nova que renega todos os paradigmas do desenvolvimento tradicional de software. Para a XP, a arquitetura do sistema uma metfora. A arquitetura na verdade desenvolvida ao longo do projeto onde todo o cdigo escrito constantemente reconstrudo para aumentar a simplicidade e objetividade do mesmo. A XP vem ganhando inmeros adeptos dentre os programadores mais experientes.
22

XP

Baseada em prticas, como programao aos pares, semana de 40 horas e reunies em p. Frases conhecidas:

1) Sem um processo, s uma pessoa excepcional consegue desenvolver um sistema. Com muitos processos, pessoas excepcionais no conseguem desenvolver sistemas excepcionais. 2) Uma boa equipe pequena produz mais que grandes equipes.

23

XP

As Prticas do XP

The Customer is Always Available - O cliente est sempre disponvel para resolver dvidas, alterar o escopo de uma iterao e definir prioridades. Metaphor - O time se comunica sobre o software em termos de uma metfora, caso consiga encontrar uma boa. Small Releases - O software entregue em pequenas verses para que o cliente possa obter o seu ganho o mais cedo possvel e para minimizar riscos. Acceptance Tests - So definidos pelo usurio e so os critrios de aceitao do software. Test First Design - Primeiro so escritos os testes, depois feita a implementao e por ltimo trabalha-se o design. Continuous Integration - Os diversos mdulos do software so integrados diversas vezes por dia e todos os testes unitrios so executados. O cdigo no passa at obter sucesso em 100% dos testes unitrios.
24

XP

As Prticas do XP

Simple Design- O cdigo est, a qualquer momento, na forma mais simples que passe todos os testes. Refactoring - A cada nova funcionalidade adicionada, trabalhado o design do cdigo at ficar na sua forma mais simples. Pair Programming - Todo cdigo de produo desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. Collective Code Ownership - E equipe como um todo responsvel por cada arquivo de cdigo. No preciso pedir autorizao para alterar qualquer arquivo. Coding Standards - Todo cdigo desenvolvido seguindo um padro. 40 Hour Week - Trabalhar por longos perodos contraproducente.
25

ASD - Adaptative Software Development

Foi proposta por Jim Highsmith como uma tcnica para construo de software complexos. O apoio filosfico do ASD concentra-se na colaborao humana e na auto-organizao. A auto-organizao aparece quando agentes individuais independentes cooperam para criar resultados emergentes. Um resultado emergente uma propriedade alm da capacidade de qualquer agente individual. Ciclo de vida:

Especulao: iniciao do projeto e planejamento adaptativo. Colaborao: pessoal motivado trabalha junto de um modo que multiplica seus talentos e resultados criativos. Aprendizado que pode ocorrer de trs modos:

foco nos grupos; reviso tcnicas formais; ps-concluso.

26

DSDM - Dynamic Systems Development Methed

Fornece um arcabouo para construir e manter sistemas que satisfazem s restries de prazo apertadas por maio de prototipagem incremental em um ambiente controlado de projeto. Segue uma adaptao do princpio de Pareto: 80% de uma aplicao pode ser entregue em 20% do tempo total do projeto. Pode ser utilizada em conjunto com a XP e ASD. Ciclo de vida:

Estudo de viabilidade: verifica se o uso da DSDM vivel. Estudo do negcio: estabelece requisitos funcionais e arquitetura do sw. Iterao do modelo funcional: gera prottipos para interao com o usurio. Iterao de projeto e construo: revisa os prottipos construdos durante a iterao do modelo funcional para garantir que cada um tenha passado por engenharia, de modo que seja capaz de fornecer valor de negcio operacional para os usurios finais. Implementao: coloca o ltimo incremento de software no ambiente operacional, caso seja necessrio pode-se retornar atividade de iterao do 27 modelo funcional.

Scrum

O nome derivado de uma atividade que ocorre durante um jogo de rugby. Princpios:

Pequenas equipes de trabalho so organizadas de modo a maximizar a comunicao, minimizar a superviso e maximizar o compartilhamento de conhecimento tcito informal. O processo precisa ser adaptvel tanto a modificao tcnicas quanto de negcio. O processo produz freqentes incrementos de softawre. O trabalho de desenvolvimento e o pessoal que o realiza dividido em parties claras de baixo acoplamento , ou em pacotes. Testes e documentaes constantes so realizados medida que o produto construdo. Atividades do processo: requisitos, anlise, projeto, evoluo e entrega.
28

Crystal

Alistair Cockburn e Jim Highsmith criaram a famlia Crystal de mtodos geis a fim de conseguir uma abordagem de desenvolvimento de software que permeia a manobrabilidade. A famlia Crystal consiste de um conjunto de processos geis que se mostram efetivos para diferentes tipos de projeto. A inteno permitir que equipes geis selecionem o membro da famlia Crystal mais apropriado para seu projeto e ambiente.

29

FDD - Feature-Driven Development

A Feature-Driven Development (Desenvolvimento Dirigido por Funcionalidade) surgiu em meados de 1997, em um projeto para um grande banco em Singapura, a partir de tcnicas de gerenciamento de projetos e de modelagem orientada a objetos. Jeff De Luca era o gerente do projeto e Peter Coad foi contratado para fazer a modelagem do domnio do problema.

Utilizando as tcnicas de De Luca com as estratgias e padres de Coad, nascia uma metodologia que equilibra as vantagens das metodologias rigorosas (planejamento e modelagem, por ex.) e das metodologias geis (ciclos curtos, orientao ao cliente, nfase em programao).
Oferece os benefcios de processos rigorosos, como modelagem, planejamento prvio e controle do projeto, ao mesmo tempo em que permite que os desenvolvedores dediquem-se quilo que realmente gostam de fazer: programar e entregar produtos teis e de qualidade.
30

FDD

A FDD compreende 5 processos:

Obs: uma caracterstica uma funo valorizada pelo cliente que pode ser implementada em duas semanas ou menos.

31

FDD

Uma das maiores atraes da FDD so os relatrios de acompanhamento. Com sua origem em experincias de gerenciamento de projetos, certamente essa nfase em ver o que acontece durante o desenvolvimento uma caracterstica tpica. E justamente essa visibilidade que permite tomar decises relativas aos riscos, qualidade, mudanas nos requisitos, utilidade para o usurio do produto e vrias outras variveis do projeto, em tempo hbil para no prejudic-lo.
32

Model Driven Architecture (MDA)

Mecanismo de organizao e gerenciamento de arquiteturas corporativas com suporte de ferramentas e servios automatizados para a definio de modelos e realizar a transformao entre diversos tipos de modelos. MDA muito mais amplo que desenvolvimento de software (ex: Processos de negcio, modelagem de banco de dados, modelos de computao, etc.). Princpio bsico: Separao clara entre lgica do negcio e tecnologias de implementao.
33

Model Driven Architecture (MDA)

http://omg.org/mda

34

Model Driven Architecture (MDA)

Analista de negcio/arquitetos descrevem modelos independentes de plataforma (PIM), usualmente em UML. Transformaes automatizam a gerao de modelos especficos de plataforma (PSM). Transformaes so escritas por arquitetos com conhecimento de MDA ou desenvolvedores de ferramentas MDA. PSM tem pontos de extenso para incluso de comportamento no automatizados pelas transformaes. Mudanas e manutenes so feitas preferencialmente ou somente no modelo PIM.
35

Model Driven Development (MDD)

Desenvolvimento de software centrado em modelos Foco central o modelo em todo o desenvolvimento de software. Aplicao de conceitos MDA para o ciclo de desenvolvimento de software. Termo criado pelo comunidade de modelers que acreditam nas idias MDA em um certo nvel, mas so mais flexveis.

36

MDA/MDD

Migrar de um desenvolvimento baseado em cdigo para um desenvolvimento baseado em modelo no burocrtico, mas uma mudana cultural forte. Modelos podem (e devem) ser geis.

37

MDA/MDD

MDA/MDD ainda est em fase inicial de evoluo. Entretanto, ferramentas de modelagem de terceira gerao (ex: IBM RSA) j implementam boa parte da infra-estrutura necessria para a criao de transformaes (e consequentemente frameworks orientados por modelos).

38

Manuteno de Software

Corretiva: corrigir erros. Adaptativa: adaptar o software a modificaes no seu ambiente externo. Perfectiva ou de melhoria: fazer melhorias solicitadas pelos usurios Preventiva ou reengenharia: realizar reengenharia para uso futuro, o que melhora a manunitebilidade.

Obs: 60% do esforo gasto com Software manuteno:

20% correo. 80% demais casos.

39

Ferramentas CASE

Toda a ferramenta ou mtodo que ajude num processo de construo lgica ou fsica, documentao ou teste pode ser considerada uma ferramenta CASE (Computer Aided Software Engineering). uma ferramenta ou conjunto de ferramentas que automatizam tarefas que compem o processo de desenvolvimento de software. Sistema Computacional composto de ferramentas que suportam a automao do ciclo de vida do software e permite o uso efetivo dos princpios e prticas gerais de engenharia de software.
40

Categorias de Ferramentas CASE

Horizontais: oferecem servios utilizados durante todo o processo de software. Verticais: utilizadas em fases especficas do processo de software. As diferentes perspectivas na definio das ferramentas CASE resultaram em confuso acerca das categorias e tipos de ferramentas CASE. O mais aceito a definio de trs grandes categorias de ferramentas CASE que so identificadas principalmente em como e quando so usadas no processo de desenvolvimento:
Upper CASE : Para o planejamento inicial, anlise de requisitos ou fases de desenho conceitual. Estas ferramentas incluem produtos que captam requisitos ou produzem e gerem modelos. Lower CASE: Para automatizao das fases de desenvolvimento de sistemas, de desenho , construo ou instalao. Estas ferramentas incluem qualquer produto que ajude na fase ps planejamento e anlise de desenvolvimento. I-CASE - (Integrated CASE): Para a fase inicial de planejamento e todo o processo de instalao. Este conjunto ferramentas integram as duas anteriores e suportam todo o processo de desenvolvimento
41

Engenharia Reversa

O processo tradicional de engenharia de software, caracterizado pelas atividades progressivas do ciclo de vida, que partem de um alto nvel de abstrao, para um baixo nvel de abstrao, conhecido como Engenharia Progressiva. O processo inverso Engenharia Progressiva, caracterizado pelas atividades retroativas do ciclo de vida, que partem de um baixo nvel de abstrao para um alto nvel de abstrao, conhecido como Engenharia Reversa Engenharia Reversa tem por objetivo principal contribuir, primeiramente, no entendimento e, posteriormente, na modificao e revalidao do software, aumentando assim a manutenibilidade do mesmo. Isto feito atravs de um processo de anlise que procura criar representaes dos programas em uma forma mais clara ou em um nvel mais alto de abstrao que o cdigo fonte 42

Engenharia Reversa

Fases genricas do ciclo de vida:

Sistema Requisitos Desenvolvimento

43

Engenharia Reversa

Processo de exame e compreenso do software existente, para recapturar ou recriar o projeto e decifrar os requisitos atualmente implementados pelo sistema, apresentando-os em um grau ou nvel mais alto de abstrao. No envolve mudanas no software ou criao de um novo software. Processo de anlise num esforo de criar uma representao do programa em um nvel de abstrao mais alto que o cdigo fonte.

44

Engenharia Reversa

Categorias:

Visualizao de Cdigo : tambm denominada Redocumentao, a criao ou reviso de representaes semanticamente equivalentes num mesmo nvel de abstrao. O processo de Visualizao de Cdigo cria as representaes a partir de informaes obtidas apenas da anlise do cdigo fonte, embora a apresentao dessas informaes possa se diversificar. As formas das representaes so consideradas vises alternativas, cujo o objetivo melhorar a compreensibilidade do sistema global. Entendimento de Programa: nesta categoria de engenharia reversa, tambm denominada Recuperao de Projeto, o conhecimento do domnio das informaes externas e as dedues so adicionadas s observaes feitas sobre o sistema atravs do exame do mesmo, de modo a obter informaes com nvel mais alto de abstrao.
45

Reengenharia

Qualquer atividade que:

Melhore o entendimento do software Prepare ou melhore o software em si, aumentando sua manuteno, seu reuso e sua extenso o exame e a alterao de um sistema para reconstitu-lo de uma nova forma, seguida pela sua implementao

Chikofsky e Cross definem reengenharia:

Sinnimos de Reengenharia: melhoramento, renovao, modernizao, engenharia de re-desenvolvimento, engenharia de reuso. Reengenharia:

sem mudana de funcionalidade, mudana parcial de funcionalidade, mudana total de funcionalidade.

46

Modelo de Processo de Reengenharia de Software

47

Verificao e Validao do Software

O teste de software um elemento de um aspecto amplo, que freqentemente referido como verificao e validao. Verificao: se refere ao conjunto de atividades que garante que o software implementa corretamente uma funo especfica. Validao: se refere ao conjunto de atividades que garante que o software construdo corresponde aos requisitos do cliente. Verificao: estamos construindo o produto corretamente? Validao: estamos construindo o produto correto?

48

Verificao e Validao do Software

V&V engloba muitas das atividades que so abrangidas pela garantia da qualidade de software (SQA), tais como:

Revises tcnicas formais; Auditoria de qualidade e configurao; Monitoramento do desempenho; Simulao; Estudo de viabilidade; Reviso da documentao; Reviso da base de dados; Anlise de algoritmos; Teste de desenvolvimento; Teste de usabilidade; Teste de instalao;
49

Estratgia de Testes

Teste de Sistema Teste de Validao Teste de Integrao Teste de Unidade Cdigo Projeto Requisitos Engenharia de Sistemas

50

Estratgia de Testes

Teste de Unidade: focaliza o esforo de verificao na menor unidade de projeto de software. considerado um apndice do passo de codificao. Teste de Integrao: seu objetivo , a partir de componentes testados no nvel de unidade, construir uma estrutura de programa determinada pelo projeto. Teste de Validao: comea no fim do teste de integrao, quando componentes individuais j foram exercitados, o software est completamente montado como um pacote, e os erros de interface foram descobertos e corrigidos. Teste de Sistema: o software apenas um elemento de um sistema maior baseado em computador (pessoal, hardware, informao). Esses testes saem do escopo do processo de software e no so conduzidos somente por engenheiros de software.
51

Caractersticas do Teste

Atributos para um bom teste:

Um bom teste tem alta probabilidade de encontrar um erro. Um bom teste no redundante. Um bom teste deve ser de boa cepa. Um bom teste no deve ser muito simples nem muito complexo.

52

Testabilidade

Testabilidade:

quo fcil um programa pode ser testado.

Operabilidade: quanto melhor funciona, mais eficientemente pode ser testado. Observabilidade: o que voc v o que voc testa. Controlabilidade: quanto melhor voc pode controlar o software, mais o teste pode ser automatizado e otimizado. Decomponibilidade: controlando o escopo do teste, podemos isolar problemas mais rapidamente e realizar retestagem mais racionalmente.
53

Caractersticas:

Testabilidade

Caractersticas (continuao):

Simplicidade: quanto menos houver a testar, mais rapidamente podemos test-lo. Estabilidade: quanto menos modificaes, menos interrupes no teste. Compreemsibilidade: quanto mais informaes temos, mais racionalmente vamos testar.

54

FIM