2- Processos

Processos

Engenharia de Software

Caainã Jerônimo de Souza Nascimento

https://sites.google.com/site/esjogos161/

Planejamento

• Contra quem vamos jogar? • Quem faz o que?

• Qual a função do Mid? Suporte? Carry? Off-Lane?

• Como identificar problemas? • Que itens comprar?

• Jogar igual contra todos? • Qual a função do capitão?

Processo

• Ação regular e contínua realizada de forma bem definida, levando a um resultado!

• Quem faz o que? • Quando?

Processo de Software

• Sugere um 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.

• Os processos de software são complexos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decisões e fazer julgamentos

Processo de Software

• Existem muitos processos de software diferentes, mas todos devem incluir quatro atividades fundamentais para a engenharia de

software:

• Especificação de software

• Projeto e implementação de software • Validação de software

Processos de Software

• Em comum:

• Participação de usuários

• Flexibilidade de configuração para projetos específicos • Comunicação entre membros da equipe

• Diferenças em:

• Detalhamento de atividades a serem seguidas • Critério de conclusão da execução das atividades • Rigor na atribuição de tarefas a responsáveis

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

Modelo de Processo

• Um modelo de processo de software é uma representação simplificada de um processo de software.

• Um modelo é usado para entendimento e comunicação do processo, e como base para análise, execução, gerência e melhoria do processo.

Modelo – Cascata (Waterfall)

• O primeiro modelo do processo de desenvolvimento de software a ser publicado foi derivado de processos mais gerais da engenharia de sistemas. (Winston Royce - 1970)

• Surgiu da Crise de Software

• Cada fase precisa de aprovação para a fase seguinte

• Você deve planejar e programar todas as atividades do processo antes de começar a trabalhar nelas

Cascata

Cascata

• O resultado de cada estágio é a aprovação de um ou mais documentos.

• O estágio seguinte não deve ser iniciado até que a fase anterior seja concluída.

Vantagens e desvantagens

• Vantagens

• Imita outras engenharias

• Documentação produzida a cada passo • Simplicidade

• Desvantagens

• Dificuldade em atender mudanças de requisitos do cliente • Desenvolvedores ficam esperando

• O modelo em cascata deve ser usado apenas quando os requisitos são bem compreendidos e pouco provavelmente venham a ser

Mudanças...

• Requisitos mudam constantemente devido a feedback • Novas tecnologias surgem

• Precisamos adaptar as mudanças • Interações

• Especificação em cada incremento

Desenvolvimento Incremental

• É baseado na ideia de desenvolver uma implementação inicial, expõ-Ia aos comentários dos usuários e continuar por meio da criação de várias versões até que um sistema adequado seja desenvolvido

• O desenvolvimento e a entrega são divididos em incrementos

• Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados"

Modelo

Definir esboço dos requisitos Associar requisitos a incrementos Projetar a arquitetura do sistema Desenvolver incremento Validar incremento Integrar o incremento Validar o sistema

Vantagens e desvantagens

• Vantagens:

• O cliente já poderá utilizar o sistema desde o primeiro incremento • Poderá dar feedback para próximos incrementos

• As funcionalidades são bem testadas até o ultimo incremento

• Desvantagens:

• Nem sempre os incrementos são pequenos

Engenharia de Software orientada a reúso

• Na maioria dos projetos existe um reuso de software

• Estágio inicial e o final desse modelo é semelhante aos anteriores. • Os estágios intermediários são:

• Analise de componentes • Modificação de requisitos

• Projeto de sistemas com reuso • Desenvolvimento e integração

Modelo

Projeto de sistema com reuso

Desenvolvimento e integração

Vantagens e Desvantagens

• Vantagens

• Reduz a quantidade de software a ser desenvolvido e, assim, reduz os custos e riscos.

• Proporciona a entrega mais rápida do software.

• Desvantagens

• Pode levar a um sistema que não atende as reais necessidades dos usuários • Pode existir falta de controle sobre novas versões de componentes

Atividades do processo - Especificação de

Software

• Especificação de software ou engenharia de requisitos é o processo de compreensão e definição dos serviços requisitados do sistema e identificação de restrições relativas à operação e ao desenvolvimento do sistema

• Tem como objetivo produzir um documento de requisitos acordados que especifica um sistema que satisfaz os requisitos dos stakeholders • Os usuários finais e os clientes precisam de uma declaração de

requisitos em alto nível; desenvolvedores de sistemas precisam de uma especificação mais detalhada do sistema.

Modelo

Estudo de viabilidade Elicitação e análise de requisitos

Especificação de

requisitos Validação de requisitos

Relatório de viabilidade Modelos de sistema Requisitos de usuários e de sistema Documentação de requisitos

Projeto e implementação de software

• É o processo de conversão de uma especificação do sistema em um sistema executável.

• Um projeto de software é uma descrição da estrutura do software a ser implementado, dos modelos e estruturas de dados usados pelo sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos usados.

Modelo

Informação da plataforma

Especificação de

requisitos Descrição de dados

Projeto de arquitetura Projeto de interface Projeto de componentes

Projeto de banco de dados

Arquitetura do sistema Especificação de banco de dados Especificação de interface Especificação de componentes

Validação e Verificação de Software

• Tem a intenção de mostrar que um software se adequa a suas

especificações ao mesmo tempo que satisfaz as especificações do cliente do sistema

• Verificação: Estamos construindo certo o produto? • Validação: Estamos construindo o produto certo? • Tem dois objetivos principais

• Descobrir falhas no sistema

Validação e Verificação de Software

• Teste de programa, em que o sistema é executado com dados de testes simulados, é a principal técnica de validação

• Sistemas não devem ser testados como uma unidade única e monolítica

• Também pode envolver processos de verificação, como inspeções e revisões, em cada estágio do processo de software, desde a definição dos requisitos de usuários até o desenvolvimento do programa

Teste de

Evolução de Software

• Sistemas são feitos para refletir o comportamento humano do mundo real. [Gall97].

• Não acompanhar as mudanças do ambiente inserido acarreta em perda de qualidade.

• O Processo de envelhecimento é algo inevitável. Porém é controlável e reversível.

• Existem dois tipos de envelhecimento de software

• Quando os responsáveis falham em adaptá-lo para novos requisitos

Lidando com mudanças

• Os requisitos do sistema mudam, ao mesmo tempo que o negócio que adquiriu o sistema responde a pressões externas e mudam as prioridades de gerenciamento.

• Qualquer que seja o modelo do software de processo, é essencial que possa acomodar mudanças no software em desenvolvimento.

Prototipação

• Uma versão do sistema ou de parte dele é desenvolvida rapidamente para verificar as necessidades do cliente e a viabilidade de algumas decisões de projeto

• Esse processo previne mudanças, já que permite aos usuários experimentarem o sistema antes da entrega

• No processo de engenharia de requisitos, um protótipo pode ajudar na elicitação e validação de requisitos de sistema.

• No processo de projeto de sistema, um protótipo pode ser usado

para estudar soluções específicas do software e para apoiar o projeto de interface de usuário.

Modelo de processo de desenvolvimento de

protótipos

protótipo Avaliar protótipo

Plano de

prototipação Definição geral

Protótipo executável

Relatório de avaliação

Alguns modelos de processo ágeis

• Extreme Programming • SCRUM

Extreme Programming - XP

• É uma metodologia ágil para equipes pequenas e médias

desenvolvendo software com requisitos vagos e em constante mudança

• Levar todas as boas práticas ao extremo • Lemas:

• Comunicação • Coragem

• Feedback • Simplicidade

Comunicação

• Comunicação face a face é a maneira

mais rápida de “espalhar” conhecimento • Preferir

• Chat a e-mail • Telefone a chat

Coragem

• Indicar problemas no projeto • Parar quando está cansado

• Pedir ajuda quando necessário • Simplificar código que já está

Feedback

• Cliente participando do desenvolvimento

• Oportunidades e problemas são evidenciados o mais cedo possível

• Testes em abundância fornecem feedback sobre sistema

Simplicidade

• Regra geral: “Pensar sempre no que pode ser feito para simplificar o que já está funcionando”

• Fazer o mínimo necessário para funcionar

Modelo

• Iterações semanais

• Cliente identifica prioridades • Desenvolvedores as estimam • O escopo é reavaliado

• Contrato de escopo negociável

• O cliente recebe novas funcionalidades

• completamente testadas – postas em produção

Práticas

• Stand‐up Meeting

• Reuniões rápidas e diárias com a equipe. “Planning game”

• Refactoring

• Remoção de redundância/duplicação, eliminação de funcionalidades inúteis,...

• Test‐driven Development

• Criação dos testes antes da codificação, conhecendo previamente as possíveis falhas do seu sistema

• Pair Programming

• Todo código desenvolvido por duas pessoas trabalhando com o mesmo computador

Práticas

• The Customer is Always Available

• O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades

• Small Release

• O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos

• Simple Design

• O código está, a qualquer momento, na forma mais simples que passe todos os testes

Práticas

• 40-Hour Week

• Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve-se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa.

• Collective Code Ownership

• Equipe como um todo é responsável por cada arquivo de código

• Coding Standards

• Todo código é desenvolvido seguindo um padrão

• Continuous Integration

• Os módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. Obter 100% sucesso.