Universidade Federal de Pernambuco Centro de Informática - CIn

Transcrição

1 Universidade Federal de Pernambuco Centro de Informática - CIn Especificação de Requisitos para Sistema agilepaying Professor: Jaelson Castro Equipe: Ângelo de Sant Ana (assd) Bruno Ghisi (bmg) Henrique Vicente (hvop) Robertson Novelino (rnff) Recife, 5 de maio de 2017

2 Conteúdo 1. Introdução Sobre a organização Motivação da organização Identificação do problema Coleta dos dados 3 2. Convenções adotadas 4 3. Atores 4 4. Requisitos dos requisitos Requisitos Organizacionais Requisitos Funcionais (RF) [RF001] Cadastrar projetos [RF002] Registrar datas de pagamento [RF003] Registrar alarmes [RF004] Registrar horas trabalhadas [RF005] Exibir horas trabalhadas [RF006] Emitir alarmes financeiros [RF007] Cobrar tempo e eventualidades Requisitos Não-Funcionais (RNF) [RNF001] Eficiência na troca de informações [RNF002] Informações devidamente registradas [RNF003] Disponibilidade [RNF004] Clareza nos alarmes e mensagens 7 5. Modelagens Modelagem Orientada a Objetivos (i*) Modelagem AS-IS Modelagem TO-BE Modelo SD Modelo SR para a parte do projeto Modelo SR para a parte do financeiro Modelagem Orientada a Fluxogramas (BPMN) Modelagem AS-IS Processo para cobrança de horas trabalhadas Processo para envio e cobrança de Invoice Processo para colaborador informar horas trabalhadas e anomalias Modelagem TO-BE Processo para cobrança de horas trabalhadas Processo para envio e cobrança de Invoice Processo para colaborador informar horas trabalhadas e anomalias Conclusão 14 1

3 1. Introdução Há vários problemas relacionados a pagamentos dentro de qualquer empresa de TI. O departamento financeiro tem a função de cobrar do cliente e do gerente questões como horas e outros gastos dentro de projetos. Isto costuma sobrecarregar tanto o gerente financeiro quanto o de projeto. O gerente de projeto deve checar com os colaboradores do projeto e isso nem sempre é uma atividade contínua, o que gera muitas trocas de contexto e interrupções em outras atividades. Se o projeto for no modelo de escopo aberto os problemas são ainda mais complicados, pois existe uma preocupação ainda maior sobre quantas horas foram trabalhadas e a clareza e nível de detalhe com que isto tem que ser especificado para o cliente. Surge, portanto, uma necessidade de algum sistema para centralizar essa comunicação e torná-la mais eficiente Sobre a organização A Vinta Software é uma empresa fundada por 3 ex-alunos do CIn e voltada para o desenvolvimento de software. Diferentemente das fábricas de software tradicionais, eles se definem como Estúdio de Software, trabalham com um time pequeno, altamente qualificado, com margem de lucro alta e vendem qualidade na produção de software, não somente menor preço. O escopo aberto de todos os projetos e a horizontalidade na gestão são outras duas características que também a diferenciam de fábricas de software. Essas características tornam difícil a negociação dentro do mercado brasileiro, então a Vinta Software vende software somente para Nova York e São Francisco, lugares com um mercado de software muito mais maduro. Trabalhando com muitos projetos de startups, por serem os mais diferentes, divertidos e recompensadores de trabalhar Motivação da organização Como o modelo de escopo aberto gera uma necessidade alta de esclarecimento para o cliente, o tempo com as atividades deve ser muito bem apurado. Isso recai sobre o gerente de cada projeto e é apenas uma das várias preocupações desses gerentes (dentre as quais tem-se: manter o projeto sem problemas). Para isso, o grupo especifica o agilepaying, para que o gerente de projetos tenha mais eficiência nessa comunicação dos valores com o financeiro e possa se focar em suas outras atividades Identificação do problema A identificação do problema surgiu de entrevistas realizadas com os três sócios da empresa e com o gerente financeiro. Além de observação de algumas iterações da dinâmica de pagamentos e o tempo decorrido para completá-la Coleta dos dados A presença de um dos integrantes do grupo, Robertson, na organização foi o meio encontrado para obter as informações necessárias sobre essa organização e o problema a 2

4 ser resolvido. Robertson ficou responsável por nos repassar o funcionamento da organização e como tem resolvido o problema, cuja análise será feita nesse projeto. Robertson obteve tais dados através de conversas com os gerentes e fundadores da empresa. 2. Convenções adotadas Para facilitar a organização e descoberta dos requisitos ao longo do documento, será adotada uma notação para os requisitos. Os requisitos funcionais serão representados por RF e os não-funcionais por RNF, onde cada requisito terá concatenado à sua breve descrição, um número que o identifica unicamente e permite ordenar o conjunto. Para exemplificar, o requisito de Realizar Login, que é funcional, seria representado como [RF001] Realizar Login. 3. Atores Os atores descritos abaixo são usuários, ou sistema, que interagem de forma significativa para o andamento do processo. Cada ator desempenha um papel específico, produzindo artefatos e informações ao longo do processo. Ator Sistema Gerente Financeiro Gerente do Projeto O sistema computacional que gerenciará o cálculo dos pagamentos do trabalho e geração das faturas e notificações. Responsável por gerenciar as finanças da empresa, realizar cobranças, e pagamentos. Responsável por informar e receber o tempo de trabalho dos desenvolvedores. Colaborador do Projeto 4. Requisitos Responsável por desenvolver a funcionalidade pedida pelo cliente. Tabela 1: Tabela com descrições dos atores do processo 4.1. dos requisitos elas: Aos requisitos foram associadas prioridades a fim de obter melhor classificação. São é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente. 3

5 Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim. Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis podem ser deixados para versões posteriores da solução, caso não haja tempo hábil para implementá-los na versão que está sendo especificada Requisitos Organizacionais Os requisitos organizacionais devem descrever com precisão as metas da organização e deixar nítida a necessidade do sistema que se propõe a resolver o problema em questão. Os requisitos reconhecidos para o sistema proposto foram: Menos tempo perdido pelo gerente de projetos na validação das horas; Mais facilidade para cobranças financeiras; Menos dependência da memória das pessoas envolvidas Requisitos Funcionais (RF) [RF001] Cadastrar projetos Permite que o gerente financeiro faça o cadastro dos projetos [RF002] Registrar datas de pagamento Permite que o gerente financeiro faça o registro das datas de pagamento realizadas pelo cliente [RF003] Registrar alarmes Permite que o gerente financeiro registre alarmes sobre os projetos cadastrados [RF004] Registrar horas trabalhadas 4

6 Permite que o gerente do projeto repasse as horas trabalhadas e possíveis anomalias (horas trabalhadas a mais ou a menos) para assim registrar as horas totais trabalhadas [RF005] Exibir horas trabalhadas Permite que o gerente financeiro veja as horas trabalhadas que já foram registradas [RF006] Emitir alarmes financeiros Faz a emissão de alarmes ao gerente financeiro sobre as datas do processo acordado com o cliente. Importante [RF007] Cobrar tempo e eventualidades Faz a emissão de cobranças ao gerente de projeto sobre o tempo trabalhado e eventualidades/anomalias ao longo do desenvolvimento do projeto Requisitos Não-Funcionais (RNF) [RNF001] Eficiência na troca de informações Os gerentes devem conseguir comunicar o que necessitam para o sucesso do processo, bem como a pessoa informada precisa obter a informação no tempo devido [RNF002] Informações devidamente registradas 5

7 Os gerentes devem ter a confiança de que o que for transmitido através do sistema será salvo para posterior visualização [RNF003] Disponibilidade O sistema deve estar disponível quando os gerentes necessitarem fazer qualquer operação ou consulta [RNF004] Clareza nos alarmes e mensagens O sistema deve gerar alarmes e mensagens de fácil entendimento e não ambíguas. 5. Modelagens As modelagens dos processos e requisitos escolhidas foram, respectivamente, a BPMN e i*. Aquela faz a captura e ordenação de uma sequência de atividades e esta foca nas fases iniciais de requisitos. Essas modelagens serão dispostas sob a forma de dois estágios distintos, o AS-IS, que representa o presente momento dos processos/requisitos e TO-BE, que designa como os processos/requisitos seriam realizados com uso do sistema proposto. O processo atual para solucionar o problema abordado é feito sem uso de sistema, apenas interação entre as pessoas envolvidas. As pessoas envolvidas são de três tipos: gerente financeiro, gerente do projeto, colaborar e cliente. No sistema proposto, esses tipos ainda existem, mas o cliente apenas interage com o gerente financeiro que descreve para ele como seu dinheiro foi gasto, cobra pagamento e gera Invoice. Assim, o cliente acaba não sendo decisivo para as decisões de construção do sistema agilepaying já que este trata de operações concernentes à interação interna entre os gerentes financeiro e de projeto. Mais claramente, atualmente o gerente financeiro precisa cobrar ao gerente de projeto as horas trabalhadas totais, contando eventuais anomalias (trabalho que foi feito além, ou aquém, do tempo programado). Este, por sua vez precisa saber dos colaboradores quantas horas foram trabalhadas. Uma vez sabendo as horas totais trabalhadas de todos os colaboradores num determinado projeto, esse gerente pode reportar essa informação ao gerente financeiro. Além disso, o gerente de projeto precisa gerar o Invoice ao cliente e informá-lo sobre o tempo trabalhado. Após o envio do Invoice, o gerente financeiro pode cobrar o pagamento do contrato ao cliente. 6

8 Com o sistema proposto, o gerente de projeto mantém a interação com os colaboradores, mas agora precisará fazer o repasse das horas trabalhadas diretamente ao sistema. Neste sistema, o gerente financeiro poderá realizar os cadastros dos projetos, visualizar as horas trabalhadas por projeto e dele receber alertas sobre os prazos acordados em contrato. O gerente financeiro também ficaria responsável por gerar o Invoice ao cliente e cobrar o pagamento do contrato Modelagem Orientada a Objetivos (i*) Modelagem AS-IS Modelagem TO-BE Imagem 1: modelo de dependência estratégica (SD) AS-IS Modelo SD 7

9 Imagem 2: modelo de dependência estratégica TO-BE Modelo SR para a parte do projeto Imagem 3: modelo de raciocínio estratégico, parte do projeto 8

10 Modelo SR para a parte do financeiro Imagem 4: modelo de raciocínio estratégico, parte do financeiro 5.2. Modelagem Orientada a Fluxogramas (BPMN) Modelagem AS-IS Processo para cobrança de horas trabalhadas Imagem 5: cobrança de horas trabalhadas AS-IS 9

11 Processo para envio e cobrança de Invoice Imagem 6: envio e cobrança de Invoice AS-IS 10

12 Processo para colaborador informar horas trabalhadas e anomalias Modelagem TO-BE Imagem 7: informar horas trabalhadas e anomalias AS-IS Processo para cobrança de horas trabalhadas Imagem 8: cobrança de horas trabalhadas TO-BE 11

13 Processo para envio e cobrança de Invoice Imagem 9: envio e cobrança de Invoice TO-BE 12

14 Processo para colaborador informar horas trabalhadas e anomalias 6. Conclusão Imagem 10: informar horas trabalhadas e anomalias TO-BE A partir da orientação que foi dada ao grupo de que procurasse uma organização real com um problema ainda a ser analisado e bem entendido, o grupo partiu para conversar e tentar achar algo que fosse útil ao desenvolvimento do projeto e não fugisse do escopo esperado pelo professor pela falta, ou excesso, de complexidade ou envolvimento excessivo a ponto de contribuir para enviesamento da real situação do problema. 13

15 Inicialmente, o grupo pensou num problema, mas um dos integrantes estava deveras envolvido nele. Para a sorte do grupo, surgiu um outro problema, o da cobrança e registro de horas trabalhadas na Vinta Software. Então, foi o problema escolhido para busca de solução. A partir disso, deu-se início ao desenvolvimento dos artefatos. Primeiro foram os SDs e SRs e por fim os diagramas em BPMN. O grupo viu que o conhecimento preciso do modo operacional da organização e do problema são fatores decisivos para a construção de uma boa solução. Contou-se com o fato de um dos integrantes do grupo já ter tido conversas com os gerentes e fundadores da Vinta. Isso fez com que as dúvidas fossem sanadas rapidamente e sem ambiguidades. A forma para resolver o problema era completamente dependente da lembrança e organização dos gerentes, além de exigir boa comunicação entre eles, o que acrescenta complexidade ao trabalho realizado. A fim de permitir que o gerente de projeto tenha o cálculo das horas trabalhadas feito mais fácil e incrementalmente, o sistema permite que reporte as horas trabalhadas aos poucos. Enquanto tiver colaborador a informar horas trabalhadas, o gerente de projeto está informando. Os requisitos organizacionais de não se valer exclusivamente da memória dos gerentes e dar maior agilidade no processo de informar as horas, foram então alcançados. Com as horas sendo informadas diretamente ao sistema e gradualmente dentro prazo estipulado, o gerente financeiro pode acompanhar ao longo do tempo a evolução do desenvolvimento do projeto. Ao fim do projeto, no devido prazo, o gerente financeiro terá todos os dados necessários para informar e cobrar o cliente. Todo o processo de cobrança de horas deixa de ser exclusivamente dependente dos gerentes para ter o sistema como gerenciador e concentrador das informações desejadas. Com a confiabilidade do sistema, o processo fica mais confiável e menos complexo aos gerentes e todos os objetivos organizacionais da organização são de fato alcançados. E por fim, o gerente financeiro pode realizar as cobranças mais facilmente. 14

16 Relatório da equipe Nome Papel Esforço no trabalho Assinatura Ângelo de Sant Ana (assd) Qualidade, BPMN e relatório 25 % Bruno Guisi (bmg) BPMN 25 % Henrique Vicente (hvop) BPMN 20 % Robertson Novelino(rnff) i*, requisitos e relatório 30 % 15