Visão da Aplicação: O Que É?

Loading...

Do curso por Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

131 classificações

Instituto Tecnológico de Aeronáutica

Princípios de Desenvolvimento Ágil de Software

131 classificações

Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios orientados a objetos, TDD e conceitos avançados de Java aplicados à Web e banco de dados exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em planejar e gerenciar o desenvolvimento das aplicações com base em modernas práticas de modelagem ágil. O objetivo deste curso é expor você às principais técnicas e princípios de desenvolvimento ágil, em especial aos que se popularizaram pela sua utilização no framework Scrum e na metodologia XP (Extreme Programming). Apresentamos o Scrum&XP, uma combinação apropriada do framework Scrum com a metodologia XP – Extreme Programming, sem no entanto afirmar que você estará aprendendo tudo sobre Scrum ou sobre XP. Os conceitos apresentados neste curso incluem o seguinte: * Manifesto ágil e princípios de desenvolvimento ágil * Requisitos de software na forma de user stories e backlog de produto * Eventos e reuniões do Scrum&XP: Sprint, Sprint Planning, Planning Poker, Daily Scrum, Sprint Review e Sprint Retrospective, TDD e Programação em Pares * Papéis do Scrum: Product Owner, Time de Desenvolvedores e Scrum Master * Tarefas, Sprint Backlog, Quadro de Tarefas e Diagrama Burndown Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar de modo ágil um sistema que incorpora um componente de gamificação constante do Trabalho de Conclusão do Programa de Cursos Integrados, com base nas boas práticas ágeis exercitadas neste curso com o Scrum&XP apresentado. Obs.: Embora o Programa de Cursos Integrados (descrito abaixo) seja sobre a linguagem Java no contexto de desenvolvimento ágil, neste curso em especial você poderá empregar a linguagem que desejar, embora incentivemos que os alunos dos cursos anteriores do programa faça uso do Java, pois será uma oportunidade muito enriquecedora de praticar TDD com Java da maneira que se faz na indústria de software. -- --- ---- coursera.org: ITA Programa de Cursos Integrados: Programação Java e Modelagem Ágil Curso 1: Orientação a Objetos com Java Curso 2: TDD – Desenvolvimento de Software Guiado por Testes Curso 3: Desenvolvimento Ágil com Java Avançado Curso 4: Princípios de Desenvolvimento Ágil de Software Curso 5: Desenvolvimento Ágil com Padrões de Projeto Curso 6: Técnicas Avançadas para Projeto de Software Curso 7: Arquitetura de Software em Projetos Ágeis Projeto Final: Aplicativo para Web com Componente Gamificado

Na lição

Semana 1

Olá, bem-vindo ao Curso 4 – Princípios de Desenvolvimento Ágil de Software! Estamos contentes que você esteja aqui para ter os primeiros contatos com modelagem ágil de software. Neste módulo introdutório, você será apresentado ao Scrum&XP, uma combinação apropriada do Scrum com o XP. Ao final deste módulo você também terá aprendido sobre Manifesto Ágil, user stories e visão da aplicação.

Visão da Aplicação: Por Quê?11:40

Visão da Aplicação: O Que É?8:26

Visão da Aplicação: Exemplo!10:31

Conheça os instrutores

Clovis Fernandes
Professor Titular in Portuguese
Ciência da Computação
Eduardo Guerra
Professor Colaborador

[MÚSICA] Olá,

bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software,

eu sou Clóvis Fernandes E hoje iremos apresentar o que é a Visão da Aplicação,

a visão do produto,

no contexto nosso do Scrum&XP s os user stories.

Bom, nós havíamos definido que a Visão da Aplicação

tem dois lados: a Visão ou Valor de negócios e que vão realmente

direcionar as necessidades dos clientes ou dos

tipos de usuários que a gente vai usar, tá certo?

O que vai nos interessar é isso aqui, né, tá certo?

Essa parte aqui da necessidade

dos clientes é que vai nos interessar, tá certo?

Nós queremos é ver isso, embora por causa do PO,

o product owner nós teremos sempre

representante que vai estar sempre olhando o que nós estamos como

equipe desenvolvendo como Visão ou Valor de Negócio,

agora quando eu estou escrevendo a Visão da Aplicação o que mais nos

interessa é isso aqui: as necessidades dos clientes,

de qualquer forma vai ser a equipe como todo que vai trabalhar nisso, né?

Inicialmente, nós identificamos os tipos de usuários ou User Roles, tá certo?

Nós vamos identificar o "Who" e nós vamos identificar as

necessidades de cada dos tipos de usuários que nós identificarmos,

então é isso que nós vamos fazer, quer dizer,

basicamente iremos identificar esses papéis,

as necessidades e com base nessas necessidades nós

vamos então desenvolver os requisitos, a segunda parte então é essa:

é identificar os atributos do produto O que são os atributos dos produtos?

São os Requisitos Funcionais e os Requisitos Não Funcionais,

ou seja, então além da identificação dos tipos de usuários

e das necessidades dos tipos de usuários, nós vamos delinear

melhor essas necessidades dos usuários de uma forma

pouquinho mais interessante que é na forma de requisitos Funcionais e Não Funcionais,

exemplos de Requisitos Funcionais: por exemplo,

no aplicativo que você tem do WhatsApp, fazer uma chamada telefônica,

isso é requisito funcional, mandar uma mensagem,

post para uma outra pessoa também é requisito funcional,

enviar e-mail no seu software de e-mail, isso é requisito funcional, tá certo?

Ou seja, o software foi feito para atender essas necessidades que são

específicas dos tipos de usuários envolvidos.

Já os Requisitos Não Funcionais,

eles vão ter impacto obviamente nos Requisitos Funcionais mas eles olham

a coisa de uma maneira mais global e eles são bastante influenciados

pelo Valor de Negócio,

pela Visão de Negócio, eu tenho aqui

requisito de performance, que é o desempenho, tá certo?

Porque se é website, por exemplo,

eu não quero que o serviço que o site está me oferecendo demore muito, tá certo?

Quer dizer, além da demora que eventualmente tem pelo tráfego na internet

normal o site vai demorar muito?

Não, então não deve demorar muito.

Questão da robustez: ou seja, não é porque ocorre algum pequeno

problema no meu sistema que tudo tem que parar, tá certo?

Pode parar exatamente uma determinada coisa que deu o problema,

mas não o resto e isso significa ter robustez e é o que eu quero,

se eu estou fazendo software pela internet ou aplicativo de tablet ou de celular,

eu quero que ele tenha bastante robustez.

E a outra coisa que eu quero também,

é a usabilidade, então ele tem que ser fácil de usar,

eu não posso ter muita dificuldade, eu não posso cometer erros porque

a disposição da interface está me causando dificuldade de entendimento.

Obviamente, nós temos outros tipos de Requisitos Não Funcionais,

como, por exemplo, seria o da disponibilidade,

o sistema tem que estar funcionando 24 horas, todo dia,

7 dias por semana, por exemplo, é outro tipo, tá certo?

E existem vários outros mais que não iremos tratar aqui.

Na Visão, quais são os cuidados que nós devemos tomar ao

desenvolver a Visão da Aplicação?

Grande problema é o que a gente chama de subespecificação,

aqui "subespecificação" não está escrito errado,

você escreve sem hífen e fala como se tivesse hífen: "subespecificação",

é você especificar muito rapidamente, com poucos elementos e o que vai acontecer?

O "desenhinho" aqui tá deixando isso bem claro aqui: a sua

estrada à frente não está clara, não está muito clara,

ou seja, é problema de subespecificação, você não tá conseguindo ver o suficiente,

pra poder prosseguir com segurança, com segurança de

que você vai desenvolver bom produto dentro do tempo no custo determinado.

O outro é a superespecificação, o mesmo problema:

a gente lê "superespecificação"

como se tivesse hífen, mas não tem hífen, tá certo?

Não tem hífen aqui.

O que que acontece com a superespecificação?

Eu não quero cair naquele problema do BDUF- Big Design Up Front,

ou seja, eu não quero perder muito tempo e fazer uma especificação detalhada e

aquilo depois não é o que o cliente final realmente quer,

então eu perdi muito tempo, muito dinheiro e não fiz o que devia, tá certo?

O que realmente nós queremos é a especificação suficiente,

o que eu chamo, atenção, é só eu que chamo isso, tá certo?

Vocês não vão encontrar esse tipo de coisa outro lugar, é o EDUF,

a especificação suficiente, então a minha Visão da Aplicação deve ter apenas

o suficiente para que eu consiga ver a estrada à frente pouco.

E não parar

porque não consegui vislumbrar coisas óbvias

que deveria vislumbrar e problemas e não consegui identificar,

então a especificação suficiente é o que é o importante nessa Visão da Aplicação,

principalmente porque nós vamos fazer isso sempre dia,

não é muito comum fazer dia, mas uma semana é o bastante comum, tá certo?

E duas semanas quando o custo da aplicação é muito grande, tá certo?

Com isso, nós mostramos pra você o que é a Visão da Aplicação no

contexto nosso do Scrum&XP.

Obrigado!

[MÚSICA]

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2018 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play