wiki

EL064X - Aula 07

Engenharia de Software é uma ciência?


  • Wikipedia:
    • "Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade"
    • Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema de informação e/ou de um sistema computacional, pois ambos se confundem!
    • Atualmente, essas tecnologias e práticas englobam:
      • linguagens de programação
      • banco de dados
      • ferramentas
      • plataformas
      • bibliotecas
      • padrões
      • processos
      • e a questão da Qualidade de Software.


  • Pode ser considerada como pesquisa onde o papel do pesquisador é compreender a natureza dos processos, produtos e o relacionamento entre os dois no contexto do sistema
  • O papel do profissional da prática (engenheiro de software) é construir sistemas cada vez melhores, utilizando o conhecimento disponível
  • Mais que em outras disciplinas, estes papéis são simbióticos
  • O pesquisador precisa dos laboratórios para observar e manipular as variáveis
  • Elas somente existem quando os engenheiros de software constróem sistemas de software
    • O engenheiro de software precisa compreender melhor como construir sistemas melhores
    • O pesquisador pode produzir modelos para ajudar


Engenharia de Software é desenvolvimento


  • As tecnologias da disciplina são baseadas no elemento humano
  • O Software não é o mesmo o tempo todo
    • Existe um enorme número de variáveis que provocam diferenças
    • Seus efeitos precisam ser entendidos
  • Atualmente,
    • o Conjunto de modelos insuficientes que nos permita pensar sobre a disciplina
    • Falta de conhecimento dos limites das tecnologias para certos contextos
    • Análise e experimentação insuficientes (empirismo x experimentação)


Processo de Software



Modelos ciclo de vida

  • Sequencial ou Cascata (Waterfall)
    • Fases distintas de especificação, projeto e desenvolvimento.




  • Desenvolvimento iterativo e incremental
    • Desenvolvimento é iniciado com um subconjunto simples de Requisitos de Software e interativamente alcança evoluções subseqüentes das versões até o sistema todo estar implementado




  • Evolucional ou Prototipação
    • Especificação, projeto e desenvolvimento de protótipos.




  • V-Model
    • Parecido com o modelo cascata, mas com uma organização melhor, que permite que se compare com outros modelos mais modernos.




  • Espiral
    • Evolução através de vários ciclos completos de especificação, projeto e desenvolvimento.




  • Componentizado
    • Reuso através de montagem de componentes já existentes.



  • Formal
    • Implementação a partir de modelo matemático formal.



  • Ágil
    • As metodologias ágeis surgiram a partir da necessidade de desenvolver aplicativos de software que pudessem acomodar a rápida e faseada evolução da Internet. Agile é, de certa forma, uma variante do ciclo de vida iterativo, onde os resultados são apresentados nos estágios
    • A principal diferença é no curto espaço de tempo de entrega, que passa de meses a semanas. As empresas que usam esta metodologia entregam os seus produtos de software em semanas, e não em meses
    • Além disso, o agile manifesto colabora lado a lado com os conceitos de desenvolvimento e ciclo de vida, tais como a colaboração, documentação e outros.




  • RAD
    • O "método de desenvolvimento rápido de aplicações" (em inglês Rapid Application Development ou RAD), definido por James Martin ao início dos anos 80, consiste num ciclo de desenvolvimento curto baseado em três fases (Enquadramento, Desenho e Construção) num prazo ideal de 90 e 120 dias no máximo.




  • Quarta geração
    • O paradigma Técnicas de Quarta Geração (4GT) da engenharia de software concentra-se na capacidade de se especificar software a uma máquina em um nível que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma função significativa.



Modelos de Maturidade


  • Capability Maturity Model Integration (CMMi)
  • MPS-BR


Metodologias e Métodos


  • Metodologia Estruturada
    • Análise Estruturada
    • Projeto Estruturado
    • Programação Estruturada
    • Análise Essencial
    • SADT - Structured Analysis and Design Techniques
    • DFD - Diagrama de Fluxo de Dados
    • MER - Modelo de Entidades e Relacionamentos


  • Metodologia Orientada a Objetos
    • Orientação a Objetos
    • Rational Unified Process ( RUP )


  • Desenvolvimento ágil de software
    • Feature Driven Development ( FDD )
    • Enterprise Unified Process (EUP)
    • Scrum (Scrum)
    • Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
    • Programação extrema ( XP )


  • Outras Metodologias
    • Microsoft Solution Framework ( MSF )

Modelagem


  • Análise estruturada [Gane & Searson]
  • Análise Essencial [Palmer & McMenamin e Ed. Yourdon]
  • UML [Grady Booch, Ivar Jacobson & Jaimes Rumbaugh]


Maré da Agilidade

O Maré de Agilidade é um evento itinerante que viaja pelas cidades do Brasil, apresentando assuntos como:

  • Extreme Programming(XP)
  • Scrum
  • Domain Driven Design (DDD)
  • Model Driven Design (MDD)
  • Test-driven Development (TDD)
  • Feature-driven Development (FDD)
  • Gerenciamento Ágil de Projetos (GAP)
  • Lean
  • e tantos outros.
  • Esses assuntos começaram a fazer parte do vocabulário do desenvolvedor de software, no entanto muitas vezes sem a devida capacitação para entendimento e aplicação de tantos conceitos.
  • Evento: Belém-PA
  • Período: 26 a 28/11/2009.

Grade


  • Gestão Ágil de Requisitos (Manoel Pimentel)
  • eXtreme Programming (XP) na Prática (Renato Willi e Paulo Igor)
  • Manifesto 2.0 (Alexandre Gomes)
  • As Armadilhas do Scrum (Alexandre Magno)
  • CASE: A Agilidade Está no Ar (Renato Willi)
  • Gestão Lean para Desenvolvimento de Software (Manoel Pimentel)
  • O Que Todo Agilista Deveria Saber Sobre Arquitetura (Felipe Rodrigues)
  • No Boteco com Agilistas (Open Space)
  • Imersão em Retrospectiva (Participe de uma Retrospectiva Real!)


Gestão Ágil de Requisitos

  • Começa com uma atividade interessante de colocar 2 pessoas que não se conheciam uma do lado da outra e pediu para que se entrevistassem durante 5 min para se conhecerem. Após isso, o parceiro era quem tinha que apresentar o colega.


  • Nessa atividade foi constatada que as perguntas tiveram um maior direcionamente nos interesses do entrevistador do que de conhecer de fato o colega, ou seja, que fazemos perguntas direcionadas ao nosso interesse.


  • Na análise de requisitos, por dependermos muito do modo como abordamos e somos abordados pelo cliente, devemos fazer reuniões e entrevistas que tenham foco no negócio que o sistema tratará.


  • Existe também outra atividade, onde algumas pessoas fazem mímicas sobre um determinado evento e os demais deveriam adivinhar do que se tratava. É um exercício para perceber quanto as pessoas são diferentes ao se expressarem. Alguns tem dificuldade de fazer a encenação e por isso surge dificuldade em ser compreendido, havendo assim, um problema de comunicação.


  • Ao se falar de Agile, muitos ligam com rapidez, entregas antes do prazo, desenvolvimento sem documentação, etc. Mas o Agile não tem a proposta de ser rápido, mas sim, ser eficiente. E sim, tem documentação, a mínima (e necessária) possível. Para escolher um mascote para o Agile entre o Coelho e a Tartaruga, seria mais óbvio escolhermos o Coelho. No entanto, se lembrarmos da estorinha da corrida, a Tartaruga foi quem venceu. Por quê? Por que ela teve foco e não se distraiu com o que não era importante.


Lateral Thinking


  • Dinâmica: Pensamento lateral
    • no futuro existirão três “mercadorias” fundamentais:
      • competência: uma empresa para poder sobreviver no futuro terá de ser competente;
      • informação: ninguém poderá destacar-se por ter mais informação, porque todos terão acesso a ela;
      • tecnologia: por si mesma não serve para criar valor. Passa-se o mesmo com a informação.
  • “A chave do êxito estará no valor que podemos extrair desta informação, tecnologia e no desenho e na distribuição dos produtos.
  • O pensamento tradicional não está preparado para esta transformação que as empresas devem levar a cabo para enfrentar o futuro.”


  • Outra dinâmica é um exercício baseado no livro do 6 Chapéus do Pensamento que coloca em ação uma forma de como controlarmos e organizarmos todos os pensamentos que nos vêm a cabeça durante uma reunião. Sessões:
  1. Organização da própria reunião (chapéu azul) => Visão global
  2. Geração de idéias (chapéu verde) => Criatividade
  3. Apuração de informações (chapéu branco) => Conhecimento
  4. Busca de uma visão positiva (chapéu amarelo) => Otimismo
  5. Identificação de riscos (chapéu preto) => Cautela
  6. Exposição de emoções (chapéu vermelho) => Emotividade



  • Ainda falando da técnica do 6 Chapéus do Pensamento, existe um outro exercício onde se usa os pensamentos do exercício anterior para montar um mapa mental. Essa técnica permite deixar clara as idéias anteriormente levantadas e onde elas se ligam. A sugestão é montar esse mapa mental (por exemplo, X-mind) junto com o cliente para que assim ele lembre ao máximo dos detalhes do que ele precisa do sistema. Se não for possível, se valida o mapa mental após ter concluído com o cliente.


  • Falando em estabelecer um escopo, é sugerido que seja feito de modo Iterativo e Incremental. É como a estória de se abater uma vaca. Não abatemos para comer ela inteira, comemos ela por partes. Devemos tentar partir nossa entrega em entregas menores, para no final compor o todo. Devemos andar em baby step's.


  • Outras técnicas
    • Story-writing workshops (Orientada pelos papéis)
      • Como um ___ (papel) eu posso/gostaria/devo ____ (funcao) para __________(realizar negocio).
    • Invest (Mike Crown) Independent, Negotiable, Valuable, Estimable, Small, Testable
    • Test First Visao do client (negocio)
    • TDD - Test Driven Development
    • BDD - Behavior Driven Development (comportamento)
      • Given <um valor>, when <situacao> then <acao>
    • FDD Feature(característica) Driven Development
    • Modelo A.R.O. <Ação> <Resultado> <Objeto>
    • FBS Feature BreakDown Structure
    • Scrum


  • Ferramentas sugeridas
    • AgileDraw
    • UML em Cores
    • X-Mind
    • FitNesse
    • Junit
    • RSPEC


Livros

  • User Stories Applied for agile software
  • Feature Driven Development
  • Agile Modeling - Scott
  • A Meta - Nobel


eXtreme Programming (XP) na Prática


  • Quando falamos em XP, Programação Extrema temos as impressões de que ele é:
    • POG melhorado
    • Não funciona com sistema grande
    • Não documenta
  • Creio o que o nome 'extrema' não tenha sido muito bem escolhido, causando essa má impressão.


  • O XP prega:

-Valores 

  Comunicação
  Simplicidade
  FeedBack
  Respeito
  Coragem

- Princípios 

  Humanidade
  Fatores econômicos
  Melhoria

- Prática 

  Prog em par
  Build em 10'
  Sentar juntos


  • No XP o constante acompanhamento e realização de pequenos ajustes durante o desenvolvimento faz com que ele esteja uma boa ferramenta para requisitos vagos e sistemas com mudança constante.

Uma premissa do XP é codificar testando. O TDD (Desenvolvimento dirigido por testes) é muito utilizado. Deve-se programar a passos de bebê. Avaliação de como trabalhar em equipe no XP Houve um exercício durante o mini curso, onde uma pessoa era o cliente e todos os demais da turma era a equipe. Um sistema de reserva de quartos de uma pousada foi montado. A forma de trabalho apresentada consistia em ter 2 programadores juntos codificando e reversavam a cada hr com outra dupla. Assim muitos puderam participar como desenvolvedores do projeto. O cliente fala para toda equipe o que deseja e todos ajudam a definir o BD, validações e testes em conjunto.

As dúvidas sobre o modo de apresentação do produto final é feita de forma aberta para o cliente, deixando ele falar o que quer. O objetivo é deixar a pergunta aberta sem sugerir uma solução. Depois, durante a conversa, podemos dar sugestão, no entanto, o cliente deve ser o responsável por essa decisão, pois se houver alteração de tempo, ele vai avaliar o que é melhor pra ele.


  • Livro
    • InfoQueue/BR - Scrum e XP direto das trincheiras

PPT \\10.32.8.163\cresult\CDS\ItensComuns\Treinamentos\MaterialTreinamentos

Palestras

Manifesto 2.0

  • Constatação: na história, a cada novo modo de fazer uma escultura, houveram vários estilos e cada um contradiz o anterior. E isso tbm vai acontecer no desenvolvimento de software.
  • É mais barato para empresa gerenciar a oscilação de humor do funcionário do que a rotatividade.
  • Aptitude 2.0 -> temos que desinstalar pacotes internos nossos, de cada integrante da equipe e instalar um pacote mais atualizado. Assim teremos mais atitude para mudar no projeto. Isso pq a mudança sempre será constante.
  • Não se querem mais especialistas, querem especialistas generalistas. Se vc só tem um martelo como ferramenta, todos os parafusos são vistos como pregos!
  • A inflação dos títulos estão denegrindo os nossos CVs. A cada ano temos que ter mais títulos e cada vez valem menos. Não q não tenham o seu valor, mas a cada ano teremos mais títulos, onde o mínimo exigido pelo mercado vai ficar cada vez maior.
  • Como o título não mede o papel de desempenho do funcionário, o q vai ser valorizar no CV daqui pra frente, vão ser os blogs, os fóruns, os projetos anteriores que o profissional participou. O qto a opinião e a interação com a comunidade vai ser cada vez mais valorizado.
  • Profissionais 2.0 se preocupa com a solução do projeto e não com a satisfaçao pessoal. Ex de profissional 1.0: qdo um proj acaba tendo frameworks não solicitados e q não agregam valor no resultado da solução, só por prazer do profissional utilizar os frameworks que quer, isso não é atitude com foco na solução.
  • O foco no desenvolvimento de software 2.0
  • Em time que ganha se mexe SIM! Se vc não tirar a equipe da rotina, não mudar a sala, não mudar de linguagem, enfim, não fazer mudanças, vc não ajuda no amadurecendo na equipe, que é o que gera a satisfação e logo a motivação da equipe.
  • Devemos abolir a Síndrome de Nostradamus
  • Mas vale um cliente 100% satisfeito com uma entrega parcial do que um cliente parcialmente satisfeito com uma entrega 100%
  • Convenção -> Rail e struts 2 -> atendem as necessidades da maioria e as exceções não são tão importantes
  • Discussão -> participar de todos e não ditar regras



As Armadilhas do Scrum


  • Scrum é como sogra, vive jogando na sua cara o que fez ou não fez de errado.

Documentar é preciso, mas somente o essencial. No momento do proj que se decide deixar a documentação para o final, neste momento vc está desvalorizando a documentação. Devemos criar novos hábitos. Cuidado com receitas de sucesso.

  • Papéis ->
    • Ex Scrum master não é só um título, mas uma mudança de comportamento. O ScrumMaster é responsável pelo funcionamento do Scrum. Não é o gerente do projeto. O PO deve ser bem escolhido, pois ele vai dar direção do que foco da solução a cada sprint.
  • Devemos continuar sendo -> multi-tarefa, multi-projeto, multi-tudo... mas tbm temos ser multi-disciplinar
  • Elaboração do Product Backlog -> o scrum master não é um gerente de projeto. Os backlogs devem ser definidos por todos.
  • Pocker -> serve não para medir o valor de uma atividade, mas o qto a pontuação de cada integrante influencia na pontuação do outro. Para cruzar as opiniões e avaliar as diferenças
  • Low-tech -> post-it, papéis de padeiro, etc. Utilize de uma forma útil, mas não seja refém dos post-it. É preciso ter organização, claro, mas não é necessário perder muito tempo com isso. Não interfere na solução final.
  • Engenharia de softw -> vc precisa, mas não é no Scrum que vc vai tê-las.
  • Reuniões diárias -> não é cofee break, não é bate-papo, não é 'conversa sobre relação', não é julgamento. Deve ser encarado como um micro gerenciamento.
  • Potencialmente entregável -> visualizar o que pode ser entregável
  • Perda de ritmo -> 1o. sprint 1 semana. 2o. sprint 3 semanas. 3o. sprint 4 semanas... isso não faz a equipe saber o seu ritmo
  • Cancelamento de sprints? q nada -> cancelar sprint é não ver isso como aprendizado.

O valor da 1a. sprint -> comece com um sprint bem elaborado para servir de exemplo para os outros sprints

  • Escopo fechado? -> é lenda! Não devemos pensar em escopo imutáveis, devemos pensar q sempre haverá alterações, pq tudo evolui.
  • Gordurinha-> security buffer

Os problemas continuam mesmo usando o Scrum. A intenção do Scrum, antecipar os problemas para que assim possam ser resolvidos a tempo. Por isso, não se anula a idéia de trabalhar no fds, a noite, etc. Ou seja, gera stress.

  • 3 práticas:
    • pergunte ao time
    • entregue
    • inspect/adapt



CASE - A Agilidade está no ar


Mostragem de projetos na aeronáutica fazendo uma retrospectiva falando de:

  • choque de cultura
  • q nao se poderia colocar post-it na parede
  • forma de trabalho
  • respeito a hierarquia
  • foi feito o uso de 'mantras'. Ex: no quadro KANBAN era escrito algumas frases como "Eu vou documentar o código"



Gestão Lean


  • Lean -> Realizar mais o q importa eliminando o q não importa. Simplicidade
  • The 5 whys -> perguntar sempre
  • heijunka -> nivelamento da producao. Evitar multitarefa (figura de um cirurgiao para varios pacientes)
  • hansei -> busca da melhoria continua. Retrospectiva
  • Kaizen -> Mudançao de atitude

pdca (plan do check action) ???

  • Poka-yoke -> Automação de testes (Dentro da TPS (Toyota Production System), Poka-Yoke é um dispositivo físico de controle que é acionado automaticamente quando há algum erro ou defeito no processo de produção, sendo que esse acionamento é feito normalmente por duas motivações: para controle e para advertencia)
  • Andon -> Impedimentos
  • KanBan -> comunicação, ritmo, entregas. O KanBan trabalha com a information irradiada e não refrigerada. Por isso o quadro, por isso os post-it coloridos. Para a inf estar aos olhos, irradiada na sala onde a equipe 'mexe o doce'. Já existem KanBan eletrônicos.
  • Fábula dos porcos cansados -> aaantigamente os porcos moravam na floresta e para comer os porcos, incediavam a floresta para comer os porcos e para isso se movimentava uma grande equipe para executar a atividade. Qdo alguém deu a idéia de caçar os porcos e depois



=== O que todo agilista deveria saber sobre arquitetura === Para aprofundar:

  • DDD
  • TDD (não é só jUnit)
  • Dependency Injection
  • REST
  • Domain Specific Language
  • eXtreme Programming

Links twitter.com/felipero felipero@gmail.com http://www.slideshare.net/rponte/entendendo-domaindriven-design

Boteco


  • Focar nos princípios e não nas metodologias. Adaptar as ferramentas a realidade da sua empresa.

Não devemos usar Agile, devemos entender seus princípios e adotar o que for bom e o que funciona para a nossa empresa. Agile X RUP:

  • A falha do RUP pode ter sido pela forma como foi vendido. Como uma ferramenta que ia resolver todos os problemas. E outra possível falha é que o entendimento geral seria de executar todos os processos do RUP.
  • O Agile está nascendo como um modo de trabalhar sem anular as atividades que já existem do cliente, mas na maneira como a equipe se comporta, se comunica. Para adotar o Agile veja onde 'tá doendo mais'. Dessa forma vc começa a adotar aos poucos a nova forma de trabalho e utilizando como uma solução de verdade.




Vídeo


  • [www.youtube.com/watch?v=1lqxORnQARw Hug a developer today]
Disponível em “http://3.143.69.156/wiki/index.php?title=EL064X_-_Aula_07&oldid=6968”