UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE TECNOLOGIA EM ANALISE E DESENVOLVIMENTO DE SISTEMAS Professor: Adriel Ziesemer Disciplina: Engenharia de Software TRABALHO ACADÊMICO Cristian Santos - nº Guilherme Morgado - nº Ricardo Torales - nº Rio Grande, 11 de maio 2011 Página 1

2 Relatório Geral Sistemas Oficina Mecânica Inspiration Corporation Página 2

3 Conteúdo Relatório Geral... 1 Introdução... 4 Estudo de Viabilidade... 5 Cronograma... 6 Análise de Resquisito... 7 Requisitos Funcionais... 8 Requisitos Não Funcionais... 8 Caso de Uso...Erro! Indicador não definido.9 Caso de Uso Expandido Modelo de Processo Diagramas de Classe Estimativa de Custos Gerenciamento de Recursos Humanos Finalização Página 3

4 Introdução A Inspiration Corporation foi requisitada para trabalhar no desenvolvimento de um novo sistema para uma oficina mecânica. A partir desse ponto, alocamos uma equipe de três profissionais do ramo de TI(Tecnologia da Informação) para conhecer a oficina e fazer um trabalho de compreendimento de necessidades. Foi realizada uma entrevista com o dono e os funcionários da oficina, e foi detectado os principais pontos positivos e negativos do sistema atual deles. Para isso, foi aplicado um questionário padrão da Inspiration para casos de Brainstorm. As perguntas são de curtas respostas, porém indicam tudo o que precisamos saber para trabalhar em cima de um projeto novo e concreto. As perguntas: Qual a principal deficiência no atual sistema? O acesso as informações são claras? O tempo de resposta entre as operações é satisfatório? As atuais funções do sistema atendem as necessidades? Caso não, quais adicionar? Quais as melhorias sugeridas para o próximo sistema? Após a obtenção de respostas dessas perguntas, realizadas uma série de conversações sobre detalhes do projeto, como custos, viabilidade, aproveitamento do banco de dados antigo, entregáveis e prazos. Ainda foi pedido para nossa equipe, que testassemos o sistema defasado, sendo questionado se teríamos novos pontos a relatar e propor mudanças. O próximo passo do projeto é o benchmarking, que consiste na procura de outros sistemas utilizados por outras oficinas mecânicas para ver se há algumas modificações que seriam de grande ajuda no sistema novo. Página 4

5 Estudo de Viabilidade Conforme citado no levantamento de informações feito pela nossa equipe, será analisada uma forma de realizar um sistema com uso da tecnologia da informação a fim de suprir as necessidades exigidas pelo cliente em questão. Com isso, teremos uma resposta se o sistema pode ou não ser reformulado, analisando a melhor alternativa a ser seguida, de maneira que beneficie os usuários interessados. Um cadastro de clientes, cadastro de produtos, uma forma de verificar no sistema se os produtos estão no estoque e sua quantidade atual (ou seja, a cada venda de um produto, o sistema retira automaticamente do estoque),além de uma consulta de clientes(demonstrando qual a forma de pagamentos destes,e se há alguma compra em débito) e a geração da Nota Fiscal. Aqui, a equipe projetará alternativas possíveis, vantagens e desvantagens do novo sistema. Trabalham as necessidades do cliente, projeto, objetivos, políticas e se comprometem com a conclusão exigida pela empresa. Qualquer problema com o sistema - em termos de interface, funcionalidades, restrições e funções tendem a ser corrigidas rapidamente (em torno de sete dias - no máximo). Enfim, esse é o momento em que os contratados vão analisar e optar por uma alternativa viável no projeto. Dentro desta análise, estão os testes de viabilidades - operacional e técnico. O operacional é basicamente uma avaliação de como o cliente se sente a respeito do projeto. São avaliadas as fases do projeto, aceitação de soluções, entre outros. Para isto teremos uma reunião e este documento será apresentado ao possível cliente, caso todos decidam pela continuação do projeto, daremos andamento. Já o técnico é uma avaliação da disponibilidade de recursos e soluções técnicas, é efetuado um estudo do grau de necessidade dos problemas do atual sistema, tentando resolver da melhor forma possível. Serão analisados também alguns pontos como: A solução/tecnologia proposta é prática? Está sendo utilizada a tecnologia necessária? O conhecimento técnico está de acordo com a necessidade? Após toda a análise e viabilidade de projeto é efetuado o prazo para entrega do projeto e a estimativa de custo deste. É marcado o momento do início do projeto e da conclusão. Os três desenvolvedores optaram pelo prazo de doze meses para a entrega do projeto, realizando sua implantação na farmácia. O custo do sistema envolve vários fatores, como os custos com os profissionais da área, utilização das máquinas, manutenção de software e hardware, licença do software, material, energia e entre outros. E, o sistema acompanha a garantia de qualidade de 12 meses para qualquer tipo de problema do sistema, a empresa se encarrega de um atendimento rápido para os problemas. Página 5

6 Cronograma O que é? O cronograma é um instrumento de planejamento e controle semelhante a um diagrama, em que são definidas e detalhadas minuciosamente as atividades a serem executadas durante um período estimado. Em nível gerencial, um cronograma é um artefato de controle importante para levantamento dos custos de um projeto e, a partir deste artefato, pode ser feita uma análise de viabilidade antes da aprovação final para a realização do projeto. O cronograma, resumido em apenas três recursos para o desenvolvimento desse projeto, será breve, porém com uma duração maior para que haja maior abrangência do conteúdo que será proposto no escopo do projeto. Esse escopo, que será fundamental para o desenvolvimento desse projeto, será entregue em breve aos seus devidos responsáveis para que saibam de suas incumbências. A seguir, a tabela de Recursos x Atividades: Recursos/Atividades Fase um Fase dois Fase três Fase quatro Fase cinco Total Guilherme Mor gado Ricardo Torales Cristian Santos * tempo gasto em horas Legenda: Fase um: Análise e Percepção; Fase dois: Prototipação; Fase três: Desenvolvimento; Fase quatro: Implementação; Fase cinco: Documentação. O tempo orçado de trabalho é relativamente baixo, o que provavelmente não deverá resultar na entrega rápida do projeto, considerando que todos os recursos são alocados em outras empresas também e/ou possuem outras ocupações que não permitam que sejam empregadas no mínimo 6 horas por dia para desenvolvimento do projeto. Página 6

7 A seguir, a tabela de Entregas x Atividades: Entregas/Atividades Fase um Fase dois Fase três Fase quatro Fase cinco Pacote um 05/05 05/05 05/05 05/05 05/05 Pacote dois 07/05 07/05 07/05 07/05 07/05 Legenda: Fase um: Análise e Percepção; Fase dois: Prototipação; Fase três: Desenvolvimento; Fase quatro: Implementação; Fase cinco: Documentação. * orçamento feito baseado em datas reais Análise de Resquisito Após ser feito o estudo de viabilidade, houve uma reunião onde se encontraram os desenvolvedores do projeto e os clientes em questão. Foi apresentado o estudo com base nos levantamentos de informações feitas pela nossa equipe e a forma como seria realizado o sistema, além de conter informações sobre as estimativas de custo. E então, após um acerto com ambas as partes foram decididas que o projeto continuará em andamento. As funcionalidades que estarão no projeto serão: Uma tela para fazer um orçamento; Uma tela para consultar a agenda de serviços; Uma tela para encerrar um evento na agenda de serviços; Uma tela para nova ordem de serviço; Uma tela onde será cadastrados os clientes; Uma tela onde serão consultado e alterado os clientes; Uma tela onde os clientes poderão ser excluídos. Requisitos Funcionais Página 7

8 RF1 - Cadastrar Clientes O sistema deverá ter uma tela para cadastrar os clientes RF2 Gerar Orçamentos O sistema deverá ter uma tela para gerar orçamentos. RF3 Agenda de Serviços O sistema devera ter uma agenda de serviços que controla todos os serviços RF4 Ordem de Serviço O sistema devera ter uma tela para cadastro de serviços a ser agendados na agenda de Serviços. Requisitos Não Funcionais RNF1 Funcionamento do Clientes RF1 O cliente deve ser cadastrado sempre antes de se gerar uma ordem de serviço. Devera constar Nome, Telefone, Endereço. RNF2 Gerar Orçamento RF2 A qualquer momento o funcionário pode gerar um orçamento. Pode ser tanto para um cliente como para um cliente novo, não cadastrado, para isto terá de ter a opção Não cliente para o Nome em que vai sair o orçamento. RNF3 Funcionamento da Agenda RF3 Existe uma agenda de compromissos diários onde será cadastrado um novo serviço. O Mecanico consulta esta para poder trabalhar em um serviço já cadastrado e ao termino encerrá-lo. RNF4 Controle de Serviços RF4 Pode se cadastrar serviços baseado na disponibilidade da agenda e sendo gerado para um cliente cadastrado. Devera contar um Cliente, descrição do que fazer e um carro. Página 8

9 Caso de Uso Página 9

10 Caso de Uso Expandido Sistema Oficina Mecânica 1. Cliente chega a oficina e solicita: 1.1 Orçamento -> vai para Serviço -> vai para 3 2. Funcionário gera um orçamento para o cliente e entrega. 2.1 Verifica se o cliente já é cliente da oficina 2.2 Gera um orçamento em nome genérico e entrega. 2.3 Gera um orçamento para um cliente cadastrado e entrega. 3. Funcionário abre uma ordem de serviço 3.1 Verifica se já é cliente cadastrado Cadastra o cliente 3.2 Gera uma ordem de serviço para o cliente já cadastrado Verifica disponibilidade na agenda para gerar o serviço 3.3 Gera ordem de serviço e envia para agenda 4. Cliente deixa o carro para o serviço 4.1 Mecanico ao consultar Agenda começa a trabalhar na ordem de serviço 4.2 Mecanico encerra a ordem de serviço 5. Cliente volta para buscar o carro 6. Cliente paga e vai embora Obs: Sistema não tratara a forma como o cliente esta pagando o serviço. Página 10

11 Modelo de Processo O que é? Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto como uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o progresso do projeto. O modelo de processo de software a ser adotado será o RAD, como já mostrado em ilustrações em páginas anteriores. A seguir, um breve sumário sobre RAD: Rapid Application Development (RAD) ou Desenvolvimento Rápido de Aplicação, é um modelo de processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias). O Processo: Modelagem de Negócio Modelagem dos dados Modelagem do Processo Geração da Aplicação Teste e Modificação Vantagens Permite o desenvolvimento rápido e/ou a prototipagem de aplicações; Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias); Cada função principal pode ser direcionada para a uma equipe RAD separada e então integrada a formar um todo; Criação e reutilização de componentes; Usado principalmente para aplicações de sistemas de informações; Comprar pode economizar recursos se comparado a desenvolver; Desenvolvimento é conduzido em um nível mais alto de abstração; Visibilidade mais cedo (protótipos); Maior flexibilidade (desenvolvedores podem reprojetar praticamente a vontade); Grande redução de codificação manual (wizards ); Envolvimento maior do usuário; Provável custo reduzido(tempo é dinheiro e também devido ao reuso); Página 11

12 Aparência padronizada (As APIs ae outros componentes reutilizáveis permitem uma aparência consistente). Página 12

13 Diagramas de Classe Página 13

14 Estimativa de Custos Definição: Há 3 principais processos de Gerenciamento de Custos no Gerenciamento de Projetos: Estimativa de Custos Determinar o Orçamento Controle de Custos A Estimativa de Custos é o primeiro desses 3 processos e basicamente desenvolve uma aproximação dos custos de todos os recursos lançados no projeto. Isso inclui, mas não se limita, à mão-de-obra, materiais, equipamentos, serviços e instalações, além de reservas específicas como provisão para inflação e contingências. Baseado no cronograma mostrado acima e em valores cobrados por hora trabalhada segue também para análise a tabela de estimativa de custos: Custo/Profissional Guilherme Ricardo Cristian Total 50% R$ 4,50 R$ 5,50 R$ 6,00 R$5.955,00 100% R$ 9,00 R$ 11,00 R$ 12,00 R$11.910,00 Prevendo gastos com compra de hardware específico para hospedagem do sistema, e na pesquisa geral feito por nosso setor de compra orçaram um computador em volta de R$ 2.500,00. Com todos esses dados previstos, podemos chegar ao total estimado com R$ 8.455,00 contando que não haverá horas extras para os profissionais envolvidos. Página 14

15 Gerenciamento de Recursos Humanos Porquê? O gerenciamento de recursos humanos do projeto inclui os processos que organizam e gerenciam a equipe do projeto. A equipe do projeto é composta de pessoas com funções e responsabilidades atribuídas para o término do projeto. Embora seja comum falar-se de funções e responsabilidades atribuídas, os membros da equipe devem estar envolvidos em grande parte do planejamento e da tomada de decisões do projeto. O envolvimento dos membros da equipe desde o início acrescenta especialização durante o processo de planejamento e fortalece o compromisso com o projeto. O tipo e o número de membros da equipe do projeto muitas vezes podem mudar conforme o projeto se desenvolve. Os membros da equipe do projeto podem ser chamados de pessoal do projeto. 1. Planejamento de recursos humanos Identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto, além da criação do plano de gerenciamento de pessoal. Essa parte será desenvolvida por toda a equipe para que haja maior interação com o sistema desenvolvido. 2. Contratar ou mobilizar a equipe do projeto Obtenção dos recursos humanos necessários para terminar o projeto. Essa parte será ignorada, pois não será necessária a contratação de novos recursos para o termino do projeto. 3. Desenvolver a equipe do projeto Melhoria de competências e interação de membros da equipe para aprimorar o desempenho do projeto. Quanto ao desenvolvimento da equipe, não será necessária, pois a equipe trabalha a alguns anos juntos e tem um workflow leve o suficiente para que se acompanhem sem que se atrapalhem. 4. Gerenciar a equipe do projeto Acompanhamento do desempenho de membros da equipe, fornecimento de opinião, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projeto. A Gerência do projeto será exclusividade de Cristian Santos, pois esse está mais a par de situações de mercado como essa. Com sua vasta experiência em empresas e equipes relacionadas com TI, ele terá leveza suficiente para poder trabalhar e gerenciar sua equipe Página 15

16 Finalização Esse documento deverá ser analisado de forma completa e coerente com fins de que haja alinhamento entre todos os pontos envolvidos no projeto. Qualquer dúvida pertinente a qualquer parte do projeto deverá ser discutida explicitamente com todos os membros envolvidos. A Inspiration Corporation agradece a ocupação do tempo de você com a leitura desse relatório de atividades. Página 16