Home
Aqui você encontra tudo em softwares e aplicativos dos melhores fabricantes.
Ainda não é Cadastrado?
Clique Aqui e cadastre-se agora.
Softwares são fonte de bons negócios e ótima lucratividade, estamos cadastrando revendedores de todo Brasil.
Procuramos soluções para agregar ao nosso potifórlio e estamos prontos para distribuir os seus produtos e serviços à nossa base de clientes.
Processo Ágil de Requisitos de Software
Processo Ágil de Requisitos de Software: Boas Práticas
No âmbito da subárea de Engenharia de Requisitos que por sua vez pertence a área de Engenharia de Software ,
surgiram novas metodologias de especificar requisitos. A metodologia
convencional de especificação e desenvolvimento de software dá forte
ênfase na documentação e planeamento antecipado de todo o Processo de Engenharia de Requisitos .
No entanto novos métodos de desenvolver software surgiram, sendo que o Desenvolvimento ágil de software e as suas metodologias tais como XP , Scrum , Feature Driven Development ou Test-driven development
permitiram que se desenvolvessem softwares mais rapidamente, com maior
qualidade, simplicidade e robustez. A nível organizacional e social
permitiu maior interacção, comunicação entre todos os stakeholders
envolvidos maior incidência no trabalho de especificação de requisitos
e Desenvolvimento de Software, não dando tanto ênfase ao planeamento,
contracto de negociação, documentação extensiva, processos e
ferramentas. Tal mudança alterou a forma como o Processo de Engenharia de Requisitos é abordado, dado origem a um Processo Ágil de Requisito de Software.
Com este artigo pretende-se abordar boas práticas que um Processo
Ágil de Especificação de Requisitos deve ter em consideração. Não se
pretende afirmar que todas estas práticas devam ser incluídas, mas sim
analisadas consoante o contexto do projecto e/ou do cliente. Geralmente
são práticas de senso comum, muitas vezes esquecidas e/ou
negligenciadas devido à absorção diária de trabalho, rotinas, falta de
constante actualização de novas formas de liderar e/ou desenvolver
projectos de software.
Quando se está a modelar e a levantar requisitos a prática
fundamental é a participação activa dos stakeholders (Robertson 2006).
Aqui há duas questões a ter em conta de forma a permitir esta boa
prática (Ambler 2002):
Quando uma equipa de projecto não consegue ter acesso adequado aos
stakeholders, isto é culpa da própria equipa de projecto (Ambler 2002),
portanto, pode ser complicado aceder aos stakeholders e mesmo
colocá-los a participar.
É importante que os stakeholders do projecto e os colaboradores
estejam envolvidos na identificação de ideias e sugestões, discutindo
requisitos, modelando-os e possivelmente documentando-os. Os
stakeholders do projecto são somente responsáveis por prioritizar os
requisitos e por sua vez os colaboradores são responsáveis por estimar
o esforço. No entanto o esforço estimado é passível de ser alterado
sempre que existem alteração de requisitos ou quando há uma má
estimativa.
Adopção de modelos inclusivos
Para facilitar o envolvimento dos stakeholders do projecto na
modelação de requisitos e documentação devemos seguir a prática "Usar
Ferramentas Simples". Notas de "Post It" e User Card Stories são dois
exemplos de levantar/modelar requisitos (Ambler 2002). Sempre que se
introduz tecnologia para modelar os requisitos levantados, de forma a
desenhar um nova versão dos diagramas, estamos a tornar difícil a
participação dos stakeholders, dado que agora não estão apenas a
aprender técnicas de modelação de requisitos bem como a aprender
ferramentas de modelação (Ambler 2002). Mantendo o processo simples
estamos a encorajar a participação e a aumentar a a colaboração
efectiva.
No entanto workshops, sessões de brainstorming são métodos de
extracção e modelação de requisitos que são bastante úteis na maioria
dos projectos (Robertson 2006). Ambos os métodos têm por base um grupo
de pessoas interessadas em gerar novas ideias de forma a resolver o
problema comum. São geralmente sessões onde os stakeholders sentem
maior entusiasmo e onde se sentem como mais um elemento de uma equipa
com o objectivo de resolver um problema.
Adoptar uma abordagem "Primeiro em Largura
É-se aconselhado a evitar a começar a descrever pormenorizadamente
requisitos (Ambler 2002) (Robertson 2006). Deve-se adoptar inicialmente
uma abordagem "Primeiro em Largura", ou seja, ter uma visão geral de
todos os requisitos que dará por si só a visão do projecto. Sendo que
depois sempre se pode detalhar requisito a requisito. No entanto muitas
empresas ainda preferem a abordagem "Big Modeling Up Front (BMUF)",
onde se investe tempo significativo a recolher, documentar, rever e a
aceitar requisitos no período inicial do projecto e só depois é que
avançam para a fase de implementação (Ambler 2002). Teoricamente parece
ser uma ideia excelente, mas na realidade não é muito eficaz na maioria
dos projectos. Num estudo efectuado em 2001 por M. Thomas no Reino
Unido, de 1027 projectos analisados referiam que a gestão relacionada
com as práticas do modelo "Waterfall" incluindo requisitos já
detalhados antes da fase da implementação, foi citado em 82% dos casos
como a causa número 1 pela falha do projecto. Este estudo é suportado
pelo estudo de Jim Johnson do Standish Group que refere que sempre que
os requisitos são especificados na fase inicial do ciclo de vida do
produto cerca de 80% das funcionalidade não são relevantes para o
cliente, referindo que 45% das características não são usadas, 19% são
raramente usadas e apenas 16% são usadas algumas vezes (Ambler 2002).
Sendo que as principais causas para tal acontecer são as seguintes:
perante um problema eles tentam imaginar todos os potencias requisitos
que daí podem adver, sem sequer pensar se isso é realmente relevante
para o cliente. Contribuindo assim para que o ciclo de desenvolvimento
do produto seja bem maior.
utilizadores mudam ao longo do ciclo de desenvolvimento do
sistema/aplicação/produto/serviço.
Modelar detalhes em Just in Time (JIT)
Os requisitos são identificados ao longo do projecto, apesar de a
maioria dos requisitos serem identificados e trabalhados no início do
processo de Requisitos, é provável que ainda estaremos a trabalhar
neles mesmo antes da entrega de uma release. É aqui que devemos
"abraçar" as alterações de requisitos e adoptar um levantamento de
requisitos de uma forma evolutiva, iterativa e incremental.
O objectivo é implementar requisitos, não documentá-los
Demasiados projectos são confrontados com o excesso de trabalho para
desenvolver e manter documentação compreensiva e manter pontos de
ligação entre os diversos documentos. Devemos seguir uma abordagem ágil
e manter a documentação "*lean*" e efectiva. A documentação eficiente e
efectiva é geralmente suficiente boa o projecto em mão. Actuando assim
podemos focar a nossa energia no desenvolvimento de software.
Criar requisitos independentes da plataforma
Deve-se sempre que possível evitar que um requisito dependa ou seja
baseado em elementos tecnológicos. Aqui a focalização é levantamento de
requisitos e não a associação com qualquer tipo de tecnologia. Da mesma
forma não se pode modelar requisitos assumindo que determinada empresa
irá adoptar determinadas tecnologias só por serem as mais aconselhadas
para a elaboração do projecto. Mais uma vez determinadas empresas ainda
não estão culturalmente, socialmente ou economicamente preparadas para
dar esse salto. Nesse caso provavelmente terá de se tirar vantagem das
infraestruturas tecnológicas da própria empresa ou organização, sendo
que mesmo até nestes casos os requisitos deverão ser sempre que
possíveis independentes da tecnologia.
Pequeno é o melhor
Pequenos requisitos, como características e "_user stories_" são
mais fáceis de estimar e construir do que requisitos grandes complexos,
tais como "_use-cases_" (Robertson 2006). Normalmente um use-case
descreve maiores e mais complexas funcionalidades do que um "_user
story_". Pequenos requisitos são igualmente bem mais fáceis de
priorizar e de gerir.
Questionar a procura de requisitos
Pensar bem antes de investir numa matriz de rastreamento de
requisitos. Rastreamento é a capacidade de relacionar vários aspectos
de um artefacto de um projecto e uma matriz de rastreamento é o
artefacto criado para guardar essas relações. Relaciona modelos de
análise, arquitectura, desenho, código fonte e testes unitários. Por
vezes será melhor efectuar uma correcta gestão de conhecimento na
empresa, departamento ou equipa de modo a poder ser mais simples
perceber qual a dimensão e a complexidade de uma alteração no sistema
e/ou produto (Ambler 2002). Esta solução pode ser adoptada dado que a
manutenção de uma matriz de relacionamento de Requisitos é muito
custosa de manter. No entanto depende da cultura da própria empresa.
(Ambler 2005)
Adoptar terminologias dos stakeholders
Não adoptar jargões técnicos ou artificiais quando se colabora com
stakeholders no projecto. É para eles que o sistema está a ser
construído, portanto é a terminologia deles que deve ser usado na
modelação do sistema. Sendo que esse tipo de terminologia é de ser
evitada! Um importante artefacto em todos os projectos é a criação de
um glossário conciso de termos (Robertson 2006).
Tenta manter o processo divertido
Modelação e especificação de requisitos não tem de ser uma tarefa
árdua, de facto, sempre que possível devemos tirar o máximo de prazer
dessa mesma tarefa. Os colaboradores irão empenhar-se num ambiente
agradável, sentir-se-ão mais confortáveis e tornar-se-ão mais
produtivos! (Ambler 2002)
Obter suporte da gestão
Investindo esforço em modelação de requisitos com recurso a
metodologias ágeis, é um conceito relativamente novo para muitas
organizações. Um ponto importante é que os stakeholders do projecto têm
de estar envolvidos na dinâmica do processo ágil, para se poder criar
uma cultura fundamental para a adesão ao processo ágil. Sem o apoio dos
gestores séniores dificilmente haverá sucesso na implanatação de
metodologias, além de que todo o apoio dos gestores do departamento do
sistema de informação é fundamental. (Ambler 2005)
Tornar os stakeholders em colaboradores
Uma implicação desta abordagem é que os stakeholders do projecto
estão a aprender competências de desenvolvimento quando estão
envolvidos no projecto de software. Tornar os stakeholders em
colaboradores traz uma mais valia para uma análise e modelação de
requisitos mais correcta e da forma mais desejada para o cliente e/ou
utilizador final. (Robertson 2006)
Processar os requisitos com prioridade
Reflectindo o "Planning Game" do XP (Extreme Programming) e a
metodologia Scrum, uma equipa de desenvolvimento terá uma lista de
requisitos estimados e priorizados que necessitam de ser implementados,
sendo que por vezes os colaboradores poderão ter uma pilha de
"user-stories cards" já priorizadas (Ambler 2002). A equipa retira um
requisito do topo da pilha que eles acreditam que poderão implementar
nessa iteração, sendo que scrum aconselha que se congele a análise de
requisitos durante a iteração, para dar estabilidade à equipa de
desenvolvimento (Abrahamsson 2002). Se a alteração de um requisito
acontecer então essa alteração será tratada como um novo requisito
(Abrahamsson 2002) (Ambler 2002).
Referências