daniel vitor fim moreto desenvolvimento baseado … · desenvolvimento baseado no processo...

of 99 /99
DANIEL VITOR FIM MORETO DESENVOLVIMENTO BASEADO NO PROCESSO UNIFICADO: UMA PROPOSTA DO PROJETO CHECKFREELA UTILIZANDO O OPENUP Trabalho de Conclusão de Curso apresentado à Faculdade Católica Salesiana do Espírito Santo, como requisito obrigatório para obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. MSc. Otávio Lube dos Santos VITÓRIA 2014

Author: phamduong

Post on 27-Nov-2018

216 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

  • DANIEL VITOR FIM MORETO

    DESENVOLVIMENTO BASEADO NO PROCESSO UNIFICADO: UMA PROPOSTA DO PROJETO CHECKFREELA UTILIZANDO O OPENUP

    Trabalho de Concluso de Curso apresentado

    Faculdade Catlica Salesiana do Esprito

    Santo, como requisito obrigatrio para

    obteno do ttulo de Bacharel em Sistemas de

    Informao.

    Orientador: Prof. MSc. Otvio Lube dos Santos

    VITRIA

    2014

  • DANIEL VITOR FIM MORETO

    DESENVOLVIMENTO BASEADO NO PROCESSO UNIFICADO: UMA PROPOSTA DO PROJETO CHECKFREELA UTILIZANDO O OPENUP

    Trabalho de Concluso de Curso apresentado Faculdade Catlica Salesiana do Esprito Santo, como requisito obrigatrio para obteno do ttulo de Bacharel em Sistemas de Informao.

    Aprovado em _____ de ________________ de ____, por:

    ________________________________

    Prof. MSc Otvio Lube dos Santos - Orientador

    ________________________________

    A definir

    ________________________________

    A definir

  • Dedico a Deus, que me mostrou que tudo

    possvel;

  • AGRADECIMENTOS

    Primeiramente a Deus, por andar comigo por todos os caminhos e me apresentar

    uma vida de imensa paz.

    Ao meu orientador, pelas palavras certeiras.

    Aos meus pais, Marcide e Clia, pessoas a quem devo toda minha criao e

    ensinamentos que tenho comigo. Sem vocs, eu sinceramente no sei o que seria

    do meu caminho at aqui. Agradeo a Deus por de me dado a honra de crescer nos

    seus braos.

    minha irm Camila por sua preocupao to aparente. um grande presente pra

    mim, poder acompanhar seu crescimento e uma ddiva poder ter um lao to forte

    contigo.

    Ao meu amor, Junile (June), por me aguentar em dias to turbulentos e por

    escolher estar ao meu lado mesmo diante tantas minhas imperfeies. Mostra-me a

    cada dia, com suas qualidades e defeitos, que mulher com quem quero viver.

    galera do Ninjutsu, em especial o meu professor, mentor e amigo Tiago, por me

    guiar pelos caminhos virtuosos da arte marcial e da perseverana.

    A uma pessoa que me socorreu num momento em que precisei de ajuda: Paloma.

    Aos amigos Joo Peterli e Leandro Tagarro, dois grandes irmos com os quais Deus

    me presenteou. Pessoas com quem sempre pude contar e sabem reconhecer

    minhas faltas.

    E em meio a tantos colegas que passaram, agradeo ao grupo The Snowys,

    composto por mim, Alberto, Joo e Jorge: obrigado, amigos, por terem ficado.

  • Se voc no tem vergonha da primeira verso de seu produto, demorou demais para

    lanar.

    Reid Hoffman Cofundador do LinkedIn

  • RESUMO

    Com a crescente demanda de desenvolvimento de software, torna-se cada vez mais

    necessria a utilizao de metodologias de desenvolvimento geis para que o

    processo de desenvolvimento possa ser realizado levando em considerao a

    descoberta das reais necessidades do cliente e melhor compreenso do problema

    envolvido. Para pequenas equipes, metodologias como o RUP e o Scrum no so

    de fcil adaptao. Este trabalho apresenta uma proposta de desenvolvimento

    direcionado para pequenas equipes utilizando como base o modelo de ciclo de vida

    OpenUP, guiado pela Eclipse Foundation, e acrescido de conceitos da modelagem

    gil, com a utilizao do quadro-branco, e do Kanban, com a utilizao do CardWall,

    que ser utilizada para o desenvolvimento do projeto CheckFreela, um sistema

    voltado para a busca e contratao de profissionais autnomos com o acrscimo de

    uma agenda para que gesto do dias de trabalho do profissional e para otimizao

    da busca pelos clientes interessados.

    Palavras-chave: Processo unificado, desenvolvimento gil, OpenUP

  • ABSTRACT

    With the increasing demand of software development, it becomes increasingly

    necessary to use agile development methodologies for the development process can

    be carried out taking into account the discovery of the real needs of the customer and

    better understanding of the problem involved. For small teams, a methodology such

    as RUP and Scrum facing big teams are not easy to adapt. This work presents a

    development proposal directed to small teams using as the base model of the life

    cycle OpenUP, guided by the Eclipse Foundation, plus concepts of agile modeling,

    using the whiteboard, and Kanban, using CardWall of which will be used for the

    development of CheckFreela project, one facing the search and hiring freelancers

    with the addition of an agenda management system for day work of professional and

    to optimize the search for interested customers.

    Keywords: Unified process, agile development, OpenUP

  • LISTA DE FIGURAS

    Figura 1 - Iterao das fases do PU .......................................................................... 36

    Figura 2 Micro-incrementos, ciclos de vida de iterao e de projeto do

    OpenUP/Basic ........................................................................................................... 49

    Figura 3 - Fluxo de solicitao de servio ................................................................. 56

    Figura 4 - Card wall com Raias e Limite de Trabalho em Progresso (WIP) Explcito 61

    Figura 5 Modelos do carto do Card Wall .............................................................. 62

    Figura 6 - Card Wall do CheckFreela ........................................................................ 63

    Figura 7 Fluxo de desenvolvimento do CheckFreela ............................................. 65

    Figura 8 Pgina inicial para viabilidade do CheckFreela ........................................ 68

    Figura 9 Pgina de explicao detalhada do CheckFreela .................................... 69

  • LISTA DE TABELAS

    Tabela 1 OpenUP/Basic x Manifesto gil ............................................................... 43

    Tabela 2 Tabela de prioridade que ser adotado do CheckFreela ......................... 62

  • SUMRIO

    1 INTRODUO ........................................................................................ 23

    2 REFERENCIAL TERICO ...................................................................... 27

    2.1 A REVOLUO TECNOLGICA, A ERA DA INFORMAO E A

    SOCIEDADE ............................................................................................................. 28

    2.2 A CONTRATAO DO AUTNOMO E A SUA DIVULGAO PELA

    INTERNET ................................................................................................................ 30

    2.3 ANLISE DO AMBIENTE ........................................................................ 30

    2.4 O DESENVOLVIMENTO ITERATIVO ..................................................... 32

    2.5 O PROCESSO UNIFICADO .................................................................... 33

    2.5.1 Caractersticas do PU ........................................................................... 34

    2.5.1.1 Guiado por casos de uso ......................................................................... 35

    2.5.1.2 Centrado na arquitetura ........................................................................... 35

    2.5.1.3 Iterativo e incremental ............................................................................. 35

    2.5.2 Fases do Processo Unificado ............................................................... 36

    2.5.2.1 Concepo .............................................................................................. 36

    2.5.2.2 Elaborao .............................................................................................. 37

    2.5.2.3 Construo .............................................................................................. 37

    2.5.2.4 Transio ................................................................................................. 38

    2.5.3 O Manifesto gil .................................................................................... 38

    2.5.4 Lean Software Development ................................................................. 38

    2.5.4.1 Os cinco princpios da Lean Thinking ...................................................... 39

    2.5.4.2 O Lean Thinking aplicado ao desenvolvimento de software .................... 40

    2.5.5 Processo Unificado gil ....................................................................... 41

    2.6 A METODOLOGIA GIL OPENUP ......................................................... 41

    2.6.1 A origem do OpenUP ............................................................................ 42

  • 2.6.2 Caractersticas e princpios ................................................................. 42

    2.6.3 Papis do OpenUP ................................................................................ 43

    2.6.3.1 Papis Bsicos ....................................................................................... 44

    2.6.3.2 Papis de Implantao ........................................................................... 45

    2.6.3.3 Papis de Ambiente ................................................................................ 45

    2.6.4 Disciplinas ............................................................................................. 46

    2.6.4.1 Requisitos ............................................................................................... 46

    2.6.4.2 Anlise e projeto ..................................................................................... 46

    2.6.4.3 Implementao ....................................................................................... 47

    2.6.4.4 Testes ..................................................................................................... 47

    2.6.4.5 Gerncia de projeto ................................................................................ 48

    2.6.4.6 Gerncia de configurao e mudanas .................................................. 48

    2.6.5 reas de Contedo do OpenUP ........................................................... 49

    2.6.5.1 Ciclo de vida do projeto........................................................................... 49

    2.6.5.2 Ciclo de vida da iterao ......................................................................... 50

    2.6.5.3 Micro-incrementos .................................................................................. 50

    3 METODOLOGIA ..................................................................................... 53

    4 ESTUDO DE CASO: DESENVOLVIMENTO DO CHECKFREELA UTILIZANDO OPENUP ............................................................................................ 55

    4.1 IDEALIZAO DO CHECKFREELA ...................................................... 55

    4.1.1 Visitas e propostas de custo ............................................................... 55

    4.2 O PRIMEIRO PROJETO......................................................................... 56

    4.3 O PROJETO EM CASCATA ................................................................. 57

    4.4 A ADAPTAO DA DOCUMENTAO PROPOSTA PELO OPENUP AO

    CASO CHECKFREELA ............................................................................................ 58

    4.4.1 A adoo da modelagem gil ............................................................... 59

    4.4.1.1 Modelagem no quadro-branco ................................................................ 59

  • 4.4.2 Adoo de conceitos do Kanban ......................................................... 60

    4.4.2.1 Criao do Card Wall .............................................................................. 60

    4.4.2.2 A Lista de Itens de Trabalho e o Card Wall ............................................. 62

    4.4.2.3 O WIP (Work In Progress) ....................................................................... 63

    4.4.2.4 O desenho do Card Wall para o CheckFreela ......................................... 63

    4.5 A CONCEPO DO CHECKFREELA COM O OPENUP ....................... 64

    4.5.1 O fluxo proposto para o projeto ........................................................... 64

    4.5.2 Realizando o teste de viabilidade ........................................................ 68

    4.5.3 Aproximando a comunicao com o usurio do sistema web .......... 69

    4.5.3.1 Utilizao do e-mail ................................................................................. 70

    4.5.3.2 Utilizao de um meio informal ................................................................ 70

    4.5.4 A primeira parte a ser entregue ............................................................ 71

    5 CONCLUSO ......................................................................................... 73

    5.1 TRABALHOS FUTUROS......................................................................... 74

    REFERENCIAS ......................................................................................................... 77

    APNDICE A DECLARAO DE ESCOPO DO PROJETO CHECKFREELA .... 83

    APNDICE B DIAGRAMA DE CASO DE USO DO CHECKFREELA .................. 85

    APENDICE C DIAGRAMA DE CLASSES DE ANLISE DO CHECKFREELA .... 87

    APENDICE D DIAGRAMA DE CLASSES DE PROJETO DO CHECKFREELA .. 89

    APENDICE E DESCRIO DE CASOS DE USO EFETUAR CADASTRO DO CHECKFREELA ....................................................................................................... 91

    APENDICE F DESCRIO DE CASOS DE USO PROMOVER-SE DO CHECKFREELA ....................................................................................................... 93

    APENDICE G DESCRIO DE CASOS DE USO BUSCAR PROFISSIONAIS DO CHECKFREELA ................................................................................................. 95

    APENDICE H DIAGRAMA DE ATIVIDADES PARA CADASTRO DO USURIO DO CHECKFREELA ................................................................................................. 97

  • APENDICE I DIAGRAMA DE ATIVIDADES DA PROMOO DE PROFISSIONAIS DO CHECKFREELA ................................................................... 99

  • 23

    1 INTRODUO

    Atualmente h uma preocupao na rea de desenvolvimento de softwares gerada

    pelos ndices de cancelamento dos projetos. Segundo vila e Spnola (2010),

    apenas 16,2% dos projetos so finalizados com sucesso, ou seja, cobre todas as

    funcionalidades em tempo e dentro do custo previsto.

    O crescimento das empresas que atuam no ramo de desenvolvimento de software,

    impulsionado pela evoluo tecnolgica e disponibilidade de mercado, provocou o

    aumento de projetos sem sucesso.

    Os motivos destes fracassos, normalmente so: atraso da entrega; questes que

    envolvem as funcionalidades do software; grande variao de custos gerados ao

    cliente; ou cancelamentos durante o fornecimento, dentre diversos outros.

    Estes fracassos tm aumentado devido a questes bsicas que deixam de ser

    cumpridas, que envolvem a qualidade do produto que gerado ao cliente, as

    funcionalidades necessrias ao cliente para gerao de valor ao seu negcio e as

    estimativas mais aprofundadas principalmente de custos que sero geradas ao

    cliente.

    Em geral, estes problemas tm ocorrido devido falta de conhecimento das reais

    necessidades do cliente. Uma empresa de desenvolvimento no obrigada a

    compreender o cliente quer naquele momento, mas ajuda-lo a entender como seu

    problema ser resolvido.

    H momentos que nem mesmo os clientes compreendem qual o seu verdadeiro

    problema. Ou seja, antes de estudar de forma aprofundada a soluo para um

    problema incerto, um projeto de desenvolvimento de software deve se aprofundar no

    conhecimento do problema para que, ao fim do projeto, a melhor soluo possvel

    tenha sido gerada.

    Este problema tem acontecido com as Startups devido a falta de contato prximo

    com o cliente final e principalmente pela sua atuao num ambiente de extrema

    incerteza.

  • 24

    Segundo Belissa (2014), Para o gestor [Vincius Machado, gestor da Associao

    Brasileira de Startups], um dos principais motivos da falncia das startups a falta

    de validao do produto no mercado..

    Hoje, startups tm boas ideias a serem lanadas no mercado, mas enfrentam

    problemas para analisar e validar o que ser fornecido.

    No geral, precisam de algo que lhe fornea um entendimento daquilo que est

    propondo e como adaptar-se ao que realmente necessrio.

    Na tentativa de minimizar os problemas enfrentados pelas startups, este trabalho

    prope a utilizao de um processo de desenvolvimento gil, que tem o foco na

    reduo de riscos.

    O processo adotado foi o OpenUP, que direcionado para pequenas equipes

    atravs da reduo da quantidade de papis exercidos durante o andamento do

    desenvolvimento de software.

    Visando adaptar o OpenUP para o projeto que ser proposto neste trabalho, foram

    adotados caratersticas da modelagem gil e do controle de produo Kanban,

    criada pela Toyota.

    Este trabalho tambm apresentar uma proposta de desenvolvimento gil voltado

    para um projeto especfico: o CheckFreela.

    O CheckFreela uma ideia que foi concebida pelo autor deste trabalho e que

    passou por uma tentativa de desenvolvimento anterior e fracassou.

    O objetivo deste trabalho a apresentao de uma proposta de desenvolvimento

    gil baseado no OpenUP, para o desenvolvimento da ideia do CheckFreela.

    Para atingir este objetivo, ser necessrio realizar:

    Primeiramente, verificar na literatura, referncias voltadas para a

    caracterizao da ideia do CheckFreela e o contexto em que est envolvido.

    Posteriormente, a verificao de referncias que expliquem o processo

    unificado que ser adotado no projeto, para que seja formada uma

    conscincia a respeito da importncia da iteratividade no processo de

    desenvolvimento.

  • 25

    O terceiro passo ser a realizao de pesquisas sobre o modelo de ciclo de

    vida OpenUP para que sejam analisados os pontos fortes e fracos e seja

    adaptado conforme a necessidade do projeto.

    Aps a pesquisa sobre o OpenUP, ser apresentada a ideia por trs do

    projeto CheckFreela e o que visa atingir na sociedade.

    Posteriormente, a apresentao da ideia, onde ser exposto como ocorreu a

    primeira tentativa de desenvolvimento do projeto que fracassou.

    O passo seguinte ser propor uma adaptao do OpenUP, acrescentando

    conceitos do controle de produo Kanban e da modelagem gil.

    E, por ltimo, ser mostrado como ser utilizado a adaptao proposta pelo

    OpenUP no processo de desenvolvimento do CheckFreela.

  • 26

  • 27

    2 REFERENCIAL TERICO

    Diversos so os tipos de profissionais autnomos existentes no mercado e as

    pessoas que desejam seus servios.

    O site Guia Trabalhista diferencia um trabalhador autnomo de um empregado:

    [...] AUTNOMO todo aquele que exerce sua atividade profissional sem vnculo empregatcio, por conta prpria e com assuno de seus prprios riscos. A prestao de servios de forma eventual e no habitual. [...] EMPREGADO toda pessoa fsica que presta servios de natureza no eventual a empregador, sob a dependncia deste e mediante salrio. (TRABALHADOR..., [entre 2002 e 2014])

    Diferente de um trabalhador empregado, o autnomo tem seus prprios esforos

    para sustento e depende da divulgao da sua imagem para que possa alcanar

    seus clientes. No site da Asaas, empresa que detm o primeiro software nacional

    responsvel por auxiliar a gesto de assinaturas e cobranas recorrentes, existe

    dicas de como um profissional autnomo pode captar novas possibilidades de

    trabalho. E estas dicas so:

    Ampliar a rede de contatos uma excelente medida para atrair novos clientes. Esse mtodo visa estabelecer e fortalecer as relaes com outros profissionais e empresas. [...] tenha uma lista completa de fornecedores, faa parcerias para oferecer vantagens aos clientes e esteja disposto a trocar experincias com seus contatos. Assim voc ficar a par das novidades do mercado e sempre atualizado no que diz respeito ao seu ramo de atuao [...] Busque essa visibilidade atravs das redes sociais, sempre aliando contedo de qualidade, imagens atrativas e a abordagem de assuntos que interessam ao pblico. Essa uma das mais baratas e eficazes mdias no segmento corporativo.[...] um cliente fidelizado amplifica a propaganda boca a boca, faz indicaes e porta-voz dos diferenciais do negcio. Invista em prestar os melhores servios possveis, oferea um atendimento personalizado, faa um acompanhamento ps-venda/ps-atendimento e busque melhorias constantes. [...] No basta ter um bom atendimento, qualidade nos servios e preo competitivo, preciso oferecer aos clientes facilidade na hora de efetuar o pagamento. Isso faz toda diferena! [...] Oferea a possibilidade do cliente pagar de forma parcelada, atravs do carto ou do boleto. (ASAAS, 2013)

    Observa-se a contratao de prestadores de servio autnomos est alavancando.

    Tanto que, segundo Ribeiro (2010), O setor de servios respondeu, por 68,5% do

    Produto Interno Bruto. Nesta informao, pode-se filtrar a ampliao da utilizao

    de mo de obra independente.

    O secretrio de Comrcio e Servios do ano de 2010, Edson Lupatini, disse, na

    mesma reportagem, que o setor de servios o que mais cresce, aqui e l fora, a

    ponto de representar cerca de 80% do PIB em pases como Estados Unidos, Reino

  • 28

    Unido e Alemanha, dentre outros (RIBEIRO, 2010). E ainda segundo escrito no

    prprio site:

    [...] para impulsionar ainda mais o setor, ele anunciou que o Dirio Oficial da Unio dever publicar [...] o decreto de criao da Nomenclatura Brasileira de Servios, elaborada em conjunto com a Secretaria da Receita Federal (SRF) e com o Instituto Brasileiro de Geografia e Estatstica (IBGE). (RIBEIRO, 2010).

    Porm, segundo o site do Ministrio do Desenvolvimento, Indstria e Comrcio

    Exterior (BRASIL, 2012):

    [...] a Nomenclatura Brasileira de Servios, Intangveis e outras Operaes que Produzam Variaes no Patrimnio (NBS), bem como as suas respectivas Notas Explicativas (NEBS), foi instituda pelo Decreto Presidencial n 7.708, de 02 de abril de 2012 [ou seja, dois anos aps o anncio do ex-secretrio Edson Lupatini].

    Mesmo passados dois anos para que fosse instituda a NBS, j havia um interesse

    em padronizar a nomenclatura de servios devido a crescente demanda que j havia

    no mercado. Vieira (2013), mostra que esta demanda continua crescendo quando

    cita que as escolas do grupo mineiro Bom Pastor formaram 1 mil pessoas no ano

    passado nos cursos de cabeleireiro, manicure, esttica facial e corporal.

    Com essa crescente oferta e procura de mo de obra e a grande utilidade da

    Internet, surge tambm a necessidade da adoo de novos paradigmas de

    contratao de servios sem a burocracia do contato direto com os prestadores de

    servio e a busca excessiva destes profissionais.

    2.1 A REVOLUO TECNOLGICA, A ERA DA INFORMAO E A SOCIEDADE

    Segundo o Castells (2005, p. 17):

    O nosso mundo est em processo de transformao estrutural desde h duas dcadas. um processo multidimensional, mas est associado emergncia de um novo paradigma tecnolgico, baseado nas tecnologias de comunicao e informao, que comearam a tomar forma nos anos 60 e que se difundiram de forma desigual por todo o mundo.

    E diz ainda que:

    Vivemos num perodo histrico caracterizado como a era da informao, onde nos deparamos com a possibilidade de interao com novos aparatos tecnolgicos, que estabelecem novas formas de comunicao entre as pessoas e das pessoas com coisas. Estamos vivenciando uma revoluo, que tem como elemento central a tecnologia da informao e da comunicao. (CASTELLS, 2005, p. 227)

  • 29

    Desde o ano de 1994 que se tem percebido o grande crescimento da Internet, como

    mostrou, na poca, uma reportagem de escrita por Barreira (1994) divulgada na

    revista Super Interessante:

    No lugar da massificao em que uma matriz serve igualmente a todo mundo, surge agora a personalizao. Exemplo: uma companhia japonesa capaz de produzir 11 milhes de modelos de bicicleta, de acordo com o gosto do fregus que recebe a encomenda em 24 horas. A bike pessoal leva em conta idade, peso, altura e estilo de vida do comprador, e custa s 10% a mais que um modelo comum. Imagine essa tendncia em tudo que o cerca. Vai ser assim. A tecnologia da informao criou uma economia totalmente nova, diz Walter B. Wriston, o principal executivo do Citicorp. Ela to diferente da economia industrial quanto a economia industrial foi diferente da agrcola. Desceremos do bonde e passaremos ao que o professor William Miller, da Universidade de Stanford, chama de economia da escolha, na qual o consumo pautado pela histria de vida do cliente e o produto tem alta qualidade e sabor individualizado. [...] A riqueza vai mudar de mos. Os dois maiores negcios do planeta, hoje, so as indstrias do petrleo e a automobilstica. Daqui a dez anos ser a indstria da informao e do conhecimento. Quem vai permitir isso a digitalizao. Tudo imagens em movimento, sons e textos pode ser transformado em dgitos binrios, em infinitas combinaes de 0 e 1. Com a ajuda de fibras pticas e satlites, esses dgitos binrios, ou bits, podem ser transportados para qualquer lado. Esse caminho foi batizado de super-rodovia da informao.

    Como perceptvel, mesmo h 20 anos, j era esperado o que est acontecendo no

    mundo de hoje.

    De acordo com Ugarte ([2005?], p. 05, grifo do autor):

    Chegamos no sculo XXI, a poca da big science, da tecnocincia, que desenvolveu segundo Morin (2001), poderes titnicos. As pesquisas determinam as relaes de poder, hoje na mo de empresas globalizadas que submetem o Estado, que por sua vez controla as universidades e portanto, as pesquisas. A acelerao das transformaes da sociedade contempornea a partir dos ltimos cinquenta anos est de tal ordem, que podemos falar em mais uma Revoluo, desta vez, da informao ou do conhecimento. Essas transformaes atingem de maneira brutal o mundo do trabalho e do corpo: alta competitividade, desaparecimento de vrias funes e de papis, com a alta tecnologia. Alto nvel de desemprego com tendncias crescentes em todo o mundo, dado que a criao de empregos no supre a entrada de novos trabalhadores no mercado.

    Poucos anos antes de 2000, tendo como crescente meio de comunicao a

    televiso, acreditava-se que este meio seria o futuro at que os consumidores

    resolveram investir na compra de um computador pessoal, onde pudesse conectar-

    se Internet. Naquela poca j se acreditava que no ano de 2005 haveria uma

    imensa utilizao da Internet (interligando cerca de 720 milhes de usurio em mais

    de 150 pases), que antes era limitada s universidades e rgos governamentais.

    Nesta poca houve uma grande exploso da utilizao da Internet, onde o acesso

    requeria apenas um computador pessoal. (CHURCHILL e PETER, 2000).

  • 30

    Lisboa ([entre 2005 e 2014], p.10), aborda que:

    A Sociedade da informao, tambm denominada de sociedade do conhecimento, expresso utilizada para identificar o perodo histrico a partir da preponderncia da informao sobre os meios de produo e a distribuio dos bens na sociedade que se estabeleceu a partir da vulgarizao das programaes de dados utiliza dos meios de comunicao existentes e dos dados obtidos sobre uma pessoa e/ou objeto, para a realizao de atos e negcios jurdicos. [...] A era da informao no apenas um slogan, mas um fato; a economia baseada no conhecimento , realmente, uma nova economia, com novas regras, exigindo novas maneiras de fazer negcios.

    Por fim, Pereira Neto (2006, p. 19) cita sobre a importncia da Internet:

    O oceano de informao em que navegamos muito vasto e suportado por mltiplos suportes e mltiplas linguagens. A Internet um exemplo de agregao dessas linguagens, o que exige novas competncias, no sentido de fazer a j referida gesto criativa da informao, para que seja possvel a produo de sentido e a construo de conhecimento, sob pena de sermos atingidos pela ansiedade.

    2.2 A CONTRATAO DO AUTNOMO E A SUA DIVULGAO PELA

    INTERNET

    Apenas um site que propicie aos clientes um portflio do profissional, talvez no seja

    suficiente para a atualidade. preciso gerar uma facilidade e comodidade maior.

    Tanto tem sido a gama de pessoas que realizam comprar pela Internet que no ano

    de 2000 foi fundada a E-Bit, uma empresa focada fornecimento de informaes e na

    certificao de lojas virtuais.

    Segundo Oliveira (2012) Para 68% dos internautas brasileiros, o preo o que mais

    chama ateno nas compras on-line, enquanto que para 56%, a comodidade o

    que mais motiva a realizar compras pela internet..

    2.3 ANLISE DO AMBIENTE

    Segundo Churchill e Peter (2000, p. 26):

    Os profissionais de marketing [e os inovadores] devem examinar todas as dimenses do ambiente externo. As informaes resultantes podem ajuda-los a identificar as oportunidades para servir melhor seus mercados, criando valor superior. A anlise tambm pode identificar ameaas capacidade de uma organizao em manter sua vantagem competitiva, sobreviver e

  • 31

    prosperar. O ambiente externo afeta no s o que as organizaes podem ou devem fazer, mas tambm o comportamento de consumidores e compradores organizacionais. O ambiente externo influencia como esses compradores avaliam o valor das trocas que realizam. [...] A anlise ambiental envolve a busca de mudanas que levem a oportunidades ou ameaas a uma organizao. Ela responde perguntas como: com que frequncia a famlia mdia janta ou almoa fora? Que leis podem afetar a escolha de determinada embalagem? A demanda por espao em escritrios tende a aumentar? Os concorrentes esto planejando introduzir um aparelho de fax com mais recursos ou qualidade superior?

    Para gerar um novo paradigma, seria necessrio unir a contratao de profissionais

    a um meio que fosse bem aceito pela sociedade e pudesse conceder aos

    contratantes, conforto e confiana sem a necessidade de deslocamentos.

    A Internet um desses meios. Uma quantidade crescente de pessoas tm recorrido

    ela para aquisio de produtos. Tanto que, Segundo Vanique (2012), em

    reportagem do site Jornal Hoje, Pesquisa divulgada nesta quinta-feira (23) pela

    Fecomercio de So Paulo mostra que quase 63% dos paulistanos fazem compras

    pela internet, crescimento de 11 pontos percentuais em relao ao ano passado..

    A unio destes dois pontos, o aumento da prestao de servios e do uso da

    Internet, j existe, conforme pode ser visto no site www.recomind.net.br da empresa

    Buscap ou no da empresa GetNinjas (www.getninjas.com.br).

    Peter e Churchil (2000, p. 48, grifo do autor), em sua anlise ao ambiente

    competitivo dizem que:

    raro que uma organizao seja a nica fornecedora de um determinado produto ou servio. [...] Essas atividades referem-se ao ambiente competitivo, ou seja, todas as organizaes que poderiam potencialmente criar valor para os clientes de uma organizao.

    Dificilmente haver apenas uma organizao para um determinado produto ou

    servio. E embora as organizaes dos citados sites tenham notado que a unio

    entre o autnomo e a Internet pode dar certo, eles fraquejam em alguns pontos

    segundo nossa analise.

    O auxlio gerncia de horrios dos prestadores de servio;

    A busca, pelos contratantes, por profissionais que tenham determinados

    horrios vagos;

    A divulgao de pacotes de servios customizados pelos prestadores de

    servio;

  • 32

    Formas de anlise dos prestadores de servio para que os contratantes

    possam escolher de que forma estabelecero usa confiana. Por exemplo,

    um selo que concedido apenas ao profissional que tiver mais de cinco anos

    de experincia comprovada na rea;

    Anlise sobre o cliente que est solicitando os servios, pois profissionais

    tambm podem se frustrar com clientes;

    Gerenciamento do pagamento do servio aos prestadores de servio;

    Nota-se, ento, que este ainda um mercado limitado simples divulgao de perfis

    dos profissionais com pequena anlise de recomendao.

    Ainda assim, torna-se necessrio a utilizao de uma metodologia de

    desenvolvimento gil para que uma verso possa ser utilizada e verificada se a atual

    soluo atende s necessidades dos usurios.

    2.4 O DESENVOLVIMENTO ITERATIVO

    Conforme diz Torres (2012, p.86):

    Quanto mais tempo voc demorar para colocar seu produto na rua, mais tempo voc vai demorar para aprender com pessoas reais se voc est no caminho certo. E pior, mais passos voc certamente estar dando na direo errada. Voc s vai saber se o produto web que voc fez realmente resolve o problema de algumas pessoas se essas pessoas usarem seu produto. Quanto mais tempo demorar para isso acontecer, mais tempo vai demorar para saber se seu produto ou no a soluo do problema.

    Alm da forte necessidade de um lanamento rpido, ainda h um problema descrito

    por Pressman (2006, p. 59):

    Na economia moderna, frequentemente difcil ou impossvel prever como um sistema baseado em computador (por exemplo, uma aplicao com base na Web) evoluir com o passar do tempo. Condies de mercado mudam rapidamente, necessidades dos usurios finais evoluem e novas ameaas de competio emergem sem alerta.

    Considerando a abordagem de Torres e o problema de Pressman, torna-se forte a

    necessidade de um contato mais prximo os clientes que utilizaro o sistema para a

    soluo seja encontrada de forma a suprir suas reais necessidades.

  • 33

    Prope-se, ento, a utilizao de uma metodologia de desenvolvimento iterativo

    proposto pelo Processo Unificado (Unified Process UP), adotando uma forma de

    processo gil.

    O Processo Unificado, embora seja um processo que tenha suas fases

    estabelecidas, pode ser realizado com ciclo de vida gil, onde sero gerados poucos

    artefatos e pouca burocracia estar envolvida no processo (WAZLAWICK, 2011, p.

    05).

    ENGHOLM JUNIOR (2011, p. 61), cita ainda como uma das vantagens do processo

    unificado [...] a utilizao do Fast Tracking em projetos de software, o que uma

    tcnica de gerenciamento de projetos que objetiva finalizar o projeto no menor

    tempo possvel, paralelizando atividades que possam ocorrer simultaneamente,

    tornando-o uma excelente ferramenta para auxiliar no desenvolvimento de um

    sistema que precisa de entregas rpidas.

    2.5 O PROCESSO UNIFICADO

    Para explicar o significado do Processo Unificado, necessrio explicar a sua

    origem e o contexto de desenvolvimento de precedeu a sua idealizao.

    Segundo Wazlawick (2013, p.75):

    O Processo Unificado (UP ou Unified Process) foi criado por trs importantes pioneiros da orientao a objetos nos anos 1990 (Jacobson, Booch & Rumbaugh, 1999), sendo resultado de mais de 30 anos de experincia acumulada em projetos, notaes e processos.

    Numa poca onde havia vrios processos prescritivos, o Processo Unificado (PU)

    [JBR99] surgiu como um processo iterativo popular para o desenvolvimento de

    software visando construo de sistemas orientados a objetos. (LARMAN, 2007,

    p. 46).

    O Processo Unificado surgiu como uma necessidade adoo de novos conceitos

    para que o processo de desenvolvimento de softwares no tivesse todo o peso de

    documentao dos processos prescritivos, onde a soluo fosse trabalhada de

    forma gradativa.

    Pressman (2006, p. 72) confirma quando aborda que:

  • 34

    Nos ltimos 30 anos, uma grande variedade de mtodos e notao para modelagem de engenharia de software foi proposta para anlise e projeto (tanto arquitetural quanto em nvel de componente). Esses mtodos tm mrito significativo, mas mostraram-se difceis de aplicar e de manuteno desafiadora (ao longo de vrios projetos). Parte do problema o "peso" desses mtodos de modelagem. Com isso, queremos dizer: o volume da notao exigido, o grau de formalismo sugerido, o tamanho dos modelos para projetos grandes e a dificuldade em manter o modelo medida que as modificaes ocorrem.

    Para Jacobson (apud CALADO, 2007, p. 11), o processo unificado (Unified

    Process-UP) de desenvolvimento de software conjunto de atividades necessrias

    para transformar requisitos do usurio em um sistema de software. Larman (2007,

    p. 46, grifo do autor) complementa que:

    O PU combina as melhores prticas comumente aceitas, como ciclo de vida iterativo e desenvolvimento guiado por risco [...]. O PU usado como um processo-exemplo dentro do qual so exploradas a anlise de requisitos e a A/POO [Anlise e Projeto Orientado a Objetos].

    Embora seja citado como um processo exemplo, o UP muitas vezes se confunde

    com o RUP (Rational Unified Process), pois foi o primeiro modelo de ciclo de vida

    que foi construdo a partir dos princpios e pelos mesmos idealizadores do UP, que

    na poca atuavam na empresa Rational. Sommerville (apud FALBO, 2014, p. 15),

    confirma e explica o UP quanto cita que:

    O Modelo do Processo Unificado, muitas vezes referenciado como RUP (Rational Unified Process), um modelo de processo bastante elaborado, que procura incorporar elementos de vrios dos modelos de processo anteriormente apresentados, em uma tentativa de incorporar as melhores prticas de desenvolvimento de software, dentre elas a prototipao e a entrega incremental.

    O PU, como qualquer outro processo, tem como foco a entrega de um software com

    base em requisitos do usurio. Porm, por ser iterativo e evolutivo, mais malevel

    s mudanas.

    Em vez tentar combater a mudana atravs de uma especificao extensa e

    esttica, o desenvolvimento iterativo e evolutivo aceita a adaptao e a mudana

    como inevitveis e essenciais (LARMAN, 2007).

    2.5.1 Caractersticas do PU

    O processo unificado possui trs caractersticas essenciais: guiado por casos de

    uso, centrado a arquitetura e iterativo e incremental.

  • 35

    2.5.1.1 Guiado por casos de uso

    Esta caracterstica no diz respeito a casos de uso como modelagem, mas como

    funcionalidade, ou seja, o PU tem como foco as funcionalidades do sistema a ser

    desenvolvido.

    Segundo WAZLAWICK (2013, p. 76), O caso de uso um processo compreendido

    do ponto de vista do usurio. Para o UP, o conjunto de casos de uso deve definir e

    esgotar toda a funcionalidade possvel do sistema.

    2.5.1.2 Centrado na arquitetura

    O objetivo final de um projeto de desenvolvimento de software a entrega de

    sistema estvel que atenda s reais necessidades do cliente.

    O PU tem como objetivo, o desenvolvimento de arquitetura slida para o sistema a

    ser entregue, mas sem perder o foco nas funcionalidades que precisam ser criadas.

    Conforme diz Wazlawick (2013, p. 76), A arquitetura, inicialmente, pode ser

    compreendida como o conjunto de classes, possivelmente agrupadas em

    componentes, que realizam operaes definidas pelo sistema..

    No UP, cara iterao que ocorre deve haver a evoluo da arquitetura, de modo a

    incluir as funcionalidades aprendidas durante a anlise dos casos de uso.

    (WAZLAWICK, 2013).

    2.5.1.3 Iterativo e incremental

    Segundo Wazlawick (2013, p. 77):

    [...] o UP preconiza o desenvolvimento baseado em ciclos iterativos de durao fixa, em que, a cada iterao, a equipe incorpora arquitetura as funcionalidades necessrias para realizar os casos de uso abordados no ciclo.

  • 36

    Pode-se dizer que esta a caracterstica inerente ao processo unificado responsvel

    por proporcionar a adaptabilidade mudana de requisitos, visto que a cada nova

    iterao, novas funcionalidades sero analisadas e desenvolvidas.

    2.5.2 Fases do Processo Unificado

    Como um processo-exemplo, o Processo Unificado composto por fases, que so

    seguidas no decorrer do processo de desenvolvimento de software. No decorrer das

    iteraes, h modificao das fases, podendo cada fase possuir uma ou mais

    iteraes, como mostra a Figura 1.

    Figura 1 - Iterao das fases do PU

    Fonte: Artigo Introduo ao Processo Unificado de Christian Cleber Masdeval Braz

    O UP possui quatro fases onde so encaixadas as diversas iteraes. Sendo:

    concepo, elaborao, construo e transio.

    2.5.2.1 Concepo

    Segundo Wazlawick (2011, p. 05, grifo do autor), A fase de concepo, denominada

    inception em ingls, a primeira fase do processo unificado, na qual se procura

    levantar os principais requisitos e compreender o sistema de forma abrangente.

    Nesta fase no h um preocupao muito grande com a modelagem ou com o

    desenvolvimento do software, sendo o foco maior o entendimento do sistema que

    ser desenvolvido, pois Nesta etapa, assume-se que o analista possui pouco

    conhecimento sobre o sistema e que a interao com o usurio e cliente ser

    grande. (WAZLAWICK, 2011, p. 09).

  • 37

    Por ser uma fase inicial do sistema, que proporciona um primeiro contato com o

    cliente, ela tem por resultado apenas uma viso geral do sistema a ser

    desenvolvimento e dura poucos dias, suficiente para que se possa entender a real

    necessidade do cliente.

    2.5.2.2 Elaborao

    Esta fase, incorpora a maior parte da anlise e projeto (WAZLAWICK, 2011, p. 05),

    onde iniciada a modelagem do sistema com os diagramas de casos de uso e de

    classes e o projeto das interfaces.

    Com a viso geral do projeto feito na fase de concepo, maior ateno fornecida

    para detalhamento dos requisitos, dos modelos conceituais e comportamentais para

    ajudar no entendimento e projeto do sistema e, por mais que exista codificao, no

    o ponto focal desta fase.

    na fase de elaborao que todos (ou a grande maioria dos requisitos) so

    levantados em detalhes. Numa primeira iterao um ou dois requisitos, os de maior

    risco e valor arquitetural, so especificados em detalhes. (BRAZ, 2006). Espera-se

    que, ao fim desta fase, a maior parte dos requisitos j esteja levantada e os

    principais riscos j tenham sido tratados.

    2.5.2.3 Construo

    A fase de construo incorpora a maior parte da implementao e testes

    (WAZLAWICK, 2011, p. 05).

    Considerando que na fase de Elaborao, as implementaes de maior risco so

    feitas, na de construo so realizadas, iterativamente, as implementaes de

    menor risco e a preparao para a implantao (BRAZ, 2006).

  • 38

    2.5.2.4 Transio

    a ltima fase do PU, onde o foco central a realizao dos ltimos testes e a

    implantao final do software.

    2.5.3 O Manifesto gil

    O manifesto gil foi originado em 2001, atravs de um grupo, composto por Kent

    Beck e outros 16 desenvolvedores, com o interesse em mtodos iterativos em

    propor mudanas rgidas aos mtodos de desenvolvimento de software da poca

    (FURGERI, 2013).

    Os princpios propostos pelo Manifesto gil foram:

    Indivduos e interaes mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano; Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. (BECK et. al, 2001).

    O Manifesto gil no veio como um processo de desenvolvimento, mas como uma

    nova prtica de desenvolvimento de software visando evoluo dos ciclos de

    desenvolvimento. Ou seja, prioriza o software, os clientes e as respostas s

    mudanas e coloca todo o planejamento, documentao e ferramentas num plano

    secundrio.

    2.5.4 Lean Software Development

    O Lean Software Delevelopment uma derivao da metodologia Lean Thinking

    criada pela Toyota.

    Segundo Gomes ([2010?]), a Lean uma metodologia que tem o objetivo de

    aumentar a qualidade e eliminar desperdcios, e vem sendo amplamente utilizada

    em organizaes dos mais diversos setores nos ltimos anos..

    A metodologia Lean, possui cinco princpios que sero descritos adiante.

  • 39

    2.5.4.1 Os cinco princpios da Lean Thinking

    Os cinco princpios da Lean Thinking so o valor, o fluxo de valor, o fluxo contnuo, a

    produo puxada e a perfeio.

    Para o primeiro princpio, que o valor, deve-se ter em mente que quem define o

    que o valor de um produto o cliente. Segundo Moreira ([20--]), Quanto maior o

    valor percebido pelo cliente maior ser a satisfao do mesmo e deste modo a

    fidelidade ser crescente.

    O segundo princpio o fluxo do valor e diz respeito ao processo que o produto deve

    seguir at que seja concludo. Este princpio visa eliminar o que desnecessrio.

    (MOREIRA, [20--]).

    Segundo MOREIRA ([20--]), este um princpio onde Verificam-se tempos

    desnecessrios, atividades inadequadas, mtodos de trabalho ineficientes, padres

    de qualidade indefinidos ou desajustados..

    No terceiro princpio, que diz respeito ao fluxo contnuo, segundo a Lean Institute

    Brasil ([entre 1998 e 2014]), deve-se dar fluidez para os processos e atividades

    que restaram. Isso exige uma mudana na mentalidade das pessoas. Elas devem

    deixar de lado a ideia que tm de produo por departamentos como a melhor

    alternativa.

    No quarto princpio, a produo puxada, diz-se que a produo deve ser iniciada

    apenas por meio de solicitao do cliente, ocorrendo uma alterao do fluxo de

    produo empurrada, onde o produto empurrado ao cliente. Neste princpio que

    aplica-se o conceito de Just-in-Time. (MOREIRA, [20--]).

    O quinto e ltimo princpio a perfeio, que diz respeito a aperfeioar

    continuamente no apenas o produto em si, mas todo o processo de produo e

    seus envolvidos. (LEAN INSTITUTE BRASIL, [entre 1998 e 2014]).

  • 40

    2.5.4.2 O Lean Thinking aplicado ao desenvolvimento de software

    O Lean Software Development (LSD) foi citado pela primeira vez em 2003, pelos

    autores Tom e Mary Poppendieck, onde foi apresentada a aplicao da metodologia

    Lean ao desenvolvimento de software. (GOMES, [2010?]).

    O LSD possui sete princpios1 que o guiam, e so eles:

    Eliminar Desperdcios: que envolve o entendimento do processo para

    eliminao dos desperdcios de tempo de espera (como no Cascata), os

    trabalhos parcialmente prontos que podem ficar obsoletos e precisarem ser

    reconstrudos, o desperdcio com funcionalidades que no agregam valor ao

    negcio, o equilbrio entre documentar o que importante e deixa o que for

    desnecessrio, o desperdcio por falta de foco que ocorre quando algum

    retirado de sua tarefa para exercer outra, o desperdcio por atrasos, o

    desperdcio por falta de recursos e o desperdcio por defeitos.

    Qualidade embutida: que define que um software deve ser criado desde o

    incio do seu desenvolvimento, levando em considerao a resoluo

    adiantada dos seus defeitos e, caso necessrio, a sua refatorao.

    Criar conhecimento: preconiza que o verdadeiro conhecimento no est nos

    requisitos levantamentos prematuramente e amplamente documentados. A

    gerao de conhecimento ocorre ao longo do processo de desenvolvimento e

    prticas como Big Requirements Up Front (Grande requisitos antes de tudo) e

    Big Design Up Front (Grande projeto antes de tudo) devem ser evitadas.

    Decidir o mais tarde possvel: para momentos em que a tomada de deciso

    difcil mudana, ou at mesmo irreversvel, indicado postergar esta deciso

    para o mais tarde possvel, onde ser maior a quantidade de informaes que

    circundam o sistema e menor a probabilidade de errar.

    Entregar rapidamente: este princpio visa a reduo dos trabalhos

    parcialmente prontos com entregas parciais e teis ao cliente, diminuindo o

    1 Todos os sete princpios foram retirados e explicados com base no artigo Lean Software Development de Andr Faria Gomes, presente no site

  • 41

    trabalho em progresso, aumentando a vantagem competitiva e reduzindo a

    carga de funcionalidades a ser entregue uma s vez.

    Respeitar as pessoas: conforme diz Gomes ([2010?]), respeitar

    compreender. Este princpio diz realmente sobre compreender o que as

    pessoas fazem e fornec-las um ambiente de trabalho limpo e seguro,

    permitir que tenham metas praticveis e realistas, e confiar nelas.

    Otimizar o todo: considera a otimizao de todo o processo de

    desenvolvimento. O fato das partes de um processo de desenvolvimento

    trabalharem bem individualmente, no quer dizer que o resultado ser

    satisfatrio. preciso que o sistema seja compreendido e aperfeioado como

    um todo.

    2.5.5 Processo Unificado gil

    Segundo Larman (2007, p. 56) [...] iteraes curtas de tempo limitado com

    refinamento evolutivo de planos, requisitos e projeto uma prtica bsica que os

    mtodos [geis] compartilham..

    At mesmo o Processo Unificado poder ser aplicado como um processo gil,

    conforme diz Wazlawick (2011, p. 05):

    Apesar de ser um processo prescritivo, o UP pode tambm ser realizado como um processo gil, com poucos artefatos e burocracia, permitindo o desenvolvimento de software de forma eficiente, uma vez que o que interessa ao cliente o software pronto e no uma pilha de documentos justificando por que no ficou pronto.

    O captulo seguinte abordar o OpenUP, uma metodologia de desenvolvimento de

    software que tem como base o UP gil.

    2.6 A METODOLOGIA GIL OPENUP2

    O OpenUP/Basic a metodologia gil que utiliza os conceitos do Processo Unificado

    e ser adotada para o estudo de caso proposto neste trabalho. Antes de utilizar esta

    2 Captulo baseado na documentao da empresa ECLIPSE FOUNDATION, atual detentora do OpenUP/Basic, presente no site

  • 42

    ferramenta para auxiliar no desenvolvimento, necessrio explicar sua origem e

    quais seus recursos.

    2.6.1 A origem do OpenUP

    Wazlawick (2013, p. 107), cita sobre a origem do OpenUP:

    Anteriormente conhecido como Basic Unified Process (BUP) ou OpenUP/Basic, o Open Unified Process (OpenUP) uma implementao aberta do UP [Unified Process Processo Unificado] desenvolvida como parte do Eclipe Process Framework (EPF) [...]. A primeira verso conhecida como BUP, foi originada pela IBM, que abriu a definio de uma verso mais leve do RUP. Entre 2005 e 2006 essa verso foi abraada pela Fundao Eclipse e passou ser um de seus projetos.

    Ou seja, inicialmente, era uma simplificao do RUP at que a empresa Eclipse

    integrou-os como um de seus projetos e atualmente o OpenUP faz parte de um

    conjunto de ferramentas chamado EPF (Eclipse Process Framework).

    O EPF um projeto que visa prover um conjunto estruturas exemplares e de

    ferramentas extensveis que auxiliem no processo de engenharia de software e um

    contedo de processos exemplares e extensveis que suportem desenvolvimento

    gil, iterativo e incremental (ECLIPSE FOUNDATION, 2014).

    2.6.2 Caractersticas e princpios

    O OpenUP possui trs caractersticas essenciais: mnimo, completo e extensvel.

    Contendo um processo com o mnimo necessrio para equipes pequenas, pode ser

    utilizado como est e pode ser estendido e personalizado para atender propsitos

    especficos.. (ECLIPSE FOUNDATION, 2006).

    Alm destas trs caractersticas essenciais, tcnicas geis e um foco na reduo de

    riscos por meio de reunies dirias de reviso.

    Os princpios do OpenUP segundo a Baduino (2007) so:

    Colaborar para alinhar os interesses e compartilhar o entendimento. Este princpio promove prticas que promovam um ambiente de equipe saudvel, permitem a colaborao e desenvolver um entendimento comum do projeto. Equilibrar as Prioridades concorrentes para maximizar o valor para os stakeholders. Este princpio promove prticas que permitem que os

  • 43

    participantes do projeto e as partes interessadas desenvolvam uma soluo que maximize os benefcios das partes interessadas, e seja compatvel com as restries colocadas sobre o projeto. Focar na arquitetura do incio para minimizar os riscos e organizar o desenvolvimento. Este princpio promove prticas que permitem a equipe para se concentrar na arquitetura para minimizar os riscos e organizar o desenvolvimento. Evoluir para continuamente obter feedback e melhorar. Este princpio promove prticas que permitem a equipe obter feedback antecipado e contnuo das partes interessadas, e demonstrar o valor incremental para eles.

    A tabela abaixo demonstra um paralelo entre os princpios do OpenUP/Basic o

    Manifesto gil.

    Tabela 1 Paralelo entre o OpenUP e o Manifesto gil

    Princpio OpenUP Declarao do Manifesto gil

    Colaborar para alinhar os interesses e compartilhar o entendimento

    Indivduos e interaes mais que processos e ferramentas

    Equilibrar as Prioridades concorrentes para maximizar o valor para os stakeholders

    Colaborao com o cliente mais que negociao de contratos

    Focar na arquitetura do incio para minimizar os riscos e organizar o desenvolvimento

    Software em funcionamento mais que documentao abrangente

    Evoluir para continuamente obter feedback e melhorar

    Responder a mudanas mais que seguir um plano

    Fonte: Artigo Introduction to OpenUP (Open Unified Process) de Ricardo Balduino

    2.6.3 Papis do OpenUP

    Durante o desenvolvimento de um sistema, seja qual for o modelo de ciclo de vida

    escolhido, existem vrios papeis que so assumidos pelo envolvidos, seja de

    desenvolvedor, analista, arquiteto ou qualquer outro.

    No OpenUP, os papis so divididos entre bsico, de implantao e de ambiente,

    que sero explicados adiante.

  • 44

    2.6.3.1 Papis Bsicos

    Os papis bsicos do OpenUP so:

    Analista: o papel responsvel por representar o cliente na empresa. a

    funo que est mais prxima das reais necessidades do cliente e define as

    prioridades. Pode ser representada tanto por um membro da equipe de

    desenvolvimento quanto por componente do cliente.

    Arquiteto: o papel que se responsabiliza pelas decises tcnicas do sistema

    e pela arquitetura do sistema. A pessoa neste papel conduz ou coordena o

    projeto tcnico do sistema e tem a responsabilidade global para facilitar as

    principais decises tcnicas expressas em arquitetura de software.

    (ECLIPSE FOUNDATION, 2012).

    Desenvolvedor: o papel que desenvolve as partes do sistema com base na

    arquitetura, incluindo o cdigo-fonte, a prototipao da interface com o

    usurio, os testes unitrios e a integrao dos componentes da soluo.

    Testador: segundo a ECLIPSE FOUNDATION (2012), este responsvel

    pelas atividades centrais do esforo de teste. Essas atividades incluem

    identificar, definir, implementar e conduzir os testes necessrios, bem como

    registrar os resultados dos testes e anlise dos resultados. Ou seja, toda a

    gama de tarefas relacionadas aos testes do sistema esto ligadas este

    papel.

    Stakeholder: esta funo que utilizar o resultado do processo de

    desenvolvimento de software, ou seja, a funo que precisa ser satisfeita pelo

    projeto.

    Gerente de Projeto: responsvel por planejar e guiar o processo de

    desenvolvimento de software. O Gerente de Projeto conduz o planejamento

    do projeto, coordena interaes com as partes interessadas, e mantm a

    equipe de projeto focada em atender os objetivos do projeto. (ECLIPSE

    FOUNDATION, 2012).

    Qualquer papel: um papel voltado para a realizao de tarefas gerais.

  • 45

    2.6.3.2 Papis de Implantao

    Estes so os papeis voltados para a implantao do software, e incluem:

    Desenvolvedor do Curso: responsvel pela criao dos materiais que

    treinamento que sero utilizados pelos usurio e pelo suporte ao pessoal de

    produo responsvel pela manuteno do sistema.

    Engenheiro de Implantao: segundo a Eclipse Foundation (2012), o papel

    responsvel por apoiar o Gerente de Implantao na misso de levar

    continuamente, facilitar e coordenar lanamentos sincronizados.

    Gerente de Implantao: o papel responsvel pelos lanamentos das

    verses do software de forma sincronizada.

    Dono do Produto: representa as necessidades do usurio final e normalmente

    um membro do time que fica localizado junto equipe de desenvolvimento.

    Redator Tcnico: tem o objetivo do auxiliar a equipe de desenvolvimento na

    descrio das funcionalidades requisitadas nas documentao direcionadas

    aos usurio finais ou aos donos dos produtos.

    Treinadores: tem amplo conhecimento do software que ser entregue e

    oferece treinamento, laboratrio e materiais de oficina de forma eficaz para

    os usurios finais e pessoal de apoio aplicao. (ECLIPSE FOUNDATION,

    2012).

    2.6.3.3 Papis de Ambiente

    Os papis que envolvem o ambiente de desenvolvimento de software so:

    Engenheiro de Processos: segundo a Eclipse Foundation (2012), o papel

    que equipa o time do projeto com um processo de desenvolvimento

    adequado, e garante que os membros da equipe no esto impedidos de

    fazer o seu trabalho..

    Especialista em Ferramentas: o papel voltado para auxiliar na aquisio,

    configurao e instalao das ferramentas que sero utilizadas no decorrer

    do processo de desenvolvimento.

  • 46

    2.6.4 Disciplinas

    Em cada iterao no OpenUP/Basic, existem disciplinas pelas quais o projeto passa

    que visam organizar os desenvolvimento do software e atribuir tarefas para os

    envolvidos no projeto. So estas disciplinas: requisitos, anlise e projeto,

    implementao, testes, gerncia de projetos e gerncia de configurao e

    mudanas.

    2.6.4.1 Requisitos

    a disciplina responsvel por elicitar, analisar, especificar, validar e gerenciar os

    requisitos para o sistema a ser desenvolvido.. (ECLIPSE FOUNDATION, 2006).

    Esta disciplina voltada para a compreenso do que ser tratado na Iterao.

    Esta disciplina possui trs tarefas em sua execuo, e so elas:

    Definir a viso: que tem como objetivos trazer o stakeholder para mais

    prximo de forma que eles colaboram com a equipe de desenvolvimento

    para expressar e documentar seus problemas, necessidades, e potenciais

    caractersticas para o sistema [...]. (ECLIPSE FOUNDATION, 2006).

    Encontrar e Descrever os Requisitos: tem como foco entender os requisitos

    dos stakeholders e comunic-los ao time de desenvolvimento.. (ECLIPSE

    FOUNDATION, 2006).

    Detalhar requisitos: segundo a empresa Eclipse Foundation (2006), esta

    tarefa tem por objetivo:

    [...] descrever um ou mais requisitos com suficiente detalhe para validar a compreenso do requisito, assegurar concorrncia com as expectativas dos stakeholders, e permitir o incio do desenvolvimento do software.

    2.6.4.2 Anlise e projeto

    Esta disciplina tem como base realizar o projeto dos requisitos que foram levantados

    na disciplina de Requisitos. Segundo a empresa Eclipse Foundation (2006), esta

  • 47

    disciplina diz como criar o projeto atravs dos requisitos os quais podem ser

    implementados pelos desenvolvedores.

    As seguintes tarefas so realizadas:

    Analisar os Requisitos Arquiteturais: define uma arquitetura para guiar o

    desenvolvimento, teste e operao da funcionalidade requerida.

    Projetar a Soluo: esta tarefa tem por finalidade:

    [...] descrever os elementos do sistema de modo que suportem o comportamento necessrio, sejam de alta qualidade e adaptem-se a arquitetura. [...] Deve ser aplicada com base em um pequeno grupo de requisitos. (ECLIPSE FOUNDATION, 2006).

    Desenvolver a Arquitetura: tem por fim a tomada de decises concretas a

    respeito da arquitetura para fornecer orientao e sentido ao trabalho de

    desenvolvimento a ser feito na iterao.. (ECLIPSE FOUNDATION, 2006).

    2.6.4.3 Implementao

    Onde realmente iniciada a codificao seguindo o projeto e trabalhando dentro da

    arquitetura e possui as seguintes tarefas:

    Implementar Testes de Desenvolvedor: criao dos testes referentes ao

    componentes individuais do cdigo.

    Implementar a Soluo: a codificao do sistema propriamente dita

    Executar testes de Desenvolvedor: executar os testes que foram

    implementados na primeira tarefa.

    2.6.4.4 Testes

    Segundo a empresa Eclipse Foundation (2006), esta disciplina define um conjunto

    mnimo de tarefas requeridas para planejar, implementar, executar e avaliar o teste

    do sistema.

    Sendo a disciplina voltada especificamente para os testes do sistema, possui como

    tarefas:

  • 48

    Criar Casos de Teste: voltada para criar as condies pelas quais o software

    ser testado

    Implementao dos Testes: a produo dos scripts que sero utilizados nos

    testes.

    Execuo dos Testes: a tarefa onde os scripts que foram criados sero

    executados e seus logs gerados.

    2.6.4.5 Gerncia de projeto

    a disciplina responsvel por gerenciar todas as outras disciplinas. Segundo a

    empresa Eclipse Foundation (2006), uma disciplina tipo guarda-chuva que

    impacta e impactada por todas as outras disciplinas..

    Possui como tarefas:

    Planejar o Projeto: definir um plano a ser seguido durante o processo de

    desenvolvimento de software

    Planejar as Iteraes: definir o que ser feito em cada Iterao.

    Gerenciar as Iteraes: a tarefa para Avaliar o status do projeto e identificar

    todas as oportunidades e/ou questes bloqueadoras. Identificar e gerenciar

    as excees, os problemas e os riscos. Comunicar o status do projeto..

    (ECLIPSE FOUNDATION, 2006).

    Avaliar resultados: a coleta dos resultados para determinar falha ou sucesso

    na iterao e a aplicao das lies aprendidas no projeto ou na melhoria do

    processo. (ECLIPSE FOUNDATION, 2006).

    2.6.4.6 Gerncia de configurao e mudanas

    a disciplina voltada para o controle das mudanas e seus impactos nos artefatos,

    para garantir sincronia com os produtos de trabalho.

    Possui como nica tarefa a Solicitao da Mudana, que responsvel por captar e

    registrar a mudana solicitada.

  • 49

    2.6.5 reas de Contedo do OpenUP

    O OpenUP organiza-se em torno de trs nveis: o pessoal, do time e do stakeholder.

    A Figura 2 demonstra como estes nveis operam com o decorrer do processo de

    desenvolvimento de software.

    Figura 2 Micro-incrementos, ciclos de vida de iterao e de projeto do OpenUP/Basic

    Fonte: Documentao do OpenUP fornecida pela Eclipse Foundation

    2.6.5.1 Ciclo de vida do projeto

    De acordo com a empresa Eclipse Foundation (2012):

    O ciclo de vida do projeto fornecem aos stakeholders, fiscalizao, transparncia e mecanismos de direo para controle dos fundos do projeto, escopo, exposio ao risco, valor fornecido e outros aspectos do processo.

  • 50

    O ciclo de vida do projeto uma viso com foco no stakeholder, guiado pelo Plano

    de Projeto e, como direcionado para o projeto, tem durao de alguns meses.

    Segundo Prikladnicki, Willi e Milani (2014, p. 61):

    O OpenUP organiza um conjunto de iteraes em fases [Concepo, Elaborao, Construo e Transio]. [...] Cada fase termina com um marco, que tem como objetivo mitigar um determinado tipo de risco tipicamente importante para os envolvidos do projeto.

    2.6.5.2 Ciclo de vida da iterao

    Este o nvel onde esto presentes as iteraes das fases, que so guiadas pelos

    Planos de Iterao. Segundo a empresa Eclipse Foundation (2012), Iteraes

    focam a equipe na entrega de valor incremental para as partes interessadas de uma

    forma previsvel.

    O ciclo de vida da iterao deve comear com um planejamento da iterao

    envolvendo toda a equipe, onde sero elaborados os itens de trabalho dos

    microincrementos, bem como os detalhes da arquitetura. (PRIKLADNICKI, WILLI e

    MILANI, 2014).

    Ao final de cada iterao, que tem intervalos semanais, entregue uma verso

    totalmente testada ao stakeholder, seja um demonstrativo ou um incremento do

    sistema.

    2.6.5.3 Micro-incrementos

    Os micro-incrementos [...] representam unidades curtas de trabalho que produzem

    um ritmo constante, mensurvel do progresso do projeto (geralmente medido em

    horas ou alguns dias).. (ECLIPSE FOUNDATION, 2012).

    O micro incremento diz respeito a unidades de progresso dirio, e definido pelos

    Itens de Trabalho. O OpenUP no visa tratar de que tipo de item o est sendo

    tratado (manuteno, casos de uso, modificao, etc.), sendo apenas um item de

    um trabalho, podendo ser de um Item de Trabalho de maior, que deve ser

    executado. E justamente a despreocupao com o tipo de item a que se trata, que

  • 51

    torna o OpenUP diferente de outras metodologias como RUP e o SCRUM.

    (PRIKLADNICKI, WILLI e MILANI, 2014).

    Prikladnicki, Willi e Milani (2014, p. 60), citam que o progresso contnuo

    demonstrado atravs da integrao contnua de microincrementos durante cada dia

    do projeto.

  • 52

  • 53

    3 METODOLOGIA

    Primeiramente, ser feito um estudo a respeito do processo unificado e seus

    conceitos de forma geral, para que seja possvel compreender a sua base

    considerando o seu lado gil.

    Posteriormente, ser explicado o OpenUP, uma metodologia de desenvolvimento de

    software mantida pela organizao Eclipse Foundation, considerando a sua

    documentao atual.

    O prximo passo ser explicar a ideologia por trs do projeto CheckFreela, o que

    motivou a sua criao, bem como a tentativa anterior de desenvolvimento em

    cascata e o motivo da sua reelaborao utilizando uma metodologia de

    desenvolvimento gil.

    A proposta seguinte ser uma adaptao do OpenUP com a adoo um dos

    conceitos do Kanban, que o CardWall, de conceitos da modelagem gil, visando

    um desenvolvimento mais preocupado com a comunicao da equipe e de um teste

    de viabilidade.

    Com a adaptao do OpenUP, proposto, tambm, um fluxo de processo de

    negcio que ser utilizado com a adoo destes novos conceitos, atravs da

    apresentao em forma de imagem deste fluxo e da sua explicao detalhada,

    percorrendo cada item.

    Por ltimo, ser apresentado como ser feito o teste de viabilidade do CheckFreela

    e quais ferramentas sero utilizadas como apoio deste teste.

  • 54

  • 55

    4 ESTUDO DE CASO: DESENVOLVIMENTO DO CHECKFREELA UTILIZANDO OPENUP

    4.1 IDEALIZAO DO CHECKFREELA

    O CheckFreela uma ideia que surgiu a partir da anlise das ferramentas voltadas

    para busca e contratao de profissionais que atuem como profissionais autnomos

    (freelancers).

    Em anlise a alguns sites como o getNinjas e Recomind, percebeu-se que

    atualmente no h uma preocupao voltada para auxiliar o profissional a gerir seus

    prprios horrios ou como um cliente em potencial procura-lo para atendimentos em

    dias e horrios especficos, sejam emergenciais ou no.

    Para a resoluo deste problema, idealizou-se um ambiente onde o profissional

    pudesse ter uma agenda virtual, a qual seus clientes acessariam e o solicitariam

    seus servios num dia e horrio especficos. Esta ideia inicialmente tornou-se

    impraticvel devido o cliente no ter cincia do tempo utilizado por um profissional

    para a realizao de uma determinada tarefa. Ento, surgiu a ideia de utilizar visitas

    e propostas de custo.

    4.1.1 Visitas e propostas de custo

    Quando um cliente entra em contato com um profissional solicitando um servio,

    duas situaes podem ocorrer: ou o cliente capaz de explicar claramente o que o

    que est ocorrendo ou este profissional faz uma visita ao cliente para fazer uma

    proposta de servio.

    Um cliente, ao buscar um profissional para a resoluo do seu problema, pode

    solicitar uma visita tcnica, que fica a cargo do profissional cobrar ou no, ou pode

    simplesmente relatar do que precisa, para que posteriormente o profissional lhe

    enviasse uma proposta, como mostra a Figura 3.

  • 56

    Figura 3 - Fluxo de solicitao de servio

    Fonte: Arquivo prprio

    Desta forma seria mais simples gerenciar aos horrios que o profissional atua de

    forma a proporcionar uma agenda mais ntegra.

    4.2 O PRIMEIRO PROJETO

    No incio havia um grande foco na modelagem, de forma a criar, antes de tudo, um

    diagrama de casos de uso completo do sistema, posteriormente o diagrama de

    classes de anlise para entendimento do problema, passando para o diagrama de

    classes de projeto e o passo seguinte seria a modelagem de atividades e de

    sequncia do sistema das diversas funcionalidades.

    Antes de iniciar a confeco dos diagramas e documentos que seria utilizados no

    desenvolvimento do projeto em cascata, foi feito uma documento de Descrio de

    Escopo do Projeto CheckFreela (APNDICE A), que tornou-se imutvel para a

    equipe. Os requisitos presentes naquela declarao no seriam modificados e o

    desenvolvimento do sistema como um todo era esperado obedecendo a todas

    aquelas descries.

    Aps a criao o escopo, o foco foi voltado para a confeco do Diagrama de Casos

    de Uso (APNDICE B) em sua totalidade, para ter uma base da amplitude do projeto

    que desenvolveramos e do tempo que demandaramos para a realizao completa

    deste projeto.

    O terceiro passo foi criar o Modelo de Classes de Anlise (APNDICE C), onde

    foram levantadas todas as entidades do sistema. A partir deste diagrama, geramos o

  • 57

    Diagrama de Classes de Projeto (APNDICE D), projetado para suportar o

    framework objeto-relacional Hibernate ORM.

    No quarto passo, onde teve incio a Descrio dos Casos de Uso (APNDICES E, F

    e G) e os Diagramas de Atividade para as funcionalidades de Cadastro do Usurio

    (APENDICE H) e Promoo Profissional (APNDICE I).

    Durante a realizao do quarto passo que foi perceptvel que a forma como o

    desenvolvimento estava caminhando era invivel pra uma ideia cujos interessados

    (os profissionais e os seus clientes) estavam ausentes. Ento, questionamentos

    sobre a aceitao do projeto surgiram. Havia muitos requisitos incertos e nenhum

    retorno dos interessados devido falta de abertura para isso. Diante destas

    incertezas, o projeto foi parado.

    4.3 O PROJETO EM CASCATA

    Como dito anteriormente, o CheckFreela passou por uma tentativa anterior de

    produo. Esta tentativa aproximou-se do modelo de ciclo de vida em cascata, onde

    houve a tentativa de produzir todos os artefatos e levantar todos os requisitos

    possveis mesmo sem conhecer os usurios para que o sistema pudesse ser

    desenvolvido.

    No era um projeto em cascata pelo fato do modelo de ciclo de vida Cascata ter

    sido adotado no incio do projeto, mas houve uma preocupao to grande em

    seguir fielmente o fluxo de modelar completamente os casos de uso, depois

    descrev-los e posteriormente iniciar o projeto que a ideia do processo em cascata

    estava sendo aplicada.

    Larman (2007, p. 51), diz que:

    Ideias tais como vamos escrever todos os casos de uso antes de comear a programar ou vamos fazer muitos modelos OO detalhados em UML antes de comear a programar so exemplos de raciocnio em cascata doentio.

    Hoje o desenvolvimento de software est sendo feito num ritmo acelerado e a

    utilizao de um modelo de ciclo de vida como o Cascata no aplicvel, exceto

    nos casos onde o fluxo de desenvolvimento retilneo e os requisitos bem

    conhecidos. (PRESSMAN, 2006).

  • 58

    Sommerville (2007, p. 45) explica que o modelo em cascata deve ser usado apenas

    quando os requisitos forem bem compreendidos e houver pouca probabilidade de

    mudanas radicais durante o desenvolvimento do sistema.

    Paula Filho (2003, p. 12) define o modelo de ciclo de vida Cascata como:

    um processo rgido e burocrtico, em que atividades de requisitos, anlise e desenho tm de ser muito bem dominadas, pois no so permitidos erros. O modelo em cascata puro de baixa visibilidade para o cliente, que s recebe o resultado no final do projeto.

    Wazlawick (2013, p. 30), diz, ainda que o Modelo Cascata, na sua forma mais

    simples, impraticvel, e Larman (2007, p. 51) complementa quando diz que a

    prtica do ciclo em cascata est fortemente associada a altas taxas de falhas,

    menor produtividade e maiores taxas de defeitos (do que projetos iterativos).

    As aplicaes web possuem como uma de suas caractersticas, o imediatismo e

    frequentemente estabelece-se um prazo para o mercado de dias ou semanas.

    (PRESSMANN, 2006).

    Devido necessidade constante de adaptao de um software que tem seus

    requisitos incertos e riscos constantes de mudanas, a adoo do processo

    unificado torna-se importante devido sua filosofia incremental e iterativa, que

    auxilia na antecipada reduo de riscos, alm de ser possvel aplicar conceitos

    geis.

    4.4 A ADAPTAO DA DOCUMENTAO PROPOSTA PELO OPENUP AO

    CASO CHECKFREELA

    Este item visa a adaptao do processo proposto pelo OpenUP para o caso do

    CheckFreela, que a uma nova ideia de negcio que precisa da adoo de

    conceitos no especificados pelo framework.

  • 59

    4.4.1 A adoo da modelagem gil

    Segundo Ambler (apud PRESSMAN, 2006, p. 72):

    A Modelagem gil (MA) uma metodologia baseada na prtica, para modelagem e documentao efetiva de sistemas baseados em software. [...] uma coleo de valores, princpios e prticas de modelagem de software que podem ser aplicados a um projeto de desenvolvimento de software de modo efetivo e leve.

    Morais ([2011?]), diz ainda que:

    [...] a modelagem gil no uma metodologia de desenvolvimento gil [...] mas sim uma boa prtica. Ela visa construir e manter modelos de sistemas de maneira eficaz e eficiente, podendo ser utilizada dentro de metodologias geis e tradicionais.

    Ou seja, a modelagem gil a reunio de prticas que visam utilizar a modelagem

    de forma mais dinmica, de forma que no seja apenas um acmulo de diagramas

    volumosos feitos apenas para gerar uma ampla documentao de um software.

    Morais ([2011?]) diz sobre o princpio Travel Light da modelagem gil:

    A modelagem gil possui um princpio chamado Travel Light. Este princpio diz que manter modelos difcil, e pode se tornar ainda mais se estes forem complexos e detalhados. Especialistas na rea afirmam que trs ou quatro modelos que forneam uma viso geral da anlise, da arquitetura e do design so suficientes para melhorar a comunicao da equipe. errado pensar que quanto maior o nmero de documentaes melhor ser o projeto.

    4.4.1.1 Modelagem no quadro-branco

    No projeto CheckFreela, ser utilizado a modelagem utilizando quadro-branco

    envolvendo toda equipe de desenvolvimento, de modo que a modelagem seja

    utilizada para a comunicao entre a equipe e no para a documentao, e aps a

    concluso, uma foto ser tirada do modelo gerado e guardada num repositrio

    comum equipe.

    O objetivo de uma modelagem justamente este, servir de auxlio comunicao da

    equipe e no para a documentao. Alm disso, a modelagem no deve ser feita

    sozinho, sendo o essencial que seja envolvido mais membros da equipe. (LARMAN,

    2007).

    Larman (2007, p. 58), cita esta prtica quando diz:

  • 60

    No modele sozinho, modele aos pares (ou trios) no quadro-branco, na certeza de que a finalidade da modelagem descobrir, entender e compartilhar esse entendimento. Faa com que a caneta rode entre os membros de modo que todos participem.

    A adoo desta prtica ocorre devido certeza que, no final, todo o modelo ficar

    impreciso e incompleto prximo ao cdigo-fonte, que o real projeto, fazendo com

    que toda a modelagem anterior seja apenas algo descartvel (LARMAN, 2007).

    4.4.2 Adoo de conceitos do Kanban

    O Kanban um controle de produo criado pela Toyota com o conceito de

    Sistemas Puxados da Toyota Production System (TPS), que veio em contrapartida

    ao sistema de produo empurrada, onde h o recebimento de uma ordem de

    produo, que empurrado da operao atual para a seguinte (GOMES, [2010?]).

    Gomes ([2010?]), diz ainda que:

    Em meados de 2007, Rick Garber e David J. Anderson apresentaram nas conferncias Lean New Product Development e Agile 2007 os resultados preliminares do uso de Kanban na Corbis, uma empresa fundada por Bill Gates da Microsoft. Desde ento o Kanban vem ganhando mais e mais fora na comunidade de desenvolvimento de software e mais empresas passaram a adot-lo.

    4.4.2.1 Criao do Card Wall

    Segundo Gomes ([2010?], grifo nosso):

    A maneira mais comum de se coordenar sistemas Kanban atravs de card walls. Tipicamente o limite do trabalho em progresso [WIP numero mximo de atividades em cada fase] escrito ao lado, ou abaixo do nome de cada coluna. As colunas representam as etapas do processo de desenvolvimento de software.

    A Figura 4 mostra um exemplo de Card wall que possui raias verticais para dividir a

    fase de progresso das atividades e horizontais para dividir os tipos de atividades e

    os nmeros em vermelho dentro dos colchetes so os Wips (Work In Progress), que

    correspondem ao limite mximo de atividades que pode haver numa determinada

    fase.

  • 61

    Figura 4 - Card wall com Raias e Limite de Trabalho em Progresso (WIP) Explcito

    Fonte: Artigo Desenvolvimento gil com Kanban de Andr Farias Gomes

    No Card wall utilizado no projeto CheckFreela, sero utilizados cores para

    priorizao das atividades e raias para diviso do tipo de atividade a ser executada.

    Problemas que a priorizao ajuda a evitar: entrega de software intil, cliente insatisfeito, metas ou sprints (no caso do SCRUM) no atingidas, demora em entregar bugs e melhorias, dificuldade realocao de times e suas capacidades dentro da equipe. (GODOY, [2014?]).

    Cada item do Card Wall representado por um carto, e a informao contida no

    carto varia conforme o contexto do projeto. Normalmente um carto contm o

    cdigo do item gerado por algum software de controle, o ttulo do item, a data que o

    item entrou no sistema, data limite de entrega e nome da pessoa ou par atribudo ao

    item. (GOMES, [2010?]).

    4.4.2.1.1 A customizao do Card Wall para o CheckFreela

    As cores utilizadas para a diviso das prioridades esto apresentadas na Tabela 2.

  • 62

    Tabela 2 Tabela de prioridade que ser adotado do CheckFreela Cor Prioridade

    Vermelho Alta prioridade (utilizada para erros e entregas emergenciais) Amarelo Mdia prioridade Verde Baixa prioridade

    Fonte: Arquivo prprio

    Alm das cores de prioridade, os cartes do Card Wall apresentao as seguintes

    informaes:

    Ttulo do Item

    Data de entrada no sistema

    Data limite de entrega

    Os cartes utilizados sero feitos como mostra a Figura 5.

    Figura 5 Modelos do carto do Card Wall

    Fonte: Arquivo prprio

    4.4.2.2 A Lista de Itens de Trabalho e o Card Wall

    O Card Wall no ser um substituto Lista de Itens de Trabalho, mas o seu

    complemento.

    Segundo a empresa Eclipse Foundation (2012), a Lista de Itens de Trabalho

    fornece um lugar para ir para a equipe de desenvolvimento para entender quais

    micro-incrementos precisam ser entregues, obter referncias ao material necessrio

    para realizar o trabalho, e relatar os progressos alcanados..

    possvel, ento, realizar uma Lista de Itens de Trabalho para acompanhamento e

    utilizar o Card Wall como um meio de exibio das tarefas aos desenvolvedores,

    sendo possvel, assim, aplicar conceitos do Kanban para que se possa tornar o

    processo de desenvolvimento mais claro.

  • 63

    4.4.2.3 O WIP (Work In Progress)

    O Card Wall possui conceitos como o WIP, que limite de itens para as raias.

    Segundo Gomes ([2010?]), o WIP utilizado para indicar quando novas tarefas

    devem ser puxadas, em outras palavras, indica quando um requisito deve ser

    analisado, desenvolvido, testado, etc. de forma que se possa verificar o lead time

    (tempo percorrido desde a entrada de um item at a sua concluso) e aplicar

    melhorias para sua reduo ou para o seu controle.

    O WIP permite, ainda, que o conceito de Pair Programming (programao em par),

    onde ocorre programao com duas pessoas num s computador, seja aplicado,

    de forma que, sempre que o Card Wall estiver em seu limite, pode ser que um

    desenvolvedor fique sem atividade e junte-se a outro para resoluo da sua atual

    tarefa.

    4.4.2.4 O desenho do Card Wall para o CheckFreela

    O Card Wall para o projeto do CheckFreela ficar como demonstrado na Figura 6.

    Figura 6 - Card Wall do CheckFreela

    Fonte: Arquivo prprio

  • 64

    Por se tratar de um projeto que ser colocado em produo por partes, necessrio

    que se acompanhe a execuo de uma tarefa do incio ao fim.

    Foram utilizados os WIPs de valor decrescentes nas raias de desenvolvimento at

    homologao para proporcionar tanto o andamento forado pelas fases, quanto para

    proporcionar a Programao em Par quando houver gargalo. Isto ser

    proporcionado por meio da execuo forada de uma tarefa numa raia que esteja

    completamente ocupada.

    4.5 A CONCEPO DO CHECKFREELA COM O OPENUP

    Para iniciar este projeto, necessrio que os requisitos dos usurios sejam

    compreendidos e que ideias possam ser captadas por quem realmente se

    interessaria pela ferramenta: os profissionais e os seus clientes.

    Ou seja, para que se possa ter um sistema alinhado com as vontades do usurio,

    necessrio que o usurio coopere com este crescimento atravs do feedback.

    Torres (2012, p.100), diz que:

    Ter entrega contnua muito importante para que voc possa, aps ter seu produto web funcionando e com usurios, fazer rapidamente modificaes nesse seu produto web baseado nos feedbacks que voc receber desses usurios.

    Ser abordada, nos itens seguintes, a proposta de fluxo para o desenvolvimento do

    projeto, como ser feito o teste de viabilidade, qual parte ser entregue

    primeiramente caso o teste seja bem sucedido e como ser a comunicao com os

    usurios do sistema para aproxim-los do ciclo de desenvolvimento.

    4.5.1 O fluxo proposto para o projeto

    Para acompanhar o projeto do CheckFreela, foi criado um fluxo de desenvolvimento

    (Figura 7) para compreenso de como ser o processo de desenvolvimento.

  • 65

    Figura 7 Fluxo de desenvolvimento do CheckFreela

    Fonte: Arquivo prprio

  • 66

    O fluxo de dados apresentado mostra quais sero os passos seguidos durante o

    processo de desenvolvimento.

    O primeiro item a ser executado Discutir a ideia. Este o primeiro item para um

    teste de viabilidade que e visa reunir toda a equipe de para discutir o projeto que

    ser proposto.

    O prximo item a criao de um hotsite para apresentao da ideia. Este hotsite

    visa divulgar a ideia que foi levantada no item anterior para no, prximo item

    (Analisar os dados do AdWords), seja feita a anlise do interesse das pessoas na

    ferramenta.

    Os itens Lanar hotsite e Analisar os dados do AdWords sero explicados com

    maiores detalhes do item 5.5.2.

    Aps analisar os dados do AdWords, que o ltimo passo da anlise de viabilidade,

    caso o resultado seja negativo, o projeto encerrado, ficando a cargo do gerente

    recomea-lo, e caso seja positivo, executado o item Reunio com toda a equipe

    para debate, que visa reunir toda a equipe do projeto para debater a ideia do

    projeto, com o objetivo de formar um senso comum e, ao fim do debate, conceitos

    como Casos de Uso de Alto Nvel, Viso e Glossrio devem estar supridos.

    O item seguinte Realizar o plano de projeto, que dever ser realizado pelo

    gerente de projetos e deve gerar um plano de projeto, contendo o cronograma das

    fases, documento que guiar todo o projeto de desenvolvimento. E, com este

    documento pronto, o gerente de projeto rene-se com os analistas e iniciam

    oficialmente o projeto no item Realizar reunio de kick-off do projeto.

    Aps iniciar oficialmente o projeto de desenvolvimento, o analista e o gerente de

    projeto devem realizar o item Planejar fase, onde ser criado o plano da fase, com

    a previso das iteraes, e a lista de riscos levantamentos.

    Seguinte a este item, o analista, juntamente com o arquiteto, realizar o item

    Planejar iterao, onde ele far um planejamento da iterao que vai gerar o plano

    da iterao com funcionalidades de baixo nvel, para posteriormente o arquiteto

    realizar o item Montar lista de itens de trabalho, onde verificar os trabalhos que

    precisam ser executados para a conquista da iterao, para depois realizar o item

    Montar CardWall e durante a iterao, o arquiteto dever realizar o item Monitorar

    o CardWall.

  • 67

    No fluxo, existem itens que devem ser realizados diariamente, e so eles:

    Realizar reunio diria: uma reunio de pouca durao (de 10 a 15 minutos)

    que deve ser realizada pelo arquiteto no comeo de cada dia, onde sero

    levantadas as dificuldades dos desenvolvedores nas tarefas que esto sendo

    realizadas. Caso algum problema seja levantado no durante a reunio,

    executado o item Fazer modelagem juntamente com a equipe, caso no, os

    desenvolvedores realizam o item Desenvolver a tarefa que pegou.

    Fazer modelagem juntamente com a equipe: o item onde realizada a

    modelagem em quadro-branco para melhorar a comunicao com a equipe,

    visando melhorar o entendimento do que deve ser desenvolvimento. Ao fim

    da modelagem, uma foto do quadro-branco tirada e guardada para consulta

    pela equipe. Aps a realizao deste item, caso as dvidas do desenvolvedor

    que percebeu o problema sejam supridas, este executar o item Desenvolver

    a tarefa que pegou, caso no, selecionado outro desenvolvedor para

    realizar o item Realizar programao em par com o primeiro.

    Desenvolver a tarefa que pegou: este item a da tarefa que o desenvolvedor

    pegou para executar.

    Realizar programao em par: realizao da programao com dois

    desenvolvedores utilizando um computador.

    Estas tarefas dirias sero executadas at o ltimo dia da iterao. No dia

    subsequente a este, toda a equipe realizar o item Reunio de finalizao da

    Iterao, onde se reuniro para levantamento do aprendizado conquistado no

    decorrer da iterao na iterao.

    Aps a execuo deste item, caso ainda haja outra iterao as ser executada, o

    analista e o projetista renem-se para, novamente, executarem o item Planejar

    Iterao. Caso no haja outras iteraes a serem executadas na fase atual, o

    analista rene-se