Processo de Desenvolvimento de Software Prof. Jean-Rémi Bourguet

Processo de Desenvolvimento de Software
Prof. Jean-Rémi Bourguet
Qualidade de Software e Testes de Sistemas

Produzir um Software via um Processo
Engenharia de Software trouxe métodos, processos, modelos e normas!

I PDS significa Processo de Desenvolvimento de Software.
I PDS é visto como uma sequência de atividades sistematizadas.
Processo de Desenvolvimento de Software (PDS) 2/31

I Um PDS é um conjunto de atividades que leva à produção de um

produto de software [Sommerville 07].
I Várias metodologias impulsionam ou organizam as atividades.

I As atividades podem ser estruturadas em fases ou etapas.

I Produzem uma variedade de documentos e produtos.
I Resulta em um programa satisfatório e executável.

I Essas atividades usam alguma linguagem de programação.

I Processo intelectual e criativo.
I A possibilidade de automatizá-los é um pouco limitada.

I Precisa de usar processos considerando muitos aspectos:

Pessoas, Restrições, Recursos, Padrões e Limitações.
I Um processo é considerado como conjunto de regras específicas.
I Os colaboradores devem adotá-las quando lidam com projetos.

I As construções de prédios são dividas em etapas muito claras.

I São práticas da engenharia com peculiaridades e especificidades.
I Para a construção de softwares, elas também existem.

Vantagens do desenvolvimento de um software como um processo:

a) O tempo de treinamento pode ser reduzido com menor custo.
b) Produtos podem ser mais uniformizados com melhor qualidade.
c) Satisfação dos clientes com menor prazo.
d) Possibilidade de capitalizar experiências.

Existem cinco atividades fundamentais de processo
1. Especificação do Software
2. Desenvolvimento do Software
3. Programação
4. Validação do Software
5. Evolução do Software

Existem muitas formas definidas de representação de processos
I Por uma sequência de passos descritos em linguagem natural.

I Por tabelas nas quais cada linha é um passo do processo.
I Por representações gráficas (fluxogramas: UML ou BPMN).


Fases de um processo de Software
1. Especificação de Requisitos:
I Análise dos requisitos.
I Independentemente do modelo de processos adotado.
I Conhecer quais são as necessidades deste software.
I Quais são as restrições e conhecer bem o domínio da aplicação.

2. Projeto de sistema:
I O projeto a partir de análises e tradução dos requisitos.
I Projeto arquitetural
I Modelagem conceitual e Projeto lógico.
I Projeto de interface.

3. Programação (Codificação):
I Desenvolvimento do código-fonte (linguagem de programação).
I Controle e lógica do sistema de acordo com os requisitos.

4. Verificação e Integração (Validação):

I Realização dos testes, a verificação do sistema.
I Check produto e componentes:
alinhados com as necessidades propostas pelo cliente?
I Qualidade do software e integração.
I Sistema em produção para que os usuários finais possam usá-lo.

5. Manutenção e evolução:
I Mudanças, ajustes, reparos e alterações que os requisitos venham a
sofrer após o sistema ser colocado em produção.
I Mudanças estruturadas como não estruturadas.

Problemas que envolvem as organizações
I Falta de clareza dos requisitos

I Ausência de testes que deveriam ser aplicados
I Inexistência de capacitação do pessoal envolvido.
I Cronogramas não observados com até 50% de não atendimento.
25% dos projetos de software falham ou são abandonados.

I Módulos de software não funcionam quando interagem entre si.

I Programas que não fazem o esperado ou com uma eficácia ruim.
I Programas difíceis de serem utilizados e entregues com defeitos.
I Programas que param de funcionar sem motivo aparente.
Até 44% do tempo utilizados para retrabalho nas companhias.


Ciclo de vida
I Os processos podem possuir um conjunto de regras especificas.

I Consideramos estes como modelos de processo [Wazlawick 13].

Ciclo de vida
O modelo de processo é chamado de ciclo de vida:

Ciclo de vida
I SDLC é o siglo para Systems Development Life Cycle.

I Processo de criação ou alteração de softwares.
I Modelos e metodologias usados para desenvolver softwares.
u https://www.youtube.com/watch?v=i-QyW8D3ei0
Plano
I. Especificação de Requisitos
II. Projeto de sistema
III. Programação
IV. Verificação e Integração
V. Manutenção e evolução

Requisitos de sistema
I Os requisitos de software norteiam estas atividades.

I Base fundamental para compreender o que será desenvolvido.
I O PDS detalha quem irá fazer o que, quando e como.
® https://github.com/DroidFoundry/DroidMetronome/wiki
Requisitos de sistema
I Descrevem as funções, limitações e restrições do sistema.

I A engenharia de requisitos abrange as atividades de:
descobertas, análises, documentações, verificações/validações.
u https://www.youtube.com/watch?v=miuUIfpaC40
Requisitos do usuário vs Requisitos de sistema
I Requisitos do usuário:
Descrições de alto nível, abstrata (linguagem natural/diagramas).
I Requisitos de sistema:
Descrições mais detalhada em termos de especificação funcional.
Contrato entre o comprador e o desenvolvedor do software.
u https://www.youtube.com/watch?v=vpNnZDwC_vs
Requisitos funcionais vs Requisitos não funcionais
Usuários e investidores podem ter opiniões diferentes.
A falta de funcionalidade está nos olhos de quem vê!

Non functionality is in the Eye of the Beholder
I Requisitos Funcionais (RF) relacionados aos processos de negócios.

I Requisitos Não Funcionais (RNF) relacionados aos recursos do sist.
Os requisitos funcionais lidam com O Quê.

Os requisitos não funcionais lidam com O Como.
(Ariel Schlesinger)
u https://www.youtube.com/watch?v=xm_EJI3_o8A
3 1. REQUISITOS NÃO FUNCIONAIS

u https://www.youtube.com/watch?v=zCX-N1H8Vps
Exemplos de requisitos funcionais:

I O sistema deverá permitir o cadastro de produtos.
I O sistema deverá ter um carrinho de compras.
I O sistema deverá permitir o pagamento por meio de cartões.

Exemplos de requisitos não funcionais:

I No sistema, não poderão ocorrer perdas de informações;
I O sistema não superará o tempo de 5s para carregar páginas;
I O sistema deverá ser compatível com os principais navegadores.
u https://www.youtube.com/watch?v=njfrdqvaGRw
Especificação do Software
I Definir quais são as funções requeridas pelos sistemas.

I A esta atividade dá-se o nome de Engenharia de Requisitos.
I Série de documentação de requisitos, gerando a especificação.
I Erros nesse estágio tornam-se problemas a seguir no projeto.
u https://www.youtube.com/watch?v=jajQyzOpLaE
4 fases no processo de Engenharia de Requisitos
Existem 4 principais fases no processo de engenharia de requisitos

[Sommerville 07]
3 4. LEVANTAMENTO DE REQUISITOS
1. Estudo de Viabilidade:
I Necessidades dos usuários identificadas podem ser satisfeitas?
I Decidirá se o sistema proposto será comercialmente viável.
I Um estudo de viabilidade deve ser barato e rápido.

2. Levantamento e Análise de requisitos:

I Obter os requisitos pela observação de sistemas existentes.
I Obter os requisitos pela conversa com usuários e compradores.
I Desenvolvimento de diferentes modelos e protótipos.
I Ajuda o analista a compreender o sistema a ser especificado.

3. Especificação de requisitos:
I Traduzir as informações coletadas durante a análise.
I Escrever um documento que defina um conjunto de requisitos.
I Os autores em [Medeiros 14] propõe o seguinte modelo:
® https://pt.overleaf.com/latex/templates/
software-requirements-specification/ryktphvctsxg
4. Validação de requisitos:
I Check da pertinência, consistência e integralidade dos requisitos.
I Descobertos erros na documentação de requisitos.
I Os requisitos são modificados para corrigir esses problemas.

Plano
III. Programação

Arquitetura de software
I Organização geral do software.

I Integridade conceitual para um sistema.
I Estrutura de componentes de programa (módulos).
I Maneira pela qual esses componentes interagem.
I A estrutura de dados usada pelos componentes.

Arquitetura de software
Para [Mazzola 10], a arquitetura de software resulta:

I das atividades particionadas do problema
(encaminhadas desde a etapa de Análise de Requisitos).
I das propriedades estruturais dos componentes de um sistema.
I de como os componentes são empacotados e interagem.
u https://www.youtube.com/watch?v=OS4s4c72HCA
CASE (Computer Aided Software Engineering)
I Uso de ferramentas automatizadas em engenharia de software.

I CASE: Engenharia de Software Auxiliada por Computador.
I Software usado para apoiar as atividades de processo de software.

I Existem ferramentas CASE que usam gráficos e diagramas.

I Ajuda a representar os módulos de um software e interconexões.
I Oferece até mesmo assistentes para a geração do código-fonte.
u https://www.youtube.com/watch?v=-1-OslyRW_w
I Limitação das ferramentas CASE é que não é possível criar uma

ferramenta que abranja todos os processos de software.
I Existe uma grande diversidade nas formas de desenvolvimento.
u https://www.youtube.com/watch?v=GPcIjsz-2cA
Plano
III. Programação

Codificação (Implementação)
I O conjunto de atividades de formalização é a codificação.

I A linguagem de programação traz maior proximidade com a
linguagem processada pela máquina [Mazzola 10].
I Conversão de uma especificação em um sistema executável.

Codificação (Implementação)
I O código-fonte é um elemento essencial para as atividades de

validacão do software e para as tarefas de manutencão.
I A documentação deve ser bastante considerado na codificação.
u https://www.youtube.com/watch?v=3Smbhnmue7Y&t=398s
Documentação de software
I A documentação de software presente em todas as fases do PDS.

I Essencial para realizar manutenção com mais eficiência.
I Traz as condições para um suporte técnico de qualidade.

Documentação técnica vs Documentação de uso
Existem dois tipos básicos de documentação

Documentação técnica:
I Voltada ao desenvolvedor.
I Descreve várias partes do código-fonte (função, classe, módulo).

Documentação de uso:
I Voltada para o usuário final.

I Apresenta o que esperar do sofwtare.
I Apresenta como o software deve ser usado.
u https://www.youtube.com/channel/UClKKWBe2SCAEyv7ZNGhIe4g
Documentação do código-fonte
I A documentação do código-fonte é feita a partir de comentários.

I Pode ser feito diretamente no código-fonte ou on-line.
I Representa um grande aliado às atividades de manutenção.
I Podemos encontrar comentários pontuais em meio ao código.

Documentação do código-fonte
I O outro aspecto importante é a formatação do código-fonte.

I A indentação do código facilita a interpretação do mesmo.
I Permite explicitar melhor a combinação dos blocos básicos.

Plano
III. Programação

Testes do produto
I Não há garantia de qualidade somente pelo uso das metologias.

I É fundamental que essa última etapa do projeto seja realizada.
I Até 40% do esforço total empreendido no desenvolvimento.
I Encontrar erros é o maior objetivo do teste.
3 5. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Testes do produto
Série de regras e objetivos trazidos por Glen Myers:

I Executar um programa com o intuito de encontrar um erro.
I Um teste bem feito traz alta probabilidade de encontrar um erro.
I Um teste bem-sucedido é aquele que revela um novo erro.
u https://www.youtube.com/watch?v=oLc9gVM8FBM&t=83
Série de características [PRESSMAN, 2011]
1. Testabilidade:
I Facilidade com que um programa pode ser testado.

2. Operabilidade:
I Quanto melhor funcionar, mais eficientemente pode ser testado.

I Haverá poucos defeitos bloqueando a execução dos testes.

3. Observabilidade:
I Entradas fornecidas no teste produzem saídas distintas.

I Estados e variáveis do sistema são visíveis e consultáveis.
I Saída incorreta é facilmente identificada.

4. Controlabilidade:
I Controlar o software para automatizar e otimizar os testes.

I Os formatos de entrada e saída são estruturados.

5. Decomponibilidade:
I Controlando o escopo do teste.

I Isolar problemas mais rapidamente.
I Executar um re-teste mais racionalmente.

6. Simplicidade:
I Conjunto de características mínimas para satisfazer os requisitos.

I Quanto menos tiver que testar, mais rapidamente podemos.
I O programa deverá ter simplicidade funcional.

7. Estabilidade:
I Quanto menos alterações, menos interrupções no teste.

I As alterações no software são pouco frequentes e controladas.
I Quando elas ocorrem, elas não invalidam os testes existentes.

8. Compreensibilidade:
I O projeto arquitetural é bem compreendidas.

I As dependências entre componentes são bem compreendidas.
I A documentação técnica é instantaneamente acessível.
I Essa documentação é bem organizada, detalhada e precisa.

Plano
III. Programação

Manutenção de software
I A manutenção de software é aliada a uma boa documentação.

I Contribui diretamente na melhoria contínua do software.
I Importancia do suporte técnico de qualidade e eficiente.

I A manutenção de software permite reparar e ajustar.

I Processo de modificação de sistemas depois de colocar em uso.
I Processo de melhoria através da correção de defeitos.
I Normalmente não envolve alteração da arquitetura do sistema.

I A manutenção é a fase mais problemática do ciclo de vida.

I O esforço desprendido pode chegar a 70% de todo o SDLC.
I Os custos podem chegar a 200% do custo de desenvolvimento
u https://www.youtube.com/watch?v=_o4rFSnhC0c
Tipos de manutenção
1. Manutenção corretiva
I Os testes dificilmente conseguem detectar todos os erros.

I Realizada para correção de erros não detectados durante o PDS.
I Corrigir defeitos de código, de projeto e de especificação.

2. Manutenção adaptativa
I Realiza alterações que se tornam necessárias por mudanças.

I São necessárias, pois a vida útil dos aplicativos é longa...

3. Manutenção preventiva
I Garante melhorias constantes com o objetivo de prevenir falhas.

I Previne futuras manutenções dos dois tipos anteriores.
I Melhorar no que se refere à confiabilidade ou manutenibilidade.

4. Manutenção perfectiva ou aperfeiçoadora
I Melhorar o software acrescentando funcionalidades.

I Geralmente são o resultado de recomendações de novidades.
I Modificações de funções existentes solicitadas pelos usuários.
I Responsável pelo maior esforço gasto com manutenção.

Manutenibilidade
I Manutenibilidade é a facilidade com que um software pode ser

entendido, corrigido, adaptado, aumentado etc.
Quão fácil é realizar a manutenção deste software?
3 6. MANUTENÇÃO
Suporte
I Atividades de engenharia que ocorrem depois que o software

foi fornecido ao cliente e posto em operação [Pressman, 2011].

O help desk
I Está mais associado aserviços de atendimentos a clientes.

I Esclarecer dúvidas, dar orientações e ajudas acerca de problemas.
u https://www.youtube.com/watch?v=37JxjNflcEo&t=92 (X1,25)
O service desk
I Possui um envolvimento mais abrangente do que o help desk.

I Considerado até mesmo uma evolução deste.
I Forte relação com a manutenção.

O treinamento
I Os usuários finais aprendem a utilizar o sistema.

I Validar alguns pontos depois da fase de testes.

O treinamento
I As consequências ótimas para uma organização.

I Implica um aumento de produtividade.
I Aproveitamento do sistema desenvolvido.
I Apoia novas demandas futuras ou novas implementações.

Referências

Processo de Desenvolvimento de Software Prof. Jean-Rémi Bourguet

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Processo de Desenvolvimento de Software Prof. Jean-Rémi Bourguet

Uploaded by

Copyright:

Available Formats

Processo de Desenvolvimento de Software

Prof. Jean-Rémi Bourguet

Qualidade de Software e Testes de Sistemas

Engenharia de Software trouxe métodos, processos, modelos e normas!

Processo de Desenvolvimento de Software (PDS) 2/31

I Um PDS é um conjunto de atividades que leva à produção de um

Processo de Desenvolvimento de Software (PDS) 2/31

I As atividades podem ser estruturadas em fases ou etapas.

Processo de Desenvolvimento de Software (PDS) 2/31

I Essas atividades usam alguma linguagem de programação.

Processo de Desenvolvimento de Software (PDS) 2/31

I Precisa de usar processos considerando muitos aspectos:

Processo de Desenvolvimento de Software (PDS) 2/31

I As construções de prédios são dividas em etapas muito claras.

Processo de Desenvolvimento de Software (PDS) 2/31

Vantagens do desenvolvimento de um software como um processo:

Processo de Desenvolvimento de Software (PDS) 2/31

Existem cinco atividades fundamentais de processo

Processo de Desenvolvimento de Software (PDS) 2/31

Existem muitas formas definidas de representação de processos

I Por uma sequência de passos descritos em linguagem natural.

Processo de Desenvolvimento de Software (PDS) 2/31

Processo de Desenvolvimento de Software (PDS) 2/31

Processo de Desenvolvimento de Software (PDS) 3/31

Processo de Desenvolvimento de Software (PDS) 3/31

Processo de Desenvolvimento de Software (PDS) 3/31

4. Verificação e Integração (Validação):

Processo de Desenvolvimento de Software (PDS) 3/31

Processo de Desenvolvimento de Software (PDS) 3/31

I Falta de clareza dos requisitos

25% dos projetos de software falham ou são abandonados.

I Módulos de software não funcionam quando interagem entre si.

Até 44% do tempo utilizados para retrabalho nas companhias.

Processo de Desenvolvimento de Software (PDS) 4/31

I Os processos podem possuir um conjunto de regras especificas.

Processo de Desenvolvimento de Software (PDS) 5/31

O modelo de processo é chamado de ciclo de vida:

Processo de Desenvolvimento de Software (PDS) 5/31

I SDLC é o siglo para Systems Development Life Cycle.

II. Projeto de sistema

IV. Verificação e Integração

Processo de Desenvolvimento de Software (PDS) 6/31

I Os requisitos de software norteiam estas atividades.

I Descrevem as funções, limitações e restrições do sistema.

Usuários e investidores podem ter opiniões diferentes.

A falta de funcionalidade está nos olhos de quem vê!

I Requisitos Funcionais (RF) relacionados aos processos de negócios.

Os requisitos funcionais lidam com O Quê.

3 1. REQUISITOS NÃO FUNCIONAIS

Exemplos de requisitos funcionais:

Processo de Desenvolvimento de Software (PDS) 9/31

Exemplos de requisitos não funcionais:

I Definir quais são as funções requeridas pelos sistemas.

Existem 4 principais fases no processo de engenharia de requisitos

Processo de Desenvolvimento de Software (PDS) 11/31

2. Levantamento e Análise de requisitos:

Processo de Desenvolvimento de Software (PDS) 11/31

Processo de Desenvolvimento de Software (PDS) 11/31

II. Projeto de sistema

IV. Verificação e Integração

Processo de Desenvolvimento de Software (PDS) 12/31

I Organização geral do software.

Processo de Desenvolvimento de Software (PDS) 13/31