BRUNO CARAZATO DE OLIVEIRA

GAIA PROTÓTIPO: UM MODELO DE PROTOTIPAÇÃOPARA PROCESSOS DE DESENVOLVIMENTO DE

SOFTWARE

LONDRINA–PR

2017

BRUNO CARAZATO DE OLIVEIRA

GAIA PROTÓTIPO: UM MODELO DE PROTOTIPAÇÃOPARA PROCESSOS DE DESENVOLVIMENTO DE

SOFTWARE

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

Bruno Carazato de OliveiraGaia Protótipo: Um Modelo de Prototipação para Processos de Desenvolvi-

mento de Software/ Bruno Carazato de Oliveira. – Londrina–PR, 2017-48 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

BRUNO CARAZATO DE OLIVEIRA

GAIA PROTÓTIPO: UM MODELO DE PROTOTIPAÇÃOPARA PROCESSOS DE DESENVOLVIMENTO DE

SOFTWARE

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 à minha família,em especial aos meus pais, por todo apoio, confiança e por nunca medir esforços ao me

ajudar em toda minha formação.

AGRADECIMENTOS

Agradeço primeiramente a Deus por todas as oportunidas que constantementecoloca na minha vida e pela proteção por onde quer que eu vá. Agradeço imensamenteaos meus pais, Fábio Wagner de Oliveira e Rosângela Ap. Carazato de Oliveira, porsempre investirem na minha formação pessoal e acadêmica e não deixarem faltar amor ecarinho na minha vida. Também agradeço ao meu irmão Murilo pelo companheirismo epelos momentos agradáveis que temos juntos.

A minha namorada Maria Paula por todo apoio em todas as situações, dentro efora da universidade, tendo sempre uma paciência imensa comigo e por esse amor fraternalque nossa relação ao longo dos anos se tornou.

A todos os amigos que caminham comigo, que também foram de suma importância

Ao meu orientador Prof. Rodolfo Miranda de Barros, por confiar no meu trabalho,me incentivar e por me guiar nessa reta final.

Por fim, agradeço a todos os professores pelo conhecimento e experiências com-partilhados, a Universidade Estadual de Londrina e o Departamento de Computação porme proporcionarem durante esses 4 anos um ótimo ambiente de estudo.

“The things that we love tell us what we are.”(Thomas Aquinas)

CARAZATO, N. A.. Gaia Protótipo: Um Modelo de Prototipação para Processosde Desenvolvimento de Software. 48 p. Trabalho de Conclusão de Curso (Bachareladoem Ciência da Computação) – Universidade Estadual de Londrina, Londrina–PR, 2017.

RESUMO

Possuir um processo de desenvolvimento de software é imprescindível para que a qualidadedo software seja o objetivo, visto que a indústria desta área esta em crescente desenvol-vimento, tornando o mercado mais competitivo. Sendo assim, o presente trabalho popõeo desenvolvimento de um modelo de prototipação que possa ser integrado nos diversosmodelos de desenvolvimento de software, uma vez que a prototipação é uma técnica queminimiza muitos problemas e limitações nos processos de desenvolvimento de software,levando em consideração as melhores práticas, os variados tipos de equipes e as diferentesculturas organizacionais.

Palavras-chave: Prototipação. Processo de Desenvolvimento de Software. Modelo.

CARAZATO, N. A.. Gaia Protótipo: A Prototyping Model for Software Deve-lopment Process. 48 p. Final Project (Bachelor of Science in Computer Science) – StateUniversity of Londrina, Londrina–PR, 2017.

ABSTRACT

To have a software development process is essential once the quality of software is thegoal since in this area the industry is in a growing evolution making the market morecompetitive. Thus, this work propose the development of a prototyping’s model that canbe integrated into various software develompment models once prototyping is a techniquethat minimizes a lot of problems and limitations on software development processes tak-ing into account the best pratices and the different types of teams and organizationalcultures.

Keywords: Prototyping. Software Development Process. Model.

LISTA DE ILUSTRAÇÕES

Figura 1 – Modelo Clássico [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 2 – Modelo espiral de desenvolvimento de software [2] . . . . . . . . . . . . 28Figura 3 – Componentes do Scrum. Figura retirada de: hubspot.com . . . . . . . . 31Figura 4 – GAIA Protótipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 5 – Preparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 6 – Planejamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 7 – Desenvolvimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 8 – Evolução. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

LISTA DE TABELAS

Tabela 1 – As treze práticas importantes que compõem o XP. [3]. . . . . . . . . . 30Tabela 2 – Tabela comparativa entre características das metodologias tradicionais

e ágeis. [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Tabela 3 – Tabela priorizada dos dez maiores itens de risco para software e técnicas

para enfrentá-los [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

LISTA DE ABREVIATURAS E SIGLAS

ISO International Organization for Standardization

PDS Processo de Desenvolvimento de Software

XP Extreme Programming

SUMÁRIO

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

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 252.1 Processo de Desenvolvimento de Software . . . . . . . . . . . . 252.2 Metodologias Tradicionais . . . . . . . . . . . . . . . . . . . . . . 252.3 Metodologias Evolucionárias . . . . . . . . . . . . . . . . . . . . . 262.3.1 Prototipação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Metodologias Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4.1 XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.4.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.5 Comparação de pontos principais entre as Métodologias Tra-

dicionais e Ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.6 Riscos, problemas e possíveis soluções para o desenvolvimento

de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3 GAIA PROTÓTIPO: UM MODELO DE PROTOTIPAÇÃOPARA PROCESSOS DE DESENVOLVIMENTO DE SOFT-WARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 Preparação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4 Evolução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

APÊNDICES 45

ANEXOS 47

23

1 INTRODUÇÃO

Ano após ano cresce a importância do software na sociedade. Não esta equivocadoquem diga que o software hoje é essencial para a vida das pessoas. Desde os variadossetores de negócios até mesmo os aspectos diários da nossa vida são afetados por software,como por exemplo: atividades pessoais ou de trabalho, infra-estruturas civis e industriais,política, educação e entretenimento. Como consequência, o desenvolvimento de softwaretornou-se uma atívidade a ser cuidadosamente estudada e melhorada [4].

A fim de se obter um produto de software de qualidade, é imprescindível esta-belecer um Processo de Desenvolvimento de Software adequado. Pode-se dizer que umPDS consiste em etapas parcialmente ordenadas bem como um conjunto de atividades aserem desenvolvidas. De forma genérica, na Engenharia de Software, uma metodologia deprocesso compreende cinco atividades, que conforme em [5] são, resumidamente:

1. Comunicação, para compreender os objetivos das partes interessadas e fazer olevantamento correto das necessidades e requisitos;

2. Planejamento, definindo as tarefas técnicas a serem conduzidas, os possíveis riscos,os recursos necessários, o que deve ser produzido ao fim do processo e um cronogramade trabalho;

3. Modelagem, esboçando de forma refinada ou não, a fim de visualizar uma ideiamais concreta de como cada parte se encaixará;

4. Construção, gerar código e executar testes para que possíveis erros sejam solucio-nados;

5. Emprego, entrega do software ao cliente que fornece um feedback.

Porém, como dito anteriormente, com o aumento do interesse na área, novas ideiassurgiram fazendo com que o mercado de software se tornasse mais competitivo e exigente,com isso, as cinco atividades citadas acima têm sido adaptadas e otimizadas para cadaformato de empresa e equipe, e com isso, novos mecanismos e modelos são desenvolvidosa fim de obter um software de melhor qualidade, minimizando custo, tempo e retrabalho.

Nesse contexto, a prototipação é de grande relevância justamente porque é umatécnica para evitar o retrabalho, e consequententemente, diminuir o custo e melhoraro prazo de entrega do produto final, pois mesmo com um levantamento de requisitosminucioso (o que é uma grande dificuldade no cenário atual), mudanças e/ou erros duranteo processo podem acontecer.

24

Existem dois tipos diferentes de protótipos no desenvolvimento de software: osprotótipos de lançamento (Throw-away), que ajudam a entender determinados requisitosde difícil compreensão pelo analista e os protótipos evolutivos, que oferecem uma projeçãovisual e/ou funcional viável do sistema para o cliente e muitas vezes se tornam parte dosistema final [6].

O objetivo do presente trabalho é desenvolver um modelo de prototipação quepossa ser integrado às diversas metodologias de desenvolvimento de software, porém commaior ênfase nas denominadas ágeis, promovendo uma melhoria contínua no PDS.

A organização segue da seguinte maneira: No Capítulo 2 são apresentados conceitose definições usados neste trabalho. O Capítulo 3 aborda o modelo proposto. O Capítulo 4exibe os resultados obtidos e uma breve discussão. No Capítulo 5 econtra-se as conclusõesfinais sobre o trabalho.

25

2 FUNDAMENTAÇÃO TEÓRICA

Segundo a ISO 12207[7], o ciclo de vida de um produto de software é modelado emestágios. Os modelos podem ser utilizados para representar todo o ciclo de vida, desde oconceito até a cessão ou parte dele. O foco deste trabalho será no PDS, que é o estágioresponsável por conceber o produto no ciclo de vida do software.

Em [8], o autor diz que o sucesso das organizações que atuam na industria desoftware se deve pela qualidade do seu produto, que esta diretamente ligado à qualidadeno processo de desenvolvimento do mesmo. Além disso, como desenvolver está relacionadoà criatividade e habilidade dos desenvolvedores de software, a força de trabalho seria oprincipal ativo organizacional, o que se confirma e é ressaltado em [9] quando o autorapresenta a influência direta da qualidade do trabalho trabalho em equipe na qualidadedo software desenvolvido.

2.1 Processo de Desenvolvimento de Software

Um Processo ou Metodologia de Desenvolvimento de Software consiste em umconjunto de atividades e resultados associados que auxiliam na produção da aplicação.

Muitas organizações no cenário brasileiro atual, mesmo cientes da importância dedesenvolver software de qualidade, ainda desenvolvem sem utilizar nenhum processo, issose deve geralmente porque as metodologias tradicionais são ditas "pesadas"e em particular,as organizações de pequeno e médio porte não possuem recursos suficiente para fazer usodelas. O resultado desta falta de sistematização na produção de software é a baixa quali-dade do produto final, além da dificuldade em entregar nos prazos e custos predefinidos eaté inviabilizar a futura evolução do mesmo. Outras empresas, por desconhecerem novasmétodologias, porém a maiora delas possui conhecimento mas têm receio da mudança,optando por permanecer com o mesmo modelo tradicional [1].

2.2 Metodologias Tradicionais

As metodologias tradicionais são chamadas de pesadas, visto que, têm como prin-cipal característica a documentação total do software antes de sua implementação, nãosão sucetíveis a mudanças no decorrer da produção, ou seja, será desenvolvido de inícioao fim o que foi planejado.

O primeiro processo tradicional publicado foi o chamado Cascata ou Clássico, porPressman, que é a principal metodologia tradicional e muito utilizada até hoje [1], deforma geral estabelece as etapas descritas na Figura 1:

26

Figura 1 – Modelo Clássico [1]

O modelo Cascata descreve um método linear e sequencial de fases, sendo quequando uma determinata fase é completada, segue-se para a próxima sem a opção devoltar, pular ou refazer a etapa atual.

Uma vantagem do modelo seria a possibilidade que ele proporciona de se realizarum controle departamental e gerencial, visto que cada fase é muito bem definida. Poroutro lado, ele não permite muita flexibilidade ou revisão. Se algo não foi bem pensadono estágio conceitual, será muito dificil fazer alterações no decorrer do desenvolvimento.

Em [5], Pressman elenca alguns problemas que o modelo enfrenta:

1. Os projetos reais raramente seguem o fluxo seqüencial que o modelo propõe. Algumaiteração sempre ocorre e traz problemas na aplicação do paradigma;

2. Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente. Ociclo de vida clássico exige isso e tem dificuldade de acomodar a incerteza naturalque existe no começo de muitos projetos;

3. O cliente deve ter paciência. Uma versão de trabalho dos programas não estarádisponível até um ponto tardio do cronograma do projeto. Um erro crasso, caso nãoseja detectado a tempo de se rever o programa de trabalho, pode ser desastroso.

2.3 Metodologias Evolucionárias

Ao longo do tempo, o software evolui, com isso, novas necessidades de negócio eproduto surgem frequentemente. Assim, para os modelos de linha reta, surgem limitaçõese então, são criados os modelos evolucionários, ou seja, a possibilidade densenvolver pro-dutos que evoluam ao longo do tempo. Os dois modelos evolucionarios mais comuns são:Prototipação e Espiral.

27

2.3.1 Prototipação

Segundo Pressman [5], o paradigma de prototipação costuma ser a melhor escolhade abordagem quando:

1. O cliente define uma série de objetivos gerais para o software, mas não identifica,de forma detalhada, os requisitos para funções e recursos;

2. O desenvolvedor encontra-se inseguro quanto à eficacia de um algoritmo ou quantoà adaptabilidade de um sistema operacional;

3. Quando há dúvida quanto à forma em que deve ocorrer a interação homem/máquina.

E em muitas outras situações. Embora a prototipação possa ser utilizada como um mo-delo de processo isolado, é mais comumente utilizada como uma técnica passível de serimplementada no contexto de qualquer um dos modelos de processo que estão ou nãodescritos nesse trabalho.

Cherubin destaca em [10], um estudo de caso feito em uma empresa chamadaEducom que dispensa as tradicionais práticas de pesquisa de mercado para conheceras demandas dos clientes, pois ao idealizar os protótipos (versão beta), são levados aosclientes para a verificação e validação de sua aceitação.

Em geral, os protótipos podem ser construídos como "descartáveis"ou então evo-lucionários, no sentido de que evoluem lentamente até se transformarem no sistema real.

2.3.2 Espiral

Apesar da possibilidade de ser classificado como Evolutivo, em [2], Almeida dizque o modelo Espiral nasce beaseado na experiência obtida com vários refinamentos domodelo tradicional Cascata, sendo que sua maior diferença com modelo citado como baseseria que este cria uma abordagem orentada a riscos para o processo de desenvolvimentode software, ao invés de ser primariamente orientado a documentação ou a codificação.

A característica principal do modelo se deve ao fato de ser incremental, tornandoformal o conceito de iterações orentadas a risco e deixando claro a necessidade de avaliaçãodos riscos a cada iteração.

Assim, a metodologia é de bom uso para aqueles que defendem o uso de planeja-mento extensivo, processos codificados e rigorosos reusos a fim de tornar o processo umaatividade preditiva e eficiente que vai gradualmente amadurecendo em direção ao objetivo,porém o modelo ainda enfrenta algumas limitações herdadas dos modelos tradicionais.

Então, com o objetivo de solucionar tais limitações, revolucionando a maneira dedesenvolver software, surgem as métodologias Ágeis.

28

Figura 2 – Modelo espiral de desenvolvimento de software [2]

2.4 Metodologias Ágeis

Novas tecnologias surgem, consequentemente, necessita-se cada vez mais do soft-ware e com isso, os problemas enfrentados no seu processo de desenvolvimento crescem.Eis que dezessete especialistas em PDS, com base em toda experiência adiquirada até opresente momento, estabelecem princípios comuns compartilhados por novas metodolo-gias, as ditas "Metodologias Ágeis", termo que se populariza em 2001.

As Metodologias Ágeis são um grupo de métodos incrementais e iterativos que sãomais eficazes e por isso têm sido usados também no gerenciamento de projetos em geral,não somente no desenvolvimento de software, segundo [11].

Os conceitos chave de grupo são:

1. Indivíduos e interações ao invés de processos e ferramentas.

2. Software executável ao invés de documentação.

3. Colaboração do cliente ao invés de negociação de contratos.

29

4. Respostas rápidas a mudanças ao invés de seguir planos.

Apesar do que foi listado, é valido a ressalva de que as metodologias ágeis nãorejeitam os processos e ferramentas, bem como documentações e negociações, porém oscolocam como importância secundária, pois como principal seria o que foi dito anteri-ormente. Brito, em [12], ressalta a transferência de conhecimento entre os membros daequipe visto que essas metodologias utilizam de uma constante comunicação e colaboraçãoentre os mesmos, especialmente através da chamada troca face-to-face.

Existem várias metodologias deste grupo, porém as mais conhecidas são: XP eScrum.

2.4.1 XP

Segundo [13], o XP seria a metodologia ágil mais amplamente utilizada, voltadopara projetos cujos requisitos são vagos e podem mudar com frequência, desenvolvimentode sistemas orientados a objeto, equipes pequenas, preferencialmente até 12 (doze) de-senvolvedores, e desenvolvimento incremental (ou iterativo), onde o sistema começa a serimplementado logo no início do projeto e vai ganhando novas funcionalidades ao longo dotempo.

As seguintes 13 (treze) práticas importantes que compõem o XP, segundo [3], são:

30

Prática no XP Descrição

1. Cliente Presente O XP trabalha com a premissa de que o cliente deve conduzir odesenvolvimento a partir do feedback que recebe do sistema.

3. Jogo do Planejamento No início de cada iteração ocorre o jogo do planejamento. Trata-sede uma reunião onde o cliente avalia as funcionalidades que serãoimplementadas.

3. Stand Up Meeting A equipe se reune a cada manhã para avaliar o trabalho que foiexecutado no dia anterior e priorizar aquilo que será implementadono dia que se inicia .

4. Programação em Par Os desenvolvedores implementam as funcionalidades em pares, ouseja, diante de cada computador, existem sempre dois desenvolve-dores que trabalham juntos para produzir o mesmo código.

5. Desenvolvimento Guiado p/ Testes Testes são escritos para cada funcionalidade antes de codificá-las.Fazendo isso, eles aprofundam o entendimento das necessidadesdo cliente.

6. Refactoring O refactoring é o ato de alterar um código sem afetar a funcio-nalidade que ele implementa. O objetivo é tornar o software maissimples de ser mantido.

7. Código Coletivo Os desenvolvedores têm acesso a todas as partes do código e po-dem alterar aquilo que julgarem importante sem pedir autorizaçãode outra pessoa.

8. Código Padronizado Para facilitar a manutenção no código por parte de toda equipe,padrões de codificação são definidos tornando o sistema mais ho-mogêneo e permitir que qualquer membro da equipe tenha condi-ções de dar manutenção no sistema.

9. Design Simples Para que o cliente possa obter feedback logo, a equipe precisa serágil no desenvolvimento, o que leva a optar pela simplicidade dodesign.

10. Metáfora Para facilitar a criação de um design simples, a equipe de desen-volvimento utiliza metáforas, já que elas têm o poder de transmitirideias complexas de forma simples.

11. Ritmo Sustentável Para garantir que a equipe tenha sempre o máximo de rendimentoe produza software com melhor qualidade possível, o XP reco-menda que os desenvolvedores trabalhem apenas oito horas pordia e evitem fazer horas-extras, visto que é essencial estar descan-sado a cada manhã, de modo a utilizar a mente na sua plenitude.

12. Integração Contínua Prática utilizada com o objetivo de checar/testar a aplicação, sem-pre que uma nova funcionalidade é implementada, seja de formamanual ou automática, forma esta que se utiliza de ferramentasespecializadas para tal.

13. Releases Curtos O XP tem como objetivo gerar um fluxo contínuo de valor para ocliente. Sendo assim, ele trabalha com releases curtos, ou seja, aequipe produz um conjunto reduzido de funcionalidades e colocaem produção rapidamente.

Tabela 1 – As treze práticas importantes que compõem o XP. [3].

31

2.4.2 Scrum

O Scrum, foi desenvolvido por Jeff Sutherland e sua equipe no inicio de 1990.Possui um padrão de processo em que ocorrem as tarefas de trabalho, chamado Sprint.Segundo [11], o Scrum consiste em um time, eventos, artefatos e regras. As regras sãoessenciais para criar equipes, eventos e artefatos juntos durante o projeto.

Neste modelo, são criados papéis para a equipe (Scrum Team), para o cliente(Product Owner) que constantemente participa do que está sendo desenvolvido, parao produto (Product) e suas respectivas funcionalidades a serem desenvolvidas (ProductBacklog) e para uma pessoa da equipe que será a responsável para gerenciar o processo deforma que tudo ocorra corretamente (Scrum Master), sempre promovendo a adaptação àmudanças.

O trabalho conduzido dentro de uma Sprint é adaptado ao problema em mãos, epodem ser frequentemente modificados pela equipe sem qualquer tipo de problema. Paraque isso aconteça, reuniões rápidas ocorrem diariamente a fim de que os membros daequipe apresentem problemas, palpites e qualquer tipo de troca de informação que sejarelevante ao processo.

Basicamente, ao final de cada Sprint são feitas reuniões mais detalhadas paraapresentar o que foi produzido durante a Sprint, bem como um feedback do ocorrido, e,com as experiências obtidas, planejar uma nova Sprint. Nessas reunições o cliente participapara ficar ciente do progresso feito.

Figura 3 – Componentes do Scrum. Figura retirada de: hubspot.com

32

2.5 Comparação de pontos principais entre as Métodologias Tra-dicionais e Ágeis

Ambos os tipos de métodologias possuem pontos fortes e que podem ser combina-dos a fim de estabelecer um PDS que melhor se adeque ao estilo da equipe, produzindoassim bons resultados. A tabela abaixo faz uma comparação entre os principais pontosdos dois tipos de modelos.

Tradicional Ágil

Premissas Funda-mentais

Sistemas são bem especifi-cáveis e pode ser construí-dos através de planejamentometiculoso e extensivo.

Software de alta qualidade eadaptativo pode ser desen-volvido por times pequenosque usam princípios de me-lhoria continua em design etestes, sendo baseados emfeedback rápidos e possíveismudanças.

Controle Centrado em processos. Centrado em pessoas.

Estilo da gestão Comando-e-controle. Liderança-e-colaboração.

Gestão do conheci-mento

Explícito. Tácito.

Atribuição de pa-péis

Individuais – favorizam es-pecialização.

Times autogeridos-encorajam troca de papéis.

Comunicação Formal. Informal.

Papel do cliente Importante. Crítico.

Ciclo do projeto Guiado por tarefas ou ativi-dades.

Guiado por funcionalidadesdo produto.

Modelo de desen-volvimento

Modelo de ciclo-de-vida(Cascata, espiral ou algumavariação destes).

Modelo de entrega evolu-tiva.

Estrutura ou formaorganizacional de-sejada

Mecânica (burocrática, comalta formalização).

Orgânica (flexível e partici-pativa, encorajando ação so-cial cooperativa).

Tecnologia Sem restrições. Favorece tecnologia orien-tada a objetos.

Tabela 2 – Tabela comparativa entre características das metodologias tradicionais e ágeis.[2].

33

Analisando a tabela acima, fica evidente concluir que as Metodologias Tradicionaisvisam o processo, a documentação, a formalidade e a individualidade, enquanto as Me-todologias Ágeis priorizam as pessoas, a adaptação à mudanças, uma comunicação maisinformal e a cooperação entre os membros da equipe.

Uma particularidade interessante é o papel do cliente em cada metodologia, nasMetodologias Ágeis o cliente está em constante contato com desenvolvimento do produto,contrastando bastante com as Metodologias Tradicionais.

2.6 Riscos, problemas e possíveis soluções para o desenvolvi-mento de software

Durante o PDS, vários problemas podem ocorrer, ainda que este tenha sido muitobem planejado, por isso a Engenharia de Software segue em constante estudo e avanço afim de minizar os mesmos.

Segundo [2], uma lista dos dez maiores itens de risco para software e possíveistécnicas para enfrentá-los seria:

Nota-se que pela Tabela 3, a prototipação seria uma técnica para enfrentar diver-sos itens de risco, sendo assim, o presente trabalho estudará técnicas e abordagens paradesenvolver um modelo que possa ser implantado em diferentes processos de desenvolvi-mento de software, a fim de minimizar tais riscos enfrentados e otimizar o processo comoum todo.

34

Item de risco Técnicas de gerenciamento de riscos

1. Perda de pessoas Elencar talentos que combinem com o trabalho; treina-mento cruzado; pré-seleção de pessoas-chave.

2. Prazos e orçamentos não-realísticos

Estimativa detalhada dos prazos e custos por várias fon-tes, desenvolvimento incremental; reuso de software; en-xugamento de requisitos.

3. Desenvolvimento das funçõeserradas de software

Análise organizacional; análise da missão; formulação deconceitos de operação; questionário com usuários; pro-totipapação; antecipação de manuais do usuário.

4. Desenvolvimento de interfacede usuário errada

Análise das tarefas; prototipação; cenários; caracteriza-ção do usuário (funcionalidade, estilo, carga de traba-lho).

5. "Gold plating"(ir além do es-forço útil)

Enxugamento de requisitos, prototipação, análise docusto-benefício, "deisgn to cost"(desenhar a custoótimo).

6. Onda contínua de requisiçõesde mudanças

Limiar para muita quantidade em mudanças; ocultaçãode informação; no desenvolvimento incremental, deferirmudanças nos últimos incrementos.

7. Perdas devido a componentesexternos

Benchmarking; inspeções; checagem de referências; aná-lise de compatibilidades.

8. Perdas devido a tarefas exter-nas

Checagem de referências; auditorias "pre-award"; con-tratos "award-fee"; design competitivo ou prototipação;construção em equipe.

9. Perdas devido ao desempenhoem tempo real

Simulação; benchmarking; modelagem; prototipação;instrumentação; configuração de cenários.

10. Problemas com capacidadescomputacionais

Análise técnica; análise do custo-benefício; prototipação;checagem de referências.

Tabela 3 – Tabela priorizada dos dez maiores itens de risco para software e técnicas paraenfrentá-los [2].

35

3 GAIA PROTÓTIPO: UM MODELO DE PROTOTIPAÇÃOPARA PROCESSOS DE DESENVOLVIMENTO DE SOFT-WARE

O GAIA Protótipo tem como objetivo descrever um modelo capaz de ser integradocom as variadas metodologias de PDS, utilizando como base a prototipação, de formaprática e categórica, a fim de minimizar os problemas enfrentados pelos PDS que resultamem gastos desnecessários, má qualidade do software, entre outros.

Na composição do modelo, fez-se o uso de duas metodologias, Scrum (Ágil) eEspiral (Evolucionária), unindo empíricamente os pontos positivos de cada modelo paraque o objetivo fosse atingido.

Vale ressaltar que, embora a prototipação possa ser utilizada como um modelo iso-lado, as ideias da técnica de prototipação também foram utilizadas no presente trabalho.Tais modelos e técnicas foram escolhidos visto que a combinação de seus componenteselicitariam um modelo capaz de ser integrado aos diversos modelos existentes.

A motivação para o presente trabalho se deu por um outro projeto em andamento,o qual consiste em desenvolver um aplicativo móvel de forma ágil, utilizando técnicas deprototipação e ferramentas para codificação que auxiliem todo o processo.

Figura 4 – GAIA Protótipo

A Figura 4 ilustra todas as fases do modelo, sendo que, cada vez passado pela etapade Desenvolvimento, o protótipo do sistema evolui, assim, é possivel que seja enviado aocliente um protótipo provisório funcional do sistema, enquanto, paralelamente segue o

36

desenvolvimento do produto final.

O Gaia Protótipo consiste de poucos processos, porém muito bem definidos, afim de torna-los atividades preditivas, eficientes e que vão amadurecendo em direção aoobjetivo. Também se faz necessária a etapa de Ánalise de Riscos, pois dessa forma, asdecisões para as próximas etapas são tomadas ponderando as diferentes alternativas. Taiscaracteríscas são encontradas também no modelo Espiral, segundo [2].

Por outro lado, o objetivo do modelo proposto no presente trabalho, é o software dealta qualidade adaptativo, podendo ser aplicado por times pequenos que usem princípiosde melhoria continua em design e testes, tratem o papel do cliente como imprescindívelno processo, baseados em feedback rápidos e possíveis mudanças. Segundo [2], tais carac-terísticas também estão presentes nas metodologias Ágeis, como por exemplo o Scrum.

3.1 Preparação

Na primeira fase do processo, denominada "Preparação", o objetivo é elicitar osrequisitos funcionais e não funcionais de tal forma que descrevam com fidelidade as neces-sidades do cliente, auxiliar o responsável pelo levantamento das funcionalidades a seremimplementadas a entender melhor o que esta sendo pedido pelo cliente e também validara plataforma e as tecnologias definidas pela equipe.

Figura 5 – Preparação

A Figura 5 retrata as seguintes etapas:

1. Levantamento de Requisitos: Nesta etapa, é estabelecida uma comunicação como cliente a fim de fazer o levantamento de requisitos do software.

37

2. Definição das Tecnologias: Aqui, a equipe define a plataforma alvo e as tecnolo-gias a serem utilizadas, podendo desenvolver um rápido Protótipo Teste de caráterdescartável, para testar na plataforma. Em seguida é desenvolvido o a primeiraversão do Protótipo de Interface de caráter evolutivo.

3. Verificação e Validação: Das etapas anterior, tem-se o Protótipo de Interface de-senvolvido com base no levantamento de requisitos realizado. Agora, este protótipoé levado para o cliente a fim de ser verificado e validado juntamente com o que setem de requisitos no presente momento, pois, empiricamente, percebe-se a maiorfacilidade e clareza que o cliente desenvolve para tratar das necessidades que visaem seu produto ao se deparar com uma candidata interface. Caso o Protótipo deInterface e os requisitos não sejam aprovados, repete-se a etapa anterior aplicandoas atualizações necessárias, caso contrário, começa então a próxima fase.

3.2 Planejamento

Esta fase é de suma importância para o processo como um topo, pois, a cadaiteração, para que o desenvolvimento ocorra da melhor maneira possível, o Planejamentodeve ser bem feito, com a Análise de Riscos, depois dividindo as equipes, distribuindo astarefas e Definindo as Sprints. Com um bom Planejamento, a Sprint tende a ocorrer semgrandes problemas.

Figura 6 – Planejamento.

A ilustração acima exemplifica as sequintes etapas:

1. Análise de Riscos: Esta etapa merece dedicação diferenciada, visto que este é omomento em que os riscos de decisões das etapas anteriores são analisados, riscos

38

que segundo [14] são definidos como eventos indesejados que têm consequênciasnegativas e a perda associada de um risco é chamada de impacto de risco. Alémdisso, o gerenciamento de riscos, cada vez mais vem sendo considerado como umadas principais tarefas dos gerentes de projetos [5].

2. Divisão da Equipe: Em seguida, a equipe é dividida de acordo com a necessi-dade do projeto, podendo ser também sub-divididas em várias equipes, porém, éimportante que uma pessoa de cada equipe seja o responsável por ela.

3. Distribuição de Tarefas: Os responsáveis de cada equipe se reunem a fim dedividir as tarefas, levando em consideração o conhecimento que possuem sobre acapacidade dos membros de sua equipe.

4. Definição das Sprints: Os mesmos responsáveis da etapa anterior também defi-nem o tempo aproximado necessário para cada etapa da Sprint e os horários que asreuniões acontecerão. Neste trabalho, a chamada Sprint consistirá a fase de Desen-volvimento, bem como suas tarefas a serem desenvolvidas de forma ágil.

3.3 Desenvolvimento

Como terceira fase, tem-se o Desenvolvimento e é em torno desta que todo o modelose projeta. Visando iterações rápidas e Reuniões Diárias provendo a troca de experiênciae cooperação entre os membros a equipe, atualizam-se as tarefas e ao fim de cada Sprint,atualiza-se também o protótipo até então desenvolvido.

Figura 7 – Desenvolvimento.

39

1. Codificação: Neste etapa, cada integrante da equipe possui tarefas pelas quaisestá responsável à desenvolver. Como um determinado período é definido na faseanterior, cada integrante deve fazer seu máximo a fim de atingir o objetivo, porémnão será penalizado caso algum imprevisto ocorra, afinal, lidar com mudanças eimprevisto é um dos focos deste modelo.

2. Reuniões Diárias: Ao término ou antes de iniciar uma etapa de Codificação, de-vem ser realizadas Reuniões Diárias, sendo que cada integrante do time tem umdeterminado tempo para falar o que desenvolveu, bem como as dificuldades queteve e o que não conseguiu desenvolver.

3. Troca de Experiências: Com base no que foi dito nas Reuniões Diárias, os inte-grantes devem conversar e trocar experiências a fim de resolver possíveis problemasencontrados ou melhorar determinados aspectos da codificação.

4. Atualização das Tarefas: A equipe faz a atualização do que foi realizado e oresponsável distribui as próximas tarefas.

5. Protótipo: Quando a Sprint atinge a duração estipulada na fase de Planejamento,a equipe deve apresentar um protótipo rápido, de caráter evolutivo, mas funcional,ou seja, um protótipo funcionando porém como parte do projeto, sendo atualizadoa cada Sprint.

40

3.4 Evolução

Nesta fase, o principal objetivo é envolver o cliente no projeto para obter um feed-back e assim evoluir o produto, sendo que após o Desenvolvimento, tem-se um protótipofuncionando porém de caráter evolutivo que será apresentado ao cliente para uma ve-rificação e validação do que foi desenvolvido. Paralelo à Evolução, mediante ao que foiacordado com o cliente, é possivel enviar um protótipo funcionando de versão provisóriaa fim de que seja colocado em operação porém com as devidas restrições.

Figura 8 – Evolução.

1. Verificação e Validação: Nesta etapa é estabelecido uma comunicação com ocliente, a fim de apresentar o protótipo de versão mais recente para que os requisitossejam verificados e validados.

2. Reunião: Uma reunião é feita com a equipe para que o feedback recebido anterior-mente direcione os integrantes para a próxima etapa.

3. Atualização das Tarefas: Após a Reunião, o responsável pela equipe faz a atu-alização do que foi realizado, aplicando as alterações necessária para adequar astarefas à qualquer tipo de mudança.

41

4 CONCLUSÃO

Ao analisar o cenário atual, constata-se que, as organizações sofrem mudanças atodo o momento, não diferente para as desenvolvedoras de softwares, destaca-se entãoa importância em adaptar os processos de desenvolvimento de software para que sejapossóvel lidar com as mudanças.

Neste sentido, o GAIA Protótipo se mostra um modelo relevante que foi desenvol-vido empiricamente, com fases e etapas bem definidas a fim de minimizar os problemasrecorrentes nos PDS utilizando como base técnicas de prototipação juntamente com aunião de práticas do modelo Espiral e do Scrum.

43

REFERÊNCIAS

[1] SOARES, M. dos S. Comparação entre metodologias ágeis e tradicionais para odesenvolvimento de software. INFOCOMP Journal of Computer Science, v. 3, n. 2,p. 8–13, 2004.

[2] ALMEIDA, G. A. M. d. Fatores de escolha entre metodologias de desenvolvimentode software tradicionais e ágeis. Tese (Doutorado) — Universidade de São Paulo,2017.

[3] TELES, V. M. Extreme programming. São Paulo: Novatec, 2004.

[4] FOSE 2014: Proceedings of the on Future of Software Engineering. New York, NY,USA: ACM, 2014. ISBN 978-1-4503-2865-4.

[5] PRESSMAN, R.; MAXIM, B. Engenharia de Software-8a Edição. [S.l.]: McGrawHill Brasil, 2016.

[6] PAETSCH, F.; EBERLEIN, A.; MAURER, F. Requirements engineering and agilesoftware development. In: WET ICE 2003. Proceedings. Twelfth IEEE InternationalWorkshops on Enabling Technologies: Infrastructure for Collaborative Enterprises,2003. [S.l.: s.n.], 2003. p. 308–313. ISSN 1080-1383.

[7] STANDARDIZATION, I. O. ISO 12207 (Standard for the InformationTechnology - Software Life Cycle Process). [S.l.], 2013. Disponível em:<http://www.iso.org/iso/catalogue_detail?csnumber=43447>. Acesso em:20.07.2017.

[8] SALIM, G. A. Guia de implantação de processos de gerenciamento de pessoaspara organizações de desenvolvimento de software. Universidade Estadual Paulista(UNESP), 2017.

[9] WEIMAR, E. et al. The influence of teamwork quality on software team performance.arXiv preprint arXiv:1701.06146, 2017.

[10] CHERUBIN, P. F. Estratégias de negócio em software-houses. Revista da FAE, v. 3,n. 2, 2017.

[11] LEI, H. et al. A statistical analysis of the effects of scrum and kanban on softwaredevelopment projects. Robotics and Computer-Integrated Manufacturing, Elsevier,v. 43, p. 59–67, 2017.

[12] BRITO, M. F. D. et al. Knowledge transfer in a management process for outsourcedagile software development. In: Proceedings of the 50th Hawaii InternationalConference on System Sciences. [S.l.: s.n.], 2017.

[13] NUNES, R. D. A implantação das metodologias ágeis de desenvolvimento desoftware scrum e extreme programming (xp): uma alternativa para pequenasempresas do setor de tecnologia da informação. ForScience, v. 4, n. 2, 2017.

[14] PFLEEGER, S. L. Engenharia de software: teoria e prática. [S.l.]: Prentice Hall,2004.

Apêndices

Anexos