LETÍCIA MAYUMI DOY OKAMOTO

ALINHAMENTO DO PROCESSO DE DESENVOLVIMENTODE SOFTWARE DO LABORATÓRIO GAIA À

METODOLOGIA ÁGIL SAFE E AO MODELO DEQUALIDADE MR-MPS-SW

LONDRINA–PR

2017

LETÍCIA MAYUMI DOY OKAMOTO

ALINHAMENTO DO PROCESSO DE DESENVOLVIMENTODE SOFTWARE DO LABORATÓRIO GAIA À

METODOLOGIA ÁGIL SAFE E AO MODELO DEQUALIDADE MR-MPS-SW

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

Orientador: Prof. Dr. Rodolfo Miranda deBarros

LONDRINA–PR

2017

Letícia Mayumi Doy OkamotoAlinhamento do Processo de Desenvolvimento de Software do Laboratório

GAIA à metodologia ágil SAFe e ao modelo de qualidade MR-MPS-SW/ LetíciaMayumi Doy Okamoto. – Londrina–PR, 2017-

69 p. : il. (algumas color.) ; 30 cm.

Orientador: Prof. Dr. Rodolfo Miranda de Barros

– Universidade Estadual de Londrina, 2017.

1. Palavra-chave1. 2. Palavra-chave2. I. Orientador. II. Universidade xxx. III.Faculdade de xxx. IV. Título

CDU 02:141:005.7

LETÍCIA MAYUMI DOY OKAMOTO

ALINHAMENTO DO PROCESSO DE DESENVOLVIMENTODE SOFTWARE DO LABORATÓRIO GAIA À

METODOLOGIA ÁGIL SAFE E AO MODELO DEQUALIDADE MR-MPS-SW

Trabalho de Conclusão de Curso apresentadoao curso de Bacharelado em Ciência da Com-putação da Universidade Estadual de Lon-drina para obtenção do título de Bacharel emCiência da Computação.

BANCA EXAMINADORA

Prof. Dr. Rodolfo Miranda de BarrosUniversidade Estadual de Londrina

Orientador

Prof. Dr. Segundo Membro da BancaUniversidade/Instituição do Segundo

Membro da Banca

Prof. Dr. Terceiro Membro da BancaUniversidade/Instituição do Terceiro

Membro da Banca

Prof. Ms. Quarto Membro da BancaUniversidade/Instituição do Quarto

Membro da Banca

Londrina–PR, 24 de novembro de 2017

Este trabalho é dedicado às crianças adultas que,quando pequenas, sonharam em se tornar cientistas.

AGRADECIMENTOS

Os agradecimentos principais são direcionados à Gerald Weber, Miguel Frasson,Leslie H. Watter, Bruno Parente Lima, Flávio de Vasconcellos Corrêa, Otavio Real Sal-vador, Renato Machnievscz1 e todos aqueles que contribuíram para que a produção detrabalhos acadêmicos conforme as normas ABNT com LATEX fosse possível.

Agradecimentos especiais são direcionados ao Centro de Pesquisa em Arquiteturada Informação2 da Universidade de Brasília (CPAI), ao grupo de usuários latex-br3 e aosnovos voluntários do grupo abnTEX2 4 que contribuíram e que ainda contribuirão para aevolução do abnTEX2.

1 Os nomes dos integrantes do primeiro projeto abnTEX foram extraídos de <http://codigolivre.org.br/projects/abntex/>

2 <http://www.cpai.unb.br/>3 <http://groups.google.com/group/latex-br>4 <http://groups.google.com/group/abntex2> e <http://abntex2.googlecode.com/>

“Não vos amoldeis às estruturas deste mundo,mas transformai-vos pela renovação da mente,a fim de distinguir qual é a vontade de Deus:

o que é bom, o que Lhe é agradável, o que é perfeito.(Bíblia Sagrada, Romanos 12, 2)

OKAMOTO, L. M. D.. Alinhamento do Processo de Desenvolvimento de Soft-ware do Laboratório GAIA à metodologia ágil SAFe e ao modelo de qualidadeMR-MPS-SW. 69 p. Trabalho de Conclusão de Curso (Bacharelado em Ciência daComputação) – Universidade Estadual de Londrina, Londrina–PR, 2017.

RESUMO

Segundo a ??, 3.1-3.2, o resumo deve ressaltar o objetivo, o método, os resultados e asconclusões do documento. A ordem e a extensão destes itens dependem do tipo de resumo(informativo ou indicativo) e do tratamento que cada item recebe no documento original.O resumo deve ser precedido da referência do documento, com exceção do resumo inseridono próprio documento. (. . . ) As palavras-chave devem figurar logo abaixo do resumo, an-tecedidas da expressão Palavras-chave:, separadas entre si por ponto e finalizadas tambémpor ponto.

Palavras-chave: Latex. Template ABNT-DC-UEL. Editoração de texto.

OKAMOTO, L. M. D.. GAIA’s Laboratory Aligment of the Software Develop-ment Process to SAFe agile methodology and quality reference model MR-MPS-SW. 69 p. Final Project (Bachelor of Science in Computer Science) – State Uni-versity of Londrina, Londrina–PR, 2017.

ABSTRACT

This is the english abstract. The Abstract in English should be faithful to the Resumo inPortuguese, but not a literal translation.

Keywords: Processo de Desenvolvimento de Software, SAFe

LISTA DE ILUSTRAÇÕES

Figura 1 – Configuração Portfolio SAFe. (Fonte: [1]) . . . . . . . . . . . . . . . . . 29Figura 2 – Exemplo de utilização do Kanban no nível de programa. (Fonte: [1]) . . 37Figura 3 – Processo de Desenvolvimento de Software GAIA. (Fonte: [2]) . . . . . . 44Figura 4 – Análise Inicial - ANI. (Fonte: [2]) . . . . . . . . . . . . . . . . . . . . . 45Figura 5 – Análise e Planejamento - APL. (Fonte: [2]) . . . . . . . . . . . . . . . . 47Figura 6 – Execução e Implementação - EXI. (Fonte: [2]) . . . . . . . . . . . . . . 49Figura 7 – Validação e Testes - VAT. (Fonte: [2]) . . . . . . . . . . . . . . . . . . . 50Figura 8 – Entrega - ENT. (Fonte: [2]) . . . . . . . . . . . . . . . . . . . . . . . . 51Figura 9 – Finalização - FIN. (Fonte: [2]) . . . . . . . . . . . . . . . . . . . . . . . 52Figura 10 – Manter requisitos - MRQ. (Fonte: [2]) . . . . . . . . . . . . . . . . . . . 53Figura 11 – Gerenciar Portifólio -GPT. (Fonte: [2]) . . . . . . . . . . . . . . . . . . 54

LISTA DE TABELAS

Tabela 1 – Princípios da metodologia ágil . . . . . . . . . . . . . . . . . . . . . . . 26Tabela 2 – Alinhamento do PDS ao SAFe – Team Level . . . . . . . . . . . . . . . 56Tabela 3 – Alinhamento do PDS ao SAFe – Program Level . . . . . . . . . . . . . 57Tabela 4 – Alinhamento do PDS ao SAFe – Portfolio Level . . . . . . . . . . . . . 57

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associação Brasileira de Normas Técnicas

BNDES Banco Nacional de Desenvolvimento Econômico e Social

IBGE Instituto Nacional de Geografia e Estatística

IBICT Instituto Brasileiro de Informação em Ciência e Tecnologia

NBR Norma Brasileira

WBS

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 252.1 Processo de Desenvolvimento de software . . . . . . . . . . . . 252.1.1 Desenvolvimento Ágil de Software . . . . . . . . . . . . . . . . . 262.1.2 Qualidade de Software . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Melhoria de processo do Software . . . . . . . . . . . . . . . . . 28

3 SCALED AGILE FRAMEWORK - SAFE . . . . . . . . . . . . 293.1 Team Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2 Program Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 Portfolio Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 MODELO DE REFERÊNCIA MPS-BR DE SOFTWARE . . 41

5 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE GAIA 435.1 Análise Inicial - ANI . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Análise e Planejamento - APL . . . . . . . . . . . . . . . . . . . . 465.3 Execução e Implementação - EXI . . . . . . . . . . . . . . . . . . 495.4 Validação e Testes - VAT . . . . . . . . . . . . . . . . . . . . . . . 505.5 Entrega - ENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.6 Finalização - FIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.7 Manter Requisitos - MRQ . . . . . . . . . . . . . . . . . . . . . . 535.8 Gerenciar Portifólio - GPT . . . . . . . . . . . . . . . . . . . . . . 53

6 ALINHAMENTO DO PDS GAIA . . . . . . . . . . . . . . . . 556.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

APÊNDICES 63

APÊNDICE A – QUISQUE LIBERO JUSTO . . . . . . . . . 65

ANEXOS 67

ANEXO A – MORBI ULTRICES RUTRUM LOREM. . . . 69

23

1 INTRODUÇÃO

Com o crescimento do uso e da criação de softwares, as empresas precisam oferecerrapidez de entrega, produtividade e produtos com qualidade para estarem em uma boaposição no mercado competitivo. Para isso, é indicado a utilização de um processo dedesenvolvimento adequado e padronizado.

Buscando oferecer rapidez e dinamicidade ao processo de desenvolvimento desoftwares, foram desenvolvidos métodos denominados ágeis, que valorizam a interaçãoconstante com cliente e a entrega contínua e incremental de funcionalidades desenvolvi-das em ciclos interativos[3]. A metodologia nasceu voltada para o setor de desenvolvimentode software, mas podem ser aplicada em outros setores, como mostra o SAFe. O ScaledAgile Framework, SAFe, é uma metodologia ágil que pode ser estendida para abrangerequipes de desenvolvimento que envolvem muitas pessoas ou para outros setores, podendoser escalonada até abranger toda a empresa[1].

Quanto à qualidade, ela pode ser quantificada através da utilização de modelos dereferência, como o MPS.BR. A partir dessa análise, o modelo de referência pode oferecerguias de como melhorias podem ser implementadas no processo, garantindo uma maiorqualidade no produto final[4].

O MPS.BR é um programa que busca promover melhorias no processo de softwarebrasileiro. É composto por cinco componentes, um deles é o MR-MPS-SW, Modelo deReferência MPS de Software, que baseado em normas nacionais, NBR ISO/IEC 12207,internacionais, ISO/IEC 33020, e no modelo CMMI-DEV R○, procura quantificar a quali-dade que se espera de um software e prover ferramentas para que atinja bons patamares[5].

Identificando a importância de ter um processo de desenvolvimento que proporci-one produtividade e qualidade ao produto final, a GAIA possui seu próprio processo dedesenvolvimento de software[2]. Para que melhorias ocorram, é necessário analisar alinha-mento do processo a uma metodologia ágil e a um modelo de qualidade.

Portanto, a finalidade deste trabalho é analisar o quão alinhado está o Processode desenvolvimento de software da GAIA ao SAFe e ao MR-MPS-SW, investigando quaisprocessos e atividades estão sendo feitos pelo PDS e, caso estiverem, mostrando onde seencontram.

Este trabalho é organizado de forma que o capítulo 2 apresenta a fundamentaçãoteórica na qual o trabalho se baseia, o capítulo 3 traz detalhes sobre o framework SAFe edescreve as principais atividades que o compõe, o capítulo 4 apresenta o funcionamentodo MR-MPS-BR e os resultados esperados para os níveis de maturidade, o capítulo 5detalha as etapas do Processo de Desenvolvimento de Software da GAIA, o capítulo 6 traz

24

o alinhamento do PDS GAIA aos modelos propostos e discussão dos resultados obtidos,e o capítulo 7 apresenta as considerações finais para o trabalho.

25

2 FUNDAMENTAÇÃO TEÓRICA

2.1 Processo de Desenvolvimento de software

Um processo é um conjunto de atividades, ações e tarefas realizadas na criação dealgum produto de trabalho. No contexto da engenharia de software, um processo é umaabordagem adaptável cuja intenção é sempre entregar um software dentro do prazo e comqualidade suficiente para satisfazer os clientes, aqueles que patrocinaram sua criação, e osfuturos usuários [4]. Ainda de acordo com Pressman [4], que utiliza o termo metodologia(framework) de processo, um PDS genérico compreende cinco atividades:

1. Comunicação: é de vital importância para o projeto que haja uma boa comunicaçãoentre seus realizadores, os clientes e demais interessados. Com isso, busca-se a totalcompreensão dos objetivos a serem alcançados pelo projeto;

2. Planejamento: envolve o desenvolvimento de um plano para guiar o processo dedesenvolvimento, descreve tarefas a serem feitas, riscos, recursos necessários, crono-grama de trabalho;

3. Modelagem: criam-se modelos que possibilitem a visualização de todo o software,buscando o projeto que melhor atende às suas necessidades;

4. Construção: implementação e testes são feitos;

5. Emprego: é entregue para avaliação do cliente o software completo (ou um incre-mento parcialmente efetivado), esperando um feedback.

Essas atividades são complementadas por atividades de apoio, que auxiliam aequipe a gerenciar, controlar o progresso, a qualidade, as mudanças e o risco. Os processospodem ser adaptados independentemente do tamanho ou complexidade do software, aadaptação também pode ser para uma necessidade específica de um projeto. A maioriadas empresas prefere desenvolver os próprios processos, mas há inúmeros PDSs disponíveispara uso, e geralmente são categorizados em:

∙ Dirigido a plano ou Prescritivo: abordagem que foca no detalhamento da definição,identificação e aplicação de atividades e tarefas do processo[4], no planejamentocom antecedência e na avaliação rigorosa através da comparação do progresso como planejamento inicial [3];

∙ Ágeis: ressaltam a agilidade do projeto, através de princípios que pregam mais in-formalidade, flexibilidade e planejamento gradativo.

26

2.1.1 Desenvolvimento Ágil de Software

O ambiente de desenvolvimento de software nos dias de hoje sofre com mudançasrápidas, precisando responder a novas oportunidades, a mudanças econômicas e ao surgi-mento de novos concorrentes. Assim, o desenvolvimento e entrega rápidos são requisitoscríticos no desenvolvimento de sistemas de software [3]. PDSs prescritivos, que especificamcompletamente os requisitos antes de planejar, construir e testar não estão adaptados paraatender o desenvolvimento rápido. Para atender essa nova realidade, em 2011, Kent Beck eoutros dezesseis desenvolvedores e consultores da área de software assinaram o “Manifestopara o Desenvolvimento Ágil de Software” ("Manifesto for Agile Software Development"):

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste tra-balho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentasSoftware em funcionamento mais que documentação abrangenteColaboração com o cliente mais que negociação de contratosResponder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais ositens à esquerda. [6]

Os processos de desenvolvimento ágil desenvolvem o software em uma série depequenos incrementos, sendo que cada um inclui uma nova funcionalidade ao sistema.Essas versões são disponibilizadas aos clientes a cada duas ou três semanas, assim, umrápido feedback sobre a evolução dos requisitos é obtido. Os diversos PDSs existentes queutilizam a noção de desenvolvimento e entrega incremental têm em comum os princípios,baseados no Manifesto Ágil apresentados na Tabela 1.

Tabela 1 – Princípios da metodologia ágil

Fonte: Sommerville, 2011, p.40[3]

27

2.1.2 Qualidade de Software

O termo qualidade de software pode ser definido, de forma geral, como:

Uma gestão de qualidade efetiva aplicada de modo a criar um produtoútil que forneça valor mensurável para aqueles que o produzem e paraaqueles que o utilizam.[4]

Essa definição foca nas expectativas de três visões:

∙ Visão do usuário: interessado na utilização e desempenho do software, o cliente es-pera que as funções e recursos desejados estejam presentes e ofereçam confiabilidadee isenção de falhas;

∙ Visão do desenvolvedor: busca atender as especificações postas pelo cliente e preocupa-se com medidas internas como um baixo tempo de resposta e a fácil manutenção;

∙ Visão do gerente de desenvolvimento: avalia custos, prazos, conformidade e outroscritérios baseados nos interesses da empresa.

É possível avaliar a qualidade a partir de frameworks como o ISO 9126, padrãointernacional desenvolvido para identificar os atributos fundamentais de qualidade deum software para computador. Esse framework é formado por características e sub-características, apresentadas a seguir[7]:

∙ Funcionalidade: conjunto de funções que satisfazem necessidades implícitas e explí-citas conforme indicado na adequação, acurácia, interoperabilidade, conformidade esegurança;

∙ Confiabilidade: capacidade do software em permanecer disponível para uso ao longode um período de tempo. Seus sub-atributos são maturidade, tolerância a falhas erecuperabilidade;

∙ Usabilidade: grau de facilidade de uso do software pronto, envolvendo compreensi-bilidade, facilidade de aprendizado e operabilidade;

∙ Eficiência: relação entre desempenho e recursos utilizados pelo software. Indicadopelo comportamento em relação ao tempo e ao uso de recursos;

∙ Manutenibilidade: Facilidade com a qual correções e alterações podem ser feitas,conforme indicado pela analisabilidade, modificabilidade, estabilidade e testabili-dade;

∙ Portabilidade: Facilidade com a qual um software portado para outro ambiente.Envolve adaptabilidade, facilidade de instalação, conformidade e facilidade de subs-tituição.

28

Ao final de um projeto, espera-se um software com qualidade que contenha essascaracterísticas e satisfaça essas visões. Para isso, o processo de desenvolvimento deve sofrermelhorias para que consiga refletir sua qualidade no produto final.

2.2 Melhoria de processo do Software

29

3 SCALED AGILE FRAMEWORK - SAFE

Com a evolução do cenário de desenvolvimento de software e a demanda por apli-cações de porte maior e mais sofisticadas, houve o incentivo para formação de váriasequipes com dezenas, centenas de desenvolvedores, tornando difícil gerenciar suas fun-ções, tarefas, prazos de entrega, alinhamento e sincronia. Além disso, empresas de grandeporte encontraram dificuldades para implantação da metodologia ágil, devido à resistênciacultural, falta de experiência dos gerentes de projetos com a metodologia e a dificuldadede interação dos diversos departamentos da empresa.

Nesse sentido, Dean Leffingwell criou o SAFe [1], acrônimo para Scaled Agile Fra-mework, uma metodologia ágil que pode ser estendida para abranger equipes maiores eoutros departamentos da empresa, podendo ser escalonada até abranger toda a organiza-ção. A metodologia tem como base o Lean Thinking e outras duas metodologias ágeis, oScrum e o XP (Extreme Programming), e possui uma abordagem bem documentada parasua aplicação.

Figura 1 – Configuração Portfolio SAFe. (Fonte: [1])

O Lean Thinking é uma filosofia e estratégia de negócios que busca aumentar asatisfação dos clientes através do melhor uso dos recursos, acredita-se que entendendo oque é o valor para o cliente, será possível eliminar desperdícios, provocando um melhora-mento contínuo nos processos de produção e alavancando a competitividade da empresa.Assim, o SAFe combina os conhecimentos das metodologias Ágeis no desenvolvimento de

30

sistemas com a estratégia de desenvolvimento de produtos do Lean, fornecendo melhoriasna produtividade, qualidade, produtividade e o engajamento dos funcionários.

Está atualmente na versão 4.5 e apresenta quatro configurações: Essential SAFe,Large Solution SAFe, Portfolio SAFE e Full SAFe. Neste trabalho será utilizado a confi-guração Portfolio SAFe como mostrado na Figura 1, indicado para empresas que desen-volvem múltiplas soluções, o que requer um gerenciamento de portfólio para coordenação,estratégia e investimento dos projetos.

A configuração utilizada possui 3 níveis: Portfolio, Program e Team. Cada níveldo SAFe fornece abstrações organizacionais com papéis e práticas voltadas a orientar aagilidade em grandes empresas de desenvolvimento de software.

Para melhor compreensão do alinhamento a ser realizado entre o SAFe e o PDSGAIA, as atividades do framework serão rotuladas e descritas nas próximas seções.

3.1 Team Level

Este nível fornece um modelo organizacional dos artefatos, papeis, e processosnecessários para que as equipes ágeis realizem suas atividades. Cada equipe escolhe suametodologia, ScrumXP ou Kanban, e seus membros, que variam entre 5 e 9, se dividemnos papeis:

∙ Time de desenvolvimento: composto por desenvolvedores, testadores e outros espe-cialistas que trabalham de forma colaborativa para entregar uma funcionalidade;

∙ Product Owner (PO): encarregado do backlog do time, organiza a lista de históriade usuário, as tarefas de manutenção e refatoração;

∙ Scrum Master : funciona como um treinador da equipe ajudando os membros passarpor impedimentos e promovendo um bom ambiente para o alto desempenho daequipe.

Assim, cada time é capaz de planejar, desenvolver, testar, ajustar uma funciona-lidade a cada iteração ou Sprint, realizando o ciclo PDCA(Plan -Do-Check-Adjust) e aentrega da funcionalidade ao final desta. Cada iteração possui os seguintes eventos, algunsdestes requerem mais de uma atividade:

∙ Iteration Planning: reunião em que a equipe decide quais os objetivos e quais his-tórias, tarefas, serão entregues nessa Sprint:

– Estabeler Velocidade – SAFe-TML01: A equipe quantifica a sua capacidade derealizar o trabalho nesta iteração. Cada membro avalia sua disponibilidade e

31

tempo de aprendizado. Também é levado em conta o tempo de manutenção eoutra atividades independentes;

– Análise e Estimativa de Histórias – SAFe-TML02: Cada caso de uso do backlogdo time é discutido e avaliado suas dificuldades, tamanho, complexidade ecritérios de aceitação, chegando a uma estimativa do tamanho da história.Geralmente, o backlog também possui atividades de arquiteura e infraestrutura,que também são avaliadas;

– Elaborar Tarefas - SAFe–TML03: esta é uma atividade opcional, em que asequipes fragmentam os casos de uso em tarefas e as dividem entre si. Esta ati-vidade é comum de ser feita em equipes novas, que ainda estão compreendendosua capacidade e velocidade;

– Estabelecer os Objetivos da Iteração – SAFe-TML04: após a compreensão dobacklog, a equipe sinteiza um ou mais objetivos para a iteração, baseando-senos objetivos passados pelo Program Level;

– Obter Comprometimento – SAFe-TML05: Os membro da equipe e o productowner concordam com as histórias a serem trabalhadas e os objetivos da ite-ração. Toda a equipe se compromete com os objetivos da iteração, e o escopopermanece o mesmo durante toda a iteração;

∙ Iteration Execution: é quando a equipe desenvolve um incremento efetivo, de altaqualidade, funcionando e testado dentro do prazo de entrega. O foco do evento éentregar as histórias com as quais a equipe se comprometeu na reunião de planeja-mento e atender os objetivos da iteração:

– Acompanhar o Progresso da Iteração – SAFe-TML06: o acompanhamento re-quer visibilidade do atual estado dos casos de uso, testes, correções e outrasatividades nas quais a equipe está trabalhando durante a iteração. As equi-pes que seguem o Kanban utilizam os seus quadros(Kanban boards), e as queseguem o Scrum, um story board;

– The Daily Stand-up(DSU) – SAFe-TML07: reuniões diárias com 15 minutosde duração em que a equipe coordena o trabalha respondendo as perguntas:O que fiz ontem para avançar em direção aos objetivos da iteração?, O queconseguirei fazer hoje para avançar em direção aos objetivos da iteração? e Oque está nos impedindo de avançar em direção aos objetivos da iteração?. Temcomo objetivo identificar problemas e dependências, e manter uma comunicaçãoconstante;

– Gereciar o Working-In-Progress(WIP) – SAFe-TML08: Limitar o WIP é umaestratégia para evitar gargalos no desenvolvimento, ajudando a melhorar ofluxo de trabalho, o foco, o compartilhamento de informações e a ideia de

32

propriedade coletiva. Esse controle força que a taxa de entrada, de histórias eobjetivos, seja compatível com a capacidade do time;

– Construir com Qualidade – SAFe-TML09: o SAFe prescreve um conjunto decinco práticas de qualidade e engenharia que contribuem para agregar quali-dade às funcionalidades: Test-First - derivada do XP(eXtreme Programming)está prática planeja os testes antes da implementação, assim as entregas sãofeitas focadas nos resultados-, Integração contínua, Refatoração, Trabalho empares e propriedade coletiva. Incorporar qualidade desde o início do trabalhofazem as entregas serem mais rápidas, fáceis e menos onerosas;

– Aprovação Contínua de Histórias – SAFe-TML10: aceitar que histórias foramcompletamente atendidas melhora continuamente o fluxo de trabalho. As equi-pes demonstram suas funcionalidades prontas antes de terminar a iteração,assim podem abordar problemas de forma rápida e eficiente, retrabalhandoseus casos de uso sem trocar de contexto;

– Automação de Testes – SAFe-TML11: sempre que possível, os critérios para ocomportamento adequado do sistema, definidos pelo Product Owner e as equi-pes, são transformados em testes para avaliação de casos de uso que podem serexecutados repetidamente para garantir a adequação ao uso e a conformidadecontínua do sistema à medida que ele evolui;

∙ Backlog Refinement – SAFe-TML12: ocorre uma ou duas vezes durante a iteraçãocom o objetivo de refinar, analisar e estimar histórias de usuários e seus requisitos,no backlog do time;

∙ Iteration Review – SAFe-TML13: reunião realizada ao final da iteração, a equipemostra o trabalho feito ao Product Owner e demais interessados, que analisam se oresultado era o desejado e oferecem um feedback. Com o retorno, a equipe discute osporquês de não conseguirem completar suas tarefas, geralmente, chegam à conclusãode que houve a descoberta de novos riscos, as prioridades foram modificadas, asestivamitavas estavam imprecisas ou hove excesso de compromissos. Esses problemasencontrados servirão para melhorar o planejamento das próximas iterações;

∙ Iteration Retrospective – SAFe-TML14: ao final de uma iteração, os membros daequipe analisam se os objetivos propostos para a iteração foram atingidos e o quepode ser melhorado para a próxima. A avaliação é baseada nas informações quali-tativas e quantitativas apresentadas durante a Iteration Review;

∙ Innovation and Planning (IP) Iteration – SAFe-TML15: é uma iteração que ofereceàs equipes a chance de explorar e inovar, obter novos conhecimentos e técnicas,trabalhar focado na parte técnica do sistema ou, como nenhuma funcionalidadeestá prevista para ser implementada nessa iteração, trabalhar as tarefas atrasadas

33

devido a dependências e imprevistos. Caso esteja próximo de realizar a entrega deuma versão, as equipes podem utilizar esse Sprint para realizar testes, verificação,validação e documentação finais do sistema.

As várias equipes utilizam esses eventos para administrar e sincronizar o andamento decada iteração, cuja duração é a mesma para todas. Para garantir que as funcionalidadescriadas pelas equipes funcionam juntas, versão com todo o sistema integrado é entreguea cada duas semanas para avaliação.

3.2 Program Level

O nível de programa é onde as equipes de desenvolvimento, os stakeholders erecursos estão dedicados ao desenvolvimento de ões em andamento, sejam elas produtos,serviços, sistemas a serem entregues, internos ou externos à empresa. Para desenvolveressas soluções, as equipes, papeis e atividades desse nível são organizados em torno dametáfora do Agile Release Train (ART), que como um trem tem cronograma de partidae chegada, velocidade padrão, planejamento previsível. Assim, os ARTs são organizaçõesvirtuais auto gerenciáveis, formadas por equipes ágeis que planejam, executam e entregamjuntas em um fluxo contínuo. Cada ART é composto por 5 a 12 equipes ágeis, envolvendoentre 50 a 125 pessoas. Dependendo da complexidade da solução, um ou mais ARTs serãonecessários para o seu desenvolvimento.

Os papeis do Program Level são voltados a guiar e direcionar o andamento doART, ajudando a alinhar as equipes de desenvolvimento a um objetivo comum:

∙ Arquiteto/Engenheiro de Sistema(System Architect/Engineer): é um indivíduo ouuma pequena equipe que define a estrutura geral do sistema, determina os principaiselementos e subsistemas, e ajuda a definir os requisitos não funcionais, as interfacese colaborações entre elas;

∙ Product Management: é a voz do cliente, trabalha junto com os Product Ownersdas equipes para entender as necessidades do cliente e garantir seu atendimento,definindo recursos e participando da validação. São responsáveis pelo backlog doprograma;

∙ Release Train Engineer (RTE): atua como o Scrum Master para ART, otimizandoo fluxo e garantindo que o trem ande dentro dos trilhos;

∙ Business Owners: é um pequeno grupo de stakeholders que têm a responsabilidadede garantir a adequação, governança, e retorno do investimento de uma ão desen-volvida pelo ART.

34

O Backlog do programa possui as definições das aplicações, features, e enablersprevistos para desenvolver um ART que atenda as necessidades do cliente e forneça umaboa arquitetura ao sistema, respectivamente. Mantê-lo atualizado e organizado é esssen-cial para o bom planejamento e andamento do desenvolvimento do ART. A forma deorganizar o backlog é priorizar algumas tarefas utilizando método Weighted Shortest JobFirst(WSJF), que possui como operadores o valor retornado pelo desenvolvimento dessatarefa ao usuário e ao negócio(User-Business Value),a criticidade de sua entrega em rela-ção ao tempo(Time Critically), os riscos reduzidos pelo seu desenvolvimento ou se geraráuma nova oportunidade(Risk Reduction | Opportunity Enablement Value) e o seu tama-nho(Job Size), medido em relação à quantidade de histórias que a compõe. Assim, segue-sea fórmula 3.1[1].

(3.1)

Nessa etapa, pode-se utilizar o Kanban para visualizar e gerenciar o fluxo dotrabalho no ART, controlando o fluxo contínuo de entrega, integração e implantação deincrementos, além de identificar gargalos e oportunidades para melhorias. Um exemplotípico de Kanban pode ser visto na Figura 2.

Para controlar o andamento do ART, utiliza-se o conceito de Program Incrment(PI), período de duração fixa em que será desenvolvida uma parte maior (valor incre-mental) do software ou sistema, envolvendo pequenas funcionalidades desenvolvidas pelasvárias equipes. Um PI tem duração de oito a doze semanas, e comumente envolve quatroiterações de desenvolvimento e uma de Innovation and Planning (IP) Iteration, etapa emque ocorre também o planejamento da próxima PI.

Os principais eventos e atividades que auxiliam na coordenação do ART são:

∙ PI Planning: Todos os membros dos times e demais interessados, realizam umareunião, conduzida pelo RTE, para alinhar todas as equipes com o objetivo comumdo PI:

– Contextualizar o Negócio – SAFe-PGL01: um executivo/proprietário descreveo atual estado do negócio e apresenta uma perspectiva sobre o quão bem assoluções atuais estão atendendo as necessidades dos clientes;

– Apresentar a Visão de Produto – SAFe-PGL02: o Product Management apre-senta a visão de produto para as próximas 10 principais funcionalidades, ge-ralmente;

35

– Apresentar Visão de Arquitetura e Práticas de Desenvolvimento – SAFe-PGL03:O arquiteto/engenheiro de sistema apresenta a visão da arquitetura. Alémdisso, um desenvolvedor sênior pode apresentar as práticas propostas por me-todologias ágeis que estarão sendo implantadas no próximo PI;

– Apresentar o Contexto de Planejamento – SAFe-PGL04: o RTE apresenta oprocesso de planejamento e os resultados esperados da reunião;

– Reunião 1 das equipes – SAFe-PGL05: as equipes estimam suas capacidadespara cada iteração e analisam quais itens do backlog serão necessários para rea-lizarem as funcionalidades atribuídas a elas. Também desenvolvem seus planospreliminares, iteração por iteração, apontando riscos e dependências com tare-fas de outras equipes;

– Revisar os Planos Preliminares – SAFe-PGL06: as equipes apresentam os ob-jetivos, riscos potenciais e dependências de seus planos preliminares. BusinessOwners, Product Management, stakeholders e demais equipes analisam e for-necem informações;

– Revisar o Gerenciamento e Solucionar Problemas – SAFe-PGL07: é provávelque os planos apresentados tenham desafios como o escopo, restrição de recur-sos e dependências, então o gerente de produto(Product Management) negociao escopo e tenta solucionar tais problemas, concordando com vários ajustes;

– Comunicar Ajustes no Planejamento – SAFe-PGL08: o gerente descreve asmudanças feitas no planejamento do escopo e dos recursos;

– Reunião 2 das Equipes – SAFe-PGL09: as equipes continuam seu planejamento,realizando os ajustes necessários. Ao finalizarem, os business owners atribuemvalores de negócio aos objetivos, estimando o impacto comportrativo destessobre a estratégia da empresa e suas prioridades;

– Revisão Final dos planos – SAFe-PGL10: as equipes apresentam seu planospara todos e declaram seus riscos e impedimentos. Se os planos forem aprovadospelos clientes, agregam-se os objetivos das equipes, sintetizando o objetivo doPI;

– Identificar Riscos – SAFe-PGL11: durante o planejamento, as equipes identifi-cara riscos e impedimentos que poderiam afetar suas capacidades de atingiremseus objetivos. Estes riscos são abordados de forma clara e discutidos;

– Votação na Confiança – SAFe-PGL12: as equipes votam na confiança que têmpara cumprir seus objetivos e os do PI;

– Refazer Plano – SAFe-PGL13: se necessário, as equipes refazem seus planos,até atingirem um alto grau de confiança;

36

– Realizar retrospectiva de planejamento – SAFe-PGL14: ao final da reunião, oRTE avalia o que ocorreu bem ou não e o que pode ser melhorado.

∙ Apresentar uma Demo do Sistema – SAFe-PGL15: realizada ao final de cada Sprint,fornece uma visão integrada entre todas as funcionalidades, antigas e novas, comisso, os stakeholders têm uma visão objetiva do andamento do desenvolvimento doprograma e as equipes recebem um rápido feedback;

∙ Inspect and Adapt (I&A): Ao final de cada PI, o atual estado da solução é demons-trado e avaliado. As equipes refletem e identificam os itens do backlog que podem sermelhorados através de workshops, que são ótimas oportunidades para coletar dados,resolver problemas e buscar ações que possam aumentar a velocidade, a qualidade ea confiabilidade para o próximo PI, possibilitando que os ARTs evoluam constante-mente. Sempre que possível, todos os "passageiros do trem", equipes, RTE, BusinessOwners, devem participar das etaps desses workshops:

– Apresentar Demo do PI – SAFe-PGL16: é diferente das demais demonstra-ções, uma vez que limita-se a mostrar apenas as funcionalidades desenvolvidasdurante o PI;

– Revisão dos indicadores quantitativos – SAFe-PGL17: as equipes coletam ediscutem sobre os dados e as tendências observadas. Uma medida discutidaé a Medida de Previsibilidade do Programa, que é a avaliação dos reais va-lores de negócio atingidos pelos objetivos do PI de cada equipe, análise feitaconjuntamente por membros das equipes, business owners, clientes e seus re-presentantes, além de outros interessados principais, durante a apresentaçãoda demo. Uma boa taxa de realização, acima de 80%, indica boa confiabilidadepara o trem;

– Retrospectiva – SAFe-PGL18: as equipes realizam uma breve retrospectivasobre o PI, buscando identificar questões, problemas que queiram abordar. Comos temas levantados, os participantes elegem os que serão tratados, geralmente,problemas maiores do nível de Programa são escolhidos ao invés dos de nível deEquipe. Com isto decidido, inicia-se o Workshop de resolução de problema(s);

– Concordar sobre o problema abordado – SAFe-PGL19: o objetivo desta ativi-dade é alinhar a perspectiva de todos sobre o problema. As visões sobre do quese trata, onde ocorre, impactos que causam devem ser expostas sucintamente;

– Analisar a raiz do problema – SAFe-PGL20: recomenda-se o uso de um dia-grama de Ishikawa, também conhecido como espinha de peixe, que propõe olevantamento de causas e sub-causas das categorias principais que no caso sãopessoas, processos, ferramentas, programa, ambiente. A equipe então procuralevantar as causas que contrubuíram para que tal problema ocorresse. Uma

37

vez identificadas, procura-se identificar suas raízes utilizando a técnica dos 5porquês, onde ao perguntar "porquê?"cinco vezes, é possível encontrar a causaraiz;

– Identificar a maior causa raiz – SAFe-PGL21: os membros das equipes votam nacausa que acham ser a maior raiz do problema. Um gráfico é feito apresentandoos votos recebidos por cada causa;

– Realizar Brainstorm – SAFE-PGL22: são levantadas o máximo de ações cor-retivas para solucionar a raiz do problema possíveis;

– Criar Itens de Melhoria para o Backlog – SAFe-PGL23: as equipes votam nastrês soluções mais prováveis, que serão transformadas em histórias e recursospara a próxima reunião de planejamento de PI, onde o RTE garante que essasmelhorias serão repassadas para os backlogs dos times;

∙ Gerenciar Fluxo do ART – SAFe-PGL24: responsável por controlar o fluxo contínuode entrega, integração e implantação de incrementos, além de identificar gargalos eoportunidades para melhorias. Sugere-se a utilização do Kanban para visualizar oprogresso das atividades, além de ser uma maneira fácil de mostrá-lo aos stakehol-ders. Um exemplo típico de Kanban pode ser visto na Figura 2.

Figura 2 – Exemplo de utilização do Kanban no nível de programa. (Fonte: [1])

38

3.3 Portfolio Level

O nível de Portfolio contem os princípios, práticas e papéis necessários para iniciare governar um conjunto de fluxos de valor. A estratégia e os investimentos financeirossão definidos nesse nível, utilizando práticas propostas pelo Lean Thinking alinhadas compráticas ágeis.

Os fluxos de valor (Value Streams), representam a série de etapas que uma orga-nização segue para criar soluções, fornecendo um fluxo contínuo de valor para um cliente.Os fluxos de valor são utilizados para definir e atingir os objetivos comerciais do Portfólio,e organizar os ARTs para oferecer funcionalidades mais rapidamente.

Empresas maiores podem possuir vários portfólios, um para cada instância doSAFe, sendo que cada portfólio possui uma conexão de duas vias com a instituição, esta-belecendo os temas estratégicos para o portfólio que são objetivos de negócio específicos edetalhados que conectam o portfólio aos objetivos estratégicos da empresa, e oferecendoum feedback constante sobre o portfolio aos stakeholders. As informações presentes nofeedback incluem o estado atual das soluções do portfólio, indicadores do desempenhodos fluxos de valores (KPIs), avaliações qualitativas da solução atual para o mercado,qualquer força, fraqueza, ameaça ou oportunidade encontrada no nível.

Os papéis no Portfolio incluem cargos de grande responsabilidade e governança:

∙ Lean Portfolio Management (LPM): Os indivíduos com esse papel possuem o maisalto nível de tomada de decisão e responsabilidade financeira em um portfolio SAFe.São responsáveis por três áreas principais: estratégia e financiamento de investimen-tos, orientação ágil e governança Lean;

∙ Epic Owners: São responsáveis por coordenar os epics, soluções grandes que exigemuma análise e aprovação financeira antes de serem implementadas;

∙ Enterprise Architect: Responsável por coordenar múltiplos fluxos de valor, ajudandona estratégia para otimizar os resultados do Portfolio.

Com a perspectiva de que cada portfólio existe com o propósito de ser um conjuntode soluções alinhadas com a estratégia do negócio, entende-se que devem trabalhar dentrode um orçamento aprovado, já que os custos operacionais no desenvolvimento das soluçõesé um fator importante para o sucesso financeiro da empresa. Assim, nessa etapa, é adotadaa prática de Lean Budgets, que minimizam os custos indiretos através do financiamentodos fluxos de valor e não dos projetos, permitindo uma tomada de decisão rápida pelosresponsáveis que acompanham o dia-a-dia do desenvolvimento.

Alguns problemas que levaram à escolha pelo Lean Budget ao invés do métodotradicional de financiamento de projetos foram a lentidão e complexidade em elaborar o

39

orçamento pois envolvem vários departamentos da empresa que necessitam ser analisadosindividualmente, as equipes terem que tomar decisões sobre prazos e quantidade de pes-soas sem terem conhecimento profundo sobre o projeto e as tarefas envolvidas, e a faltade flexibilidade e adaptação às mudanças de prioridades, o que leva a um re-orçamento,o mesmo acontece com atrasos no desenvolvimento de tarefas.

Dessa forma, o Lean Budgets propõe maior rapidez, adaptabilidade e transpa-rência na distribuição de investimentos, não havendo necessidade de re-orçamentos, em-poderando os papéis que acompanham o dia-a-dia do desenvolvimento, como o ProductManagement, para tomada de decisões, oferecendo a possibilidade de financiadores acom-panharem o desenvolvimento das soluções, através das demonstrações feitas ao final decada PI, e verificarem se o investimento está sendo bem aplicado. Os responsáveis por ge-renciar todo esse processo são os Lean Portfolio Management, que definem os orçamentosde cada Value Stream para cada PI, geralmente.

As atividades realizadas nesta etapa são:

∙ Realizar Reunião Estratégica – SAFE-PTL01: realizada entre os executivos da em-presa e os responsáveis pelo portfólio, tem como objetivo aprovar orçamentos edefinir os temas estratégicos. Para isso, analisam o orçamento operacional total, osobjetivos de desempenho financeiro como participação no mercado e rentabilidade,as missões e valores da empresa, além da análise da competitividade do mercado;

∙ Realizar o Orçamento – SAFe-PTL02: cada Value Stream pertencente ao projetorecebe um orçamento para cada PI, seguindo o método Lean Budgets;

∙ Realizar acompanhamento – SAFe-PTL03: utiliza-se um sistema de Kanban paravisualizar, gerenciar e analisar o andamento do projeto, desde a idealização até aconclusão. Uma parte importante deste processo são os Epics que por serem grandese afetarem mais de um ART necessitam de mais atenção. Assim, o Kanban do nívelde portfólio é desenvolvido para idealizar, analisar, aprovar e rastrear os Epics,principalmente.

41

4 MODELO DE REFERÊNCIA MPS-BR DE SOFTWARE

43

5 PROCESSO DE DESENVOLVIMENTO DE SOFTWAREGAIA

O Laboratório GAIA - Fábrica de Projetos em Tecnologia da Informação e Comu-nicação, é apresentado como:

A Tecnologia da Informação (TI) vem assumindo uma importância cres-cente para as organizações, seja para aperfeiçoar suas atividades ou comosubsídio para tomar suas decisões estratégicas. Para obter um diferen-cial em sua atuação, as organizações públicas ou privadas buscam na TIa melhoria da produtividade, redução de custos e elevação da qualidadede seus serviços e produtos. Inserido neste cenário, o laboratório GAIA- Soluções em TIC do Departamento de Computação da UEL desen-volve trabalhos para apoiar as organizações no uso de TI, abordandodiferentes aspectos como infraestrutura, recursos humanos, processos esistemas. Estes trabalhos envolvem desde consultorias até o desenvolvi-mento de soluções inovadoras, todos baseados na experiência acumuladaem pesquisas acadêmicas realizadas na área. [8]

Nesse contexto, foi criado o processo de Desenvolvimento de software(PDS) GAIA[2] baseado em uma perspectiva de gerenciamento do PMBOK[9]. Organizado pelo ProjectManagement Institute(PMI), o PMBOK é um conjunto de práticas na gestão de projetosque conceitua e identifica processos, áreas de conhecimento, ferramentas e técnicas, sendoconsiderado por muitos profissionais da área como sendo a base para o conhecimento degestão de projetos.

Assim, o PDS GAIA possui 6 fases: Análise Inicial, Análise e Planejamento, Exe-cução e Implementação, Validação e Testes, Entrega e Finalização. Além dessas etapas,o PDS é composto por mais duas componentes que atuam paralelamente aos demais, oManter Requisitos e Gerenciar Portifólio.

Como pode ser visto na Figura 3, o processo começa pela Análise Inicial, cujastarefas são focadas em estabelecer o escopo e a viabilidade do projeto. Em seguda, ocorre aAnálise e Planejamento que revisa e valida requisitos, define tarefas, elabora cronogramase define prazos.

A próxima etapa é a Execução e Implementação, que envolve a gerência de riscose a garantia da qualidade, além das tarefas referentes à execução do projeto. Após aimplementação ocorre a Validação e Testes, que, como um ciclo, volta para a fase deexecução caso ocorra falhas. Paralelamente às essas duas etapas há o Manter Requisitos,que recebe, analisa e define o impacto de alterações nos requisitos e atualiza os documentosnecessários.

Após a validação e os testes serem concluídos, ocorre a Entrega, que realiza testesde integração, analisa resultados, executa correções e realiza reuniões de feedback com os

44

clientes. Por último, acontece a Finalização, onde é feita a entrega final e uma confrater-nização.

O Gerenciar Portifólio é responsável por manter o portifólio de produtos e serviçosda organização, realizando reuniões estratégica e de acompanhamento.

Figura 3 – Processo de Desenvolvimento de Software GAIA. (Fonte: [2])

A fim de estudar o alinhamento do PDS GAIA ao framework ágil SAFe e, poste-riormente, ao modelo de qualidade MR-MPS-SW, serão detalhadas e rotuladas as tarefasenvolvidas nas etapas do PDS [10].

5.1 Análise Inicial - ANI

A análise inicial reúne as tarefas necessárias para iniciar o projeto, procurando,principalmente, definir o escopo do projeto e obter o comprometimento de todos os en-volvidos. Seu fluxograma pode ser visto na Figura 4.

As tarefas envolvidas nessa etapa são:

∙ Reuniões - PDS-ANI01: são reuniões realizadas entre os responsáveis pelo forneci-mento dos requisitos e os responáveis por recebê-los e gerenciá-los. É guiada peladefinição das datas e pautas das reuniões e criação das atas assinadas das mesmas;

∙ Estabelecer Escopo - PDS-ANI02: Um escopo inical do projeto é desenvolvido, afimde guiar as próximas etapas. É feito através do levantamento das necessidades docliente, onde se estabelece o escopo e gera-se um WBS simplificado do projeto;

45

Figura 4 – Análise Inicial - ANI. (Fonte: [2])

46

∙ Realizar Estimativas - PDS-ANI03: é estimado o tamanho do projeto, através daidentificação de suas características e seguindo técnicas específicas;

∙ Preparar ambiente - PDS-ANI04: prepara o ambiente para o desenvolvimento doprojeto, incluindo seu planejamento, controle de acesso, versionamento, entre outros,de acordo com o padrão organiacional;

∙ Analisar Viabilidade - PDS-ANI05: Verifica-se a viabilidade do projeto, analisandoriscos, premissas e restrições identificados durante a elaboração do escopo. São de-terminados também os prazos e custos para o projeto;

∙ Criar Project Charter - PDS-ANI06: se o projeto for considerado viável, reúne-setodas as informações disponíveis em um único documento(Project Charter);

∙ Realizar Reunião de Kick-off - PDS-ANI07: todos os participantes do projeto sãoreunidos a fim de se obter o comprometimento de todos. É definida a pauta dareunião e apresenta-se o Project Charter.

5.2 Análise e Planejamento - APL

Essa etapa reúne as tarefas de análise e planejamento do projeto e de suas fases,são realizadas estimativas e planos. A Figura 5 traz seu fluxograma.

As tarefas envolvidas nessa etapa são:

∙ Levantar Requisitos - PDS-APL01: Necessidades e requisitos são levantados com ocliente. Procurando entender a situação, é realizada uma reunião entre os reponsáveispelos requisitos e o cliente, em seguida, os requisitos são elencados seguindo asnecessidades e detalhados conforme o padrão da organização. Aqui também sãomodelados os casos de uso;

∙ Expandir WBS - PDS-APL02: o WBS é melhor detalhado. Atividades e tarefas sãoderivadas da original e o domínio da aplicação é esmiuçado;

∙ Revisar Requisitos - PDS-APL03: feito o levantamento e a expansão do WBS, osrequisitos são reunidos, revisados e verificados seguindo critérios estabelecidos;

∙ Validar Requisitos - PDS-APL04: Os requisitos classificados e verificados são apre-sentados ao cliente, a fim de obter sua validação e questionamentos por quaisqueralterações;

∙ Definir Entregas - PDS-APL05: com os requisitos definidos, revisados e validados,o sitema especificado é dividido em entregas implementáveis para que seu desen-volvimento possa ocorrer de forma mais fluída e visível. É definido quais serão asentregas;

47

Figura 5 – Análise e Planejamento - APL. (Fonte: [2])

48

∙ Manter Rastreabilidade dos Requisitos - PDS-APL06: é criado um relacionamentobidirecional entre os requisitos. Relacionamentos bidirecionais entre requisitos e ou-tros ativos de projeto também são criados;

∙ Planejar Indicadores - PDS-APL07: indicadores de desempenho são identificados eestabelecidos. Para isso, são identificados, primeiramente, os objetivos de medição,obtidos com a ajuda da elaboração de questões que devem ser respondidas a par-tir dos dados coletados. Com os objetivos definidos, é definido a política de quais,quando e como os dados serão coletados, determinando priridades, descrevendo mé-todos de coleta e criando um Plano de Métricas;

∙ Planejar Recursos - PDS-APL08:os recursos necessários para a realização das tarefassão identificados, sua disponibilidade é verificada e seu orçamento realizado. Por fim,uma lista com os recursos é criada e um plano de alocação de recursos é feito;

∙ Análise de Risco - PDS-APL09: os riscos potenciais do projeto são identificados equalificados de acordo com sua probabilidade de ocorrência. Os riscos também sãoqualificados segundo o impacto que podem causar no projeto. São elaboradas açõespreventivas e corretivas para os riscos identificados, além de planos de contingência.Todas essas ações são organizadas então em uma única lista;

∙ Estimar Prazos e Custos - PDS-APL10: tarefas e recursos são elencados e dados decustos indiretos e de RH são coletados. Com essas informações, é possivel estimar aduração das atividades e dos recursos, permitindo a realização de uma previsão decusto efetivo do projeto no geral;

∙ Elaborar Cronograma - PDS-APL11: atividades, recursos, estimativas de prazos ecustos são reunidos, adicionando uma margem para erros. Pontos de controle sãodefinidos e então, o cronograma é elaborado;

∙ Elaborar Tarefas - PDS-APL12: atividades e tarefas são identificadas e organizadasem uma lista;

∙ Planejar Testes - PDS-APL13: testes necessários para garantir a qualidade dos pro-dutos parciais são pensados e então, é determinado o que testar, como os testesserão executados e como analisá-los;

∙ Planejar Configuração - PDS-APL14: define o plano de gerenciamento de configu-ração. São definidos os ativos que serão gerenciados, o local de armazenamento, aconfiguração inicial de arquivos, pontos de revisão, ferramentas de gerenciamentode configuração e pontos de criação das baselines;

∙ Revisar Planos - PDS-APL15: os planos criados até agora são revisados em suaconsistência. A coerência de cada plano é verificada separadamente, para depois ser

49

verificada como uma unidade. Os objetivos e aderência dos planos são analisados e,por fim, relacionamentos entre os mesmos são criados;

∙ Disponibilizar Informações - PDS-APL16: as informações são reunidas na ferra-menta de configuração, disponibilizadas, em um único ambiente, a todos interessa-dos, e, opcionalmente, restrições de acesso pode ser aplicadas;

∙ Definir Fase - PDS-APL17: A fase a ser desenvolvida é definida através da seleçãodas entregas implementáveis a serem realizadas;

∙ Analisar Viabilidade - PDS-APL18: identifica-se o que falta ser realizado e seusriscos para, então, analisar a viabilidade do projeto.

5.3 Execução e Implementação - EXI

Nessa etapa estão envolvidas tarefas referentes à execução do projeto, controlandosuas tarefas e andamento geral. Seu fluxograma é apresentado na Figura 6

Figura 6 – Execução e Implementação - EXI. (Fonte: [2])

As tarefas envolvidas nessa etapa são:

∙ Executar Tarefas - PDS-EXI01: tarefas planejadas anteriormente são executadas eatualizadas em seu marcador de progresso;

50

∙ Gerenciar Riscos - PDS-EXI02: O desenvolvimento do projeto é monitorado e seusriscos controlados através da identificação dos riscos potenciais, de acordo com oplano de riscos, execução de ações preventivas e corretivas, e registro dos riscosocorridos;

∙ Garantir Qualidade - PDS-EXI03: o código é verificado, padrões são controlados, osoftware versionado, são implementados planos de testes, dados do projeto e processosão coletados e analisados, tudo para garantir que os produtos estão em conformi-dade com o esperado e com os padrões, além de garantir que o processo está sendoseguido;

∙ Gerenciar Comunicação - PDS-EXI04: garante que as informações necessárias sãoentregues às devidas pessoas no tempo certo;

∙ Gerenciar Configuração - PDS-EXI05: revisa os baseline e os ativos de projeto queestão sob a gerência de configuração.

5.4 Validação e Testes - VAT

A etapa de Validação e Testes é responsável por reunir as atividades referentes aotrabalho de tester unitariamentes os resultados da fase executada. A Figura 7 apresentao fluxograma da etapa.

Figura 7 – Validação e Testes - VAT. (Fonte: [2])

51

As tarefas envolvidas nessa etapa são:

∙ Executar Teste Unitário - PDS-VAT01: testes unitários são realizados a fim de evitarerros de código e validar a fase;

∙ Analisar Resultados - PDS-VAT02: Analisa os resultados dos testes e valida o pro-duto;

∙ Realizar Correção - PDS-VAT03: efetua correções necessárias de acordo com a aná-lise dos resultados dos testes.

5.5 Entrega - ENT

A etapa reúne as tarefas necessárias para implantação do sistema no cliente e obterseu feedback. Seu fluxograma pode ser visto na Figura 8.

Figura 8 – Entrega - ENT. (Fonte: [2])

As tarefas envolvidas nessa etapa são:

∙ Executar Testes de Integração - PDS-ENT01: testes de integração são realizados,segundo o plano de testes, para evitar erros no sistema;

∙ Analisar Resultados - PDS-ENT02: analisa os resultados do teste de integração,identifica erros e valida o produto;

52

∙ Executar Correções - PDS-ENT03: correções são feitas conforme os resultaods daanálise;

∙ Implantar Resultado da Fase - PDS-ENT04: com a aprovação nos testes, é pos-sível realizar a implantação do resultado da fase no cliente, reunindo os recursosnecessários e configurando e testando seu funcionamento;

∙ Realizar Reunião de Feedback (equipe e cliente) - PDS-ENT05: reunião para forma-lizar a entrega do resultado da fase para o cliente e receber feedback. Pode ocorrera aprovação ou não do cliente.

5.6 Finalização - FIN

Atividades necessárias para finalização do projeto, incluindo o contrato, são reu-nidas nesta etapa. Seu fluxograma pode ser visto na Figura 9.

Figura 9 – Finalização - FIN. (Fonte: [2])

As tarefas envolvidas nessa etapa são:

∙ Realizar Reunião de Entrega - PDS-FIN01: formaliza a entrega do produto ao clientee feedback do produto. Reúne-se informações e as apresenta em reunião, as liçõesaprendidas são capturadas e os feedback obtidos e registrados;

∙ Confraternização - PDS-FIN02: realiza-se uma confraternização para comemorar ofim do projeto.

53

5.7 Manter Requisitos - MRQ

Nessa etapa reúne-se as atividades ligadas diretamente ao gerenciamento de requi-sitos. Seu fluxograma pode ser visto na Figura 10.

Figura 10 – Manter requisitos - MRQ. (Fonte: [2])

As tarefas envolvidas nessa etapa são:

∙ Receber Alteração - PDS-MRQ01: o cliente solicita alterações de requisitos. Asalterações podem ser recebidas pelo help-desk, são registradas e compreendidas.Uma reunião pode ser marcada com o cliente;

∙ Analisar Impacto da Alteração - PDS-MRQ02: as alterações recebidas são avaliadasjunto à equipe. Discute-se sobre a viabilidade das alterações;

∙ Definir alteração - PDS-MRQ03: se a alteração for viável, é definido como e quandoela será feita;

∙ Atualizar Documentação de Requisitos - PDS-MRQ04: Os produtos de trabalho sãoatualizados de acordo com as alterações definidas.

5.8 Gerenciar Portifólio - GPT

As atividades necessárias para gerenciar o portifólio de produtos e serviços daorganização são reunidas nessa etapa. A Figura 11 traz o fçuxograma da etapa.

As tarefas envolvidas nessa etapa são:

∙ Realizar Reunião Estratégica - PDS-GPT01: essas reuniões são realizadas com ointuito de tomar decisões estratégicas, identificando e priorizando oportunidades.

54

Figura 11 – Gerenciar Portifólio -GPT. (Fonte: [2])

Ocorre também o direcionamento de investimentos e responsabilidades no gerenci-amento de projetos, a atribuição das responsabilidades aos gerentes de projeto e apriorização dos investimentos;

∙ Realizar Reunião de Acompanhamento - PDS-GPT02: essas reuniões são realizadasa fim de obter informações sobre o andamento dos projetos atuais e identificar pos-síveis ações necessárias. A partir dessas informações, é possivel identificar e planejarsoluções.

55

6 ALINHAMENTO DO PDS GAIA

6.1 Metodologia

O processo de alinhamento leva em consideração as características e detalhes doSAFe, explorados no capítulo 3, e todos os processos e subprocessos do PDS GAIA es-tudados no capítulo 5. Uma tabela tabela foi montada para relacionar as evidências doPDS que mostravam a realização de alguma atividade proposta pelo SAFe.

O alinhamento do PDS ao MR-MPS-SW ocorreu de modo análogo, considerandoos resultados esperados dos níveis, expostos no capítulo 4.

56

Tabela 2 – Alinhamento do PDS ao SAFe – Team LevelNível Evento Atividade SAFe PDS Observações

Team

Iteration Planning

SAFe-TML01

SAFe-TML02PDS-ANI03PDS-APL08PDS-APL10

SAFe-TML03 PDS-APL02PDS-APL12

SAFe-TML04 PDS-APL07

SAFe-TML05 PDS-ANI07

No PDS, o compro-metimento ocorrecom o projeto comoum todo

Iteration Execution

SAFe-TML06 PDS-EXI01

SAFe-TML07 PDS-EXI04 Não define umareunião diária

SAFe-TML08Não há gerencia-mento de fluxo detrabalho

SAFe-TML09 PDS-EXI03

Nem todas as prá-ticas propostas peloSAFe para agregarqualidade são se-guidas

SAFe-TML10PDS-VAT01PDS-VAT02PDS-VAT03

SAFe-TML11 PDS-VAT01

Backlog Refinement SAFe-TML12

PDS-APL03PDS-MRQ-02PDS-MRQ03PDS-MRQ04

Iteration Review SAFe-TML13 PDS-ENT05Não especifica sea equipe discute aiteração

Iteration Retrospective SAFe-TML14

No PDS não háuma reunião espe-cífica para a equipediscutir o que podeser melhorado

IP Iteration SAFe-TML15 PDS-ENT01PDS-ENT02

Não especifica quehá uma hora parainovar, explorar no-vas possibilidades

57

Tabela 3 – Alinhamento do PDS ao SAFe – Program Level

Nível Evento Atividade SAFe PDS Observações

Programa

PI Planning

SAFe-PGL01 Não há nenhuma inte-ração parecida

SAFe-PGL02 PDS-ANI02 WBSPDS-APL02

SAFe-PGL03 Não há referências so-bre arquitetura

SAFe-PGL04

SAFe-PGL05 PDS-ANI03 estimativas realizadaspara o projeto inteiro

PDS-APL08SAFe-PGL06 PDS-APL15SAFe-PGL07

SAFe-PGL08 PDS-EXI04 é um exemplo de co-municação

SAFe-PGL09 Não há menção aos va-lores de negócio

SAFe-PGL10 PDS-APL07 parcialSAFe-PGL11 PDS-APL09SAFe-PGL12SAFe-PGL13SAFe-PGL14

ApresentarDemo SAFe-PGL15 PDS-ENT01 não ocorre implanta-

ção

Inspect & Adapt

SAFe-PGL16

SAFe-PGL17 PDS-ENT02só que a avaliação é so-bre a demo da PI, nãodo sistema integrado

SAFe-PGL18SAFe-PGL19SAFe-PGL20SAFe-PGL21SAFe-PGL22SAFe-PGL23

Gerenciar Fluxodo ART SAFe-PGL24

Tabela 4 – Alinhamento do PDS ao SAFe – Portfolio Level

Nível Evento Atividade SAFe PDS Observações

PortfolioSAFe-PTL01 PDS-GPT01SAFe-PTL02SAFe-PTL03 PDS-GPT02

59

7 CONCLUSÃO

61

REFERÊNCIAS

[1] LEFFINGWELL, D. Scaled Agile Framework. 2017. Disponível em: <http://www.scaledagileframework.com>. Acesso em: 24.07.2017.

[2] GAIA. Processo de desenvolvimento de software GAIA. 2010. Disponível em:<http://gaia.uel.br/projetos/gaia_PDS/default.htm>. Acesso em: 04.09.2017.

[3] SOMMERVILLE, I. Engenharia de oftware. 9. ed. [S.l.]: Pearson Prentice Hall, 2011.

[4] PRESSMAN, R. S. Engenharia de software: uma abordagem técnica. 7. ed. [S.l.]:McGraw Hill Education, 2011.

[5] BRASILEIRO(SOFTEX), A. para promoção da excelência do software. Mps.br–melhoria de processo do software brasileiro: Guia geral mps de software. 2016.

[6] BECK, K. et al. Manifesto para o desenvolvimento ágil de software. 2001. Disponívelem: <http://www.manifestoagil.com.br/>.

[7] CORTêS, M. L. Modelos de qualidade de Software. 1. ed. [S.l.]: UNICAMP, 2001.

[8] GAIA. GAIA - Soluções em TIC. 2017. Disponível em: <www.gaia.uel.br>. Acessoem: 04.09.2017.

[9] INSTITUTE, P. M. A Guide to the Project Management Body of Knowledge(PMBOK R○ Guide). 2008.

[10] GALHARDI, L. B. Alinhamento dos Processos de Desenvolvimento de Software doLaboratório GAIA aos níveis G e F do modelo de qualidade MR-MPSSW. 2016.Universidade Estadual de Londrina, Londrina - PR. Trabalho de Conclusão deCurso (Bacharelado em Ciência da Computação).

Apêndices

65

APÊNDICE A – QUISQUE LIBERO JUSTO

Quisque facilisis auctor sapien. Pellentesque gravida hendrerit lectus. Mauris ru-trum sodales sapien. Fusce hendrerit sem vel lorem. Integer pellentesque massa vel au-gue. Integer elit tortor, feugiat quis, sagittis et, ornare non, lacus. Vestibulum posuerepellentesque eros. Quisque venenatis ipsum dictum nulla. Aliquam quis quam non metuseleifend interdum. Nam eget sapien ac mauris malesuada adipiscing. Etiam eleifend nequesed quam. Nulla facilisi. Proin a ligula. Sed id dui eu nibh egestas tincidunt. Suspendissearcu.

Anexos

69

ANEXO A – MORBI ULTRICES RUTRUM LOREM.

Sed mattis, erat sit amet gravida malesuada, elit augue egestas diam, tempusscelerisque nunc nisl vitae libero. Sed consequat feugiat massa. Nunc porta, eros in eleifendvarius, erat leo rutrum dui, non convallis lectus orci ut nibh. Sed lorem massa, nonummyquis, egestas id, condimentum at, nisl. Maecenas at nibh. Aliquam et augue at nuncpellentesque ullamcorper. Duis nisl nibh, laoreet suscipit, convallis ut, rutrum id, enim.Phasellus odio. Nulla nulla elit, molestie non, scelerisque at, vestibulum eu, nulla. Ut odionisl, facilisis id, mollis et, scelerisque nec, enim. Aenean sem leo, pellentesque sit amet,scelerisque sit amet, vehicula pellentesque, sapien.