Aula 3

Prévia do material em texto

Introdução à Engenharia de Software
Ementa
Introdução à Engenharia de Software;
Desenvolvimento Ágil;
Engenharia de Requisitos;
UML;
Modelos de Processo
Modelos Prescritivos de Processo
Modelo em Cascata;
Modelo Incremental;
Modelo RAD;
Modelos Evolucionários;
Modelo de Prototipagem;
Modelo Espiral;
Modelo de Desenvolvimento Concorrente;
Modelos Especializados de Processo;
Desenvolvimento Baseado em Componentes;
Modelo de Métodos Formais;
Desenvolvimento Orientado a Aspectos;
Modelos Prescritivos de Processo
Modelo Cascata;
Modelo Incremental;
Modelo RAD;
Modelo Cascata
Planejamento
Comunicação
Modelagem
Construção
Implantação
Modelo Cascata
Também chamado de ciclo de vida clássico;
Sugere uma abordagem sistemática e sequencial;
É o paradigma mais antigo da engenharia de software;
Ideal quando os requisitos são bem definidos, razoavelmente estáveis (de preferência fixos) e o trabalho pode prosseguir até o fim de modo linear;
Modelo Cascata
Tem sido constantemente criticado, questionando-se sua eficácia;
Projetos reais raramente seguem um fluxo sequencial;
É difícil para o cliente estabelecer todos os requisitos explicitamente. Não acomoda muito bem a incerteza natural que existe no início dos projetos;
O cliente precisa de paciência. O programa executável ficará disponível somente no final do projeto;
Modelo Incremental
Incremento 1
Incremento 2
Incremento n
Entrega do
Incremento 1
Entrega do
Incremento 2
Entrega do
Incremento n
Tempo decorrido do projeto
Funcionalidades do software
Comunicação
Planejamento
Modelagem
Construção
Implantação
Modelo Incremental
Combina elementos do modelo cascata aplicado de maneira iterativa;
Aplica sequências lineares de forma racional à medida que o tempo passa;
Cada sequência linear produz “incrementos” de software possíveis de ser entregues;
O primeiro incremento é chamado de núcleo do produto;
Os requisitos básicos são satisfeitos, mas características suplementares deixam de ser elaboradas;
O núcleo do produto é usado pelo cliente;
Modelo Incremental
Um plano é desenvolvido para o próximo incremento como resultado do uso;
Visa a modificação do núcleo do produto para melhor satisfazer às necessidades do cliente;
Elaboração de características e funcionalidades adicionais;
O processo é repetido a cada incremento, até que o produto esteja completo;
Modelo RAD
60 – 90 dias
Comunicação
Planejamento
Modelagem
Construção
Modelagem
Construção
Modelagem
Construção
Implantação
Equipe 1
Equipe 2
Equipe n
Modelo RAD
RAD (Rapid Application Development) é um modelo incremental de ciclo de desenvolvimento curto;
Mistura atividades do modelo cascata com o modelo incremental;
Adaptação do modelo cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes;
Sendo os requisitos bem compreendidos e o objeto do projeto restrito, o processo RAD cria um sistema funcional no período de 60 a 90 dias;
Modelo RAD
Para projetos grandes, exige recursos humanos suficientes para criar várias equipes RAD;
Desenvolvedores e clientes devem estar comprometidos com atividades continuamente rápidas;
O sistema precisa ser adequadamente modularizado;
O modelo RAD pode não ser adequado quando os riscos técnicos são altos;
Modelos Evolucionários de Processo
Modelo Espiral;
Prototipagem;
Modelo de Desenvolvimento Concorrente;
Modelo Espiral
Comunicação
Planejamento
Modelagem
Implantação
Construção
Início
Modelo Espiral
Modelo de processo evolucionário que combina a natureza iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo cascata;
Fornece o potencial para o desenvolvimento rápido de versões de software cada vez mais completas;
Diferentemente de outros modelos, que terminam quando o software é entregue, o modelo espiral pode ser adaptado para aplicação ao longo da vida do software;
Modelo Espiral
O primeiro circuito em volta da espiral pode representar um projeto de desenvolvimento de conceitos que começa no centro da espiral e continua por várias iterações até que o projeto seja completado;
Se for um projeto de desenvolvimento de novo produto, o novo produto vai evoluir por meio de num número de iterações em torno da espiral;
Quando pronto, um novo circuito em volta da espiral poderia ser usado para representar um projeto de aperfeiçoamento do produto;
Modelo Espiral
Permanece operacional até que o software seja retirado de serviço;
Há momentos que o processo fica adormecido, mas sempre que um modificação é iniciada, o processo começa do ponto de entrada;
Como o software evolui a medida que o processo avança, o desenvolvedor e o cliente entendem melhor e reagem aos riscos de cada nível evolucionário;
Usa a prototipagem como mecanismo de redução de risco e permite ao desenvolvedor aplicar a prototipagem em qualquer estágio do produto;
Modelo Espiral
Pode ser difícil convencer os clientes (principalmente por questões de contrato) que a abordagem evolucionário é controlável;
Exige competência considerável na avaliação dos riscos e depende dessa competência para obter sucesso;
Se um risco importante não for descoberto e gerenciado, fatalmente ocorrerão problemas;
Prototipagem
Plano rápido
Construção do
protótipo
Implantação
Entrega e
Feedback
Comunicação
Modelagem
Plano rápido
Prototipagem
Apesar de poder ser usada como modelo de processo independente, é mais comumente usada dentro do contexto dos outros processos;
Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos;
A iteração de prototipagem é planejada e modelada rapidamente. O projeto rápido concentra-se nos aspectos visíveis para o cliente e leva à construção de um protótipo que é implantado e avaliado pelo cliente. O feedback refina os requisitos do software;
Prototipagem
O que fazer com o protótipo?
Pode ser lento, grande, complicado de usar ou tudo isso ao mesmo tempo. A alternativa é começar novamente e construir uma versão projetada;
Planejar antecipadamente a construção de um protótipo descartável;
Mas o protótipo pode servir como “o primeiro sistema” e evoluir a partir de então;
Desenvolvimento Concorrente
Em desenvolvimento
Pronto
Aguardando modificações
Em revisão
Sob inspeção
Transformado em referência
Nenhum
Desenvolvimento Concorrente
Todas as atividades ocorrem em paralelo, mas estão em diferentes estados;
O modelo define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades;
Em vez de usar uma sequencia como o modelo cascata, ele define uma rede de atividades;
Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de como está o estado do projeto;
Desenvolvimento Concorrente
Exemplo: Começo de projeto
A atividade de comunicação completou sua primeira iteração e está no estado aguardando modificações;
A atividade de modelagem passa do estado nenhum para o estado em desenvolvimento.
Se o cliente requere mudança nos requisitos, a modelagem passa de em desenvolvimento para aguardando modificações e a comunicação passa de aguardando modificações para em revisão;
Modelos Especializados de Processo
Desenvolvimento baseado em componentes;
Modelo de métodos formais;
Desenvolvimento orientado a aspectos;
Desenvolvimento Baseado em Componentes
Compõe aplicações a partir de componentes de software previamente preparados;
Segue os seguintes passos implantados com uma abordagem evolucionária:
Pesquisa e avaliação de componentes disponíveis para o domínio em questão;
Considerações sobre a integração de componentes;
Projeto de arquitetura de software;
Integração dos componentes à arquitetura;
Testes para garantir a funcionalidade adequada;
Desenvolvimento Baseado em Componentes
Leva ao reuso de software, que segundo estudos tem como vantagens:
Redução significativa do prazo de desenvolvimento;
Redução significativa no custo do projeto;
Aumento do índice de produtividade;
Em que situações o desenvolvimento baseado em componentes não é adequado?
Aquelas em que não existam componentes padrão disponíveis ou em que nãose queira pagar pelos componentes;
Modelo de Métodos Formais
Métodos formais permitem ao engenheiro de software especificar, desenvolver e verificar um sistema aplicando uma rigorosa notação matemática;
Uma variante chamada engenharia de software sala limpa é aplicada por algumas organizações;
Elimina muitos problemas encontrados nos outros modelos, como ambiguidade, incompletude, inconsistência, etc;
Servem de base para a verificação de programas, oferecendo a promessa de um software livre de defeitos;
Modelo de Métodos Formais
Apropriado para softwares críticos (por exemplo, de aeronaves e dispositivos médicos);
Porém, é um modelo de processo altamente lento e dispendioso;
Exige treinamento extensivo para dar aos desenvolvedores o preparo necessário;
É difícil usar os modelos como um mecanismo de comunicação com a maioria dos clientes;
Desenvolvimento Orientado a Aspectos
É um paradigma novo de engenharia de software que fornece mecanismos para definir, especificar, projetar e construir aspectos;
Aspectos são preocupações do cliente que permeiam diversos níveis do sistema, incluindo:
Propriedades de alto nível (ex: segurança, tolerância a falha);
Funções (ex: aplicação de regras de negócio);
Sistêmicas (ex: sincronização e gestão de memória);
Um processo orientado a aspectos ainda não foi totalmente desenvolvido, mas deve adotar características do modelo espiral e do modelo concorrente;
O Processo Unificado
É uma tentativa de unir os melhores recursos e características dos modelos convencionais;
Reconhece a importância da comunicação com o cliente e dos casos de uso para descrever a visão do cliente;
Utiliza a UML como a notação para modelagem e análise de projeto;
Sugere um fluxo de processo que é iterativo e incremental;
Também conhecido como RUP (de Rational Unified Process) – a Rational construiu ferramentas de apoio ao processo unificado;
Histórico do Processo Unificado
Década de 1980: popularização dos métodos de programação orientada a objeto (OO) levando a métodos variados de análise e projeto OO;
Início da década de 1990: Rumbaugh, Booch e Jacobson começaram a trabalhar em um “método unificado”, que resultou na UML e tornou-se uma norma industrial. A Rational e outros vendedores desenvolveram ferramentas UML;
Final da década de 1990: Jacobson, Rumbaugh e Booch desenvolvem o Processo Unificado, um arcabouço para engenharia de software OO;
Hoje em dia, o Processo Unificado e a UML são amplamente usados em projetos OO de todas as naturezas;
O Processo Unificado
É um processo incremental, ou seja, enquanto acontecem as fases de construção, transição e produção, já pode ser iniciado o incremento seguinte;
Um fluxo de trabalho de engenharia de software é distribuído ao longo de todas as fases do Processo Unificado;
Identifica as tarefas exigidas para realizar uma ação importante de engenharia de software;
Fases do Processo Unificado:
Elaboração: 
abrange as atividades de comunicação com o cliente, planejamento e modelagem. Refina e expande os casos de uso preliminares e expande a representação arquitetural para incluir cinco visões diferentes:
O modelo de casos de uso;
O modelo de análise;
O modelo de projeto;
O modelo de implementação;
O modelo de implantação;
O plano é revisto e pode ser modificado;
Fases do Processo Unificado
Construção:
Idêntica a atividade de construção no processo genérico:
Usa o modelo arquitetural como entrada;
Desenvolve ou adquire e integra componentes de software;
Torna cada caso de uso operacional;
Modelos de análise e projeto são completados;
Testes são elaborados e executados;
Fases do Processo Unificado
Transição: abrange atividades de construção e implantação:
O software é dado aos usuários finais para testes beta e relatórios de feedback que podem levar a modificações;
Informações de apoio necessárias são criadas (manuais e procedimentos de instalação);
Na conclusão dessa fase tem-se uma versão utilizável do software;
Fases do Processo Unificado
Produção: 
Abrange as atividades de implantação:
O uso do software é monitorado;
É fornecido suporte para o ambiente de operação;
Os relatórios de defeito e solicitações são recebidos e avaliados;
Fases do Processo Unificado
Concepção: 
Abrange atividades de comunicação com o cliente e de planejamento, tais como:
Requisitos de negócio usando casos de uso preliminares;
Arquitetura geral do sistema com os principais subsistemas e funções;
Planejamento com recursos, riscos e cronogramas;
Principais Produtos de Trabalho – Concepção
Documento de visão;
Modelo inicial de caso de uso;
Glossário inicial do projeto;
Caso de negócio inicial;
Avaliação inicial de risco;
Plano de projeto;
Modelo de negócio;
Um ou mais protótipos;
Principais Produtos de Trabalho – Elaboração
Modelo de caso de uso
Requisitos suplementares
Modelo de análise
Descrição da arquitetura do software
Protótipo arquitetural executável
Modelo de projeto preliminar
Lista de risco revisada
Plano de projeto incluindo planos de iteração, fluxos de trabalho adaptados, marcos, produtos técnicos de trabalho
Manual preliminar do usuário
Principais Produtos de Trabalho – Construção
Modelo de projeto
Componentes de software
Incremento integrado de software
Plano e procedimento de teste
Caso de teste
Documentação de apoio
Manuais do usuário
Manuais de instalação
Descrição do incremento atual
Principais Produtos de Trabalho – Transição
Incremento de software entregue
Relatório de teste beta
Realimentação geral do usuário
Padrões de Processo
O processo de software pode ser definido como uma coleção de padrões que definem um conjunto de:
Atividades;
Ações;
Tarefas de trabalho;
Produtos de trabalho;
Comportamentos de trabalho necessários ao desenvolvimento de software;
Pela combinação de padrões, uma equipe pode construir um processo que melhor satisfaça às características de um projeto;
Descrição de Padrões de Processo
Nome do Padrão: descreve sua função dentro do processo;
Intenção: descreve o objetivo do padrão;
Tipo:
– Padrão de Tarefa: define uma ação ou tarefa de trabalho;
– Padrão de Estágio: define uma atividade de arcabouço;
– Padrão de Fase: define uma sequencia de atividades de arcabouço;
• Contexto Inicial: descreve condições sob as quais o padrão se aplica;
• Problema: descreve o problema a ser resolvido pelo padrão;
• Solução: descreve como o estado inicial do processo é modificado em consequência da aplicação do padrão;
• Contexto Resultante: condições que resultarão quando o processo for aplicado;
• Padrões Relacionados: lista de todos os padrões relacionados a este;
• Usos Conhecidos/Exemplos: instâncias específicas nas quais o padrão é aplicável;
Exemplo
Nome do Padrão: Prototipação;
Intenção: Construir um protótipo que será avaliado iterativamente pelos interessados em solidificar requisitos de software;
Tipo: Padrão de fase;
Contexto Inicial:
– Interessados identificados;
– Modo de comunicação estabelecido;
– Problema identificado;
– Entendimento inicial do escopo, requisitos e restrições;
Problema: interessados estão inseguros do que desejam;
Solução: descrição do processo de prototipação;
Contexto Resultante: um protótipo de software que identifique os requisitos básicos é aprovado pelos interessados;
Padrões Relacionados: comunicação-com-o-cliente, projeto-iterativo, desenvolvimento-iterativo, avaliação-pelo-cliente, levantamento-derequisitos;
Usos Conhecidos/Exemplos: a prototipação é recomendada quando os requisitos são incertos;
Atividade
Formem duplas e escrevam uma descrição para o padrão de processo:
Comunicação-inicial-com-o-cliente
Incluindo nome, intenção, tipo (tarefa, estágio ou fase), contexto inicial, problema, solução, contexto resultante, padrões relacionados e usos conhecidos;