Escolhendo a

metodologia

Engenharia de Software
Jousy Gomes
jousy@fgf.edu.br
 Objetivo
• Conhecer como escolher dentre vária
metodologias.
 Clareza dos Requisitos (História) do Usuário

• Quando os requisitos do usuário a respeito do que o sistema deve

fazer não estiverem claros ou sujeitos a alterações.
• Em geral, a prototipagem do sistema e a prototipagem descartável
são mais apropriadas quando os requisitos do usuário não estiverem
claros, porque fornecem protótipos com os quais os usuários podem
interagir no início do CVDS.
• O desenvolvimento ágil também pode se mostrar apropriado se
houver a disponibilidade do usuário no local do desenvolvimento.
 Familiaridade com a tecnologia

• Aplicar a nova tecnologia nas fases iniciais da metodologia aumentará a

probabilidade de sucesso. Se o sistema for concebido sem alguma
familiaridade com a tecnologia de base, os riscos aumentam porque as
ferramentas podem não ser capazes de fazer o que é necessário.
• A prototipagem descartável é particularmente adequada para os casos de
falta de familiaridade com a tecnologia, porque estimula de forma explícita os
desenvolvedores a criarem protótipos de design para áreas com altos riscos.
• O desenvolvimento interativo (em fases) também é bom porque são criadas
oportunidades de investigar a tecnologia com alguma profundidade antes que
o design seja concluído.
• Embora alguém possa achar que a prototipagem do sistema também seja
apropriada, ela é muito menos adequada porque, em geral, os protótipos
iniciais construídos só arranham superficialmente a nova tecnologia. Somente
após vários protótipos e vários meses, em geral, os desenvolvedores
descobrem os pontos fracos ou os problemas da nova tecnologia.
Familiaridade com a tecnologia
 Complexidade do sistema

• Os sistemas complexos exigem análise e design cuidadosos e detalhados.

• A prototipagem descartável é particularmente bem apropriada para tais
análises e designs detalhados, mas a prototipagem do sistema, não. As
metodologias em cascata tradicionais podem ser empregadas no
desenvolvimento de sistemas complexos, porém, sem a capacidade de
entregar nas mãos do usuário os sistemas e protótipos no início do
desenvolvimento, algumas questões importantes podem passar
despercebidas.
• Embora as metodologias iterativas de desenvolvimento permitam que os
usuários interajam com o sistema no início do processo, temos
observado que as equipes de projeto cuja metodologia adotada é essa
tendem a dedicar menor atenção à análise do domínio completo do
problema que dedicariam se estivessem usando outras metodologias.
 Confiabilidade do sistema

• Quem deseja um sistema não confiável?

• Para algumas aplicações, a confiabilidade é verdadeiramente crítica (por exemplo,
equipamento médico, sistemas de controle de mísseis), enquanto, para outras,
ela é simplesmente importante (por exemplo, jogos, vídeos da Internet).
• O modelo V é útil quando a confiabilidade é importante em virtude da ênfase que
dedica aos testes.
• A prototipagem descartável é a mais apropriada quando a confiabilidade do
sistema possui prioridade alta, porque ela combina as fases detalhadas de análise
e projeto com a capacidade da equipe de projeto em testar muitas abordagens
diferentes por meio de protótipos de design antes de concluir o projeto.
• Geralmente, a prototipagem do sistema não é uma boa opção quando a
confiabilidade é crítica em razão da falta de fases criteriosas de análise e design,
essenciais para sistemas confiáveis.
 Selecionando uma tecnologia

• Quem deseja um sistema não confiável?

• Para algumas aplicações, a confiabilidade é verdadeiramente crítica (por exemplo,
equipamento médico, sistemas de controle de mísseis), enquanto, para outras,
ela é simplesmente importante (por exemplo, jogos, vídeos da Internet).
• O modelo V é útil quando a confiabilidade é importante em virtude da ênfase que
dedica aos testes.
• A prototipagem descartável é a mais apropriada quando a confiabilidade do
sistema possui prioridade alta, porque ela combina as fases detalhadas de análise
e projeto com a capacidade da equipe de projeto em testar muitas abordagens
diferentes por meio de protótipos de design antes de concluir o projeto.
• Geralmente, a prototipagem do sistema não é uma boa opção quando a
confiabilidade é crítica em razão da falta de fases criteriosas de análise e design,
essenciais para sistemas confiáveis.
 Escolhendo a metodologia

• Suponha que você seja um analista da ABC Company, uma grande

firma de consultoria com escritórios em todo o mundo. A empresa
deseja construir um novo sistema de gerenciamento de
conhecimentos que possa identificar e controlar a experiência de
consultores individuais em qualquer lugar do mundo, com base na
sua formação e nos vários projetos de consultoria nos quais
trabalharam. Admita que isso seja uma ideia inovadora, nunca antes
experimentada na ABC ou em qualquer outro lugar. A ABC tem uma
rede internacional, mas os escritórios em cada país podem usar
hardware e software diferentes. A administração da ABC deseja que o
sistema esteja pronto e funcionando em um ano.
• QUESTÃO: Qual metodologia você recomendaria para ser usada na
ABC Company? Por quê?
 Onde o desenvolvimento ágil funciona e onde não funciona
A British Airways (BA) enfrentou problemas como desenvolvimento de
software, apesar de possuir uma equipe de desenvolvimento disposta e
capaz. Mike Croucher, designado como engenheiro de software chefe,
recomendou uma mudança para o desenvolvimento ágil após estudar o
processo de desenvolvimento da BA. O movimento em direção ao
desenvolvimento ágil foi conduzido cuidadosamente, reconhecendo
que ele representa uma imensa mudança cultural para os
desenvolvedores. Os membros da equipe de desenvolvimento da BA,
acessíveis e adequados para os métodos ágeis, foram treinados como
mentores e treinadores do desenvolvimento ágil para ajudar a tornar a
transição mais fácil.
 Onde o desenvolvimento ágil funciona e onde não funciona
Converter para métodos ágeis permitiu à BA diminuir substancialmente
as exigências de tempo de determinados projetos. Em alguns casos, um
projeto, que podia levar nove meses seguindo uma metodologia
tradicional, foi concluído em oito semanas. Entretanto, apenas 25% da
organização foi modificada para o desenvolvimento ágil. A BA
reconheceu uma utilização contínua para a metodologia em cascata em
determinadas áreas e não pretendia forçar a utilização da metodologia
ágil em qualquer lugar. Na BA, a metodologia ágil é usada quando a
base de usuários exigir velocidade, flexibilidade e design orientado aos
clientes. A metodologia ágil é ideal quando uma área que exige
pequena funcionalidade pode ser desenvolvida.
 Cronogramas com prazos curtos
Os projetos com cronogramas de prazos muito curtos são bem
adequados às metodologias RAD, porque elas foram concebidas para
aumentar a velocidade do desenvolvimento. O desenvolvimento
iterativo e a prototipagem do sistema são excelentes opções quando os
prazos forem apertados, porque permitem que a equipe de projeto se
ajuste melhor à funcionalidade no sistema com base em uma data de
entrega específica. Se o cronograma do projeto começar a sofrer
atrasos, ela poderá ser reajustada pela remoção da funcionalidade da
versão ou do protótipo em desenvolvimento. As metodologias
baseadas no desenvolvimento em cascata são a pior opção quando o
tempo for uma prioridade por não permitirem fáceis alterações de
cronograma.
 Visibilidade de cronograma

Um dos grandes desafios no desenvolvimento de sistemas é saber se

um projeto está dentro do prazo. Isso é particularmente verdadeiro
para as metodologias com base no desenvolvimento em cascata,
porque o design e a implementação ocorrem ao final do projeto. As
metodologias RAD movem muitas decisões críticas de design para um
instante mais cedo no projeto a fim de ajudarem os gerentes de projeto
a reconhecerem e tratarem dos fatores de risco, além de manterem as
expectativas sob controle.
 Referências
PRESSMAN, R. S. & MAXIM, B. R.; Engenharia de
software. Uma abordagem profissional, 8 ed., McGraw
Hill, 2016.