Questão Discursiva - FCC - Tecnologia da Informação

Analista Judiciário - TRT3 - 2015 - FCC

Metodologia de Desenvolvimento de Software

Um tribunal está iniciando dois projetos de desenvolvimento de Software, um projeto A e um projeto B.

No projeto A está sendo utilizada uma metodologia de desenvolvimento considerada rigorosa e orientada a planejamento na qual os requisitos do sistema são estáveis, os requisitos futuros são previsíveis e documentos são criados para guiar o processo de desenvolvimento. Adota um processo iterativo visando a construção do ssistema de forma orientada a objeto, em que o projeto é dividido, em que o projeto é dividido em miniprojetos curtos, de duração fixa, denominadas iterações. Cada iteração é um sistema executável, testável e integrável e inclui atividades de requisitos, projeto, implementação e teste. Trabalha em ciclos divididos em quatro fases consecutivas: concepção, elaboração, construção e transição.

No projeto B está sendo utilizada uma metodologia baseada em código, focada na adaptação ao invés de planejamento, que não utiliza muita documentação e adota processos mais simplificados, facilitando a adaptação às mudanças de requisitos e permitindo entregas rápidas e menores. Ocorre em um ambiente complexo, onde os requisitos e as prioridades mudam constantemente. O software é desenvolvido em ciclos que, em geral, duram de duas a quatro semanas. Na equipe, que é auto organizada e tem entre 6 e 10 pessoas, existem diversos perfis, dentre eles, o de um facilitador que conhece bem o modelo e soluciona conflitos e o de um responsável pelo projeto em si, inclusive pelo ROI (Return Of Investmente), que indica quais são os requisitos mais importantes, já que conhece e avalia a necessidade do cliente.

Dado o cenário de desenvolvimento dos dois projetos, pede-se para:

a) Identificar e indicar o modelo, prática ou metodologia utilizada nos projetos A e B;

b) Descrever, fundamentadamente, como se lida com os requisitos, quais são os recursos indicados para captura e entedimento dos requisitos em ambos os projetos e como esses recursos são utilizados;

c) Descrever, fundamentadamente, como é tratada a rastreabilidade de requisitos nos projetos A e B;

Sugestão de resposta:

a) No projeto A, a metodologia de desenvolvimento de software utilizada é o Rational Unified Process - RUP, ou Processo Unificado da Rational, uma vez que este modelo é bastante verboso, utiliza um processo iterativo e incremental e é dividido nas fases de concepção, elaboração, construção e transição, assim como o tal projeto.

No projeto B, é utilizada uma metodologia ágil como o Scrum, podendo ser complementada também com o XP. Uma vez que ambas se completam e são baseadas em código, priorizam a entrega de software ao invés de ampla documentação, funciona melhor com equipes de até 10 pessoas e é auto organizada, as mudanças dos requisitos são bem-vindas e o software é desenvolvido em ciclos curtos, de até 4 semanas, assim como o projeto B.

b) No projeto A, em que se utiliza o RUP, existem papeis específicos responsáveis pela a coleta, análise, revisão e validação dos requisitos, como o Especificador de Requisitos e o Revisor de Requisitos. Estes requisitos são coletados e através destes são modelados diversos Casos de Uso para melhor avaliação, descoberta e validação dos requisitos pelos usuários do sistema. São em sua maior parte coletados durante as fases de concepção e elaboração, restando poucos que são descobertos e ajustados nas fases de construção e transição.

No projeto B, que utiliza o Scrum, toda a equipe Scrum é responsável pela correta elicitação dos requisitos. Os requisitos são coletados inicialmente de forma geral e sem aprofudamento, apenas para conhecimento básico do escopo e estudo de viabilidade, gerando o Product Backlog - PB. Posteriormente, no início cada sprint, é realizada a Reunião de Planejamento da Sprint em que o time de desenvolvimento se reune com o Product Owner - PO, este vai selecionar as histórias prioritárias do PB, que deverão ser entregues ao final da Sprint, e o time de desenvolvimento irá transformas as histórias selecionadas em atividades detalhadas, refinando o entendimento dos requisitos e gerando o Sprint Backlog - SB. A equipe poderá utilizar técnicas de medição de tamanho das histórias como o Planning Poker para garantir que é possível a entrega daqueles itens selecionados durante o tempo da Sprint.

c) Uma importante processo para o controle de requisitos e mudanças é o de “Gerenciamento de Requisitos”. Neste processo um dos artefatos mais importantes gerados é o documento de Rastreabilidade de Requisitos.
No projeto A, o gerenciamento e mudança de requisitos é bastante formal, havendo um processo específico para mudanças de requisitos. Assim, a rastrabilidade de requisitos é de fundamental importância, pois através desta informação é possível rastrear todos os artefatos ligados a determinado requisito. É comum que em um documento deste tipo se identifique a origem do requisito, quais outros requisitos aquele impacta, quais os trechos de código associados ao requisitos e outras informações. Assim, é possível prever qual o impacto um projeto sofrerá devido a alteração de um determinado item.

No projeto B, pelos requisitos serem mais maleáveis, não existe um processo tão formal e verboso para o rastreamento e controle desses requisitos. Ainda assim é um importante documento, mas a sua importância se dá por motivo diverso do projeto A. A rastreabilidade é importante para identificar os artefatos que validam se o requisito está correto e condizente com a necessidade do usuário, como Casos de Teste, produtos entregues por um requisito. Assim, contiunua sendo um artefato importante, mas enquanto no projeto A a mior utilidade é identificar quais itens são impactados por possível alteração, no projeto B esá mais voltado a confirmar que o que o usuário solicita é aquilo que ele recebe.

O que acharam das respostas ? Concordam, discordam ? Deixem seus comentários baixo.