• Nenhum resultado encontrado

2.4 Modelos de Referˆ encia

2.4.3 Modelos de Processo de Software

Corroborando com a afirma¸c˜ao de Villaz´on-Terrazas et al. (2011) que estabelece que os processos de publica¸c˜ao de dados conectados governamentais devem ter um ciclo de vida como os existentes na Engenharia de Software, e que devem ser de natureza incremental e iterativa, apresentaremos dois ciclos de vida (ou modelos de processo de software) com estas caracter´ısticas e que servir˜ao de referˆencia `a proposta apresentada nesta pesquisa.

Um modelo de processo de software ´e uma representa¸c˜ao abstrata de um processo de software. Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informa¸c˜oes parciais sobre o processo (SOMMERVILLE, 2007). Desta forma, cada modelo de processo de software define a sequˆencia com que as atividades ser˜ao executadas, quais as pessoas est˜ao envolvidas e quais os artefatos s˜ao gerados por cada atividade (CARRION; WERNER, 2013).

Cumpre destacar que na literatura de Engenharia de Software os modelos de pro- cesso de software tamb´em s˜ao denominados (i) ciclos de vida de software; (ii) paradigmas de processo de software ou (iii) modelos gen´ericos de software (SOMMERVILLE, 2007; PRESSMAN, 1995).

Contemplando os requisitos (incremental e iterativo) estabelecido por Villaz´on-Terrazas et al. (2011), apresentaremos dois modelos de processo projetados explicitamente para apoiar a itera¸c˜ao de processo apresentados em Sommerville (2007):

1. Entrega Incremental: A especifica¸c˜ao, o projeto e a implementa¸c˜ao de software s˜ao divididos em uma s´erie de incrementos desenvolvidos um de cada vez;

2. Desenvolvimento espiral: O desenvolvimento do sistema evolui em espiral a partir de um esbo¸co inicial at´e o sistema final.

2.4.3.1 Entrega Incremental

A entrega incremental ´e uma abordagem intermedi´aria entre outros dois paradigmas de desenvolvimento de software (cascata e evolucion´ario) que busca combinar as vantagens destes dois paradigmas. Neste modelo de processo, o cliente identifica, em linhas gerais, os servi¸cos a serem fornecidos pelo sistema, conforme exemplificado na Figura 19.

O desenvolvimento mediante este modelo de processo permite que o software seja desenvolvido em incrementos. Os incrementos priorit´arios s˜ao desenvolvidos inicialmente e de forma paralela, os requisitos dos pr´oximos incrementos s˜ao estabelecidos. Ao concluir o desenvolvimento de cada incremento, esta parte do software entra em opera¸c˜ao, ou seja, fica dispon´ıvel ao cliente. `A medida que novos incrementos s˜ao conclu´ıdos, estes s˜ao

Figura 19 – Modelo de processo de desenvolvimento incremental

Fonte: Sommerville (2007)

integrados aos j´a existentes, de tal forma que o software ´e aprimorado a cada incremento entregue (SOMMERVILLE, 2007).

2.4.3.2 Desenvolvimento em Espiral

O modelo de processo em espiral foi apresentado por Boehm (1986). Em vez de representar o processo de software como uma sequˆencia de atividades com alguma sa´ıda entre uma atividade e outra, o processo ´e representado como uma espiral. Cada loop (ciclo) na espiral representa uma fase do processo de software (SOMMERVILLE, 2007). Foi desenvolvido para abranger as melhores caracter´ısticas tanto do ciclo de vida cl´assico como da prototipa¸c˜ao, acrescentando, ao mesmo tempo, um novo elemento, a an´alise de riscos que falta a esses paradigmas. De acordo com Sommerville (2007), o modelo define quatro importantes setores representados em quadrantes, conforme t´opicos abaixo:

1. Defini¸c˜ao de objetivos: Definir os objetivos espec´ıficos de cada fase do projeto, com o estabelecimento de restri¸c˜oes sobre o produto e identifica¸c˜ao dos riscos. Permite a elabora¸c˜ao de um plano de gerenciamento do projeto;

2. Avalia¸c˜ao e redu¸c˜ao de riscos: ´E realizada uma an´alise detalhada dos riscos do projeto propondo solu¸c˜oes para cada um deles;

3. Desenvolvimento de valida¸c˜ao: Desenvolvimento do sistema ap´os a avalia¸c˜ao dos riscos. Dependendo dos tipos de risco, podem ser adotados processos de desenvolvi- mento distintos. Por exemplo: se os riscos de interface forem dominantes, sugere-se o uso da prototipa¸c˜ao;

4. Planejamento: O projeto ´e revisado gerando decis˜oes para o prosseguimento do pr´oximo loop da espiral. Se o projeto prosseguir, o planejamento ´e atualizado. A Figura 20 esclarece o desenvolvimento de software mediante o modelo de processo em espiral conforme (BOEHM, 1986):

Figura 20 – Modelo de processo de desenvolvimento em espiral proposto por Boehm

Fonte: Boehm (1986)

Complementarmente, Pressman (1995) apresenta uma vers˜ao simplificada da espiral, composta dos seguintes setores:

1. Planejamento: determina¸c˜ao dos objetivos, alternativas e restri¸c˜oes;

2. An´alise de riscos: an´alise de alternativas e identifica¸c˜ao/resolu¸c˜ao de riscos; 3. Engenharia: desenvolvimento do produto no “n´ıvel seguinte”;

4. Atualiza¸c˜ao feita pelo cliente: avalia¸c˜ao dos resultados da engenharia.

A Figura 21 esclarece o desenvolvimento de software mediante o modelo de processo em espiral conforme Pressman (1995):

Pressman (1995) entende que este modelo de processo tamb´em pode ser considerado como uma abordagem “evolucion´aria” `a engenharia de software, capacitando o desenvol- vedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa um prot´otipo (do modelo de processo prototipa¸c˜ao) como um mecanismo de redu¸c˜ao de riscos, mas, o que ´e mais importante, possibilita que o desenvolvedor aplique caracte- r´ısticas da abordagem de prototipa¸c˜ao em qualquer etapa da evolu¸c˜ao do produto. Outro benef´ıcio deste modelo ´e que ele mant´em a abordagem de passos sistem´aticos sugerida pelo ciclo de vida cl´assico, incorporando-a numa estrutura iterativa que reflete mais re- alisticamente o mundo real. O modelo espiral exige uma considera¸c˜ao direta dos riscos

Figura 21 – Modelo de processo de desenvolvimento em espiral proposto por Pressman

Fonte: Pressman (1995) adaptado de Boehm (1986)

t´ecnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problem´aticos.

2.4.3.3 SCRUM ´

E um modelo de desenvolvimento ´agil de software estabelecido por Jeff Sutherland nos anos 90. Tem como principais estrat´egias a defini¸c˜ao de times auto-organizados, progresso do desenvolvimento atrav´es de ciclos curtos para atingir metas espec´ıficas, conhecidos como Sprints, e requisitos de produtos organizados numa lista de itens, conhecido como “Product Backlog” (VARASCHIM, 2009).

O Scrum tem o progresso de desenvolvimento baseado em itera¸c˜oes de curto prazo. O primeira etapa dentro do Sprint consiste de uma reuni˜ao de planejamento (Sprint Plan- ning), onde o time (Scrum Team), em conjunto com o cliente (Product Owner ) define o que ser´a implementado na itera¸c˜ao, sendo responsabilidade do cliente realizar a priori- za¸c˜ao do trabalho a ser feito. Posteriormente, ´e desenvolvida a etapa de execu¸c˜ao, com detalhamento das tarefas necess´arias para implementar o que foi solicitado. Diariamente s˜ao realizadas reuni˜oes para averiguar o andamento do projeto.

Ao final do Sprint ´e realizada uma reuni˜ao para a valida¸c˜ao da entrega (Sprint Review ), onde o cliente e quem mais tiver interesse no produto pode verificar se o objetivo do Sprint foi atingido. Logo ap´os, ´e realizada apenas pelo time uma reuni˜ao (Sprint Retrospective) onde o Sprint ´e avaliado sob a perspectiva de processo, time ou produto, quais foram os acertos e os erros com o objetivo de melhorar o processo de trabalho.

A Figura 22 apresenta uma vis˜ao geral do ciclo de desenvolvimento utilizando o Scrum: Figura 22 – Modelo de processo de desenvolvimento Scrum

Fonte: Dispon´ıvel em <http://paulgestwicki.blogspot.com.br/2011/02/scrum-diagram-rfc.html>. Acesso em: 27 out. 2015

Al´em dos ciclos iterativos, um dos grandes benef´ıcios do SCRUM baseia-se nas revis˜oes per´ıodicas das atividades, al´em do estabelecimento de metas de curto prazo. Scrum ´e recomendado especialmente para projetos de software cujos requisitos n˜ao foram ou n˜ao podem ser estabelecidos previamente.