METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE

Prévia do material em texto

METODOLOGIAS
ÁGEIS DE
DESENVOLVIMENTO
DE SOFTWARE
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de Brasília
Apresentação 
Olá, seja muito bem-vindo(a)!
Existem diferentes metodologias de desenvolvimento de software, algumas clássicas,
outras ágeis. A adoção da abordagem metodológica vai variar em função do perfil da equipe
e desenvolvimento e do tipo de tecnologias e técnicas envolvidas. Questões culturais e de
formação também são relevantes nesta escolha. Se por um lado as metodologias clássicas
de desenvolvimento de software demandam processos e padrões mais rígidos, com a
construção de documentação densa, por outro lado, as metodologias ágeis de
desenvolvimento de software apresentam alta flexibilidade e processos simples de serem
compreendidos e dominados. Não se trata de uma abordagem ser melhor ou pior do que a
outra. A análise que deve ser feita é sobre qual abordagem metodológica é a mais aplicável
ao seu contexto de desenvolvedor de software.
Esta Unidade está organizada em quatro seções que abordam, na sequência, os seguintes
conteúdos:
Qualidade.
Abordagens ágeis.
Scrum.
Extreme Programming.
Bons estudos!
Objetivos
Entender o conceito inicial de qualidade aplicada ao desenvolvimento de software.
Conhecer diferentes metodologias ágeis de desenvolvimento de software.
Compreender os benefícios das abordagens ágeis, considerando sua aplicabilidade
em diferentes contextos.
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de Brasília
Desafio 
Vamos acessar o site oficial da Scrum para conhecermos sobre as certificações para a
formação profissional em Scrum?
Abra um navegador de Internet (o Google Chrome, por exemplo).
Digite a seguinte URL: http://scrum.org/.
Clique na opção GET CERTIFIED.
Leia sobre os diferentes tipos de certificações, níveis, tipos de certificação por
carreiras.
Observe que a plataforma Scrum também traz treinamentos específicos para o
processo de certificação. Verifique qual se aplica ao seu perfil. É importante que você
comece direcionar sua especialidade dentro da área de tecnologia de informação e
comunicação. Isso amplia sua empregabilidade.
http://scrum.org/
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de Brasília
Conteúdo 
Qualidade
A qualidade de software pode ser compreendida como a totalidade das características de
um produto de software, que lhe confere a capacidade de satisfazer às necessidades
explícitas e implícitas (NBR 13596 , 1996).
Avaliar produtos de software constitui uma atividade bastante complexa em que a demanda
está crescendo significativamente devido a fatores externos como a globalização que afeta
diretamente grandes empresas e futuras empresas que pensam em crescer. Sendo assim,
os usuários exigem cada vez mais qualidade, eficiência, eficácia, dentre outros requisitos
que podem influenciar na aquisição de software. Por um lado, surge a oportunidade de se
desenvolver metodologia para avaliar a qualidade de produto de software com base em
requisitos de qualidade reconhecidos internacionalmente, dando subsídios para os clientes
(compradores de tecnologia) que adquirirem produtos com qualidade. Por outro lado, os
produtores de software têm a possibilidade de fornecer produtos de maior qualidade e
podendo crescer no mercado competitivo.
Os processos de desenvolvimento de software demandam estruturas de controle eficazes,
com etapas avaliativas e evolutivas, de modo a garantir a qualidade do produto de software
a ser entregue aos clientes. Isso envolve o projeto de software como um todo, mas também
suas partes, módulos, plug-ins, ou seja, toda a capacidade computacional precisa ser
avaliada.
Os benefícios de avaliação de software servem para:
o desenvolvedor utilizar os resultados da avaliação de seu produto para identificar
ações não desejadas como os bugs, com o objetivo de melhorá-lo, ou de tomar
decisões sobre a estratégia de evolução do produto podendo tomar como parâmetros
para outras áreas em que esse software poderá atuar; 
o fornecedor de software demonstrar confiabilidade no seu produto, sobretudo
agregar valores em relatório de Avaliação com finalidades comerciais; 
no futuro o cliente poderá conhecer o nível de qualidade do software para ajudá-lo na
tomada de decisão de aquisição deste produto.
Serão apresentados, nesta Unidade, alguns conceitos resumidos sobre qualidade e também
qualidade de software com base em modelos de qualidade de software. Além disso, uma
breve discussão para a verificação da qualidade do software em metodologias de
abordagens ágeis por meio de modelos de qualidade de software.
Conceituar qualidade é uma tarefa complexa, pois depende do ponto de vista, referência,
pela qual é avaliada, ou seja, ela é multifacetada. Segundo Kitchenham  (1996, p.36), a
qualidade pode ser descrita em cinco diferentes perspectivas:
1. A Visão Transcendental, que vê a qualidade como algo que pode ser reconhecido, mas
não definido.
2. O ponto de vista do usuário, a qualidade é descrita pela utilidade do produto para o
cliente.
3. O ponto de vista de produção, a qualidade é o grau de igualdade com o que foi
especificado pelo cliente.
4. O ponto de vista do produto, a qualidade é determinada pelas características
intrínsecas do produto.
5. O ponto de vista do valor, a qualidade é dependente do valor que o cliente está
disposto a pagar por ela.
 Kitchenham (1996) relaciona algumas definições sobre qualidade. Veja a seguinte tabela.
Tabela 1 - Definições sobre Qualidade
PERSPECTIVA DEFINIÇÃO
Transcendental Qualidade não é pensamento nem matéria, porém uma terceira
entidade independente das duas... muito embora qualidade não
possa ser definida, você sabe o que é. (Robert M. Pirsig)
Baseada no produto Diferenças na qualidade devem-se a diferenças na quantidade de
alguns ingredientes ou atributos desejados. (Lawrence Abbot)
Baseada no usuário Qualidade consiste na capacidade de satisfazer necessidades.
(Corwin Edwards)
Em uma última análise do mercado, a qualidade de um produto
depende de quão bem ele se ajusta aos padrões de preferência dos
consumidores. (Alfred Kuehn)
Qualidade é adequação ao uso. (J. M. Juran)
PERSPECTIVA DEFINIÇÃO
Baseada na produção Qualidade significa conformidade com as especificações. (Philip B.
Crosby)
Qualidade é o grau com o qual um produto específico atende a um
projeto ou às especificações. (Harold Gilmore)
Baseado no valor Qualidade é o grau de excelência a preço e controle de variabilidade
a custos aceitáveis. (Robert Broh)
Fonte: Kitchenham, 1996. (Adaptado)
Na essência, o propósito geral da qualidade é satisfazer as necessidades do cliente. Porém,
existem muitos fatores que na maioria das vezes são subjetivos a cada situação, como
descritos nas cinco diferentes perspectivas. Junto à qualidade de software não é diferente,
sendo até mesmo um segmento com grau de complexidade diferenciado.
Mesmo não tendo uma definição padrão sobre o que seja qualidade, essa é uma disciplina
estudada e explorada há bastante tempo, como se pode observar em várias organizações
que discutem e regulamentam a qualidade, dentre elas a American Society for Quality
Control (ASQC), a Associação Brasileira de Normas Técnicas (ABNT) e a International
Standardization Organization (ISO). O Institute of Electrical and Electronics Engineers (IEEE)
elaborou o Software Engineering Body Of knowledge (SWEBOK) ou Corpo de Conhecimento
de Engenharia de Software que divide a Engenharia de Software em onze áreas de
conhecimento, requisitos, gerência de engenharia, projeto, métodos e ferramentas de
engenharia, construção, processo de engenharia, testes, qualidade, manutenção, disciplinas
relacionadas à gerência de configuração. Porém, todas trabalham em conjunto com as
demais, tornando a qualidade uma subárea de cada uma das onze áreas (SWEBOK , 2004).
Da mesma forma que vimos na Unidade anterior, os modelos de maturidade também
apontam para a garantiada qualidade.
O modelo de qualidade de software mundialmente conhecido é o Capability Maturity Model
Integration (CMMI), que é um modelo que propõe um maior controle de qualidade no
desenvolvimento de software por meio da verificação de cinco níveis de maturidade, Nível 1
– Inicial, Nível 2 – Gerenciado, Nível 3 – Definido, Nível 4 – Gerenciado Quantitativamente e
Nível 5 – Otimizado.
O modelo de Melhoria do Processo de Software Brasileiro (MPS.BR) é outro modelo de
melhoria da qualidade, focado também em melhorias no que diz respeito a processos. O
objetivo do MPS.BR é definir um modelo de melhoria e avaliação de processo de software.
Este modelo assim como o CMMI possuem como base de sua evolução e
consequentemente um maior controle da qualidade, considerável ganho de maturidade
atingido por meio de níveis sequencialmente organizados em uma abordagem bottom-up:
Nível G – Parcialmente Gerenciado, Nível F – Gerenciado, Nível E – Parcialmente Definido,
Nível D – Largamente Definido, Nível C – Definido, Nível B – Gerenciado Quantitativamente,
Nível A – Em Otimização.
Abordagens ágeis
As metodologias de abordagens ágeis para desenvolvimento de software priorizam
processos empíricos que agregam de forma imediata algum valor para a produção de
software qualificada, trabalhando na forma de interações curtas, porém constantes ao longo
de todo o seu desenvolvimento.
O emprego de métodos ágeis é adequado em situações em que os requisitos sofrem
constantes alterações, agindo de forma a adequar-se às mudanças. São pertinentes aos
métodos ágeis o incentivo a comunicação entre as pessoas, recebendo de forma eficaz e
constante, algum retorno do trabalho desempenhado, tornando desta forma o cliente uma
peça fundamental para o bom desempenho da equipe garantindo o nível de qualidade
esperado para o software que foi desenvolvido em colaboração (BECK , 2004).
Segundo Toshiaki  (2006), as metodologias de abordagens ágeis parecem com o modelo
espiral tradicional, porém as metodologias de abordagens ágeis tratam de filosofias dentro
do desenvolvimento de software, além de simples processos ligados à engenharia de
software.
As metodologias de abordagens ágeis existentes possuem em comum os princípios e a
grande parte de seus valores, tendo como principal fonte destes o Agile Manifesto, em
Língua Portuguesa, Manifesto Ágil (MANIFESTO , 2010). O Manifesto Ágil contém uma
lista de princípios extremamente simples e focados no real objetivo do desenvolvimento de
software, a entrega de software funcional e valorada ao cliente.
São considerados valores do Manifesto Ágil (MANIFESTO, 2010):
Indivíduos e Iterações têm prioridade a processos e ferramentas.
Software Funcional tem prioridade à documentação excessiva.
Colaboração com o Cliente ao invés de contratos e negociações.
Adaptação a Mudanças ao invés de escopos de planejamento fechados.
São considerados princípios do Manifesto Ágil (MANIFESTO, 2010):
Prioridade é satisfazer ao cliente mediante entregas de software de valor em tempo
hábil e continuamente.
Aceitar mudanças dos requisitos, independente da fase no desenvolvimento, fazendo
das mudanças uma vantagem competitiva para o cliente.
Entrega funcional de software frequentemente em um intervalo curto de tempo, o
menor possível.
As equipes de negócios trabalham juntas com a equipe de desenvolvimento,
diariamente, durante todo o tempo.
Elaborar projetos rodeados de indivíduos motivados, dando ambiente, apoio e
confiança que eles precisam para realizar o trabalho.
Levantar informações de forma iterativa para a equipe melhorar os resultados finais,
procurar sempre a conversa cara a cara.
Software sempre funcionando como principal medida de progresso.
Processos ágeis promovem o desenvolvimento em um ritmo sustentável. Investidores,
desenvolvedores e usuários devem manter um ritmo constante.
Excelência técnica e um bom projeto como foco da atenção continuam aumentando a
agilidade.
Essencialmente não produzir o trabalho que possivelmente jamais será utilizado.
Equipes organizadas provêm arquiteturas, requisitos, e projetos de melhor qualidade.
Realizar periodicamente períodos de reflexão com toda a equipe, no intuito de se
tornar mais eficaz, ajustando e adaptando seu comportamento.
Existem diferentes metodologias ágeis de desenvolvimento de software. Cada metodologia
tem uma aplicabilidade específica para cada realidade de times de desenvolvimento de
software, mas também varia em função do tipo de software a ser desenvolvido. Como
método de abordagem ágil, podemos citar: Scrum; Programação extrema (Extreme
Programming (XP)), Feature Driven Development (FDD), entre outros.
SCRUM
O Scrum foi criado por Ken Schwaber, Jeff Sutherland e Mike Beedle entre os anos de 1980
e 1990. O foco da abordagem ágil Scrum é encontrar uma forma de trabalho dos membros
da equipe para produzir o software de forma flexível e em um ambiente em constante
mudança.
A ideia principal da Scrum é que o desenvolvimento de softwares envolve muitas variáveis
técnicas e do ambiente, como requisitos, recursos e tecnologia, que podem mudar durante o
processo. Isto torna o processo de desenvolvimento imprevisível e complexo, requerendo
flexibilidade para acompanhar as mudanças (MOREIRA , 2012). O resultado do processo
deve ser um software que seja realmente útil para o cliente. Desta forma, Scrum é um ótimo
modelo de gerenciamento de projetos e que também possui artefatos de incríveis
indicadores de acompanhamento dos projetos desenvolvidos de software (SCHWABER ,
2004).
Segundo a scrum.org, organização responsável pela conceituação e estruturação do Scrum,
trata-se de um framework com o qual equipes podem lidar com problemas complexos de
forma adaptativa, ao mesmo tempo que desenvolvem produtos de software de forma
produtiva, criativa e com a maior qualidade possível.
O Scrum divide o desenvolvimento em iterações (sprints) de trinta dias. Equipes pequenas,
de até dez pessoas, são formadas por projetistas, programadores, engenheiros e gerentes
de qualidade. Essas equipes trabalham em cima de funcionalidades (os requisitos, em
outras palavras) definidas no início de cada sprint. A equipe é responsável pelo
desenvolvimento desta funcionalidade. Liderados, o time se reúne sistematicamente, mas
com encontros curtos e de pé, para não haver aumento do tempo de reunião, como uma
estratégia caso os participantes não se cansem e, se cansarem, terminem a reunião. Neste
momento, pontos importantes são tratados, assim como retrospecto do dia anterior.
O ciclo de vida da Scrum pode ser representado em três visões conforme suas principais
fases:
1. Pré-planejamento (Pre-game phase): os requisitos são descritos em um documento
chamado backlog. Posteriormente, eles são priorizados e são feitas estimativas de
esforço para o desenvolvimento de cada requisito. O planejamento inclui também,
entre outras atividades, a definição da equipe de desenvolvimento, as ferramentas a
serem usadas, os possíveis riscos do projeto e as necessidades de treinamento.
Finalmente é proposta uma arquitetura de desenvolvimento. Eventuais alterações nos
requisitos descritos no backlog são identificadas, assim como seus possíveis riscos
(SHWABER, 2004).
2. Desenvolvimento (game phase): as muitas variáveis técnicas e do ambiente
identificadas previamente são observadas e controladas durante o desenvolvimento.
Ao invés de considerar essas variáveis apenas no início do projeto, como no caso das
metodologias tradicionais, na Scrum o controle é feito continuamente, o que aumenta
a flexibilidade para acompanhar as mudanças. Nesta fase, o software é desenvolvido
em ciclos (sprints) em que novas funcionalidades são adicionadas. Cada um desses
ciclos é desenvolvido de forma tradicional, ou seja, primeiramente faz-se a análise, em
seguida o projeto, implementação e testes. Cada um desses ciclos é planejado para
durar de uma semana a um mês.
3. Pós-planejamento (post-game phase): post-game phase é a etapa de pós-
planejamento, com encontros sistemáticos para avaliação e controledo progresso de
desenvolvimento de software, realizando as integrações com outros módulos e
sistemas, testagem e atualização documental, se for o caso.
Figura 1 –Visões de um projeto
Fonte: Kniberg, 2009. (Adaptado)
A Figura 1 apresenta as três visões do Scrum: (i) visão do projeto; (ii) visão do produto; e (iii)
visão do processo. Em nível de processo, são realizadas reuniões diárias rápidas e todos os
sprints são realizados dentro das melhores práticas de engenharia de software, de modo a
entregar o produto dentro dos padrões de qualidade para o cliente.
Scrum é um framework para projetos cujo horizonte não é superior ao período de um mês,
onde já há complexidade suficiente tal que um horizonte mais longo seria arriscado demais.
Times Scrum são projetados para otimizar flexibilidade e produtividade (SHWABER, 2004).
Para esse fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações. O
Time consiste em desenvolvedores com todas as habilidades necessárias para transformar
os requisitos do Product Owner em um pedaço potencialmente entregável do produto ao
final da Sprint (SHWABER, 2004).
O Scrum apresenta uma estrutura simples e não demanda grandes volumes de
documentações. Não se trata de uma metodologia, mas de um conjunto de práticas auto-
organizadas, heuristicamente programadas para a resolução de situações imprevistas e
problemas complexos.
Extreme Programming
A Extreme Programming (XP), em português, Programação Extrema ou simplesmente XP
(BECK, 2004), é uma das mais conhecidas Metodologias Ágeis de desenvolvimento de
software.
A metodologia ágil de desenvolvimento de software Extreme Programming contém um
processo documental, com diferentes tipos de documentos (também chamados de
artefatos), para garantir a atualização e manutenção do sistema. Um dos principais
artefatos desta metodologia é o User Stories, ou Cartão de Histórias, visto sua importância
para a coleta de requisitos funcionais e não funcionais dos sistemas. Auxilia também na
especificação dos modelos e diagramas, além de servir como base para métricas de
software.
Entre outras práticas e características de XP, convém destacar a programação dirigida a
testes, TDD Test Driven Development e também a programação pareada, Pair Programming
(BECK, 2004; TOSHIAKI, 2006).
As principais diferenças da XP em relação às outras metodologias são:
Feedback constante.
Abordagem incremental.
A comunicação entre as pessoas é encorajada (BECK, 2004; TOSHIAKI, 2006).
A XP enfatiza o desenvolvimento rápido do projeto e visa garantir a satisfação do cliente,
além de favorecer o cumprimento das estimativas. As regras, práticas e valores da XP
proporcionam um agradável ambiente de desenvolvimento de software para os seus
seguidores, que são conduzidos por quatro valores: comunicação, simplicidade, feedback e
coragem (BECK, 1999).
 A XP baseia-se nas 12 práticas (BECK, 1999) a seguir:
1. Planejamento: consiste em decidir o que é necessário ser feito e o que pode ser
adiado no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de
software, não em requisitos futuros. Além disso, a XP procura evitar os problemas de
relacionamento entre a área de negócios (clientes) e a área de desenvolvimento. As
duas áreas devem cooperar para o sucesso do projeto, e cada uma deve focar em
partes específicas do projeto. Desta forma, enquanto a área de negócios deve decidir
sobre o escopo, a composição das versões e as datas de entrega, os desenvolvedores
devem decidir sobre as estimativas de prazo, o processo de desenvolvimento e o
cronograma detalhado para que o software seja entregue nas datas especificadas.
2. Entregas frequentes: visa à construção de um software simples. Conforme os
requisitos surgem, há a atualização do software. Cada versão entregue deve ter o
menor tamanho possível, contendo os requisitos de maior valor para o negócio.
Idealmente, devem ser entregues versões a cada mês, ou no máximo a cada dois
meses, aumentando a possibilidade de feedback rápido do cliente. Isto evita surpresas
caso o software seja entregue após muito tempo, melhora as avaliações e o feedback
do cliente, aumentando a probabilidade do software final estar de acordo com os
requisitos do cliente.
3. Metáfora: são as descrições de um software sem a utilização de termos técnicos, com
o intuito de guiar o desenvolvimento do software.
4. Projeto simples: o programa desenvolvido pelo método XP deve ser o mais simples
possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros.
Eventuais requisitos futuros devem ser adicionados assim que eles realmente
existirem. Esta forma de raciocínio se opõe ao “implemente para hoje e projete para
amanhã”.
5. Testes: a XP focaliza a validação do projeto durante todo o processo de
desenvolvimento. Os programadores desenvolvem o software criando primeiramente
os testes.
6. Refatoração: focaliza o aperfeiçoamento do projeto do software e está presente em
todo o desenvolvimento. A refatoração deve ser feita apenas quando é necessário, ou
seja, quando um desenvolvedor da dupla, ou os dois, percebe que é possível
simplificar o módulo atual sem perder nenhuma funcionalidade.
7. Programação em pares: a implementação do código é feita em dupla, ou seja, dois
desenvolvedores trabalham em um único computador. O desenvolvedor que está com
o controle do teclado e do mouse implementa o código, enquanto o outro observa
continuamente o trabalho que está sendo feito, procurando identificar erros sintáticos
e semânticos e pensando estrategicamente em como melhorar o código que está
sendo implementado. Esses papéis podem e devem ser alterados continuamente.
Uma grande vantagem da programação em dupla é a possibilidade dos
desenvolvedores estarem continuamente aprendendo um com o outro.
8. Propriedade coletiva: o código do projeto pertence a todos os membros da equipe.
Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código,
mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça a
bateria de testes necessária. Isto é possível porque na XP todos são responsáveis pelo
software inteiro. Uma grande vantagem desta prática é que, caso um membro da
equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto com
poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que
não seja de forma detalhada.
9. Integração contínua: interagir e construir o sistema de software várias vezes por dia,
mantendo os programadores em sintonia, além de possibilitar processos rápidos.
Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona
bem porque fica óbvio quem deve fazer as correções quando os testes falham: a
última equipe que integrou código novo ao software. Esta prática é facilitada com o
uso de apenas uma máquina de integração, que deve ter livre acesso a todos os
membros da equipe.
10. 40 horas de trabalho semanal: a XP assume que não se deve fazer horas extras
constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda
semana consecutiva, existe um problema sério no projeto que deve ser resolvido não
com aumento de horas trabalhadas, mas com melhor planejamento, por exemplo. Esta
prática procura ratificar o foco nas pessoas e não em processos e planejamentos.
Caso seja necessário, os planos devem ser alterados, ao invés de sobrecarregar as
pessoas.
11. Cliente presente: é fundamental a participação do cliente durante todo o
desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas
as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma
ideia interessante é manter o cliente como parte integrante da equipe de
desenvolvimento.
12. Código padrão: padronização na arquitetura do código, para que este possa ser
compartilhado entre todos os programadores.
Finalizando a Unidade 
Nesta Unidade, conhecemos as relações entre os processos de desenvolvimento de
software e como as abordagens ágeis podem contribuir para a entregade produtos
com qualidade e dentro dos parâmetros definidos pelos atores envolvidos nos
diferentes processos.
Navegamos um pouco no contexto do conceito inicial de qualidade aplicada ao
desenvolvimento de software, perpassando por diferentes metodologias ágeis de
desenvolvimento de software e sobre quais seriam os possíveis benefícios de adoção
de tais abordagens, considerando sua aplicabilidade em diferentes contextos.
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de Brasília
Dica do Professor 
Você estudou que as metodologias ágeis têm características contemporâneas que
incrementam a produtividade em ambientes de desenvolvimento de software. Para que se
tenha sucesso com esse tipo de metodologia, é preciso que o trabalho em equipe seja
efetivo. Fazer gestão de pessoas é essencial, nesse contexto. Inclusive, é importante a
adoção de práticas que despertem competências socioemocionais dos membros da equipe.
Vamos ampliar nosso conhecimento sobre metodologias ágeis?
Busque a seguinte referência no Google Acadêmico e divirta-se com a leitura:
SOARES, Michel dos Santos. Metodologias ágeis extreme programming e scrum para o
desenvolvimento de software. Revista Eletrônica de Sistemas de Informação, v. 3, n. 1,
2004.
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de Brasília
Saiba Mais 
Nesta Unidade, discutimos um pouco sobre abordagens metodológicas e algumas técnicas
envolvidas. Para a modelagem de sistemas, existem diferentes plataformas, incluindo
aquelas específicas para o desenho de fluxogramas, com definição de responsáveis,
processos e indicadores de tomada de decisão. Você já ouviu falar sobre o Bizagi?
Bizagi Modeler é uma plataforma gratuita, intuitiva, que pode ser utilizada para a
modelagem de processos de negócio, com funcionalidades baseadas em notação BPMN.
Quer saber um pouco mais? Acesse o Bizagi Modeler e navegue na plataforma. Crie seu
cadastro e utilize o Bizagi Modeler para simular a construção de fluxos automatizados.
Acesse o canal Scrum.org no YouTube e assista ao vídeo “A brief overview of the Scrum
Framework ”. Este vídeo traz uma explicação gráfica sobre os aspectos introdutórios
do Scrum.

http://bizagi.com/
https://www.youtube.com/watch?time_continue=6&v=gy1c4_YixCo&feature=emb_log
http://savefrom.net/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Ftime_continue%3D6%26v%3Dgy1c4_YixCo%26feature%3Demb_log&utm_source=chrome&utm_medium=extensions&utm_campaign=link_modifier
©2018 Copyright ©Católica EAD. Ensino a distância (EAD) com a qualidade da Universidade Católica de Brasília
Referências 
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 13596: tecnologia de
informação - avaliação de produto de software: características de qualidade e
diretrizes para o seu uso. Rio de Janeiro, RJ, 1996.
BECK, Kent. Programação Extrema Explicada. Porto Alegre: Bookman, 2004.
MANIFESTO, Agile. Manifesto for Agile Software Development, 2010.
KITCHENHAM, B.; PFLEEGER S. Software Quality: The Elusive Target. IEEE Software,
Boston, vol 13, n. 1, p. 12-21, jan. 1996.
SCHWABER, Ken. Agile project management with Scrum. Microsoft press, 2004.
SWEBOK. Guide to the SWEBOK, 2004.
TOSHIAKI, Danilo Sato. Uso Eficaz de Métricas no Desenvolvimento Ágil de software,
São Paulo, 2007.