Aula 2_3 - Complemento

(1)

Aula 2 e 3

(2)

Distribuição de Pontos

 Primeiro Bimestre

 Segundo Bimestre

Tipo Pontos

Entrega do Trabalho 1 3 Pontos

Prova 7 Pontos

Tipo Pontos

A Definir

(3)

Trabalho 1

 Definir um processo para

desenvolvimento de software para o desenvolvimento da

empresa da situação problema.  Cada etapa do processo de

desenvolvimento de software deve ser bem explicado como devem ser explicados e

demonstrados os artefatos gerados.

(4)

Prova

 Matéria da Primeira Prova: Toda

Disciplina lecionada ate a realização da mesma(Prova Fechada de 10

Questões);

 Matéria da Segunda Prova: Toda

Disciplina do Semestre; (Prova

Fechada de 10 Questões)

 Matéria da Prova Substitutiva: Toda

Disciplina do Semestre; (Prova aberta de 20 Questões).

(5)

Pontuação

1. Trabalhos Peso 3 Valor 10 = 3 Pontos;

2. Provas Peso 7 Valor 10 = 7 pontos;

3. Pesos dos Bimestres:

1. Primeiro Bimestre Peso 4;

(6)

Contato

 https://sites.google.com/site/thia

goaalves/

 thiago.augusto2@anhanguera.co m

No assunto especificar seu nome e o nome da disciplina e a sala.

(7)

Disciplina

(8)

Bibliografia Básica Padrão

 MAITINO NETO, Roque. Engenharia de Software. 1.

Londrina: Editora e Distribuidora Educacional S.A, 2016. 9788584824168.

 Wazlawick, Raul. Engenharia de Software. 1. Rio De

Janeiro: Elsevier, 2015. 9788535260847.

 GUSTAFSON, DAVID A. Engenharia de Software -

Colecao Schaum. 1. Porto Alegre: Bookman Cia Editora Ltda, 2015. 8536301856.

 PRESSMAN, ROGER S. Engenharia de Software

7Ed. 7. Porto Alegre: Amgh Editora Ltda, 2015. 9788563308337.

 IAN SOMMERVILLE. Engenharia de Software 9

Edicao. 9. São Paulo: Pearson, 2011. 9788579361081.

 SCHACH, STEPHEN R. Engenharia de Software:Os

Paradigmas Classico 7Ed. 7. Porto Alegre: Amgh Editora Ltda, 2015. 9788577260454.

(9)

Bibliografia Complementar – Biblioteca Virtual

WINDER, Russel; GRAHAM, Roberts. Desenvolvendo Software Em Java, 3ª Edição. 3. Rio De Janeiro: Grupo Gen, 2015. 9788521616580.

COHN, Mike. Desenvolvimento de Software Com Scrum. 1. Porto Alegre: Grupo A, 2015. 97885778080760.

OKUYAMA, Fabio Yoshimitsu; MILETTO, Evandro Manara; NICOLAO, Mariano. Desenvolvimento de Software I: Conceitos Básicos - Série Tekne. 1. Porto Alegre: Grupo A, 2014. 9788582601464.

PADUA FILHO, Wilson de Paula. Engenharia de Software, 3ª Edição. 3. Rio De Janeiro: Grupo Gen, 2008. 9788521619925.

SCHACH, Stephen R. Engenharia de Software, 7ª Edição. 7. Porto Alegre: Grupo A, 2015. 9788577260454.

(10)

Bibliografia

Complementar

 Noticias a relacionados ao tema;  Artigos relacionados ao tema;

 Sites de autores relacionados ao tema.

(11)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO:

Desenvolvimento Ágil de Software

◦Métodos ágeis - Extreme Programming (XP): conceitos, características,

princípios/práticas e exemplos.

◦Métodos ágeis - Scrum: conceitos, características e princípios/práticas.

◦Métodos ágeis - Scrum: exemplos e aplicabilidade.

◦Métodos ágeis para o desenvolvimento de software: conceitos, histórico e princípios.

(12)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO:

Fundamentos de Engenharia de Software

◦Fundamentos dos processos de

desenvolvimento de software: conceitos e principais atividades.

◦Introdução à Engenharia de Software: aspectos gerais, objetivos, evolução do software e crise do software.

◦Modelos de processos de software: características e atividades.

◦Modelos dos processos de software: aplicabilidade e evolução.

(13)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO: Gerenciamento

de Configuração e Testes

◦Desenvolvimento dirigido a testes - Test-DrivenDevelopment (TDD): conceitos, processo e benefícios.

◦Evolução de Software - gerenciamento de mudanças e versões: conceitos,

características e processo.

◦Testes de desenvolvimento de software: conceitos, características e tipos.

◦Testes de release e de usuário: conceitos, características e tipos.

(14)

Conteúdo Programático - PEA

 UNIDADE DE ENSINO: Gerenciamento

de Qualidade de Software

◦Gestão de qualidade de software: conceitos, fundamentos, processo e planejamento.

◦Introdução a revisões, inspeções, medições e métricas.

◦Introdução às normas de qualidade de software: ISO 9001, ISO 9126 e

CapabilityMaturityModelIntegration (CMMI).

◦Padrões de software no gerenciamento de

qualidade de software: conceitos, importância e processo/passos.

(15)

Datas Importantes – Turma de

Quinta

Data Tema

1º Avaliação 30/03/2017 Dia para reclamação e revisão

de notas e trabalhos mais conhecido como dia do “Choro”

06/04/2017

SIP 22/05/2017 a 26/05/2017 Entrega Trabalho segundo

Semestre ?????????????? 2º Avaliação 01/06/2017

OBS. As datas estão com possíveis alterações de acordo com o calendário da faculdade.

(16)

(17)

Processo

 O que é um Processo?  processo

 substantivo masculino

 1. ação continuada, realização contínua

e prolongada de alguma atividade; seguimento, curso, decurso.

 2. sequência contínua de fatos ou

operações que apresentam certa

unidade ou que se reproduzem com certa regularidade; andamento,

(18)

Processo

 Processos de Software

 “Quando se fornece um serviço ou cria-se um produto, seja

desenvolvendo um software, escrevendo um relatório ou fazendo uma viagem de

negócios, segue-se

costumeiramente uma sequencia de etapas para completar um

(19)

Processos de Software

 Não existe um processo ideal. As organizações devem criar,

verificar, validar e aperfeiçoar seus próprios métodos (CMMI,

2006). Mas me smo ass im e nec essário s e conhe cer alguns m odelos p ara se b asear. “N ão se pode cr iar algo do nada ”.

(20)

Cascata

 O modelo clássico ou cascata, que

também é conhecido por abordagem

“top-down”, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação geral. Esse modelo foi derivado de modelos de atividade de engenharia com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software.

Comparado com outros modelos de desenvolvimento de software.

(21)

(22)

Cascata

 O modelo Cascata é um modelo de engenharia projetado para ser aplicado no desenvolvimento do software.

 A ideia principal que o dirige é que as diferentes etapas de

desenvolvimento seguem uma sequência de eventos.

(23)

Cascata

 O Funcionamento Básico do Cascata:

 “a saída da primeira etapa “fluí” para a segunda etapa e a saída da segunda etapa “fluí” para a terceira e assim por diante. As atividades a executar são

agrupadas em tarefas,

executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado.”

(24)

(25)

(26)

Cascata

 O modelo em cascata tem a

vantagem que só avança para a tarefa seguinte quando o cliente valida e aceita as atividades

realizadas na etapa em que se encontra.

(27)

Cascata

 Pressupõe que o cliente participa

ativamente no projeto e que sabe muito bem o que quer. Este modelo

minimiza o impacto da compreensão adquirida no decurso de um projeto,

uma vez que se um processo não pode voltar atrás de modo a alterar os

modelos e as conclusões das tarefas anteriores, é normal que as novas

ideias sobre o sistema não sejam aproveitadas.

(28)

Cascata

 Numa tentativa de resolver este tipo de

problema foi definido um novo tipo de

processo baseado no clássico em cascata, designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidade de a partir de qualquer

tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que

entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido.

(29)

(30)

Cascata

 Problemas

 O ciclo de vida Cascata é o paradigma mais visto e mais amplamente empregue na

engenharia de software, porém sua aplicabilidade, em muitos campos, tem sido questionada. Entre os problemas que surgem quando se aplica o modelo são:

(31)

Cascata

◦Na realidade, os projetos raramente seguem o fluxo sequencial que o modelo propõe. A

interação é sempre necessária e está presente, criando problemas na aplicação do modelo;

◦Em princípio, é difícil para o cliente especificar os requisitos explicitamente, o que acarreta a incerteza natural do início de qualquer projeto;

◦O cliente deve ser paciente, pois uma versão funcional não estará disponível até o final do desenvolvimento. Qualquer erro ou mal

entendido, se não for detectado até que o software seja revisado, pode ser desastroso.

(32)

Reflexão

 Qual e o maior Problema enfrentado no modelo em

cascata? (Não existem respostas certas e erradas)

 Resposta: Dependendo da Alteração a ser realizada o Custo pode ser elevado

(33)

(34)

Modelo Evolucionário

 O software evolui ao longo do tempo e conforme o

desenvolvimento deste software avança também temos mudanças nas necessidades de negócio e

de produtos que mudam frequentemente.

(35)

Modelo Evolucionário

 Isso torna inadequado seguirmos um planejamento em linha reta de um produto. Os modelos de processo evolucionário tornaram-se realidade para que possamos desenvolver um produto que

(36)

Modelo Evolucionário

 Modelos evolucionários são caracterizados por serem

iterativos e apresentarem

características que possibilitem desenvolvermos versões cada

vez mais completas do software. Os processos evolucionários se caracterizam por dois modelos comuns: Prototipação e

(37)

Modelo Evolucionário

 Prototipação: A prototipação é utilizada quando o desenvolver

não tem certeza quanto à eficiência de um algoritmo, ou quanto à adaptabilidade

de um sistema operacional ou ainda quanto à forma em que deva ocorrer a interação

(38)

Modelo Evolucionário

 Quando temos essa situação a

prototipação é uma excelente alternativa. Vale ressaltar que a prototipação pode ser utilizada em qualquer processo de

software, visto que a prototipação auxilia os interessados a

compreender melhor o que está para ser construído.

(39)

Modelo Evolucionário

 A prototipação se dá basicamente

com a comunicação que ocorre

através de uma reunião com todos os envolvidos afim de definir

objetivos gerais do software e

identificar quais requisitos já estão bem conhecidos e esquematizar as áreas que realmente necessitam

(40)

Modelo Evolucionário

 Uma iteração de prototipação deve

ser planejada rapidamente e dessa forma ocorre a modelagem na forma de um projeto rápido. O projeto rápido foca na representação dos aspectos do software que serão visíveis aos

usuários como layout da interface e os formatos de exibição. Esse projeto

rápido leva à construção de um protótipo que será avaliado pelo cliente.

(41)

Modelo Evolucionário

 O cliente por sua vez retornará um feedback á equipe de

software que irá aprimorar os requisitos. A iteração vai

ocorrendo conforme vamos ajustando o protótipo às

(42)

(43)

Modelo Evolucionário

 De forma geral o protótipo auxilia na identificação dos requisitos do software. Os protótipos podem

ser descartados quando usamo-los apenas para entender um determinado requisito ou pode ser utilizado como um produto evolucionário que servirá para o cliente.

(44)

Reflexão

 Qual e a Principal diferença entre um Protótipo e um Layout?

 Embora bastante semelhantes o Protótipo e considerado

“Funcional” enquanto o Layout e só visão.

(45)

Modelo em Espiral

 O famoso modelo espiral foi proposto

por Boehm. Esse é um modelo de processo de software evolucionário que também é iterativo como a

prototipação, porém com aspectos

sistemáticos e controlados do modelo cascata. O modelo espiral fornece um grande potencial para que possamos ter rápido desenvolvimento de versão cada vez mais completas.

(46)

Modelo em Espiral

 Um modelo espiral possui

diversas atividades definidas pela engenharia de software, onde

cada uma dessas atividades representa um segmento do caminho espiral.

(47)

(48)

Modelo em Espiral

 Sempre iniciamos pelo centro da

espiral e prosseguimos no sentido horário.

 Os riscos são considerados à medida

que cada evolução é realizada. A primeira atividade se dá com o

desenvolvimento de uma especificação de produto, as próximas passagens

podem ser usadas para desenvolver um protótipo e, assim sucessivamente vamos evoluindo para versões cada

(49)

Modelo em Espiral

 Cada passagem pela parte de

planejamento, por exemplo, resulta em ajustes no planejamento do

projeto.

 O custo e o cronograma são

sempre ajustados de acordo com o feedback obtido do cliente após

uma entrega. Também teremos um ajuste no número de iterações

planejadas para completar o software.

(50)

Modelo em Espiral

 Podemos notar que diferente de

outros modelos que terminam

quando o software é entregue, o modelo espiral pode ser

adaptado a cada entrega. O projeto finaliza quando o cliente

fica satisfeito, quando o software é retirado de operação ou uma data encerra definitivamente o projeto.

(51)

Modelo em Espiral

 O modelo espiral é largamente utilizado e é considerada uma abordagem realista para

desenvolver sistemas em larga escala.

(52)

Modelo Baseado em

Componentes

 O modelo baseado em

componentes incorpora muitas características do modelo em Espiral, tendo como base os seguintes pontos:

◦_{Baseado na tecnologia de orientação}

a objetos;

◦Reaproveitamento de código;

◦Recursão onde um componente esta presente dentro de outro

(53)

Modelo Baseado em

Componentes

 As atividades de modelagem e construção começam com a

identificação de componentes candidatos. Esses componentes podem ser projetados como

módulos de software

convencional ou como classes ou pacotes de classes orientados a objetos.

(54)

Modelo Baseado em

Componentes

 O modelo de desenvolvimento baseado em

componentes incorpora os seguintes passos:

◦Produtos baseados em componentes disponíveis são pesquisados e avaliados para o domínio da aplicação em questão.

◦Tópicos de integração de componentes são considerados.

◦Uma arquitetura de software é projetada para acomodar os componentes.

◦Componentes são integrados à arquitetura.

◦Testes abrangentes são realizados para garantir a funcionalidade adequada.

(55)

Modelo Baseado em

Componentes

 Para projetar um sistema

baseado em componentes é

necessário entender os benefícios e dificuldades da tecnologia, bem como a ferramenta disponível. Os benefícios da componentização

estão ligados a

manutenabilidade, reuso,

composição, extensibilidade,

integração, escalabilidade, entre outros.

(56)

Modelo Baseado em

Componentes

 As dificuldades podem ser

separadas em dificuldades do desenvolvimento para

componentização (construção dos componentes e da

infra-estrutura) e dificuldades do desenvolvimento com

(57)

Modelo Baseado em

Componentes

 As primeiras estão ligadas ao

esforço inicial de análise, projeto e desenvolvimento, enquanto as segundas estão ligadas ao

esforço despendido no

entendimento dos componentes e das ferramentas envolvidas, à perda de flexibilidade, à

dependência de terceiros e à adaptação do processo de

(58)

Modelo Baseado em

Componentes

 Vantagens  Reutilização de Código;  Redução do tempo de desenvolvimento;

(59)

(60)

Aula 3

 Reflexão

 Você Lembram o que são requisitos?

 Entendem quando alguém fala dos requisitos?

◦_{Requisitos Funcionais?}

◦Requisitos Não Funcionais?

(61)

Aula 3

 O dilema com o qual se depara um analista pode ser mais bem

entendido, repetindo-se a

declaração de um cliente anônimo:  “Sei que você acredita que

entendeu o que acha que eu

disse, mas não estou certo que percebeu que aquilo que ouviu não é o que eu pretendia

(62)

(63)

Aula 3

 Identificação dos Requisitos: Tipos de Requisitos

 Os requisitos podem ser divididos em duas categorias básicas :

(64)

(65)

Aula 3

 Requisitos Funcionais: ◦ Os requisitos funcionais descrevem o que o sistema deve fazer, isto é, as funções necessárias para atender os objetivos do sistema.  Exemplo: ◦ Cadastrar Clientes; ◦ Fazer Análise de Crédito; ◦ Fazer uma Transação com Banco de Dados; ◦ Cadastrar um Registro de Atendimento; ◦ Imprimir Relatório...

(66)

Aula 3

 Requisitos Não Funcionais: ◦ Os requisitos não funcionais dizem respeito as características do software, exemplos: performance, portabilidade, segurança, usabilidade e etc. Estas características descrevem também a qualidade do serviço.  Exemplo:

◦ O sistema deve usar

gráficos comparativos do aproveitamento do aluno com a média da turma; ◦ O sistema deve usar

cores na construção dos gráficos;

◦ As cores utilizadas

devem ser vermelho e preto;

◦ O tempo de resposta na elaboração do relatório não pode ser superior a 15 segundos.

(67)

Aula 3

 Regras de Negocio

 Regras do Negócio são declarações

sobre a forma da empresa fazer negócio.

 Elas refletem políticas do negócio.  Organizações têm políticas para

satisfazer os objetivos do

negócio,satisfazer clientes, fazer bom uso dos recursos, e obedecer às leis ou convenções gerais do negócio.

(68)

Aula 3

 As regras de negocio representam o

comportamento da organização dentro do sistema.

 É a regra de negócio que especifica as particularidades das

funcionalidades a serem desenvolvidas.

 As regras de negocio ajudam a

entender o funcionamento da empresa e obviamente o funcionamento do

(69)

Aula 3

 As regras de negocio tem relação com o comportamento da organização e desejável que este comportamento seja refletido no sistema.  EXEMPLO:  Ao se cadastrar no

nossa loja física todo cliente tem

que apresentar um CPF valido; ◦ No desenvolvimento do sistema durante o cadastro do cliente obrigatoriamente ele tem que possuir um CPF valido.

(70)

Aula 3

 Como Diferenciar :

◦Requisitos Funcionais?

◦Requisitos não Funcionais ?

◦Regras de Negocio;

 Resposta:

◦São Ações que o meus sistema tem que apresentar;

◦São características do meu sistema;

◦Normalmente tem haver com o problema em sí e não ao sistema.

(71)

Aula 3

 Sobre os Trabalhos:

◦As vezes uma imagem vale mais que mil palavras: