SISTEMA DE CONTROLE E GERENCIAMENTO DE ACADEMIA
índice
- 1. RESUMO
- 2. INTRODUÇÃO
- 3. OBJETIVOS
- 3.1 OBJETIVO GERAL
- 3.2 OBJETIVOS ESPECÍFICOS
- 4. METODOLOGIA
- 4.1 CARACTERIZAÇÕES DA PESQUISA
- 4.2 UNIVERSO
- 4.3 AMOSTRA
- 4.4 INSTRUMENTO DE COLETA
- 4.5 PROCEDIMENTOS
- 4.6 ESTRUTURA DO TRABALHO
- 5. DESENVOLVIMENTO
- 5.1 METODOLOGIAS ÁGEIS
- 5.1.1 Scrum
- 5.1.2 Como surgiu a Metodologia
- 5.1.3 Artefatos
- 5.1.4 Quadro Kanban
- 5.2 Papéis e Responsabilidades
- 5.3 No scrum cada integrante tem seus papeis bem definidos dentre eles:
- 5.3.1 O Product Owner (PO):
- 5.3.2 O Scrum Master (SM):
- 5.3.3 Os Membros do Time:
- 5.4 Ciclo de vida do Scrum
- 5.5 CERIMÔNIAS SCRUM (CERIMONIES)
- 5.5.1 Daily Scrum (Reuniões Diárias)
- 5.5.2 Sprint Planning (Reunião de Planejamento da Sprint)
- 5.5.3 Sprint Review
- 5.5.4 Sprint Retrospective
- 5.6 VANTAGENS E DESVANTAGENS
- 5.7 ICONIX
- 5.7.1 Requisitos
- 5.7.2 Análise / Design Preliminar
- 5.7.3 Projeto Detalhado
- 5.7.4 Implementação
- 6. TECNOLOGIA PROPOSTA
- 6.1 LINGUAGEM DE PROGRAMAÇÃO
- 6.2 ANÁLISE DE SISTEMAS
- 6.3 DELPHI
- 6.4 MS SQL SERVER
- 6.5 Astah Community
- 7. ANÁLISE DE SISTEMAS EXISTENTES
- 7.1 EMPRESA SOFTGESTOR
- 7.2 Academia
- 7.3 EMPRESA POWERSYSTEM TI
- 7.3.1 Powergym
- 7.4 COMPARAÇÃO
- 8. MODELAGEM DO SISTEMA DE GERENCIAMENTO E CONTROLE DE ACADEMIA
- 8.1 Lista de funcionalidades
- 8.2 Protótipos do Sistema
- 8.3 Casos de uso
- 8.4 Fluxogramas de processos
- 8.5 Diagramas de Domínio
- 8.6 DER Proposto
- 9. CONSIDERAÇÕES FINAIS
- 10. REFERÊNCIAS
O texto publicado foi encaminhado por um usuário do site por meio do canal colaborativo Monografias. Brasil Escola não se responsabiliza pelo conteúdo do artigo publicado, que é de total responsabilidade do autor . Para acessar os textos produzidos pelo site, acesse: https://www.brasilescola.com.
1. RESUMO
Com o aumento da necessidade que as pessoas vêm buscando de um “corpo perfeito” e uma vida saudável e prolongada vem surgindo cada vez mais no mercado de Academias. Com a necessidade de acompanhar as atividades das academias na parte administrativa e financeira é necessário que tenha um apoio por parte da Tecnologia para acompanhamento do seu desenvolvimento. Os proprietários das academias vêm procurando suprir suas necessidades de modo eficaz e seguro no intuito de suprir essa questão, pensando nisso o sistema será desenvolvido para a necessidade do ambiente corporativo da academia, onde o sistema terá todo e qualquer atendimento.
PALAVRAS CHAVE: Academia. Desenvolvimento. Sistema.
ABSTRACT: With the increased need that people have been seeking a "perfect body" and a long and healthy life are appearing increasingly in the market Academies. With the need to monitor the activities of the academies in the administrative and financial information you need to have a support from the Technology for monitoring their development. The owners of the academies have been trying to meet their needs in an effective and safe in order to overcome this issue, thinking that the system will be developed for the needs of the business environment of the academy, where the system will need any assistance.
KEYWORD: Academy. Development. System.
2. INTRODUÇÃO
O termo Academia tem sua origem na Grécia, em torno do século III AC, quando Platão passou a reunir pensadores que discutiam questões filosóficas em um local chamado Jardins de Akademus (herói Ateniense). O grupo passou a ser conhecido por Akademia. Com o tempo, a reunião de pessoas especializadas em uma determinada área também passou a receber a mesma denominação. Mais tarde o termo passou a serem usadas também para designar estabelecimentos de ensino superior e posteriormente escolas onde se ministram práticas desportivas, artísticas e outras. Sociedades de caráter científico, artístico ou literário também passaram a ser denominadas de academia. Atualmente, quando nos referimos genericamente à Academia, estamos nos referindo ao sistema educacional e ao meio intelectual como um todo. (AZEREDO, 2010).
A grande demanda de pessoas em academias e pela busca de um Estilo de Vida Saudáveis e a Prevenção das Doenças. "Estilo de Vida" é um conceito amplo que inclui a pessoa como um todo, e que tem muitos aspectos. Os aspectos do estilo de vida se combinam para influenciar a saúde individual em todas as áreas: Física, Mental, Espiritual e Social. O estilo de vida inclui as relações de trabalho, recreativas, e em casa e na família. Um bom estilo de vida deve ser desenvolvido o mais cedo possível em sua vida - quanto mais jovem melhor; estes hábitos devem ser mantidos durante a vida adulta e na idade madura. Fatores modificáveis do estilo de vida são a causa de 50% das mortes, Mais de 80% das mortes atribuídas à obesidade ocorreram em pessoas com um índice de massa corporal de 30 ou mais (entre as 10 causas mais importantes), incluindo: Doenças cardíacas, Câncer, Derrame cerebral, Acidentes, Doença pulmonar crônica, Hipertensão arterial, Diabetes, Aumento da Morbidade, Litíase biliar, Osteoartrite. Por conta de todos estes fatores se deu o alto índice de pessoas buscando as academias como forma de vida ativa, de atividade física. (BOA SAÚDE, 2002).
Através dos tempos, o ser humano vem desenvolvendo sua tecnologia para facilitar sua vida. Desde os mais remotos tempos, vê-se que a busca dessa comodidade impulsionou a espécie humana para desvendar a natureza, suas leis, desenvolver mecanismos, criar métodos, equipamentos, leis, convenções, tudo voltado a trazer-lhe o conforto. É evidente que o salto tecnológico foi acompanhado, primeiramente do choque causado na população, seguida pela adaptação à nova invenção, descoberta ou aperfeiçoamento, passando pela acomodação ao novo recurso, culminando na substituição dessa inovação por outra mais elaborada e que veio suprir novas necessidades humanas, reiniciando todo esse processo.
E com o passar do tempo à humanidade percebeu seu avanço tecnológico, seja através de grandes conquistas que serviram para a evolução, caso típico das tecnologias na área da saúde, seja também através da destruição originada, por exemplo, pelos equipamentos de guerra. No entanto, apesar de toda a conquista tecnológica que culminou no mundo que vivemos hoje, sentimos que o ser humano continua insatisfeito.
A angústia, o medo, a incerteza assolam as esperanças da humanidade em si própria e parece que toda conquista material não é capaz de suprir essa insatisfação. Isso ocorre, porque a humanidade ainda não descobriu o que fazer com todos esses inventos, oriundos de sua capacidade criadora. Claro está que o ser humano continua buscando desenvolver mais a tecnologia, sem, no entanto atribuir a essa conquista algo efetivo que possa auxiliar todos os seres humanos e trazer-lhe, de maneira global, aquele conforto que poderia ser fornecido pelo avanço da tecnologia. Claro está que a tecnologia é voltada para suprir as necessidades de poucos e a insatisfação cresce, na medida em que muitos nada têm e poucos tudo possuem. Com exceção, é evidente, da paz, que nenhum deles foi capaz de conquistar. Diante disso, cabe uma indagação; deveríamos abandonar a busca pelo desenvolvimento tecnológico? É evidente que não. Devemos sim aproveitar nossa potencialidade, cada um na sua área de atuação, e continuar desenvolvendo equipamentos, sistemas, tecnologias que possam trazem a todos os seres humanos a oportunidade de se manifestarem melhor e também de terem seus anseios atingidos. Mas, ressalte-se, para toda a humanidade, e não apenas para um grupo seleto.
Porém, a humanidade não deve pensar no desenvolvimento tecnológico como seu objetivo final, pois a tecnologia alcançada deve servir de subsídio para o ser humano crescer, evoluir. E quando o ser humano descobrir seu objetivo grandioso, que pode até ser ajudar os seres humanos que ainda não se reconheceram aí sim a tecnologia também estará em sintonia com esse objetivo, que é servir ao ser humano. Até essa ocasião, o ser humano continuará insatisfeito com a tecnologia, como também com sua ausência, por não se reconhecer como ser humano. Por isso, a maior conquista não está na tecnologia, mas sim no reconhecer-se como ser humano e saber aplicar todo o conhecimento adquirido para o bem da humanidade (D`ABRONZO, 2006).
Desenvolvidos com tecnologia de ponta, os aparelhos eletrônicos e com design especial ganham cada vez mais adeptos nas academias, dividindo espaço com os conhecidos colchonetes, pesos e barras de sustentação.
Os painéis computadorizados e a aparência futurista podem assustar os malhadores de primeira viagem. Apesar de seus recursos modernos, porém, esses aparelhos não são difíceis de utilizar (KLINGER, 2002).
As novas tendências tecnológicas têm influenciado na vida humana como uma toda a informatização em determinadas áreas de serviços tem trazido um aproveitamento de recursos melhorando significativamente e diminuindo os custos. A tecnologia tem auxiliado nos bons resultados de serviços.
Com o passar do tempo e com a modernidade dos dias atuais, homens e mulheres têm procurado manter a forma. Pode-se notar que as academias de musculação estão expandindo e atraindo um número cada vez maior de adeptos.
Segundo Basu (1986), para se alcançar os objetivos desejados das empresas, a habilidade de tomar decisões rápidas e eficazes é de vital importância para ambos, o administrador e sua organização. No caso das academias o processo de tomar decisões na hora de desenvolver um cronograma específico para o aluno é complicado e demorado, pois deve ser levado em conta todo um histórico do aluno. Muitas vezes o profissional que está desenvolvendo o mesmo pode acabar esquecendo-se de perguntar algo de sumo importância ao aluno e esse mero esquecimento poderá acarretar graves danos à saúde do mesmo.
A tomada de decisão constitui uma ação que requer conhecimento técnico, lógica, dados e informação disponíveis, equacionando as alternativas possíveis. Para isso existem os Sistemas de Informação.
Neste contexto, o sistema proposto auxiliará na tomada de decisão do professor que trabalha na Academia. O software utilizará como princípio os dados sobre a saúde do aluno e os dados fisiológicos, informados sobre o mesmo, apresentando como resposta um cronograma contendo um treino específico para cada situação.
O projeto Gerenciamento de Academias apresentado a Academia Master que tem por finalidade auxiliar no gerenciamento da empresa, fornecendo dados mais precisos sobre o Faturamento/Financeiro, passando a oferecer informações precisa sobre a sua empresa com maior eficiência. Muitas vezes, o empresário deixa de lucrar por desconhecimento, mesmo por mais simples que possa parecer.
Dados da International Health, Racquet & Sportsclub Association (IHRSA), entidade internacional do setor, mostram que, de 2007 para 2010, o número de academias no Brasil dobrou, chegando a 15.551 estabelecimentos, deixando o País atrás apenas dos Estados Unidos. Com faturamento de US$ 1,1 bilhão no último ano, a perspectiva da associação é de que o setor continue em crescimento, impulsionado pela ascensão das classes econômicas C e D (PACTO, 2011).
O Brasil é o maior mercado de academias de ginástica da América Latina e o segundo país do mundo com o maior número de academias, perdendo apenas para os Estados Unidos e gerando um faturamento em torno de R$ 2 bilhões segundo a ACAD - Associação Brasileira de Academias. Estima-se que existam no país cerca de 15 mil academias de ginástica. O setor de Academias de Ginástica no Brasil cresce cerca de 10% ao ano, atendendo a 1,7% da população, representando uma frequência de 3,2 milhões de pessoas (DIÁRIO DE NATAL, 2011).
O Sistema de Academia que propomos desenvolver a piore será entregue a Academia Master, mas após a conclusão do mesmo pretendemos revende-lo no mercado. A área de atuação que buscamos atender será a cidade de Natal no estado do Rio Grande do Norte.
2.1. SISTEMA DE CONTROLE E GERENCIAMENTO DE ACADEMIA
O sistema será moderno e eficiente, SCGA possui inúmeros recursos para o gerenciamento das academias em geral, o software traz opções de controle financeiro, avaliação física, ficha de treinamento e terminal de Consulta.
Controle Financeiro
Será possível controlar receitas e despesas da sua academia de maneira prática e eficiente. Gerencie seus alunos, matrículas, controle de inadimplências, funcionários entre outras funcionalidades.
Avaliação Física
Gerencie e acompanhe a avaliação física de todos os alunos da academia com o Sistema SCGA.
Ficha de Treinamento
Não perca mais tempo na sala de musculação. Monte e imprima e acompanhe facilmente a ficha de treinamento dos seus alunos pelo computador.
Terminal de consulta
Com o Terminal, os alunos podem consultar os pagamentos, a frequência, a avaliação física ou a ficha de treinamento na própria academia.
2.2. PROCESSOS DE NEGÓCIO
O processo inicia com o atendimento aos clientes, onde na primeira parte será feita a sua matricula, depois o cliente ira escolher a modalidade que deseja participar e então se cadastrar na mesma pra que assim seja feita a cobrança, onde apos o pagamento se conclui a etapa de matricula do aluno.
O próximo passo será a anotação dos dados para a avaliação física para dizer se o aluno estando apto ou não a realizar aquela modalidade por ele escolhida.
Neste momento o aluno estando apto será feita a sua ficha de treinamento para acompanhamento do seu treinamento nas modalidades escolhidas pelo aluno, o mesmo poderá acompanhar em sua rotina na academia como anda seu desempenho por um terminal de consulta.
3. OBJETIVOS
3.1. OBJETIVO GERAL
Tem como objetivo informatizar o Gerenciamento Financeiro/Faturamento, auxiliando a empresa na aquisição de informações mais detalhadas e precisas com relação parte Financeira. O objetivo desse trabalho é projetar e implementar um sistema , que vai fazer a administração da academia, de forma a solucionar os problemas levantados anteriormente. O sistema deve permitir que os dados informados dos alunos, fiquem armazenados, para acompanhamento dos professores em suas rotinas de treinamento diárias e avaliações físicas, podendo também emitir cobranças.
3.2. OBJETIVOS ESPECÍFICOS
-
Resolver problemas com o controle e armazenamento de dados;
-
Auxiliar no planejamento baseado em estatísticas;
-
Substituir sistema atual da empresa;
-
Suprir problemas de inconsistências de dados;
-
Prover suporte e manutenção ao sistema;
-
Treinamento dos funcionários;
-
Auxiliar no processo de tomada de decisão do profissional que atua na academia;
-
Automatizar o controle dos cronogramas, dispensando o uso de fichas manuais que facilmente são extraviadas pelos próprios alunos;
4. METODOLOGIA
4.1. CARACTERIZAÇÕES DA PESQUISA
Quanto ao estudo foi caracterizada como descritiva de natureza quantitativa e qualitativa, de campo e com um corte transversal no tempo entre agosto e novembro de 2010, ao qual se pretende analisar. De acordo com Andrade, (2006) na pesquisa do tipo descritiva, os fatos são observados, registrados, analisados, classificados e interpretados, sem a intervenção do pesquisador. Isso significa que os fenômenos do mundo físico e humano são estudados, mas não manipulados pelo pesquisador.
4.2. UNIVERSO
O responsável por esta pesquisa será o proprietário da academia Master da cidade do Natal. Aonde se averiguou a necessidade da informatização do sistema para a sua empresa.
4.3. AMOSTRA
Foi investigada a amostra do atual software em sua empresa, e a estrutura interna da academia, e estudamos mais dois softwares atuais no mercado fazendo assim uma engenharia reversa para termos de base na implementação de nosso software.
A amostra final pesquisada resultou em vários critérios para serem analisados e implementados no software a qual propomos a desenvolver. Por meio de entrevista com o dirigente da academia.
A partir dessa análise, foram obtidos cinco fatores distribuídos entre as necessidades que à academia apresenta em ter um software específico, que foram: Resolver problema com o controle e armazenamento de dados, Auxiliar no planejamento baseado em estatísticas, Substituir sistema atual da empresa, Suprir problemas de inconsistências de dados e Prover suporte e manutenção ao sistema.
4.4. INSTRUMENTO DE COLETA
As informações foram obtidas por meio da aplicação de uma entrevista com o gestor, conduzido por um roteiro elaborado previamente, seguindo uma ordem preestabelecida, permitindo ao entrevistador a qual será respondido por alguma pessoa responsável pelas unidades, acrescentar perguntas de esclarecimento quando necessário, (LAVILLE; DIONNE, 1999).
O tema estabelecido a priori foi: Sistema de Controle e Gerenciamento de Academia. Visando à melhoria do gerenciamento da academia e acompanhamento de seus clientes.
Para a coleta de dados (entrevista) buscou identificar e destacar a importância do papel de um Sistema informatizado no âmbito da academia. A coleta de dados e informações para análise foi feita de forma sucinta e descritiva.
O tratamento dos dados seguiu as características da análise de conteúdo permitindo extrair da entrevista. Essa técnica de análise dos dados é caracterizada pela criação de temas e categorias, sendo ambas as estratégias de mapear os dados para facilitar sua correlação e compreensão. No caso desse estudo, as representações que se fazem presentes ou ausentes nas necessidades que a academia apresenta em ter um Sistema especificam.
4.5. PROCEDIMENTOS
O estudo foi constituído por softwares presentes no mercado, inseridos em todo Brasil. Após a seleção entramos em contato com o gestor, que participou de forma voluntária do estudo e foram devidamente informados sobre os objetivos da pesquisa por meio de uma proposta apresentada. As informações foram obtidas por meio da aplicação de um questionário estruturado conduzida por um roteiro elaborado previamente, seguindo uma ordem preestabelecida, permitindo ao entrevistador acrescentar perguntas de esclarecimento quando necessário.
4.6. ESTRUTURA DO TRABALHO
Na parte inicial, desse trabalho, foi apresentada uma descrição sobre o modelo do sistema.
Mais a frente, será detalhado o projeto para o novo sistema que será implementado para atender os requisitos que o aplicativo atual não atende.
Em seguida, será feita uma breve apresentação sobre a metodologia Scrum e Iconix que será usada nesse projeto.
Será feita ainda, uma breve descrição sobre as ferramentas de Software que serão usadas na fase de projeto a implementação. Será usada a ferramenta de modelagem Astah Community para modelagem dos diagramas UML, a linguagem de programação Delphi, o banco de dados MS Sql Server.
5. DESENVOLVIMENTO
5.1. METODOLOGIAS ÁGEIS
Decidimos utilizar o Scrum para auxiliar no desenvolvimento do projeto e o Iconix para facilitar na modelagem do projeto, juntando assim as duas ferramentas para auxilio nas tomadas de decisões.
5.1.1. Scrum
É um framework dentro do qual você pode empregar diversos processos e técnicas, usado para organizar as equipes e fazer um trabalho de melhor qualidade. Ele permite aos times escolher a quantidade de trabalho a ser feito e decidir de que maneira deverá ser feito, de forma a tornar o ambiente de trabalho mais agradável. É um processo ágil para gerenciamento de projetos, baseado em inspeção e adaptação, escalável para projetos grandes, longos e distribuídos. (SCHWABER; SUTHERLAND, 2010, p. 3)
5.1.2. Como surgiu a Metodologia
O termo vem de um estudo de 1986 feitos pelos estudiosos Takeuchi e Nonaka publicado na revista Harvard Business Review. Na publicação, ambos dizem que projetos que utilizam pequenos times com funcionalidades cruzadas historicamente produzem melhores resultados. Esses times eram como a formação Scrum do Rugby, em que o time oferece um tipo de proteção à jogada. Jeff Sutherland desenvolveu o processo Scrum na Easel Corporation em 1993. Ken Schwaber formalizou o processo para a indústria de software e publicou o primeiro paper sobre Scrum.
O Scrum visa liderança e colaboração por parte de seus integrantes e não o comando e controle, pois dessa forma não permitiria:
-
Processar informações, nem tomar decisões rapidamente.
-
Não envolve ou motiva ao trabalho.
-
Não propicia responsabilidade diária sobre o andamento da equipe.
5.1.3. Artefatos
Os artefatos SCRUM são as ferramentas básicas para se trabalhar com este modelo de desenvolvimento. Estes artefatos servem como guias e indicadores durante o processo. São divididas em três: Product Backlog, Sprint Backlog, Impediment List, Sprint Burndown e Sprint BurnUp.
Product Backlog é a lista que contém os requisitos do projeto. Aqui temos todas as necessidades e/ou vontades do Product Owner para o projeto. Este é um artefato "vivo", pois será priorizado e re-priorizado ao longo do projeto de acordo com a visão do P.O. Uma forma ágil de gerenciar e manter seu Product Backlog é por meio das user stories. Utilizando essa abordagem você verá muitos resultados interessantes em seu processo de engenharia. Mas, como já dissemos o Scrum não é um processo de engenharia então você pode utilizar o que quiser pra manter seu Product Backlog (Casos de Uso, Requisitos, Especificação, etc), desde é claro que o P.O reconheça valor nesses documentos e que eles sejam claros para o time.
Impediment List é a lista com os impedimentos do Time, na qual o S.M deverá trabalhar.
Sprint Backlog possui as atividades nas quais o Time vai atuar dentro de uma Sprint. Essas atividades são planejadas pelo Time durante a reunião de planejamento da Sprint. Este também é conhecido por ser representado pela Kanban, provavelmente um dos símbolos mais associados ao Scrum.
Sprint Burndown é um gráfico com as informações referentes a execução do Sprint. O eixo X mostra os dias de trabalho do Sprint e o eixo Y mostra a quantidade de esforço necessária para terminar a Sprint. A representação do esforço necessário pode ser em horas reais de trabalho.
Este gráfico mostra a execução indo de cima para baixo com relação ao esforço necessário de execução e da esquerda para direita com relação aos dias de trabalho.
Sprint Burnup pode mostrar mais informações do que um gráfico burndown, porque tem uma linha que mostra quanto o trabalho está no projeto como um todo (o escopo de trabalho) .
O gráfico burnup apresenta trabalho entregue até atual momento para prever se a data de lançamento será cumprida.
Resumindo, temos informações de quanto à equipe esta trabalhando para final do Sprint.
5.1.4. Quadro Kanban
No Scrum temos uma característica marcante que é o quadro de acompanhamentos, onde todo o time pode verificar como estão ao passar dos dias, esse é geralmente dividido em partes e situações atuais:
-
Item estimado na Sprint
-
Tarefas
-
Em análise
-
Em desenvolvimento
-
Em teste
-
Concluído
5.2. Papéis e Responsabilidades
5.3. No scrum cada integrante tem seus papeis bem definidos dentre eles:
5.3.1. O Product Owner (PO):
-
Define funcionalidades
-
Faz o plano de Release
-
Product vision
-
ROI
-
Priorização
-
Ajusta escopo
-
Aceita ou rejeita um Sprint
-
Disponibiliza técnicos de domínio
5.3.2. O Scrum Master (SM):
-
Liderança
-
Cativa valores e princípios
-
Remove impedimentos
-
Garante a produtividade
-
Colaboração entre papeis
-
Protege o time de interferências
5.3.3. Os Membros do Time:
-
Entre 5 a 8 membros
-
Auto-organização
-
Comprometimento
-
Colaboração
-
Compartilhar conhecimento
-
Estimar complexidade de forma realista
-
Meta do Sprint
-
Participar das reuniões diárias
-
Manifestar impedimentos
Product Owner (P.O) é o dono do produto. Ele possui a visão do retorno que o projeto trará para a empresa e para os envolvidos, logo sua missão é cuidar do Product Backlog, planejar releases, priorizar requisitos e passar ao time uma visão clara sobre os objetivos do projeto. É muito indicado então que o P.O seja alguém do lado do cliente.
ScrumMaster (S.M) exerce um papel de liderança no processo, mas ele não é um gerente de projetos. O papel de S.M não possui autoridade alguma perante o P.O ou o Time. A responsabilidade do Scrum Master é manter o foco no processo, remover impedimentos da equipe e auxiliar na comunicação entre equipe e P.O.
Os membros do Time é o conjunto de pessoas que implementará o projeto. É composto por uma equipe multidisciplinar que tem a característica da autogestão. A responsabilidade do Time é manter a autogestão de suas atividades, planejar as Sprints, assumir metas com o P.O e dar feedback sobre os impedimentos para o S.M.
Então vejamos:
-
O Product Owner gerencia: Escopo, prazo (datas de entregas) e acompanha o ROI (medição e análise);
-
O ScrumMaster gerencia: Processo, risco (impedimentos) e planejamento (atingir metas);
-
Os Membros do Time gerenciam: Configuração, riscos, requisitos e planejamento.
5.4. Ciclo de vida do Scrum
O ciclo de vida do Scrum tem o seu ciclo composto por uma série de iterações bem definidas, cada uma com duração de duas a quatro semanas, chamada Sprints.
Antes de cada Sprint, realiza-se uma reunião de planejamento (Sprint Planning Meeting) em que os membros do time têm contato com o Product Owner para selecionar e estimar os itens do Product Backlog que acreditam conseguir entregar ao final da Sprint, chamado Sprint Backlog.
A próxima fase é a execução da Sprint. Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias (Daily Meeting) de não mais que 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown.
Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão (Sprint Review), em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido.
Logo em seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições aprendidas, com o objetivo de melhorar o processo, time e/ou produto para a próxima Sprint.
5.5. CERIMÔNIAS SCRUM (CERIMONIES)
5.5.1. Daily Scrum (Reuniões Diárias)
A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.
Os Daily Scrums normalmente são realizados no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.
Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.
O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:
-
O que você fez ontem?
-
O que você fará hoje?
-
Há algum impedimento no seu caminho?
Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.
Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.
5.5.2. Sprint Planning (Reunião de Planejamento da Sprint)
A Sprint Planning Meeting é atendido pelo Product Owner, Scrum Master, todo o Scrum Team, e representantes de qualquer interessado e de gestão adequados ou cliente.
Durante a reunião de planejamento do sprint o proprietário do produto descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas bastante durante esta reunião para que eles possam sair após a reunião e determinar as tarefas que eles vão passar a partir do product backlog para o sprint backlog.
O proprietário do produto não tem que descrever cada item que está sendo monitorada no product backlog. Dependendo do tamanho do atraso e da velocidade da equipe pode ser suficiente para descrever apenas os itens de alta prioridade, salvando a discussão de itens de menor prioridade para o sprint planejamento próxima reunião. Normalmente, o Scrum Team irá fornecer orientação, quando eles começam a ficar mais na lista de atrasos do que sei que poderia ser feito no próximo sprint.
Coletivamente, a equipe Scrum e o dono do produto define uma meta de sprint, que é uma breve descrição do que a corrida vai tentar alcançar. O sucesso do sprint, posteriormente, serão avaliados durante a Sprint Review Meeting contra o objetivo do sprint, e não contra cada item específico selecionadas a partir do product backlog.
Após a reunião de planejamento do sprint, a equipe Scrum atende separadamente para discutir o que ouviu e decidir o quanto eles podem comprometer-se a, durante o sprint seguinte. Em alguns casos, haverá negociação com o proprietário do produto, mas ele sempre será até o time para determinar o quanto eles podem comprometer a concluir.
Existem diversas técnicas de estimativas que podem ser utilizadas em projetos Scrum.
O Planning Poker é uma das mais populares, onde se utilizam cartas numeradas seguindo a tabela de Fibonacci.
5.5.3. Sprint Review
Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.
Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.
Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.
5.5.4. Sprint Retrospective
A Sprint Retrospective é uma das ferramentas mais importantes para que você obtenha sucesso com Scrum.
Está é a oportunidade que o time tem para discutir sobre o que funcionou e o que não durante a Sprint.
Product Owner, Scrum Máster e os membros do time devem participar da retrospectiva. Uma boa estratégia é convidar alguém neutro para facilitar a reunião.
A estrutura da Sprint Retrospective é bem simples. Divida um quadro branco em duas áreas com os seguintes títulos: “O que funcionou bem” e “O que pode ser melhorado”. Após isso, cada membro deve colocar post-its em cada uma das áreas indicando os itens que, em sua opinião, merecem está ali.
Então, o time visualiza os itens citados, discute sobre e planeja ações a serem tomadas para a próxima Sprint.
5.6. VANTAGENS E DESVANTAGENS
O Scrum tem como principais vantagens, segundo seus entusiastas, a velocidade, o fato de evitar surpresas com o cronograma ou com resultados – já que as reuniões diárias preveem esse controle – e também sobre visibilidade. Ao fim das semanas é feita uma Sprint Review, que é a análise daquele módulo. Ao término, acontece uma retrospectiva. Por outro lado, a sensação de informalidade é a grande desvantagem do Scrum. Não há no escopo a documentação formal do software a ser desenvolvido, por exemplo, ele é simplesmente desenvolvido! Ele só é criado caso os envolvidos considerem necessário.
5.7. ICONIX
O Iconix e uma metodologia de desenvolvimento de software que tem se destacado através de uma abordagem equilibrada em relação aos processos que exigem um grande volume de documentação e as metodologias ágeis. Podemos perceber isso nas etapas iniciais, pois se começa com um diagrama de domínio em conjunto com a construção das interfaces gráficas SILVA & VIDEIRA (2001, apud BONA, 2002, p. 60).
As interfaces gráficas facilitam a comunicação com os usuários, que poderão expressar suas opiniões sobre o funcionamento do sistema, e por sua vez essa resposta ajudara nas demais etapas em todo o processo de desenvolvimento. Segue abaixo representação na figura 1.
Figura 1 - Visão do ICONIX ROSENBERG & SCOTT (1999, apud Martins, et al., 2005, p.2)
O Processo ICONIX é dividido em fluxos de trabalho dinâmicos e estáticos, que são altamente interativos: você pode passar por uma iteração de todo o processo para um lote pequeno de casos de uso, todo o caminho para o código-fonte e testes de unidade. Por esta razão, o Processo ICONIX é bem adequado para projetos ágeis, onde feedback rápido é necessário em fatores tais como os requisitos, o design, e estimativas.
5.7.1. Requisitos
- Requisitos funcionais: Definir o que o sistema deve ser capaz de fazer. Dependendo de como o projeto é organizado, ou você estará envolvido na criação de requisitos funcionais ou os requisitos serão "proferida do alto" por um cliente ou uma equipe de analistas de negócios.
-
Modelagem de domínio: Compreender o espaço do problema em termos inequívocos.
-
Requisitos comportamentais: Define como o usuário e o sistema irá interagir. Recomendamos que você comece com um protótipo de GUI e identificar todos os casos de uso que você vai implementar, ou pelo menos chegar a uma lista de primeira passagem de casos de uso, que você seria razoável esperar a mudar à medida que explora os requisitos de forma mais aprofundada.
-
Revisão de Requisitos: Certifique-se que o texto do caso de uso corresponde às expectativas do cliente. Note que você pode rever os casos de uso em pequenos lotes, pouco antes de projetá-los. Depois, em cada iteração (ou seja, para um lote pequeno de casos de uso), você faça o seguinte.
5.7.2. Análise / Design Preliminar
- Análise de robustez: Desenhe um diagrama de robustez (uma "imagem de objeto" dos passos em um caso de uso), reescrevendo o texto do caso de uso que você vá.
-
Atualizar o modelo de domínio, enquanto você está escrevendo o caso de uso e desenho do diagrama de robustez. Aqui você vai descobrir a faltar às aulas, as ambiguidades correta, e adicionar atributos para os objetos de domínio (por exemplo, identificar que um objeto do livro tem um título, autor, sinopse, etc.)
-
Nome de todas as funções de software lógico (controladores) necessário para fazer funcionar o caso de uso.
-
Reescrever os casos de uso primeiro projeto.
5.7.3. Projeto Detalhado
- Sequência de diagramação: Desenhe um diagrama de sequência (um diagrama de sequência por caso de uso) para mostrar em detalhes como você vai implementar o caso de uso. A principal função da sequência de diagramação é alocar comportamento às suas classes.
-
Atualizar o modelo de domínio, enquanto você está desenhando o diagrama de sequência, e adicione operações aos objetos de domínio. Por esta fase, os objetos de domínio são realmente classes de domínio, ou entidades, e o modelo de domínio deve ser rápido se tornando um modelo estático, ou de classe diagrama de uma parte crucial do seu projeto detalhado.
-
Limpar o modelo estático.
5.7.4. Implementação
- Codificação testes / unidade: Escreva o código e os testes de unidade. (Ou, dependendo de suas preferências, escrever os testes de unidade e depois o código).
-
Testes de integração e cenário: Base os testes de integração sobre os casos de uso, de modo que você está testando tanto o curso básico e os cursos alternativos.
-
Realizar uma revisão de código e atualização do modelo para se preparar para a próxima rodada de trabalho de desenvolvimento.
6. TECNOLOGIA PROPOSTA
6.1. LINGUAGEM DE PROGRAMAÇÃO
“Uma linguagem de Programação (LP) é uma ferramenta utilizada pelo profissional de computação para escrever programas, isto é, conjuntos de instruções a serem seguidas pelo computador para realizar um determinado processo.” (VAREJÃO, 2004, p. 1).
Para desenvolver um sistema automatizado, uma linguagem de programação é essencial, pois é nesta linguagem que o programador irá escrever o código que será interpretado pelo computador.
As principais características de uma Linguagem de Programação são:
-
Legibilidade: facilidade para se ler e entender um programa;
-
Redigibilidade: possibilita ao programador se concentrar nos algoritmos centrais do programa, sem se preocupar com aspectos de pouca importância para a resolução do problema;
-
Confiabilidade: relacionada com os mecanismos fornecidos pela linguagem para construir programas confiáveis;
-
Eficiência: relacionada com o consumo de memória, tempo de execução entre outros aspectos de determinada aplicação desenvolvida utilizando uma linguagem específica;
-
Reusabilidade: possibilidade de reutilizar o mesmo código para diversas aplicações;
-
Modificabilidade: possibilitar o programador alterar o programa em função de novos requisitos, sem que tais modificações impliquem mudanças em outras partes do programa.
6.2. ANÁLISE DE SISTEMAS
“Por Análise de Sistemas entendemos a fase do desenvolvimento em que se determinarão quais os requisitos do sistema, “o que” o sistema deve fazer, em termos essenciais.” (POMPILHO, 2002, p. 12).
Segundo Pompilho (2002), o objetivo da fase da análise é interpretar e definir a estrutura para um problema ainda não estruturado, e se refere à eficácia do sistema, sem se preocupar no momento com o desempenho.
Sendo assim as tecnologias por nos adotadas serão Delphi 7 como linguagem de programação, MS Sql Server como banco de dados, Scrum como metodologia de desenvolvimento e Iconix como metodologia de modelagem.
O Scrum será usado da seguinte forma, todo o escopo do projeto entrará no Product Backlog, faremos a reunião de planejamento (Sprint Planning Meeting) com os Stakeholders, para selecionar e estimar os itens do Product Backlog então de acordo com a necessidade/Prioridade do cliente faremos o primeiro sprint com as tarefas priorizadas e estimadas, que durará e torno de 15 a 30 dias.
Ao final de cada Sprint, faremos uma Reunião de Revisão (Sprint Review), em que o nosso time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido.
Logo em seguida, realizaremos a Reunião de Retrospectiva (Sprint Retrospective), com o objetivo de melhorar o processo, time e/ou produto para a próxima Sprint.
6.3. DELPHI
Delphi (pronuncia-se "dél-fi"), também conhecido como Borland Delphi, é um compilador, uma IDE e uma linguagem de programação, produzido antigamente pela Borland Software Corporation e atualmente produzido pela Embarcadero. O Delphi, originalmente direcionado para a plataforma Windows, chegou a ser usado para desenvolvimento de aplicações nativas para Linux e Mac OS, através do Kylix (o Kylix é um IDE para as linguagens C++ e Object Pascal), e para o framework Microsoft.NET em suas versões mais recentes. O desenvolvimento do Kylix foi descontinuado.
O Delphi é um sistema POO (Programação Orientada a Objetos), o que torna fácil a criação dos fontes, pois quase todo o trabalho de criação da parte gráfica do software é feita pelo sistema, ficando para o programador posicionar e colocar a função de cada objeto.
6.4. MS SQL SERVER
O MS SQL Server é um SGBD - sistema gerenciador de Banco de dados relacional criado pela Microsoft. Com a nova versão o Microsoft SQL Server 2008 é fornecida uma plataforma de dados confiável, produtiva e inteligente que permite que você execute suas aplicações de missão crítica mais exigentes, reduza o tempo e o custo com o desenvolvimento e o gerenciamento de aplicações e entregue percepção que se traduz em ações estratégicas em toda sua organização. O SQL É um Banco de dados robusto e usado por sistemas corporativos dos mais diversos portes.
6.5. Astah Community
A ferramenta Jude Community é uma boa ferramenta de modelagem UML gratuita. Por ser uma versão Community possui algumas limitações. Há uma versão Professional disponível, mas os recursos presentes na versão Community podem suprir a necessidade de grande parte dos artefatos necessários no dia-a-dia. A partir de 2010, a ferramenta será descontinuada, e a Change Vision, empresa responsável pelo Jude, recomenda desde já a utilização da ferramenta que substituirá o Jude, ferramenta esta batizada de Astah. Assim como o Jude, esta ferramenta possui versões Community e Professional. Dentre os recursos da ferramenta estão:
-
Suporte a UML 2.1
-
Diagramas de Classe, Caso de Uso, Sequência, Atividade, Comunicação, Máquina de Estado, Componentes, Implantação, Estrutura de Composição, Objetos e Pacotes.
-
Ajustes de alinhamento e tamanho dos diagramas
-
Impressão dos diagramas
7. ANÁLISE DE SISTEMAS EXISTENTES
Nesta parte do trabalho, foi feita uma pesquisa dos softwares de controle de academia existentes no mercado para coleta de requisitos e funcionalidades.
7.1. EMPRESA SOFTGESTOR
O primeiro software que foi analisado foi o Academia da empresa SoftGestor.
A Softgestor Informática é uma empresa paranaense fundada em 2010, na cidade de Curitiba - PR, com o objetivo de prestar serviços especializados na área de desenvolvimento de softwares e sites, principalmente no seguimento de gestão administrativa, industrial, comercial e serviços. Com uma conceituada carteira de clientes, atende todo o território Nacional e Internacional, com softwares práticos e objetivos adaptados as necessidades do cliente. Por ser uma empresa de desenvolvimento seu foco principal é a criação de soluções de software e sites para o segmento empresarial e comercial (SOFTGESTOR, 2011).
7.2. Academia
O Software Academia na Versão 2011 demonstrou ser bem simples porem capaz de atender todas as necessidades de uma academia, o modulo é dividido em seis partes principais, sendo elas:
-
Cadastros
-
Modalidades
-
Financeiro
-
Ficha
-
Acesso
-
Operacional
Cadastro
Nesta tela é possível cadastrar:
-
Cadastro de alunos
-
Visitantes
-
Professores e Funcionários
-
Fornecedores
-
Agenda
-
Cadastro de produtos
-
Lembretes
Figura 2 – Tela de Cadastro do Sistema Academia.
Todas as opções são relativamente fáceis de manipular com menus de escolha ou digitando as informações solicitadas em cada um dos cadastros supracitados.
Modalidades
Neste momento será definido se o cliente ira fazer Musculação, Spinning entre outros pacotes existente em cada academia, no menus é possível definir horários, turnos e dias da semana e o professor responsável.
Figura 3 – Tela de Modalidade do Sistema Academia.
Financeiro
Essa funcionalidade é possível controlar:
-
Caixa
-
Contas a receber
-
Recibos
-
Demonstrativo
-
Contas a pagar
Que são as funções básicas de uma parte financeira de uma empresa.
Figura 4 – Tela do Financeiro do Sistema Academia.
Ficha
A ficha serve para administrar as medidas e as series de cada aluno, para acompanhamento do professor durante o plano do aluno.
Figura 5 – Tela de Ficha do Sistema Academia.
Acesso
O acesso serve para liberar da entrada do aluno que não esteja inadimplente na academia através de uma catraca.
Operacional
Controla todas as opções do software, podendo fazer o cadastro da academia no mesmo, manipulação de senhas, cadastramento de banco de dados, backups entre outras funcionalidades.
Figura 6 – Tela Operacional do Sistema Academia.
Resumo
Depois de devida analise podemos concluir que este software de aparência singela e simplória tem todas as funções que um software necessita para atender um ambiente corporativo de uma academia seja ela de pequeno e médio porte, apesar de sua aparência suas funções são amplas tanto para a parte operacional como estratégica de uma empresa.
É possível fazer uma demonstração do software ate o limite de 35 acessos, logo em seguida é solicitada uma chave para a licença de uso.
Figura 7 - Print screen da tela principal do Software Academia.
7.3. EMPRESA POWERSYSTEM TI
O segundo software que foi analisado foi o PowerGyn da empresa PowerSystem-TI.
Formada por profissionais com larga experiência em suporte, desenvolvimento de sistemas e automação de empresas, a equipe da POWERSYSTEM-TI analisa a atividade e as necessidades individuais de cada Cliente, a fim de prover a solução de informática que melhor o atenda. Os nossos sistemas são compostos por diferentes módulos, cada qual voltado a uma necessidade específica do empreendimento, porém todos integrados entre si. O resultado é um sistema global, que organiza e une os diferentes setores da empresa, facilitando o dia-a-dia, evitando o desperdício de tempo e de profissionais, garantindo maior eficiência e permitindo a canalização de custos e energia para a obtenção dos resultados empresariais almejados.
Os Clientes da POWERSYSTEM contam com suporte diário e atendimento pessoal, por meio de visitas, telefone, e-mail ou SAC on-line. Os sistemas permitem a atualização remota, via internet, permitindo o rápido atendimento ao Cliente. Além disso, a nossa equipe está sempre pronta para criar novos módulos/rotinas para cada sistema, de modo a atender novos anseios ou necessidades surgidas no curso da prática empresarial.
Os segmentos atendidos são os mais variados, desde Indústria e Comércio (Atacadista e Varejista) até academias, clubes, centros esportivos, clínicas, restaurantes, cursos, dentre outros (POWERSYSTEM TI, 2009).
7.3.1. Powergym
O software PowerGym é um programa bem robusto personalizado com muitas funções e acessórios visando atender toda e qualquer necessidade de uma academia, suas principais funções são:
-
Alunos ou Sócios
-
Modalidades ou atividades
-
Caixa
-
Funcionários
-
Fornecedores
-
Armários
-
Agenda
-
Acessos
Alunos ou Sócios
Este ambiente é possível incluir alunos, editar ou excluir, acompanhar as frequências do mesmo, ver sua situação financeira com a academia, listar suas series e dependentes.
Figura 8 – Tela de Alunos ou Sócios do Sistema PowerGyn.
Modalidades ou atividades
Nessa tela se controla as atividades na academia, sendo elas musculação, Spinning, Yoga entre outras.
Figura 9 – Tela de Modalidades ou Atividades do Sistema PowerGyn.
Caixa
O caixa que é apresentando é o caixa atual (do dia) contendo filtros para acessar outros de tempos diferentes, além de poder abrir o caixa e fazer estornos nessa mesma tela.
Figura 10 – Tela Caixa do Sistema PowerGyn.
Funcionários
Onde o proprietário da academia ira cadastrar seus subordinados e definir acessos ao software da academia, nesta mesma tela é possível ver os acessos do funcionário na academia.
Figura 11 – Tela de Funcionários do Sistema PowerGyn.
Fornecedores
É onde será feito o cadastro dos fornecedores.
Armários
Seria o estoque/almoxarifado da academia, onde os produtos estão armazenados para serem vendidos posteriormente, nessa tela será feita o controlo de todos eles.
Agenda
Essa tela serve para marcar as avaliações dos alunos, fazer acompanhamento de suas serias e frequência às aulas.
Figura 12 – Tela Agenda do Sistema PowerGyn.
Acessos
Controla a entrada e saída dos alunos na academia através de leitores biométricos.
Figura 13 – Tela de Acessos do Sistema PowerGyn.
Resumo
O software apresente enorme beleza para os olhos dos usuários devido as suas enumeras funções e utilidades, algumas muito simples outras muito complexas, apesar disso tudo o software também tem todas as funções que uma empresa de todos os portes pode vim a precisar.
É possível fazer uma demonstração do software ate o limite de 15 dias, logo em seguida é solicitada uma chave para a licença de uso.
O software também apresenta a:
-
Possibilidade de customização e personalização;
-
Suporte e apoio Online (internet), presencial e telefônico;
-
Verifica Impressões digitais em menos de 1 segundo;
-
Agilidade no processo de identificação;
-
Funcionamento local (um micro) ou em rede (cliente/servidor), permitindo também acesso via internet;
-
Nossos sistemas utilizam as mais altas tecnologias do mercado;
-
É desenvolvido em Delphi;
-
Usa o mesmo algoritmo usado pelo FBI para comparações de digitais;
-
Utiliza banco de dados padrão servidor de SQL (Firebird) Freeware, que é usado em empresas como NASA, NOKIA, e outras mais.
Figura 13 - Print screen da tela principal do Software PowerGyn.
7.4. COMPARAÇÃO
O Academia é um software bem simples, com menus básicos e fácil de operar, suas funcionalidades são ótimas para usuários leigos e experientes, mas atende toda a demanda de uma academia.
O PowerGyn é um software bem robusto, com menus complexos e avançados, esses podendo dificultar a vida de muitos usuários caso não venha a ter uma treinamento apropriado para utilização do mesmo, apresenta funções como leitura biométrica para controle da frequência de alunos.
8. MODELAGEM DO SISTEMA DE GERENCIAMENTO E CONTROLE DE ACADEMIA
O Software proposto será prático e objetivo, sendo facilmente adaptadas as necessidades do cliente a fim de prover soluções na área de informática.
O sistema será baseado em diferentes módulos, cada um terá uma necessidade especifica, mas todos serão interligados resultando assim em um sistema global. Para organização da empresa facilitando seu desenvolvimento no dia a dia evitando perca de tempo com manuseio de papeis garantindo assim uma total eficiência nos custos e nos resultados que a empresa obtém atingir.
8.1. Lista de funcionalidades
As Principais Funcionalidades do sistema serão:
-
Matricula de Alunos
-
Contas a Pagar
-
Contas a Receber
-
Caixa
-
Avaliação Física
-
Relatórios
8.2. Protótipos do Sistema
Aluno
Neste ambiente é possível incluir alunos, editar ou excluir, e ver todas as suas informações pessoas, endereço, telefone entre outras informações.
Figura 14 – Tela de Aluno do Sistema SCGA.
Esta tela esta vinculado ao Diagrama Matricular Aluno.
Empresa
Nessa parte do sistema o proprietário poderá definir as informações de sua empresa dada como razão social, nome fantasia entre outros.
Figura 15 – Tela de Configuração da empresa no Sistema SCGA.
Contas a Receber
No contas a Receber o usuário vai incluir valores relacionados aos alunos, matriculas e das modalidades que o mesmo pode exercer na academia.
Figura 16 – Tela das Contas a Receber no Sistema SCGA.
Esta tela esta vinculado ao Diagrama Gerar e Receber Boletos.
Contas a Pagar
No contas a Pagar o usuário vai cadastrar contas que a academia vai ter durante o mês, como exemplo conta de Luz e Telefone.
Figura 17 – Tela das Contas a Pagar no Sistema SCGA.
Esta tela esta vinculado ao Diagrama Lançar e Receber Contas a Pagar.
Modalidades
Aqui será possível cadastras as modalidades que os alunos poderão se matricular, o usuário poderá incluir excluir e modificar as modalidades.
Figura 18 – Tela de Modalidades no Sistema SCGA.
Caixa
Este ambiente tem vários filtros podendo acessar outras datas, além de abrir e fechar o caixa poderá fazer estornos, sangria e suprimento.
Figura 19 – Tela do Caixa no Sistema SCGA.
Esta tela esta vinculado ao Diagrama Movimentar Caixa.
8.3. Casos de uso
Nesse momento vamos apresentar o diagrama de caso de uso, no qual destacamos o usuário do sistema, além de cuidar de todos os cadastros feitos no sistema, também vai fazer a parte da administração do faturamento e financeiro e cadastramento dos alunos e modalidades. E o Aluno onde o mesmo se matricula em uma modalidade, consulta e paga os seus débitos e realiza uma avaliação física para ver se esta apta àquela modalidade a qual ele deseja se inscrever.
Figura 20 – Diagrama de caso de uso Usuario.
Matricular Aluno
O sistema vai apresentar uma tela onde haverá vários campos para se digitar as informações do aluno, onde deve ser preencher os campos nome, sexo, estado civil, data de nascimento, cor ou raça, e-mail, nome do pai e da mãe, CPF, RG, telefone e celular, naturalidade e nacionalidade e o endereço completo e matricula o aluno.
Cadastrar Avaliação Física
Nessa tela o usuário vai informar os dados físicos do aluno, para acompanhamento do profissional de educação física.
Gerar e Receber Boletos
O usuário ira gerar os boletos dos alunos, basta localizar a matricula do aluno, feito isso aparecerão seus dados cadastrais para breve conferencia e assim pode se dar o lançamento das contas baseado nas modalidades em que o mesmo se cadastrou.
Para lançar uma conta basta informa o serviço que seria a modalidade a data de vencimento e o valor a pagar.
Lançar e Receber Contas a Pagar
No contas a pagar o usuário vai informar os dados referente ao mês em que vão ser lançadas as contas, haverá um breve resumo do saldo geral o saldo a pagar e o pago.
Para lançar uma conta basta informar o plano de conta sé é uma aluguel, por exemplo, a data do vencimento o valor a pagar e a situação da conta se já esta paga ou em aberto e a forma de pagamento realizado se foi em dinheiro ou outra forma.
Movimentar Caixa
No caixa será realizada toda a movimentação financeira da academia nele vai apresentar o histórico das contas, data, hora, valor, formas de pagamento, vai informar se o caixa esta em aberto ou fechado terá a possibilidade de realizar filtros de outros caixas de dadas anteriores, e um breve resumo do saldo do caixa como o valor inicial, valores de entrada e de saída e o saldo, pode-se também realizar sangrias e suprimentos do caixa.
Gerar Relatórios
O Usuário poder gerar vários desde relatórios acadêmicos ate relatórios financeiros a parti do sistema.
8.4. Fluxogramas de processos
Efetuar Matrícula
Figura 21 – Fluxograma de Efetuar Matricula.
Contas a pagar Figura 22 – Fluxograma de Contas a Pagar
|
Contas a Receber Figura 23 – Fluxograma de Contas a Receber
|
8.5. Diagramas de Domínio
Figura 24 – Diagrama de Domínio.
8.6. DER Proposto
9. CONSIDERAÇÕES FINAIS
-
Os profissionais da Tecnologia da Informação (TI) desconhecem os diversos campos de atuação inerentes à área academia.
-
O papel do profissional de TI pode atuar em conjunto com outros desenvolvedores e programadores.
-
Cabe ao profissional de TI buscar pela sua aceitação, demonstrando capacidade técnica científico, construindo no referencial teórico, o necessário para uma melhor desenvoltura de seu trabalho.
-
Ações para ampliar a participação deste profissional em equipes multidisciplinares de desenvolvimento.
-
Constatou se a diversidade quanto aos benefícios que o profissional de TI na área academia pode contribuir, servindo como interventor dos padrões de qualidade e eficiência.
-
No desenvolvimento deste projeto foi observado que as academias, que tem objetivo de propiciar uma melhor qualidade necessitam de um sistema informatizado para oferecer um melhor serviço a seus clientes e para controle administrativo.
-
A automação traz inúmeros benefícios, tanto para os administradores quanto para os clientes. Como em qualquer estabelecimento comercial, a satisfação do cliente deve ser o principal foco, pois sem eles a empresa não sobreviveria, principalmente em um ambiente fortemente concorrido. Baseado nesse ponto, o sistema desenvolvido oferece recursos para o cliente visualizar quais atividades foram escolhidas para determinado dia, e fazer o acompanhamento de seus resultados através das avaliações físicas.
10. REFERÊNCIAS
ACADEMIA. Disponível em: Acesso em 23 de Março de 2011.
AVANÇO DA TECNOLOGIA NA VIDA HUMANA. Disponível em: . Acesso em 31 de Março de 2011.
Os negócios mais lucrativos no RN Disponível em: < http://www.diariodenatal.com.br/2011/02/27/economia2_1.php>. Acesso em 06 de Agosto de 2011.
ACADEMIAS SE FORTALECEM NO MERCADO Disponível em: < http://www.pactosolucoes.com.br/blog/?p=1020>. Acesso em 06 de Agosto de 2011.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem de sistemas orientados a objetos através da linguagem de modelagem unificada. 2.ed. Rio de Janeiro: Elsevier, 2007. 369p.
KNIBERG, H. Scrum e XP direto das trincheiras. Disponível em: . Acesso em 10 de Fevereiro de 2011.
MANIFESTO ÁGIL. Disponível em: . Acesso em 10 de Fevereiro de 2011.
POWERSYSTEM. Disponível em: Acesso em 29 de Fevereiro de 2011.
SAÚDE. Disponível em: . Acesso em 23 de Março de 2011.
SCHWABER, K. Guia do Scrum. Disponível em: Acesso em 10 de Fevereiro de 2011.
SOFTGESTOR. Disponível em: Acesso em 29 de Fevereiro de 2011.
TECNOLOGIAS NAS ACADEMIAS. Disponível em: . Acesso em 31 de Março de 2011.
SILVA, Alberto M. R.; VIDEIRA, Carlos A. E. UML, Metodologias e Ferramentas base. Lisboa: Centro Atlântico, 2001 apud BONA, Cristina Avaliação de processos de software: um estudo de caso em XP e ICONIX, dissertação de mestrado, UFSC, 2002.
ANDRADE, M. M. Introdução à Metodologia do Trabalho Científico. 7°ed, 2. Reimpressão. São Paulo: Atlas, 2006.
BASU, Amit, Imprecise reasoning in intelligent decision support systems – tese de doutorado, Universidade de Rochester. EUA, 1986.
LAVILLE, C.; DIONNE, J; SIMAN, L. M. A constituição do saber: manual de metodologia da pesquisa em ciências humanas. Porto Alegre: ARTMED, 1999.
D'ABRONZO, Giuliano Pereira. Tecnologia e a Evolução do Ser Humano. 2006. Disponível em: . Acesso em 31 de Março de 2011.
ANDRADE, F.; LIMA, IURI Sistema Para Administração De Vendas Para Fábrica De Etiquetas – trabalho de conclusão de curso, Universidade Potiguar. 2010.
POMPILHO, S. Análise Essencial: guia prático de Análise de Sistemas. Rio de Janeiro: Ciência Moderna, 2002.
SCHWABER, Ken. Agile Project Management with Scrum. Usa: Microsoft Press, 2004.
SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide. Disponível em: . Acesso em: 31 Março de 2011.
ICONIX Disponível em: Acesso em 29 de Fevereiro de 2011.
DELPHI Disponível em: Acesso em 18 de junho de 2011.
MS SQL SERVER Disponível em: Acesso em 18 de junho de 2011.
ASTAH COMMUNITY Disponível em: < http://onipotentes.blogspot.com/2010/09/astah-community-62.html> Acesso em 18 de junho de 2011.
Escrito por Ítalo Bruno Duarte da Luz e Thiago Araújo Campos
Publicado por: Thiago Araújo Campos
O texto publicado foi encaminhado por um usuário do site por meio do canal colaborativo Monografias. Brasil Escola não se responsabiliza pelo conteúdo do artigo publicado, que é de total responsabilidade do autor . Para acessar os textos produzidos pelo site, acesse: https://www.brasilescola.com.