Engenharia de-software-1217199594686494-9

Engenharia de SoftwareEngenharia de Software

Tópicos – Engenharia de SoftwareTópicos – Engenharia de Software

O que é?O que é? CamadasCamadas Perguntas que devem ser respondidasPerguntas que devem ser respondidas Fases genéricas da Engenharia de SoftwareFases genéricas da Engenharia de Software Modelos de Processos de Engenharia de SoftwareModelos de Processos de Engenharia de Software Modelos de Processos de Desenvolvimento de Modelos de Processos de Desenvolvimento de

SoftwareSoftware RUP - RUP - (Rational Unified Process)

O que é Engenharia de Software?O que é Engenharia de Software?

É um conceito que está baseado em camadas:

Qualidade: Toda engenharia deve se fundamentar no comprometimento com a qualidade;

Processo: É a base da engenharia de software. É o processo que “cola” as ferramentas e os métodos;

Métodos: Fornecem a definição do “como fazer” o desenvolvimento de software;

Ferramentas: Realizam o suporte automatizado ou semi-automatizado para os processos e métodos (exemplo: ferramentas CASE);

Camadas de Engenharia de Camadas de Engenharia de SoftwareSoftware

Foco em Qualidade

Processos

Métodos

Ferramentas

Perguntas que devem ser respondidasPerguntas que devem ser respondidas

1) Qual é o problema a ser resolvido?

2) Quais características do software a ser gerado resolvem o problema?

3) Como o software (a solução) serão concebidos?

4) Como o software será construído?

5) Qual a abordagem que será utilizada para cobrir erros feitos no projeto e construção do software?

6) Como o software será mantido a longo prazo, quando correções, adaptações e melhorias forem requeridas por usuários do software?

Fases Genéricas da Engenharia de Fases Genéricas da Engenharia de SoftwareSoftware

Modelos de Processos de Engenharia Modelos de Processos de Engenharia de Softwarede Software

Para resolver problemas reais, o engenheiro de software deve aplicar uma estratégia de desenvolvimento que contemple as camadas de processos, métodos e ferramentas;

Esta estratégia é o modelo de processo ou paradigma de engenharia de software;

É escolhido baseado na natureza do projeto e aplicação, nos métodos e ferramentas a serem utilizados e nos controles e entregas requeridos;

Os modelos definem ordem para uma atividade inerentemente caótica;

Modelos de Processos de Modelos de Processos de Desenvolvimento de SoftwareDesenvolvimento de Software

Modelo Linear Seqüencial

Modelo de Prototipação

Modelos Evolucionários- Incremental- Espiral

RUP – Rational Unified Process

Atividades de suporte : independentes do modelo de

processo - Garantia de Qualidade de Software- Gerenciamento da Configuração do Software- Mensuração de Software

Modelo Linear SeqüencialModelo Linear Seqüencial

Também chamado de “ciclo de vida clássico” e “modelo cascata”;

Sugere uma abordagem seqüencial para o desenvolvimento de software;

AnáliseProjeto (Design) Codificaçã

oTestes

Engenharia do Sistema / Informação

Engenharia do sistema/informação: O software é parte de um sistema maior. Por isso, o trabalho inicial com a definição dos elementos do sistema e do software, é realizada uma análise do projeto superficial;

Análise: Intensificação do levantamento de requisitos, agora focado no software. Define domínio de informação, funcionalidade, comportamento, performance e interface;

Projeto (design): Traduz os requerimentos para uma representação técnica;

Codificação: É a tradução do projeto em uma linguagem de programação. Se o projeto for detalhado, a codificação é um processo mecânico;

Teste: Teste do programa codificado. Pode ser da lógica interna do software ou focado nas funcionalidades externas;

Suporte: Corrige e adapta o software gerado. Reaplica as fases precedentes no programa existente.



É o mais antigo paradigma de engenharia de software;

Problemas do modelo linear seqüencial:

Projetos reais raramente seguem a ordem seqüencial proposta e mudanças nesta seqüência podem causar confusão na equipe de projeto;

É difícil para os usuários definir todos os requisitos explicitamente. O modelo seqüencial requer esta definição e é difícil acomodar incertezas nos requisitos;

O cliente deve ter paciência. Uma versão “visível” do programa estará disponível somente no fim do projeto. Erros percebidos somente nesta fase podem ser tornar um desastre;

Modelo de PrototipaçãoModelo de Prototipação

Permite que o cliente “perceba” o software que está sendo gerado antes da finalização;

Atividades do modelo:

Definição de requisitos;

Projeto “Rápido”: foca em representar os aspectos do software que serão visíveis ao usuário. É a construção de um protótipo;

Avaliação do Protótipo: o usuário avalia o protótipo e refina os requisitos;

Natureza iterativa: as atividades se repetem até que o software fique pronto;

Problemas:

O cliente vê o que parece ser uma versão que funciona do software. Apesar das grandes mudanças que devem ser feitas para que o protótipo se torne um software completo e com qualidade, o cliente pode querer fazer “remendos” no protótipo para iniciar o uso;

Práticas não desejáveis de codificação podem ser utilizadas para construção do protótipo e depois “esquecidas”, tornando-se a solução definitiva;

“Software nunca está pronto”...


A natureza evolucionária do software não é considerada explicitamente nem no modelo linear seqüencial, nem no modelo de prototipação;

Os modelos evolucionários são iterativos, ou seja, são caracterizados de maneira que permitem aos engenheiros de software, construções com versões cada vez mais completas do software;

Veremos dois tipos de modelos evolucionários:- Incremental- Espiral

Modelos EvolucionáriosModelos Evolucionários

O modelo incremental combina elementos do modelo linear seqüencial (aplicado repetidamente) com a filosofia iterativa da prototipação;

Cada seqüência linear produz um “incremento” entregável (deliverable) do software;

Exemplo de um processador de texto:– Primeiro entregar funções básicas de

manipulação de arquivo;

– Depois, entregar funcionalidades de edição e produção de documentos mais avançadas;

– No terceiro incremento, entregar verificação de grafia e gramática;

– ...

Modelo IncrementalModelo Incremental

A cada incremento, o usuário pode utilizar o produto gerado ou fazer uma revisão detalhada;

O próximo incremento deve implementar as solicitações do usuário, mais as novas funcionalidades planejadas;

O processo é repetido até que o produto completo é entregue;



O modelo incremental, como o de prototipação, é iterativo. Mas diferentemente do de prototipação, ele foca em entregar um produto operacional em cada incremento;

É um modelo que acopla a natureza iterativa da prototipação com os aspectos sistemáticos e controlados do modelo linear seqüencial;

O software é desenvolvido em uma série de “releases” incrementais: nas primeiras iterações podem apenas ser um modelo em papel ou um protótipo; nas últimas, versões cada vez mais completas do software são produzidas;

Modelo EspiralModelo Espiral


O modelo espiral é dividido em um número de atividades, chamadas regiões de tarefas. Tipicamente, existem de 3 a 6 regiões;

Comunicação com cliente: tarefas requeridas para estabelecer comunicação efetiva entre desenvolvedor e cliente;

Planejamento: tarefas requeridas para definir recursos, tempos de tarefas e outras atividades de planejamento;

Análise de Risco: tarefas requeridas para avaliar riscos técnicos e de gerenciamento;

Engenharia: tarefas requeridas para construir um ou mais representações da aplicação;

Construção e Entrega: tarefas requeridas para construir, testar, instalar, e prover suporte ao usuário;

Avaliação do cliente: tarefas requeridas para obter feedback do cliente baseado na avaliação das representações do software criadas durante o estágio de engenharia;


Cada região possui um conjunto de tarefas, que são adaptadas às características do projeto a ser iniciado. Para pequenos projetos, poucas tarefas. Para grandes projetos, mais tarefas para garantir nível maior de formalidade;

Quando o processo inicia, a equipe de desenvolvimento se move na espiral em sentido horário, iniciando no centro:

- O primeiro circuito resulta no desenvolvimento da especificação;

- O subseqüente, pode ser usado para desenvolvimento do protótipo;

- Cada passagem na região de Planejamento resulta em ajustes no plano de projeto (inclusive o número de iterações necessárias para finalizar o projeto);


Não termina quando o software é entregue: pode ser adaptado a todo o ciclo de vida do software;

“Eixos de Entrada de Projeto”: cada cubo localizado no eixo pode ser utilizado para representar o ponto de início de diferentes tipos de projetos;


Projeto de Desenvolvimento de Conceito: inicia no centro da espiral e continua na espiral até que esteja completo (área mais escura);

Se o conceito será desenvolvido na forma de um produto, o processo continua através do próximo cubo (ponto de entrada de desenvolvimento de novo produto). O novo produto evolui na espiral na área em cinza médio;

Em essência, se a espiral for vista dessa forma, ela continua até que o software é retirado de uso;

Problemas:

- Pode ser difícil convencer os clientes de que a abordagem evolucionária é controlável;

- O modelo não é usado na mesma extensão que o linear e o de prototipação, e, por isso, não foi “testado” o suficiente;


As demandas atuais para softwares poderosos e complexos não têm sido atendidas pela forma como softwares são desenvolvidos. Hoje em dia, muitas pessoas desenvolvem software usando modelos de 25 anos atrás;

A comunidade de software precisava de um processo que:

- Provesse um guia para a ordem das atividades da equipe do projeto;

- Direcionasse as tarefas dos desenvolvedores e da equipe como um todo;

- Especificasse quais os artefatos que devem ser desenvolvidos;

- Oferecesse critérios para monitoramento e medida dos produtos

atividades de um projeto;

RUP - RUP - (Rational Unified Process)

O RUP é um modelo de processo de desenvolvimento de software (dessa forma, ele descreve um conjunto de atividades para transformar os requisitos do usuários em um software);

É baseado em componentes: o sistema de software sendo desenvolvido é feito de componentes de software interconectados via interfaces bem definidas;

Utiliza a UML (Unified Modeling Language)

RUP - RUP - (Rational Unified Process)

Direcionado a Caso de Uso: o processo de desenvolvimento segue um fluxo (procede) através de uma série de workflows que derivam dos casos de uso;

Centrado em Arquitetura: o processo do RUP ajuda o arquiteto a focar nos objetivos corretos, como entendimento, resiliência a mudanças futuras e reuso. Casos de uso e arquitetura se completam e devem evoluir em paralelo;

Iterativo e incremental: divide o trabalho de engenharia do software em “mini-projetos” ou iterações. Cada iteração resulta em um incremento no produto;

Características Fundamentais

Em cada iteração, os desenvolvedores identificam e especificam casos de uso relevantes, criam um projeto usando a arquitetura escolhida como um guia, implementam o projeto em componentes e verificam se os componentes satisfazem o caso de uso;

Se a iteração atinge seu objetivo, prossegue-se para a próxima iteração. Quando não, os desenvolvedores revisam suas decisões e tentam nova abordagem;

Iterações

A iteração controlada reduz o custo do risco às despesas de um único incremento, e não do produto pronto;

A iteração controlada reduz o risco de não colocar o produto no mercado no tempo esperado, ou seja, os riscos são descobertos antes;

Acelera o tempo de desenvolvimento porque trabalha com tarefas mais curtas e focadas;

Reconhece uma realidade geralmente ignorada: necessidades dos usuários e requerimentos não podem ser definidos logo no início. São tipicamente refinados em iterações sucessivas.

Benefícios das Iterações

Segundo o RUP, um produto de software deve ter:

Um modelo de casos de uso com todos os casos de uso e seus relacionamentos com usuários;

Um modelo de análise que tem dois propósitos: refinar os casos de uso em mais detalhes e fazer uma alocação inicial do comportamento do sistema em uma série de objetos que provêem o comportamento;

Um modelo de projeto (design) que define: a) a estrutura estática do sistema como subsistemas, classes e interfaces; e b) os casos de usos realizados como colaborações entre os subsistemas, classes e interfaces;

Um modelo de implementação, que inclui componentes (representando código fonte), e mapeando as classes para os componentes;

Um modelo de implantação (deployment), que define os nós físicos dos computadores e os mapeamentos dos componentes para estes nós;

Um modelo de testes, que descreve os casos de teste e verifica os casos de uso;

E uma representação da arquitetura;

O Produto de Software do RUP

O Produto de Software do RUP

O processo unificado repete uma série de ciclos que formam a vida de um sistema. Cada ciclo é concluído com uma release (entrega) aos clientes;

Cada ciclo consiste de 4 fases: inception (iniciação), elaboration (elaboração), construction (construção), transition (transição) e cada fase é dividida em iterações;

O Ciclo de Vida do RUP

O Ciclo de Vida do RUP

Uma fase termina com um marco (milestone), que é definido pela disponibilidade de certos artefatos (modelos ou documentos) em um determinado estado;

Dentro de cada fase, são realizadas iterações. Uma iteração é equivalente a um “mini-projeto”;

Fases e Iterações do RUP

Iniciação: o foco é chegar a um acordo com os stakeholders quanto à visão do sistema e aos objetivos e estimativas das demais fases do ciclo/projeto;

Elaboração: esta fase é um processo de engenharia, onde o foco está em especificar uma arquitetura robusta e confiável para o sistema e fazer o planejamento para o restante do ciclo/projeto;

Construção: a fase de construção basicamente consiste num processo de manufatura, onde o foco está na construção do sistema e no gerenciamento dos recursos e otimização de tempo, custos e qualidade;

Transição: o objetivo desta fase é transferir o produto para a comunidade de usuários. Pode ser apenas uma release do produto, e não o produto final.

Fases

Os processos são procedimentos compostos de atividades logicamente seqüenciadas e têm objetivos específicos em relação ao projeto;

O RUP possui 6 processos de engenharia e 3 processos de suporte, também chamados de disciplinas;

As Disciplinas do RUP

Engenharia:

– Modelagem de Negócio: foca no entendimento do negócio ser automatizado pelo software;

– Requisitos: foca no entendimento dos requisitos do software;

– Análise e Design: análise dos requisitos e projeto (design) do software;

– Implementação: codificação dos componentes;

– Teste: avaliação do sistema em relação aos requisitos;

– Implantação: entrega do software;

Suporte:– Gerenciamento de Projeto;

– Gerenciamento de Configurações e Mudanças;

– Ambiente: preparação do ambiente para desenvolvimento do projeto;


Quando o projeto amadurece, a ênfase em certas atividades das disciplinas aumenta ou diminui;

As atividades podem ser executadas qualquer tempo durante o ciclo de vida do projeto;


Engenharia de-software-1217199594686494-9

Documents

Transcript of Engenharia de-software-1217199594686494-9