ENTRETIENS SEMI-DIRECTIFS AVEC LES PARENTS

Tendo em consideração os resultados apresentados na secção 4.3 e analisados na secção 4.4, verifica-se que os principais pontos de melhoria devem incidir sobre o desenvolvimento e gestão dos requisitos. Apesar de terem sido encontrados outros problemas no fluxo de trabalho diário das equipas de TI, não será possível, no âmbito deste trabalho, proceder otimização de todos os pontos que necessitam de melhorias.

Foi escolhida uma área para proceder à otimização. Tendo em conta o elevado número de vezes que questões ligadas aos requisitos foram referidas nas retrospetivas e também na influência que os mesmos têm no sucesso de um projeto, foi escolhido como base para este trabalho as áreas ligadas à gestão e desenvolvimento de requisitos.

27

5 Requisitos no CMMI

Este capítulo tem como objetivo apresentar e mapear com métodos ágeis os recursos fornecidos pelo CMMI de forma a resolver os problemas encontrados no capítulo 4 na gestão e desenvolvimento de requisitos. Para tal na secção 5.1 é descrito o papel da engenharia de requisitos no desenvolvimento de software e são também descritas as duas áreas de processo do CMMI que irão ser estudadas neste trabalho, a área de processo Desenvolvimento de Requisitos e a área de processo Gestão de Requisitos. Na secção 5.2 é feito o mapeamento das áreas de processo com métodos ágeis de desenvolvimento de software. Para cada prática específica são apresentadas as vantagens da sua aplicação e também como pode ser satisfeita e demonstrada recorrendo a metodologias ágeis. Por fim na secção 5.3 é feita a análise e conclusões do mapeamento apresentado na secção anterior.

5.1 Introdução

Conforme determinado no capítulo 4 foi escolhido como base para este trabalho as áreas ligadas à gestão e desenvolvimento de requisitos. Tendo em conta a documentação fornecida pelo CMMI, após a sua consulta em (Dalton et al., 2016) foi encontrada uma listagem de vários problemas comuns às organizações que usam abordagens ágeis no desenvolvimento de software. Após uma análise à referida listagem foi encontrado um item nessa listagem que se identifica com alguns dos problemas relatados pelas equipas nas retrospetivas, é ele “Os requisitos são vagos ou ficam em aberto”. O CMMI prevê a resolução deste problema através da adoção das práticas sugeridas nas áreas de processo Desenvolvimento de Requisitos e Gestão de Requisitos, em conjunto com as seguintes técnicas e cerimónias do Scrum:

 Epic/User Story.  Definition of Done.  Backlog Grooming.

Posto isto todo o trabalho realizado teve com base as áreas de processo, técnicas e cerimónias enumeradas anteriormente. Apesar disso foi possível chegar à conclusão que para fazer uma boa definição do processo de requisitos também seria necessário definir algumas etapas do PDS. Desta forma foi documentada a primeira versão do PDS da Crossing Answers Anexo B, anexo este criado no contexto deste trabalho. A sua criação teve uma grande importância para a organização, isto porque permitiu criar uma base a implementação de melhoria contínua com base nas retrospetivas e também para futuras otimizações de maior impacto nos procedimentos principais. Ainda que necessite de muito trabalho e algumas melhorias já permite a todas as equipas seguirem a mesma linha orientadora no desenvolvimento dos projetos.

Processo de Desenvolvimento de Software: Um caso de estudo de análise, implementação e validação

28

5.1.1 Desenvolvimento de Requisitos

A área de processo Desenvolvimento de Requisitos tem como principal objetivo elicitar, analisar e estabelecer requisitos de clientes, de produtos e componentes de produtos. Em conjunto, os três tipos atendem às necessidades dos stakeholders e dos atributos do produto, abordando ainda as decisões tomadas em questões de design e arquitetura (CMMI Product Team, 2010). O desenvolvimento de requisitos inclui as seguintes atividades:

 Elicitação, análise, validação e comunicação das necessidades, expectativas e restrições do cliente para obter requisitos prioritários dos clientes que irão satisfazer os stakeholders.

 Recolha e coordenação das necessidades dos stakeholders.  Desenvolvimento do ciclo de vida dos requisitos.

 Estabelecimento dos requisitos funcionais e de qualidade.

 Estabelecimento de requisitos de produtos consistentes com os requisitos do cliente.

Os requisitos são identificados e refinados ao longo das fases do ciclo de vida do produto. Decisões de design, ações corretivas e feedback durante cada ciclo são analisados quanto ao impacto nos requisitos. Para tal existem três objetivos específicos na área de processo de Desenvolvimento de Requisitos:

1. Desenvolver os requisitos do cliente: aborda um conjunto de requisitos do cliente para usar no desenvolvimento de requisitos do produto.

2. Desenvolver os requisitos do produto: aborda a definição de um conjunto de requisitos de produto a serem usados no design e arquitetura do produto.

3. Analisar e validar os requisitos: aborda a análise de requisitos do cliente e do produto para definir e entender os requisitos.

As análises são usadas para entender, definir e selecionar os requisitos e destinam-se a auxiliar as restantes práticas da área de processo.

5.1.2 Gestão de Requisitos

A área de processo de Gestão de Requisitos tem como principal objetivo gerir os requisitos dos projetos e garantir o alinhamento entre esses requisitos e os planos do projeto, para tal são geridos todos os requisitos recolhidos ou gerados durante o desenvolvimento do projeto. São tomadas medidas apropriadas para assegurar que os requisitos aprovados sejam geridos de forma a suportar as necessidades de planeamento e de execução do projeto (CMMI Product Team, 2010).

Quando um projeto recebe requisitos, esses requisitos são revistos de forma a resolver o máximo de problemas e evitar mal-entendidos antes que os requisitos sejam incluídos no plano do projeto. Após a revisão, deve ser criado um compromisso por parte dos intervenientes no projeto em relação ao que ficou definido.

Relativamente às mudanças, devem ser geridas à medida que os requisitos evoluem e que são identificadas inconsistências. Parte do trabalho da gestão de requisitos é documentar as mudanças de requisitos e as suas razões, mantendo rastreabilidade bidirecional com os requisitos originais.