Modelos de processos de software
Upcoming SlideShare
Loading in...5
×
 

Modelos de processos de software

on

  • 1,940 views

 

Statistics

Views

Total Views
1,940
Views on SlideShare
1,940
Embed Views
0

Actions

Likes
0
Downloads
76
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Modelos de processos de software Modelos de processos de software Presentation Transcript

    • Engenharia de SoftwareUnidade II – Processos de SoftwareObjetivo: Apresentar os principais paradigmas e modelosde processos de software, demonstrando o ciclo de vida dodesenvolvimento de software e enfatizando os processosde especificação de requisitos, projeto, implementação,testes e mudanças Prof. Nécio de Lima Veras
    • Processos de Desenvolvimento deSoftware Vimos anteriormente que os processos definem uma estrutura, que consiste em áreas de processos chave. Percebemos também que Sommerville subdivide em quatro atividades básicas:  Especificação;  Desenvolvimento;  Validação; e  Evolução. Partindo disso, muitos modelos já foram propostos...
    • Roteiro... Então para esta aula, veremos:  Definições de processos e modelos de processos de software;  Alguns modelos existentes:  Cascata;  Evolucionário;  Desenvolvimento incremental;  Espiral; e  Prototipação.
    • Definições Processo de software:  “É uma seqüência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos”. Modelo de processo de software:  “Um modelo de processo de software é uma representação abstrata de um processo. Ele apresenta uma descrição de um processo a partir de uma perspectiva específica”.
    • O Modelo em Cascata Primeiro modelo publicado do processo de desenvolvimento de software; Originou-se de outros processos de engenharia; Retrata um desenvolvimento gradual e possui seqüência de passos em ordem que devem ser seguidos. Pode consumir um tempo estimado entre seis e dezoito meses;
    • O Modelo em Cascata:Principais Estágios Análise e Definição de Requisitos: as funções, as restrições e os objetivos do sistema são estabelecidos por meio de consulta aos usuários do sistema. Em seguida, são definidos em detalhes e servem como uma especificação do sistema.
    • O Modelo em Cascata:Principais Estágios Projeto de Sistemas e Software: o processo de projeto de sistemas agrupa os requisitos em sistemas de hardware e software. Envolve a identificação e a descrição das abstrações fundamentais do sistema de software e suas relações.
    • O Modelo em Cascata:Principais Estágios Implementação e Testes de Unidade: Durante este estágio, o projeto do software é compreendido como um conjunto de programas ou unidades de programa. O teste de unidade envolve verificar se cada uma das unidades atendem à sua especificação.
    • O Modelo em Cascata:Principais Estágios Integração e Teste de sistemas: as unidades de programa ou programas individuais são integrados e testados como um sistema completo a fim de garantir que os requisitos de software foram atendidos. Depois do teste, o software é entregue ao cliente.
    • O Modelo em Cascata:Principais Estágios Operação e manutenção: O sistema é instalado e colocado em operação. Envolve corrigir erros que não foram descobertos em estágios anteriores, melhorando a implemen- tação e descobrindo novos requisitos
    • O Modelo em Cascata: Problemas Particionamento inflexível do projeto em fases distintas; Isso torna difícil responder a requisitos do usuário que mudam; Portanto, esse modelo é apropriado somente quando os requisitos são bem compreendidos;
    • O modelo Evolucionário Tem com base a ideia de desenvolver uma implementação inicial, expor o resultado ao comentário do usuário e fazer seu aprimoramento por meio de muitas versões, até que tenha sido desenvolvido; A especificação, desenvolvimento e validação são executados concorrentemente para gerar um retorno rápido;
    • O modelo Evolucionário Pode ser:  Exploratório: tem como objetivo trabalhar com o cliente a fim de explorar seus requisitos e entregar um sistema final. São feitas partes inicias e acrescentadas novas de acordo com o desenvolvimento.  Protótipos descartáveis: tenta compreender os melhor os requisitos a partir de protótipos e então desenvolver uma especificação de requisitos completa.
    • O modelo Evolucionário Problemas:  O processo não é visível: como o sistema é desenvolvido rapidamente, não há tempo de documentar as versões;  Os sistemas são mal-estruturados: mudanças constantes podem corromper a estrutura do software;  Requer ferramentas e técnicas especiais: que nem sempre são disponíveis ou são aplicáveis ao caso.
    • O modelo Evolucionário Aplicabilidade:  Para sistemas interativos pequenos ou de médio porte  Para partes de sistemas grandes (p.ex., a interface com o usuário)  Para sistemas de vida curta.
    • O modelo DesenvolvimentoIncremental É uma variação do modelo Cascata;
    • O modelo DesenvolvimentoIncremental A ideia é alargar pouco-a-pouco; Analogia à construção de uma mansão;
    • O modelo DesenvolvimentoIncremental Vantagens:  Redução dos riscos envolvendo custos a um único incremento.  Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto.  Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.  Reconhecimento de uma realidade freqüentemente ignorada: as necessidades dos usuários e os requisitos correspondentes não podem ser totalmente definidos no início do processo.  Este modelo de operação facilita a adaptação a mudanças de requisitos.
    • O modelo DesenvolvimentoIncremental Desvantagens:  Dificuldade de gerenciamento. Isso ocorre porque as fases de do ciclo podem estar ocorrendo de forma simultânea.  O usuário pode se entusiasmar excessivamente com a primeira versão do sistema e pensar que tal versão já corresponde ao sistema como um todo.  Como todo modelo esta sujeito a riscos de projeto:  O projeto pode não satisfazer aos requisitos do usuário.  A verba do projeto pode acabar.  O sistema de software pode não ser adaptável, manutenível ou extensível.  O sistema de software pode ser entregue ao usuário tarde demais.
    • O modelo Espiral O processo é representado como uma espiral, em vez de uma seqüência de atividades com caminhos de retorno Cada volta na espiral representa uma fase no processo Não há fases fixas, tais como especificação ou projeto  As voltas na espiral são escolhidas dependendo do que for exigido Os riscos são explicitamente avaliados e resolvidos durante todo o processo Para cada iteração temos:  Envolvimento do cliente;  Seis e vinte e quatro meses de duração (presumidamente);  Prazo suficiente para que o cliente tenha um brainstorm;
    • O modelo Espiral
    • O modelo Espiral: Setores Definição do objetivo  Identificam-se os objetivos específicos da fase Avaliação e redução de risco  Os riscos são avaliados e são adotadas as atividades para reduzir os ricos principais Desenvolvimento e avaliação  É escolhido um modelo de desenvolvimento para o sistema, que pode ser qualquer um dos modelos genéricos Planejamento  O projeto é revisado e a próxima fase da espiral é planejada
    • O modelo Prototipação Busca, principalmente, velocidade no desenvolvimento; O cliente “enxerga” telas e relatórios resultantes do software, com os quais ele terá alguma pequena interação. O usuário deve ser envolvido para opinar sobre as telas e relatórios do software, de maneira que se consiga torná-lo quase que co-autor do desenvolvimento responsabilizando-o também, desta forma, pelo sucesso final do software, uma vez que terá tido participação ativa na montagem do mesmo.
    • O modelo Prototipação Análise de Desenvolvimento Experimentação Requisitos de Protótipo Revisão Codificação e Detalhamento Testes Manutenção Implantação
    • O modelo Prototipação Perigos:  Cliente “empolgar-se”;  Pressão a fim de que concessões de implementações ocorram para a urgência da implantação, sugerindo-se que o protótipo seja evoluído e entre rapidamente em funcionamento.
    • Interseção entre os modelo? Longo período de tempo para o desenvolvimento; Volume muito grande de documentação e planejamento; Fases maiores ainda => Big Design Up Front (BDUF); Um software BDUF implica em:  O planejamento é completado e aperfeiçoado antes mesmo de iniciar a codificação, o que praticamente inviabiliza uma mudança brusca de escopo [Fox e Patterson 2012]. E agora, para onde vamos?
    • Agilidade Um grupo em fevereiro de 2001, chamado de Agile Alliance, começou a descobrir maneiras melhores e mais leves de desenvolver software valorizando:  pessoas e interações ao invés de processos e ferramentas;  softwares funcionando no lugar de documentações abrangentes;  colaborações com clientes do que negociações de contratos e respostas à mudanças por planos fechados. Esses valores originaram o Manifesto Ágil com outros DOZE princípios que regem a filosofia de criar softwares com agilidade [BECK, 2001]
    • Agilidade O modelo é baseado em mudanças abrangentes; O desenvolvedor deve melhorar continuamente um protótipo incompleto até que o cliente fique feliz com o resultado; Algumas práticas são enfatizadas:  Test-Driven Development (TDD);  User Stories; e  Velocity.
    • Contraste com os outrosmodelosÉ tão rápido que novas versões sãodisponibilizadas ao cliente a cada duassemanas e novos recursos são adicionadoscontinuamente ao mesmo protótipo até que ocliente esteja satisfeito [Fox e Patterson 2012].
    • Exercícios
    • Referências Beck, K., et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. http://agilemanifesto.org/. Acessado em 18 de agosto de 2012. Fox, A., Patterson, D. (2012). “Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing”, Alpha Edition. Strawberry Canyon LLC, 2012. Pressman, R. S. (2005). “Software engineering: a practitioner‟s approach”, 6 ed. New York: MacGraw-Hill, 2005.