PERGUNTAS FREQUENTES (FAQ) E ORIENTAÇÕES PARA … · Caso julgar necessário, apresentar, no...

PERGUNTAS FREQUENTES (FAQ) E ORIENTAÇÕES PARA

ELABORAÇAO DE CONTESTAÇÃO DA ANÁLISE DO

RELATÓRIO DEMONSTRATIVO ANUAL (RDA )

VERSÃO DO DOCUMENTO

Data Versão Atualização

22/02/2018 1.0 Versão inicial no formato FAQ.

Introdução

Este documento elaborado pela Secretaria de Política de Informática (SEPIN)

tem por finalidade apresentar orientações às empresas na forma de perguntas

frequentes sobre a etapa da contestação das análises relativas aos Relatórios

Demonstrativos Anuais RDAs.

Regulamentação aplicável

i. Lei nº 8.248/2001

ii. Decreto nº 5.906/2006

iii. Portaria 4561/2017 regula os procedimentos referente as contestações.

PERGUNTAS FREQUENTES (FAQ)

1. Como funciona o processo de análise do RDA?

A figura acima apresenta, de maneira suscinta, o processo de análise do RDA

no âmbito da SEPIN. Para melhor entendê-la, detalharemos o passo-a-passo de

cada etapa a seguir:

Os RDAs recebidos por meio do Sistema Sigplani - Módulo RDA são analisados

pela equipe de analistas da SEPIN. Nessa etapa são consultados referências e

controles mantidos em processos paralelos, como depósitos no FNDCT

Trimestral, no FNDCT Residual-Investimento insuficiente, no FNDCT opção de

Investimento e aportes financeiros nos PPIs, lista de produtos incentivados que

possuem Portaria nº950, lista de produtos que são Unidades de Processamento

Digital (UPD), no sentido de validar as informações declaradas pela empresa. A

análise termina com a geração de um Parecer Técnico, contendo o resultado da

avaliação dos projetos e demais declarações da empresa.

Ao fim da análise, comunica-se a empresa do resultado, enviando-lhe um ofício,

informando a ausência ou presença de débito de aplicação em P&D, além da

cópia do Parecer resultante da análise.

Caso a empresa não possua débito, é enviado um comunicado por ofício à

Receita Federal atestando sua adimplência. Caso a empresa possua débito e o

quitou, o mesmo procedimento mencionado é executado.

Se a empresa possuidora de débito contestar, deverá ela então enviar sua

contestação pelo sistema CADSEI à SEPIN, a qual tem a incumbência da

análise. Nesta etapa, a SEPIN poderá fazer diligência à empresa, de modo a

complementar e/ou esclarecer as informações apresentadas.

Finalizada a análise da Contestação, a SEPIN informará à empresa sobre o

resultado.




A empresa possuidora de débitos pode interpor o Recurso ao Ministro,

apresentando argumentações que busquem justificar a aprovação de seus

projetos e reversão das glosas aplicadas. No entanto, com a medida provisória

nº 810 que alterou a Lei 8.248/1991, ela poderá propor plano de reinvestimento

dos débitos referentes aos investimentos residuais, renunciando ao direito em

que se funda a ação judicial e desistindo de recurso administrativo ao ministro

que tenha por objeto os débitos.

Se a empresa que ainda possui débito não apresentar Recurso ao Ministro ou

não apresentar o plano de reinvestimento no escopo do regulamento pertinente,

segue-se com o processo de Suspensão.

Caso a empresa apresente Recurso ao Ministro e for solicitado um parecer da

SEPIN, procede-se com a Análise do Recurso e encaminhamento do resultado

da análise ao gabinete.

Cabe ao Gabinete decidir acerca do Recurso, encaminhar o processo à SEPIN

e comunicar a empresa sobre o resultado.




Se a empresa não quitou o débito que possuía, nem apresentou contestação,

segue o processo de suspensão, que resultará no cancelamento do incentivo

caso a empresa nao se adimpla no período da suspensão, que é de 180 dias.

2. O que é a Contestação?

As empresas beneficiárias da Lei de Informática serão comunicadas sobre os

resultados das análises dos Relatórios Demonstrativos Anuais (RDAs) por

meio de ofício encaminhado pela SEPIN, acompanhado do respectivo parecer

técnico.

Para os casos em que não obtiver aprovação dos projetos, ou parte deles, a

empresa poderá apresentar a sua contestação, justificando as suas arguições

e disponibilizando as informações que julgar pertinentes.

A SEPIN poderá contatar os representantes da empresa para solicitar

informações adicionais em caso de esclarecimentos ou insuficiência das

informações apresentadas durante a fase de contestação.

3. Posso apresentar novos projetos na Contestação?

A apresentação no ato da contestação de projetos novos, que não foram sequer

mencionados ou indicados no RDA, não será considerada para fins da reanalise.

Esta condição não se aplica para os casos em que for comprovado o erro ou

problema na transmissão do Relatório Demonstrativo por meio do Sistema

Sigplani.

4. Posso apresentar dispêndios novos na Contestação?

Da mesma forma, informações sobre dispêndios que sequer foram mencionados

ou apresentados no escopo do projeto original declarado no RDA, não são

válidas para fins de reanalise no escopo da contestação.

A contestação do RDA é uma etapa do processo da análise em que cabe a

empresa a apresentação das informações para explicar, justificar e/ou

complementar os dados infomados por meio do Sistema Sigplani-Módulo RDA.

Portanto, recomenda-se que as informações sejam apresentadas de maneira

clara e objetiva.

5. O que vem a ser a fase de pré – análise do RDA?

A fase de pré-análise definida na Metodologia de Avaliação do RDA faz parte do modelo de referência de enquadramento de projetos de pesquisa e desenvolvimento. O objetivo principal desta fase é realizar a triagem de projetos declarados que são inviáveis de serem analisados utilizando o método para análise do enquadramento como P&D. Para todos os casos da pré-análise, recomenda-se as empresa a verificação das demais informações sobre o projeto. Caso julgar necessário, apresentar, no momento da contestação, as informações detalhadas e contextualizadas para análise dos critérios de enquadramento, bem como para verificação dos dispêndios declarados. A seguir são abordados os aspectos verificados na pré-análise e as principais situações de não aprovação ou glosas, bem como as respectivas recomendações para solucioná-las.

6. Como proceder no caso em que não há preenchimento adequado dos

campos obrigatórios?

Esta situação ocorre quando a empresa não apresentou informações minimamente exigidas para que fosse caracterizado um projeto. Caso a empresa constate que os dados informados no parecer técnico estão divergentes dos dados contidos no RDA impresso/cópia eletrônica ou encaminhado via CADSEI. A empresa deverá apresentar a solicitação para consideração das informações que julgar divergentes, acrescentando, sempre que possível, a cópia da página do RDA impresso ou do documento eletrônico enviado por meio do CADSEI, em que a informação correta está contida.

7. O que fazer no caso em que o período de execução declarado não se

encontra compreendido no ano base?

Nesta situação o projeto não pôde ser analisado, pois o período de execução declarado não está compreendido no ano base. Caso tenha ocorrido equívoco no cadastro das datas de início e/ou fim do projeto no RDA, a empresa deverá informar as datas corretas e justificar, caso necessário, o equívoco ocorrido.

8. O projeto apresentado foi considerado como não sendo de Tecnologia

da Informação e Comunicação (TIC). Posso pedir reconsideração?

Nesta situação, o projeto não foi classificado como Tecnologia da Informação e Comunicação e, portanto, não é elegível para o cumprimento das obrigações da Lei de Informática conforme o Decreto nº 5.906/2006.Caso o projeto não tenha sido classificado como sendo de TIC, mas a empresa considere elegível dentro do contexto da legislação pertinente, poderá ser apresentada contestação solicitando a reanalise das informações contidas no RDA e, caso julgar necessário, poderá apresentar informações complementares para evidenciar que se trata de projeto realizado no escopo das áreas das TICS.

9. Meu projeto foi considerado como Programa de Projetos? Como devo

proceder para solucionar?

Essa situação ocorre em que os projetos do RDA foram analisados e considerados como Programa, ou seja, um conjunto de projetos ou subprojetos que foram declarados como sendo um projeto único. Podemos ter duas situações distintas:

- Projeto com subprojetos/módulos:

Quando o projeto, que foi analisado e considerado como programa, se trata de um projeto único, com subprojetos/módulos desenvolvidos correlacionados entre si, para atender ao mesmo problema tecnológico ou objetivo do projeto, a empresa deverá apresentar solicitação e justificativa para reanálise do projeto evidenciando a correlação dos subprojetos ou módulos desenvolvidos no projeto. Recomenda-se a apresentação das informações de forma objetiva e contextualizada das etapas do projeto, bem como das informações sobre dispêndios e colaboradores que atuaram em cada fase do projeto.

- Programa com Projetos Distintos:

Quando o projeto, que foi analisado e considerado como programa, se trata de dois ou mais projetos que não estão correlacionados diretamente, ou que tenham como objetivos gerar produtos distintos e sem correlação um com outro, a empresa deverá apresentar separadamente cada um dos projetos, identificando e detalhando o escopo (problema técnico-científico, objetivo) e as atividades realizadas em cada um deles, de maneira contextualizada. Além disso, deve separar os dispêndios de cada projeto para que seja possível analisar a pertinência e adequação de cada rubrica declarada.

Obs: Quando a separação dos projetos resultar na incapacidade de segmentação precisa de determinados dispêndios, recomenda-se à empresa a utilização de técnicas de rateio.

10. Meu projeto executado com ICT/IES não foi analisado devido a

divergências no cadastro em relação à natureza do instituto (público

ou privado) ou região de origem. Posso corrigir?

Quando se tratar de projeto conveniado que não foi analisado por causa de informações incorretas da IES ou ICT, a empresa deve apresentar na contestação a justificativa e informações corretas da instituição para análise do projeto. Caso tenha ocorrido equívoco no cadastro do tipo de instituição (pública ou privada) no projeto do RDA, a empresa deverá informar a natureza da instituição em que foi realizado o projeto e, caso necessário, justificar o equívoco ocorrido.

Caso tenha ocorrido equivoco no cadastro da região e/ou da UF da instituição conveniada que realizou o projeto do RDA a empresa deverá informar a região e/ou UF de origem da instituição onde foi realizado o projeto e, caso necessário, justificar o equívoco ocorrido.

11. Meu projeto de P&D strictu sensu não foi enquadrado por falta de

informação. Como proceder?

Nos casos em que o que projeto foi classificado no critério C1 = 0: Não há informações claras e suficientes para o entendimento do problema tecnológico proposto (escopo, objetivos do projeto, etc. A empresa deve apresentar na Contestação as informações claras sobre o escopo do projeto, ou do problema tecnológico a que se pretende esclarecer e/ou solucionar com o projeto proposto. Deixar claro quais são os objetivos e motivações da realização do projeto.

Nos casos em que o que projeto foi classificado no critério C2 = 0: As etapas e

as atividades foram declaradas pela empresa de uma maneira genérica, não

específica, nem direcionada aos objetivos propostos. A empresa deve

apresentar na contestação as etapas e atividades de P&D realizadas de maneira

contextualizada para o projeto. Aqui não se observa somente qual é a

metodologia utilizada pela empresa, mas sim como a empresa utilizou a sua

metodologia para alcançar os objetivos propostos. Recomenda-se a

apresentação das informações das etapas e atividades que foram realizadas no

projeto, com as datas de início e fim ou duração, de modo que possibilite ao

analista evidenciar o esforço realizado para resolver o problema tecnológico.

Obs: Documentos estritamente técnicos, esquemáticos, códigos-fonte, não são

necessários. Porém, fica a critério da empresa, caso julgue importante para

corroborar as informações declaradas no projeto.

12. Meu projeto strictu sensu não foi enquadrado como sendo de P&D.

Posso pedir reconsideração? Como proceder?

Projetos classificados como C2 = 1:

Caso o projeto tenha sido analisado e classificado como não enquadrado, por

haver indícios que as atividades principais do projeto apontaram para uma

estrutura de etapas de natureza não técnico-científica, ou meramente

operacionais de configuração e customização de equipamentos, ou ainda

referentes a aquisição de uma solução, a empresa deve observar se as

atividades principais do projeto estão relacionadas com os casos descritos nesta

situação. Em caso afirmativo, o projeto não poderá ser classificado como sendo

de Pesquisa e Desenvolvimento, de acordo com a legislação pertinente. Caso

contrário, a empresa deve apresentar na contestação a justificativa, as etapas e

atividades de P&D realizadas de maneira contextualizada para cada projeto.

Caso a análise do projeto resultou em não enquadramento por apresentar

indícios que apontam que as principais atividades do projeto são das áreas de

Organização e Métodos (O&M), Planejamento e Controle da Produção ou

Mapeamento de Processos, a empresa deve observar se as atividades principais

do projeto estão relacionadas com os casos descritos nesta situação. Em caso

afirmativo, o projeto não pode ser classificado como sendo de Pesquisa e

Desenvolvimento, conforme a legislação pertinente. Caso contrário, a empresa

deve apresentar na contestação as etapas e atividades de P&D realizadas de

maneira contextualizada para cada projeto.

Obs: Em muitos casos, a empresa apresenta um projeto de melhoria de

processo, porém descreve apenas atividades de implantação ou redesenho nas

áreas mencionadas acima. No entanto, ela não apresenta, ou deixa de dar

ênfase em atividades de desenvolvimento de solução de hardware ou software

que foram realizadas para a melhoria do processo. Essas atividades é que

podem ajudar a caracterizar o projeto como sendo de P&D.

13. Meu projeto de Capacitação foi considerado como não enquadrado.

Posso pedir reconsideração? Como proceder?

Existem várias situações em que o projeto de capacitação pode ser

considerado não enquadrado. A seguir citamos os casos possíveis:

Quando classificado como C5 = 1: Os indícios encontrados durante a análise

remetem que o curso realizado possui conteúdo meramente operacional.

Quando se tratar de um curso operacional, este só pode ser considerado como

sendo de P&D quando associado e necessário para a execução de um projeto.

Logo, deve ser declarado na rubrica de “Treinamentos” do sistema Sigplani-

Módulo RDA e não como um projeto de capacitação isolado. Caso este curso

não esteja associado a um projeto, não há como enquadrá-lo como sendo de

P&D.


remetem que o curso realizado é de nível básico. A empresa deve apresentar

informações complementares para a caracterização de que se trata de um

curso direcionado a profissionais de nível médio ou superior. Caso o curso,

capacitação e/ou formação não esteja destinado ao público de nível médio ou

superior, não há como enquadrá-lo como sendo de P&D.


remetem que a(s) pessoa(s) formadas ou capacitadas não são pertencentes a

área de TIC, ou que não há indícios de que possam realizar atividades de P&D.

A empresa deve informar a função dos colaboradores formados ou

capacitados. Caso o colaborador formado ou capacitado não seja da área de

TIC, a empresa deve apresentar a justificativa da participação no curso,

indicando qual e a função do colaborador nas atividades de P&D da empresa.

Quando classificado como C5 = 0: Durante a análise não foi possível obter

informações sobre o conteúdo do curso realizado. A empresa deve apresentar

o conteúdo e/ou ementa do curso realizado. O detalhamento das informações

deve possibilitar ao analista a compreensão sobre tipo, o conteúdo do curso e a

sua estruturação.

Quando classificado como C6=0: Durante a análise não foi possível obter

informações sobre o nível do curso realizado. A empresa deve apresentar

informações complementares para a caracterização de que se trata de um

curso direcionado a profissionais de nível médio ou superior. Caso o curso,

capacitação e/ou formação não esteja destinado ao público de nível médio ou

superior, não há como enquadrá-lo como sendo de P&D.

Quando classificado como C7=0: Após a análise não foi possível encontrar

indícios sobre o pessoal capacitado/formado ou em capacitação/formação. A

empresa deve informar quem são e quais as funções dos colaboradores

formados ou capacitados. Caso o colaborador formado ou capacitado não seja

da área de TIC, a empresa deve apresentar a justificativa da participação no

curso, indicando qual e a função do colaborador nas atividades de P&D da

empresa.

14. Como a SEPIN considera que devem declarados corretamente os

dispêndios de P&D?

A empresa deve apresentar, pelo menos, as seguintes informações para

cada tipo de dispêndio:

Software

• Nome e o tipo do software.

• Data de aquisição, o valor da licença adquirida e o tipo (anual sem renovação automática; anual com renovação automática; perpétua; outra, conforme explicação).

• A finalidade e justificativa do uso do software no projeto, indicando também a qual das etapas mencionadas na Descrição do Projeto o item está associado.

Obs: Recomenda-se à empresa utilizar o valor proporcional de acordo com a utilização do software em cada projeto, limitando-se à depreciação de 20% do valor total para cada ano base a partir do ano de aquisição do software. O período máximo de utilização desta regra será de 5 anos. No caso de licença anual, deve-se desconsiderar a depreciação e utilizar o valor proporcional à utilização no projeto.

Equipamentos - bens de Informática

• Descrição do equipamento.

• Data de aquisição e o valor total do equipamento adquirido.

• A finalidade e justificativa do uso do equipamento no projeto, indicando também a qual das etapas mencionadas na Descrição do Projeto o item está associado.

Obs: Recomenda-se à empresa utilizar o valor proporcional de acordo com a utilização do equipamento em cada projeto, limitando-se à depreciação de 20% do valor total para cada ano base a partir do ano de aquisição. O período máximo de utilização desta regra será de 5 anos. No caso de equipamento alugados, utilizar o valor total do aluguel como base para calcular a proporcionalidade de utilização do equipamento no projeto.

Equipamentos – outros

• Descrição do equipamento.

• Data de aquisição e o valor total do equipamento adquirido.

• A finalidade e justificativa do uso do equipamento no projeto, indicando também a qual das etapas mencionadas na Descrição do Projeto o item está associado.

Obs: Recomenda-se à empresa utilizar o valor proporcional de acordo com a utilização do equipamento em cada projeto, limitando-se à depreciação de 20% do valor total para cada ano base a partir do ano de aquisição. O período máximo de utilização desta regra será de 5 anos. No caso de equipamento alugados, utilizar o valor total do aluguel como base para calcular a proporcionalidade de utilização do equipamento no projeto.

Obras civis

• Tipo de obra executada.

• Dados da empresa que executou a obra, com CNPJ e Razão social.

• Data de execução da obra.

• Descreva a finalidade da obra executada.

Obs: Em caso de projetos continuados, em que a criação de

laboratório ou obras civis seja uma fase do projeto de P&D, a

empresa deve apresentar com clareza as demais fases do projeto

para que seja possível analisar os critérios de enquadramento.

Livros / Periódicos

• Informe o título da obra e a quantidade de exemplares adquiridos; ou o periódico que foi objeto de assinatura.

• Valor unitário do livro e/ou periódico, ou o valor da assinatura do periódico.

• Justificativa da aquisição do livro e/ou periódico para o projeto.

Material de consumo

• Informe os principais materiais de consumo utilizados no projeto.

• Descreva a finalidade do uso desses materiais no projeto,

justificando os valores declarados.

Obs: Quando se tratar de uma grande quantidade de materiais de

consumo utilizados no projeto, recomenda-se o agrupamento por

tipo de materiais. Exemplo: Materiais de escritório (caneta, papel,

toner para impressora, etc).

Material de consumo – Protótipos

• Informe os principais materiais de consumo utilizados no projeto.

• Descreva a finalidade do uso desses materiais no projeto, justificando os valores declarados.

• Obs: Quando se tratar de uma grande quantidade de materiais de consumo para protótipos utilizados no projeto, recomenda-se o agrupamento por tipo de materiais. Exemplo: Componentes eletrônicos (capacitores, resistores, baterias, diodos, placas, etc).

Viagens

• Nome(s) do(s) viajante(s);

• Datas de início e fim da viagem.

• Itinerário

• Custo da viagem.

• Descreva a finalidade da viagem no projeto, indicando também a

qual das etapas mencionadas na Descrição do Projeto o item está

associado.

Treinamento

• Descrição do Treinamento;

• Local, data, duração, entidade que ministrou o curso;

• Colaboradores que participaram do treinamento;

• Valor do treinamento para cada colaborador;

• Finalidade do treinamento para o projeto.

Serviços Tecnológicos

• Informe a pessoa física ou jurídica contratada (com CPF ou CNPJ).

• Descreva o serviço tecnológico prestado ao projeto e o período de sua realização.

• Informe o valor do serviço tecnológico.

• Justificativa do serviço no projeto, indicando, quando for o caso, a qual das etapas mencionadas na Descrição do Projeto o item está associado.

Obs: Caso o projeto seja realizado totalmente (ou sua maior parte)

por terceiros, a empresa deve apresentar o valor na rubrica

pertinente e detalhar todo o gasto que foi realizado pela empresa

terceira. Não sendo aceitos os gastos com pagamento de taxa de

administração e/ou quaisquer tipo de taxas e lucros cobrados pela

empresa terceira para fins de cumprimento de P&D.

Serviços – outros

• Informe a pessoa física ou jurídica contratada (com CPF ou CNPJ).

• Descreva o serviço contratado para o projeto e o período de sua realização.

• Informe o valor do serviço realizado.

• Justificativa do serviço no projeto, indicando, quando for o caso, a qual das etapas mencionadas na Descrição do Projeto o item está associado.

Obs: Caso o projeto seja realizado totalmente (ou sua maior parte)

por terceiros, a empresa deve apresentar o valor na rubrica

pertinente e detalhar todo o gasto que foi realizado pela empresa

terceira. Não são aceitos os gastos com pagamento de taxas de

administração e/ou quaisquer tipo de taxas e lucros cobrados pela

empresa terceira para fins de cumprimento de P&D.

Outros correlatos

• Discrimine detalhadamente os dispêndios, qual o item de custo

direto que o gerou e qual a forma de apropriação contábil (por

exemplo, rateio).

• Valor individualizado ou por agrupamento do tipo de gasto (ex:

manutenção, taxas, etc);

• Justificar a necessidade do dispêndio discriminado à execução do

projeto.

Recursos Humanos Diretos

• Informe o nome, formação e tipo de RH (médio ou superior) do pessoal diretamente envolvido nas atividades de P&D;

• Descreva a atuação no projeto, indicando também a qual das etapas mencionadas na Descrição do Projeto o RH está associado;

• Informe as horas trabalhadas no projeto e o respectivo valor dispendido.

Obs: Dados como: CPF, Formação, etc. são informações

desejáveis, mas não necessárias.

Recursos Humanos Indiretos

• Informe o nome, formação e tipo de RH (médio ou superior) do pessoal que não faz parte da equipe de P&D, mas participou de atividades do projeto;

• Descreva a atuação no projeto, indicando também a qual das etapas mencionadas na Descrição do Projeto o RH está associado;

• Informe as horas trabalhadas no projeto e o respectivo valor dispendido.

Obs: Dados como: CPF, Formação, etc. são informações

desejáveis, mas não necessárias.

Custos incorridos

• Poderá haver glosas sobre a rubrica de “custos incorridos” em

projetos de P&D realizados em regime de convênio, quando o valor

declarado exceder o percentual estabelecido pelo §5º do Art. 25 do

Decreto 5906/2006, ou quando parte ou total do montante gasto

no projeto é glosado durante a análise, limitando o valor dos custos

incorridos em até 20% do montante gasto e aprovado no projeto.

• Recomenda-se que a empresa durante a fase de contestação,

apresente a solicitação para reconsideração do valor glosado nesta

rubrica em consonância à justificativa apresentada para os demais

dispêndios do projeto.

15. Como a SEPIN considera que devem declarados corretamente os

dispêndios de P&D?

Se a empresa realizou depósito(s) no FNDCT ou no PPI e durante a análise

a SEPIN tiver glosado, ou não reconhecido, parte, ou total do valor

informado no RDA, ou mesmo se a empresa tiver declarado um valor menor

que o realmente depositado, recomenda-se no ato da contestação a

apresentação da justificativa pertinente e o comprovante do depósito

realizado.

16. EXEMPLOS DE PROJETOS

16.1. Projeto de P&D Stricto Sensu

Estrutura mínima:

▪ Motivação

• Escopo do projeto

• Objetivos

• Problema técnico-científico

• O que o projeto espera alcançar?

▪ Metodologia/Fases

• Etapas do projeto

• Atividades realizadas

• Como? O que foi feito para resolver o problema?

▪ Resultados

• O que o projeto resultou?

▪ Descrição dos Dispêndios

16.1.1. Projeto de HW

PROJETO: Desenvolvimento de um equipamento concentrador de informações de

sistemas de controle de acesso e de frequência – Concentradora ARM9

OBJETIVO

O objetivo do projeto é desenvolver um novo equipamento concentrador para a

família de sistemas de acesso da “EMPRESA X”. O concentrador é o principal

componente de uma solução de acesso e a ele são conectados todos os

equipamentos de controle de acesso (catracas, portas, ...) de uma empresa,

permitindo a liberação, ou não, de indivíduos a um determinado ambiente.

Será também desenvolvido uma nova aplicação WEB que permitirá a gestão de

acesso a partir de qualquer browser e computador conectado à rede e ao

concentrador, ao contrário da situação atual onde o controle somente é possível

pelo computador instalado nas portarias.

Outro objetivo do projeto é fazer uma renovação tecnológica nos sistemas da

“EMPRESA X”, utilizando tecnologias mais modernas e potentes de

processadores que suportam sistemas operacionais Linux. Desta forma, futura

atualizações de sistemas serão mais simples e rápidas, garantindo a posição de

vanguarda da “EMPRESA X” ao Mercado.

ESCOPO

O escopo do projeto Concentrador AMR9 é desenvolver um equipamento

concentrador de acesso com as seguintes característica mínimas:

• Adoção de novo processador da família ARM de 32 bits substituindo o antigo

processador da família 8086

• Adoção de uma nova arquitetura de software baseada em Linux.

• Adoção de um banco de dados SQL Lite embarcado para o armazenamento

dos dados de acesso e registro do histórico de cada acesso realizado.

• Portabilidade do software existente nos equipamentos antigos para a nova

arquitetura

• Compatibilidade com os equipamentos de controle de acesso da

“EMPRESA X”

• Desenvolvimento de uma fonte de alimentação compatível com os novos

níveis de tensão requeridos pela nova arquitetura de HW e com maior grau

de proteção contra picos e sobretensões da rede de energia elétrica

• Suportar interfaces de comunicação via Ethernet (conexão rede e até 10

equipamentos de acesso via Interface serial indústria RS485).

• Entrada para leitor de código de barras ou código magnético.

• Entrada para leitor de proximidade Wiegand ou ABA track2.

Desenvolver uma nova aplicação baseada em WEB, em linguagem PHPe que

disponibilizará todas as funcionalidades usuais de gestão de acesso (ex: cadastro

de pessoas, grupos, ambientes, graus de permissão, horários de acesso, horários

de restrição, etc, a partir de qualquer computador e browser).

ATIVIDADES

Atividade 1: Levantamento e Análise de Requisitos

Descrição: Usualmente os requisitos para um novo produto seriam levantados pela

equipe de marketing/comercial, através de consultas à clientes externos (de

diversos segmentos) e depois seriam na sequência validados pela equipe de P&D,

para determinar a sua exequibilidade. Entretanto, dado o caráter de renovação

tecnológica necessário para o Concentrador, seguiu-se um caminho inverso, com a

maior parte dos requisitos definidos pela equipe de P&D, sendo que estes foram

depois validados pelo pessoal de marketing.

Dado o caráter de renovação do projeto, gastou-se um grande esforço para

entender as reais capacidades dos novos componentes (ARM, Linux), resultando

em uma especificação de requisitos focada em aspectos não funcionais, como

capacidade de expansão de memória, quantidade de interfaces seriais e assim por

diante.

Os requisitos funcionais do produto (tanto do equipamento quanto do sistema de

gestão) foram totalmente baseados nas soluções então comercializadas pela

empresa

Nesta fase também ocorreram testes de avaliação de alternativas tecnológicas, em

especial, sobre a distribuição do Linux embarcado (quais componentes de SW

deveriam ser integrados).

Resultado da atividade: Especificação de requisitos

Período: 04/01/2009 a 31/03/2009

Participantes: Fulano; João; Beltrano; Ciclano; Silva; Antônio, FredericoIII

Atividade 2: Elaboração Da Especificação De Produto

Descrição: A especificação do produto Concentrador ARM9 desenvolvida nesta

fase foi na verdade uma especificação de nova arquitetura, tanto de SW

(embarcado e Web) quanto de HW. Ela foi desenvolvida com o apoio dos

fornecedores, que capacitaram os profissionais da “EMPRESA X” no uso da

Tecnologia e ao mesmo tempo contribuíram para a definição da arquitetura, uso do

sistema operacional, etc.

Um exemplo típico foi o uso do Linux como sistema operacional. Um sistema Linux

embarcado difere de um sistema Linux desktop, nos requisitos de processamento,

armazenamento, consumo de energia e confiabilidade. Dessa forma foi necessário

obter um entendimento completo da aplicação (exemplo: tempos máximos de

respostas para o processamento de determinados eventos), através de testes no

desempenho nas soluções existentes, de modo a conseguir especificar uma

distribuição Linux compatível e um processador poderoso o suficiente para entregar

o tempo de resposta necessário.

Resultado da atividade: Especificação de produto (HW e SW)

Período: 15/02/2009 a 31/05/2009

Participantes: Fulano; João; Beltrano; Ciclano; Silva; Antônio

Atividade 3: Análise de Riscos e Impactos

Descrição: Dado o caráter disruptivo do novo desenvolvimento (novas tecnologias

para a empresa) foi necessário realizar um acompanhamento constante do

desenvolvimento do concentrador, de modo a identificar os riscos e minimizar os

seus impactos. Os riscos foram mapeados no inicio do projeto e o acompanhamento

foi realizado a cada reunião de revisão do projeto.

A falta de conhecimento nos sistemas em Linux foi o principal fator de risco do

projeto e teve impacto mediano nos prazos alcançados.

Resultado da atividade: Planilha de riscos (atualizada constantemente ao longo

do projeto)

Período: 04/01/2009 a 31/12/2009

Participantes: Ailton Quadrante Freitas, FredericoIII

Atividade 4: Desenvolvimento de Hardware

Descrição: Para o desenvolvimento de HW seguiu-se um processo bem definido:

• Desenho do diagrama em blocos da solução identificando os principais

componentes, no caso processador, drivers de interface ETH, RS485,

RS232, fonte de alimentação, interface para periféricos principais (leitor de

código de barras, leitor de proximidade, etc), estabelecendo as conexões

entre os mesmos,

• Seleção das possíveis soluções de componentes (componente principal

mais circuitos auxiliares) de acordo com os Cookbooks indicados pelos

fabricantes. Seleção dos componentes conjugando fatores técnicos e

financeiros. A solução de processador selecionada foi o Microcontrolador

ARM9 – Fabricante ATMEL AT91SAM9260QU - TQFP208 (208 pinos)

operando com Memória Flash (4M x 16 = 8Mbytes) Fabricante: Atmel

AT49BV642D, com capacidade de expansão via slot para SD Memory Card

67840-800, tanto para expansão de memória ou boot do sistema;

• Para o desenvolvimento do diagrama esquemático e do consequente

projeto da placa de circuito impresso foi necessária a atualização da

biblioteca de componentes para a inclusão do processador e alguns

componentes mais novos e com encapsulamento fora do padrão (base

desatualizada);

• Não ocorreram dificuldades para a criação do diagrama esquemático. Para

o projeto da placa de circuito impresso, algumas restrições mecânicas

alteraram o posicionamento de componentes, para comportar pontos

múltiplos de fixação da placa (necessários para a robustez da montagem

interna).

• Uma característica importante do concentrador ARM9 é de este não dispõe

de uma interface com o usuário propriamente dita (como display e teclado),

como outros produtos da própria “EMPRESA X”. Trata-se de uma versão

para aplicações restritas. O usuário possui uma interface simples de status

(5x LEDs) e uma buzzer interna para leitura de situações de erro. Toda a

configuração e controle são realizados remotamente (via comunicação

TCP/IP)

• No fim do ano base foram produzidos os primeiros protótipos e realizados

o teste elétricos básico para verificação do projeto (testes de bancada com

software embarcado reduzido – drivers and interface de debug)

Resultado da atividade: Diagrama esquemático e projeto da placa de circuito

impresso, primeiros protótipos da placa principal do controlador ARM 9.

Período: 01/07/2009 a 31/12/2009

Participantes: João; Ciclano;

Atividade 5: Desenvolvimento de Firmware

Descrição: SW embarcado no equipamento (Concentrador ARM9).

O desenvolvimento do Software embarcado seguiu a metodologia de

desenvolvimento Ágil SCRUM, o que permitiu um desenvolvimento gradual do

software, começando com uma versão básica (device drivers) e aos poucos

adicionando, via portabilidade, as demais funcionalidades do concentrador.

O software foi modelado em UML considerando todos os casos de uso (histórias)

que modelam o comportamento do Concentrador, foi desenvolvido em C++ e foi

utilizado um sistema de gestão de configuração (SVN) para gerenciamento de

versões de software. A equipe de testes usava apenas código liberado o sistema

de controle para garantir sempre testar a última versão.

O desenvolvimento do SW embarcado foi planejado em três etapas:

• Desenvolvimento/integração dos device drivers: Vários device-drivers foram

desenvolvidos ou adaptados de versões disponibilizadas pelos próprios

fabricantes dos componentes. A primeira versão do SW basicamente

possuía o Kernel do Linux com os device drivers (usada para validar os

protótipos de HW)

• Implementação do banco de dados SQLite: até então os dados dos

programas desenvolvidos pela “EMPRESA X” armazenavam os dados

coletados em arquivos texto/binários que eram ou carregados em memória

em estruturas tradicionais de dados como pilhas ou listas encadeadas (para

rápida localização). O SQLite é, na verdade, uma biblioteca em C que

implementa um banco de dados SQL embarcado e não um SGBD separado

(como o mySQL). Ele emula, para o programador o acesso a tabelas de

dados, como em uma aplicação tradicional, abstraindo grande parte da

complexidade que era até então manipulada pelo código fonte. O uso da

biblioteca no projeto foi importante para modificar a maneira como dados

coletados durante a operação eram armazenados, apesar do esforço extra

necessário para adaptar o código fonte existente (a ser executado no ano

base de 2010). Ver também Atividade 6 para mais detalhes.

• Portabilidade das funcionalidades típicas de um Concentrador de outros

produtos da “EMPRESA X”.

No ano base de 2009 foi realizado o desenvolvimento da camada de device drivers

e iniciada a implementação do banco de dados SQLite. O desenvolvimento

consistiu em portar os drivers disponibilizados pelos fornecedores, testando-os para

verificar se atendiam o comportamento esperado e modificando-os para

compatibilidade com a arquitetura do software. Extensas modificações foram

implementadas em vários devices drivers, alterando as passagens de parâmetros

nos métodos.

Entende-se que o maior desafio do projeto é o desenvolvimento do driver de

comunicação, que consistirá de um módulo Webservice (que disponibilizará

páginas Web que implementam as funções de gestão de passos e seus respectivos

acessos) e o módulo de comunicação com os terminais. O desafio está em

conseguir uma solução com desempenho adequado (tempo de espera do usuário),

pois a cada operação de acesso é necessário que exista uma comunicação do

terminal de acesso com o concentrador, a validação do direito de acesso do usuário,

e o envio da autorização de volta para o terminal.

Resultado da atividade: Desenvolvimento da versão inicial do software embarcado

(Linux + device drivers) + banco de dados SQLite.

Período: 01/07/2009 a 31/12/2009

Participantes: Fulano; Beltrano; Antonio

Atividade 6: Desenvolvimento Software

Descrição: Um dos requisitos do projeto era que o controle do concentrador fosse

realizado por qualquer computador na rede do cliente, sem a necessidade de um

SW instalado em todas os computadores da empresa. Para isso decidiu-se

abandonar o conceito de um software de gestão centralizado, capaz de gerenciar

vários concentradores e criar um software de gestão especifico para cada

equipamento.

Dessa forma, o software de gestão Web, na verdade também é um software

embarcado no próprio concentrador. Na distribuição Linux criada especificada para

a aplicação (baseada na versão 2.6.26.5) foi integrado um servidor Web que

hospeda um conjunto de páginas PHP que implementa todas as funcionalidades de

cadastro de usuários, inserção, remoção, poderes específicos, login, administração,

cadastros de visitantes, equipamentos, cadastro de áreas de acesso e suas

permissões, bem como o monitoramento de todos os usuários, relatórios e testes

de performance. Isso significa que todos os dados de configuração e log sempre

estão armazenados dentro do próprio concentrador.

Todas essas informações estão armazenadas em um banco de dados SQLite, que

é na verdade uma biblioteca em C que implementa um banco de dados SQL para

uso embarcado. Tal mudança (de um banco de dados armazenado em arquivos de

registros) para uma solução baseada em SQL demandou uma modelagem de

banco de dados típica de um sistema não embarcado e uma grande adaptação no

software de controle da placa (ver seção do firmware).

A aplicação PHP foi criada no ano base corrente, porém fora do ambiente

embarcado, rodando em um servidor externo e acessando uma base de dados pré-

preeenchida. Essa abordagem permitiu a independência no desenvolvimento em

relação ao equipamento, agilizando o ciclo de P&D. A portabilidade dessa aplicação

para o servidor web embarcado, e os subsequentes testes de desempenho estão

planejadas para 2010.

Resultado da atividade: Desenvolvimento da aplicação PHP (solução Web) porém

rodando em servidor externo.

Período: 01/06/2009 a 31/12/2009

Participantes: Fulano; Antonio

Atividade 7: Desenvolvimento do Gabinete

Descrição: O desenvolvimento mecânico compreendeu a modelagem do gabinete

metálico na ferramenta CATIA para acomodar a placa controladora, a fonte de

alimentação e a disponibilização de a interface externa.

O projeto identificou quais peças metálicas e plásticas já existiam na empresa e

poderiam ser reutilizadas, evitando assim geração de novos custos de ferramentais

na produção. Para as peças novas, os fornecedores atuais foram consultados para

identificar a possível existência de complicações a eles na produção das mesmas.

Os principais requisitos do projeto do gabinete foram

• Robustez: O Gabinete foi projetado para evitar violação por pessoas mal-

intencionadas

• Proteção contra umidade e pó.

• Facilidade de montagem durante a produção

• Facilidade de Manutenção: fácil abertura

No ano base de 2009 foi possível obter o primeiro desenho completo em CATIA e

a produção das primeiras amostras para validação. A validação final da mecânica

precisa esperar a finalização do projeto de hardware. A produção dos moldes e

testes de produção também ficaram para 2010.

Resultado da atividade: 1º desenho em CATIA e amostras.

Período: 15/09/2009 a 31/12/2009

Participantes: Silva;

Atividade 8: Montagem do Protótipo

Descrição: Com o objetivo de preparar o ambiente para testes, protótipos dos

produtos foram montados. Envolveu a revisão das listas de materiais, requisição

dos mesmos para compra, acompanhar a chegada do mesmo, revisar o material

recebido, Montagem dos componentes SMD em linha de produção de protótipos,

soldar os componentes não SDM (exemplo: conectores) e colocar a placa para

rodar pela primeira vez, garantindo que tudo estava corretamente montado para

então disponibilizar para a equipe de desenvolvimento e testes.

Resultado da atividade: Protótipos.

Período: 01/09/2009 a 31/12/2009

Participantes: João; Beltrano; Ciclano;

Atividade 9: Execução de Testes e Validação de Produto

Descrição: Os testes executados em 2009 foram.

• Testes no HW - após a montagem dos componentes, foram realizados

testes de estresse elétrico, mecânico, robustez dos componentes,

aquecimento, durabilidade e confiabilidade. Análise FMEA (Fail Mode Effect

Analisys). Os testes demonstraram que o HW estava robusto suficiente para

atender a todos os requisitos, de tal forma que esta fase do desenvolvimento

foi considera concluída em 2009.

• Testes preliminares na Mecânica - foram realizados testes de montagem,

procedimentos de análise de falhas na pintura, fixações e proteções contra

umidade e poeira.

• Testes preliminares do firmware (SW embarcado) - Foram realizados vários

testes funcionais relacionados a camada de device drivers, ou seja, foi

verificado que comandos de alto nível que virão da aplicação são traduzidos

corretamente para o HW pelos device drivers em questão. Foram

detectados vários problemas de funcionamento dos device drivers que

resultaram na realização de correções por parte da equipe de

desenvolvimento de SW. Foram também realizados testes para verificação

do sistema operacional Linux embarcado.

• Testes preliminares do Software Web - Foram realizados somente testes

funcionais, já que dentro do período reportado tinha-se a solução rodando

em um ambiente PC isolado Banco de dados + servidor Web + páginas

PHP). Os testes consistiram basicamente em testar a funcionalidade das

telas e a gravação e leitura dos dados do banco de dados.

De modo a simular a comunicação com um equipamento foram criados alguns

módulos de Software que simulavam um concentrador.

Testes mais críticos relacionados ao desempenho a solução web estão

programadas para 2010.

A fase de integração do produto será executada em 2010, até final de 2009 foram

obtidos protótipos e realizados os testes preliminares acima mencionados.

Resultado da atividade: Relatórios de Testes.

Período: 01/10/2009 a 31/12/2009

Participantes: João; Beltrano; Ciclano; Silva; Antonio

Atividade 10: Gerenciamento do Projeto

Descrição: Atividades relacionadas ao acompanhamento de prazos, custos e

escopo do projeto, com reporte para a alta gerência da empresa

Resultado da atividade: Cronogramas atualizados, relatórios de acompanhamento

do projeto

Período: 04/01/2009 a 31/12/2009

Participantes: Ailton Quadrante Freitas, FredericoIII

RESULTADO DO PROJETO

O Projeto durante o ano de 2009, chegou até a construção dos protótipos, ou seja,

teve as fases de:

• Desenvolvimento do gabinete mecânico concluído, a ser validado em 2010,

após a entrega da versão final do HW.

• Desenvolvimento de interfaces de comunicação RS485, utilizadas para

controle dos controladores de acesso, e testes com todos os equipamentos

que o Concentrador ARM irá operar no campo.

• Desenvolvimento da nova fonte de alimentação, com uma arquitetura que

atenda todas as demandas do produto e seja robusta suficiente para

suportar os problemas de qualidade de fornecimento de energia que o

mercado brasileiro sofre.

• Desenvolvimento do circuito da placa controladora utilizando o

Microcontrolador ARM9 – Fabricante ATMEL AT91SAM9260QU - TQFP208

(208 pinos) operando com Memória Flash (4M x 16 = 8Mbytes) Fabricante:

Atmel AT49BV642D, com capacidade de expansão via slot para SD Memory

Card 67840-800, tanto para expansão de memória ou boot do sistema.

• Montagem e protótipos para testar a integração da Mecânica com o HW e

passar pelos testes de integração, performance, confiabilidade e robustez.

• Desenvolvimento do software embarcado da concentradora,

desenvolvimento de todos os drivers de comunicação tanto com a ethernet

como com os dispositivos externo.

• Desenvolvimento do sistema WEB completo em linguagem PHP com banco

de dados SQL LITE. Este desenvolvimento englobou: Desenvolvimento de

telas de cadastro de usuários; Desenvolvimento de telas de cadastro de

usuários do sistema e login; Desenvolvimento de telas de cadastro de

visitante; Desenvolvimento de telas de cadastro de equipamentos e

configuração; Desenvolvimento de tela de cadastro de área de acesso;

Desenvolvimento de tela de monitoramento de usuário; Desenvolvimento de

relatórios;

• O Projeto irá continuar em 2010 com a finalização para finalizar todos os

testes e ajustes necessários para atingir os requisitos do projeto. Por ser um

produto inovador, novas tecnologias, seguramente vários ajustes serão

necessários, porém conseguiu-se em 2009 estar com os protótipos em mão.

DESCRIÇÃO DO INVESTIMENTO

RECURSOS HUMANOS DIRETOS

Nome: Frederico

Formação: Superior

Nº de horas despendidas no projeto: 206

Gastos: R$ 24.720,00

Atividades executadas: Planejamento/Coordenação - Vice-presidente e

representante da alta direção da empresa; acompanhou todas as fases do projeto

opinando com poder de decisão, sugerindo e monitorando os resultados obtidos

confrontando-os com as determinações iniciais geradas pela Alta Direção. Dado o

perfil familiar da empresa, o envolvimento direto nas atividades de P&D faz parte

das responsabilidade do Vice-Presidente de operações

Nome: Ailton Quadrante Freitas


N° de horas despendidas no projeto: 280

Gastos: R$ 12.381,60

Atividades executadas: Planejamento/Coordenação - Gerente do Projeto:

acompanhou todas as fases do projeto em função de sua responsabilidade sobre

P&D. Opinando, decidindo e monitorando e interagindo diretamente com o

Coordenador do Projeto e áreas envolvidas.

Nome: Beltrano



Gastos: R$ 50.185,84

Atividades executadas: Desenvolvimento da aplicação de baixo nível- foco nos

módulos de comunicação com os terminais e controle de acesso, protocolo de

comunicação entre a concentradora e os dispositivos de controle de acesso,

aplicação de controle de acesso que faz a interface entre o banco de dados e os

dispositivos de controle de acesso. Testes de comunicação de performance.

Nome: João



Gastos: R$ 25.074,56

Atividades executadas: Desenvolvimento do hardware responsável pelo

desenvolvimento da concentradora, fonte de alimentação e interfaces de

comunicação, acompanhamento da montagem dos protótipos e teste para

validação do hardware.

Nome: Fulano



Gastos: R$ 16.272,00

Atividades executadas: Coordenação e Desenvolvimento de FW - Coordenador e

suporte do desenvolvimento de firmware decidindo, monitorando e interagindo

diretamente com os engenheiros e programadores envolvidos no projeto. Participou

ativamente no desenvolvimento do FW; SW e testes.

Nome: Antonio



Gastos: R$ 39.360,00

Atividades executadas: Desenvolvimento do Software WEB - desenvolvimento dos

módulos de controle de acesso utilizando linguagem PHPe banco de dados

SQLLITE; desenvolvimento de telas de cadastro de usuários, telas de cadastro de

usuários do sistema e login, telas de cadastro de visitante, telas de cadastro de

equipamentos e configuração, tela de cadastro de área de acesso, tela de

monitoramento de usuário; desenvolvimento de relatórios e testes de performance.

Nome: Ciclano

Formação: Médio


Gastos: R$ 1.548,80

Atividades executadas: Desenvolvimento de HW- Montagem dos protótipos,

conferência das listas de material das placas e atualização de esquemáticos

elétricos. Estas atividades foram de apoio ao projetista em todas as suas

demandas.

Nome: Silva

Formação: Médio


Gastos: R$ 6.508,80

Atividades executadas: Desenvolvimento da Mecânica - responsável pelo projeto

mecânico do gabinete da concentradora, criação dos desenhos técnicos das peças

e componentes em 2D e 3D; montagem das peças e criação de instruções para a

fábrica e avaliação da montagem dos protótipos, integralizando o HW com a

mecânica e analisando necessidades de futuros ajustes.

MATERIAIS DE CONSUMO

Descrição da Finalidade do conjunto de materiais para o projeto: Material

necessário para execução das atividades do projeto Concentradora ARM9.

Tipo de material: Solda, pequenas ferramentas, material isolante (material termo

retrátil), cabos diversos, spray limpa contatos (para limpeza de placas de circuito

impresso e resíduos de solda), extensão de tomadas, etiquetas (para identificação

de cabos e equipamentos), fusíveis, parafusos diversos de fixação, álcool

isopropílico (para limpeza de componentes eletrônicos). Toner de impressora.

Material de escritório para uso na implantação da metodologia SCRUM (caneta

piloto, post-it, flip chart, cartões, quadro branco, etc)

Valor: R$ 3.500,24

MATERIAIS DE CONSUMO PARA PROTOTIPOS

Descrição dos materiais: Aquisição de partes, peças e componentes elétricos e

eletrônicos (processadores ARM, memórias Flash, memórias RAM, conectores,

componentes SMD, reguladores de tensão, drivers de comunicação, capacitores,

etc)

Descrição da Finalidade: Materiais necessários para montagem de protótipos para

execução de ensaios e testes, nas fases de desenvolvimento de HW, prototipações

e integração.

Valor: R$ 12.111,20

OUTROS CORRELATOS

Tipo de material: Despesas relacionadas à infraestrutura básica de suporte, como

energia elétrica, provedor de acesso, telefone, água e esgoto entre outras.

Justificativa: Despesas necessárias para o desenvolvimento adequado do projeto,

ou seja, na infraestrutura direta para execução do projeto.

Forma de Apropriação: O custo total foi rateado utilizando o critério número de

colaboradores alocados no projeto.

Custos: R$ 4.678,12

16.1.2. Projeto de SW

PROJETO: Sistema XPTZ - Desenvolvimento de um sistema para monitoramento em

tempo real das condições de funcionamento dos equipamentos instalados nas linhas de manufatura.

DESCRIÇÃO DO PROJETO

Os equipamentos das linhas de manufatura são tipicamente submetidos a altas

cargas de utilização, especialmente quando levamos em conta que um dos

objetivos de uma linha de manufatura considerada produtiva é a baixa taxa de

parada de linha. Uma linha de produção parada por problemas técnicos afeta

significativamente os índices de produtividade.

O objetivo deste projeto é o desenvolvimento de um sistema para monitoramento

em tempo real das condições de funcionamento dos equipamentos instalados

nas linhas de manufatura, através da utilização de algoritmos de previsão e

extração de relatórios técnicos. O sistema, por meio do uso de algoritmos e dos

relatórios, notificará o usuário sobre uma possível falha no equipamento,

podendo, então, a unidade ser substituída ou reparada antes que paralise a linha

de produção.

Poderão ser monitoradas desde versões de software dos equipamentos até

dados de auto diagnóstico. O conjunto completo de dados a monitorar será

objeto de estudo do projeto. Espera-se que o sistema seja capaz de gerar alertas

claros sobre problemas que estão ocorrendo e ainda ser inteligente para informar

com antecedência equipamentos que estão com tendência a falhar em um futuro

próximo.

O escopo desta primeira fase do projeto foi o desenvolvimento de um sistema

integrado de monitoramento e alertas com foco nas estações de teste de

múltiplas linhas de produção. Este sistema foi concebido para permitir a

configuração de filtros dos dados para facilitar a busca e monitoramento de estações

específicas.

O sistema deve assegurar que as calibrações estão ocorrendo como deveriam,

monitorando também que as versões de software mais atualizadas estejam em

uso.

As principais funcionalidades estão descritas e divididas nas etapas de

desenvolvimento listadas abaixo, sendo identificados em cada etapa os

respectivos participantes. Esse projeto foi desenvolvido com práticas ágeis de

desenvolvimento sendo o conceito de Sprints e entregas parciais usado em todo

o projeto.

Etapa 1 - Levantamento de Requisitos e Mapeamento dos Processos: Auditoria nas

linhas de fabricação para levantamento de requisitos das diferentes condições

dos equipamentos (Sistema XPTZ) a serem monitorados, algoritmos a serem

implementados para identificação de tendências e entendimento das possíveis

integrações com sistemas existentes da Empresa.

Nessa etapa, foi identificado que o monitoramento da versão do software

principal das estações de testes era controlado através de relatórios simples

baseados nas linhas de produção de cada localidade separadamente.

Identificou-se que para o monitoramento de calibração de estações de testes de

áudio seria necessário utilizar um algoritmo proprietário da Empresa utilizado em

outro sistema que seria descontinuado com o desenvolvimento do Sistema

XPTZ, uma vez que esse sistema tinha também a abrangência restrita a apenas

algumas estações por vez.

Identificou-se também que para o monitoramento de calibração de estações de

testes de radiofrequência eram utilizadas planilhas com algoritmos proprietários,

porém, limitados a um certo número de estações por vez.

Data Inicial: XX/XX/XXXX

Data final: XX/XX/XXXX

Etapa 2 - Arquitetura: Desenvolvimento de proposta de arquitetura para

implementação da Sistema XPTZ e monitoramento, inicialmente contemplando

monitoramento de versão de software das estações de teste e auditoria da

calibração de estações de rádio frequência e de acústica.

Devido ao acesso restrito a alguns sistemas Empresa, foi decidido que

inicialmente a arquitetura seria localizada para dados das estações de testes de

radiofrequência e acústica (monitoramento de auditoria de calibração), ou seja,

haveria servidores em cada uma das fábricas para extrair os dados das

determinadas estações de cada linha de produção de determinada fábrica.

Devido a decisão de uma arquitetura localizada (pelo menos para essa fase

inicial do projeto), o banco de dados usado foi o mySQL, por se tratar de um

banco de dados relacional de código

aberto.



Etapa 3 - Prototipação: Desenvolvimento de protótipo da interface gráfica do

sistema, protótipo esse que foi desenvolvido de forma animada, a fim de que

alguns usuários finais e os principais envolvidos no sistema pudessem revisar a

navegação e a disposição dos dados e gráficos nas telas do sistema.

Essa etapa trouxe grande benefício ao processo de desenvolvimento, pois

possibilitou uma grande interação com os principais envolvidos, que foram

capazes de alterar e até mesmo eliminar funcionalidades que só seriam

possíveis após o sistema pronto.



Etapa 4 - Desenvolvimento: Desenvolvimento do software para implantação e

testes nas linhas de produção. O software é composto por:

• Autenticação e Autorização de usuários: Nesta área checa-se se o

usuário tem acesso a ferramenta, assim como se ele tem acesso aos dados das

estações de testes das linhas de produção do produto que pretende de monitorar

(nesse caso integrou-se com sistema da Empresa),

• Auditoria de calibração:

- Extração de dados das estações de testes de radiofrequência e de acústica:

Como mencionado acima, essa extração é realizada diretamente das estações,

pois elas estão conectadas a rede da Empresa dentro das fábricas.

- Algoritmos de análise de auditoria da calibração dessas estações: Os

algoritmos são proprietários da Empresa.

- Visualização dos resultados dos algoritmos, incluindo gráficos e dados antes e

pós-processamento. É possível ter acesso aos dados antes do processamento

(dados crus), como vieram das estações, e após serem

combinados/processados pelos algoritmos. O usuário pode comparar estações

do mesmo tipo. Algumas análises básicas foram realizadas e mostradas através

de gráficos, como, por exemplo, quantas estações falharam a auditoria

comparada ao total.

• Versão de software:

- Integração com sistema da Empresa para verificação da versão de software

das estações de teste (todas - independente do tipo): Para estações que não

estavam com software adequado, o sistema exige uma justificativa e prove um

tempo para correção do problema.

- Visualização, possibilitando comparação entre diferentes fábricas.

• Funcionalidade de filtragem de dados para facilitar busca e foco em

fábricas/linhas/estações mais problemáticas.

• Opção de exportar os relatórios para diversos formatos de arquivos e

envio por e-mail:

Relatórios de resultados de monitoramento de versão de software e de auditoria

de calibração de um determinado período.



Etapa 5 – Teste e Validação: Validação e testes de todas as funcionalidades

acima usando simuladores de dados:

Durante esta atividade foi realizada a definição e revisão dos casos de testes,

bem como a execução de casos de teste seguindo diversos métodos de

execução, além da elaboração de relatórios periódicos de execuções de testes.

Após a execução dos testes, alguns ajustes foram necessários por questões de

performance do Sistema, o qual foi implantado inicialmente em um servidor

central na Califórnia e em uma das fábricas na China.

A implantação inicial foi supervisionada por engenheiros locais da fábrica

escolhida e os dados conferidos com seus métodos anteriores e os algoritmos

ajustados de acordo com mudanças necessárias sugeridas pelos próprios

engenheiros, agora com maior facilidade para análise dos dados.

Os dados de monitoramento de versão de software vindo do servidor central

também foram conferidos por engenheiros das fábricas e por seus supervisores,

ampliando assim a visibilidade dos problemas e de sua correção.

Data Inicial:XX/XX/XXXX


RESULTADOS OBTIDOS:

Resultado: Desenvolvimento de aplicação Web (Sistema XPTZ)

Desenvolvimento de aplicação web para visualização e monitoramento do status

das versões de software das estações de testes e das medidas de rádio

frequência e acústica para análise de problemas de calibração das estações.

Os relatórios de dados possibilitam visualizar dados antes e depois dos

algoritmos de análise, assim como alguns gráficos de medidas para as estações

de rádio frequência e acústica. A aplicação também permite exportar os

relatórios para diferentes formatos de arquivos e envio por e-mail.

Este sistema foi concebido para permitir a configuração de filtros dos dados para

facilitar a busca e monitoramento de estações específicas.

O sistema assegura que as calibrações estão ocorrendo como deveriam,

monitorando também que as versões de software mais atualizadas estão em

uso.

O desenvolvimento desta aplicação envolveu o levantamento dos processos,

contemplando a auditoria nas linhas de fabricação para levantamento de

requisitos das diferentes condições dos equipamentos (Sistema XPTZ) a serem

monitoradas, algoritmos a serem implementados para identificação de

tendências e entendimento das possíveis integrações com sistemas existentes

da Empresa.

Baseado nestes levantamentos, foi desenvolvida a arquitetura para

implementação da Sistema XPTZ e monitoramento - inicialmente contemplando

monitoramento de versão de software das estações de teste e auditoria da

calibração de estações de rádio frequência e de acústica.

Foi desenvolvido um protótipo da interface gráfica animada, buscando revisar a

navegação e a disposição dos dados e gráficos nas telas do sistema antes de

iniciar o desenvolvimento do software e sua implantação e testes nas linhas de

produção.

A implantação inicial foi feita em um servidor central na Califórnia e em uma das

fábricas na China.

DISPENDIOS

1) SOFTWARE:

Descrição: 2 Licença Adobe TLP Master Collection CS6 Multiplataforma/Inglês

Data da Aquisição: 26/03/2013

Forma de Apropriação: Aquisição

Tipo de Licença: Licença Anual sem Renovação Automática

Valor (R$): 7.468,40

Justificativa: Usado pelo time de interface gráfica para geração de componentes gráficos

das aplicações. Software usado na etapa 3 – Prototipação, na atividade de criação de

protótipo de interface gráfica do sistema.

2) RECURSOS HUMANOS DIRETOS:

Nome do Colaborador: Funala de Tal

Cargo / Função: Líder Projeto III

Data Inicial: 01/03/2013

Data Final: 01/03/2014

Horas Dedicadas: 1800

Valor (R$): 200.000,00

Justificativa: Salários e encargos pagos ao colaborador, responsável pelo

desenvolvimento das seguintes atividades:

a) Etapa 1 - Levantamento de Processos: Gerente de Projetos, realizou visitas

a fábrica, entendimento dos requisitos e análise de riscos. Participou de

reuniões com a empresa para revisão dos requisitos e decisões das

integrações com sistemas existentes.

b) Etapa 2 - Arquitetura: Gerente de Projetos responsável pela revisão da

proposta de arquitetura, revisão dos riscos, planejamento inicial. Também

participou de reuniões com a empresa para revisão proposta de arquitetura,

da análise de riscos e do planejamento inicial.

c) Etapa 4 - Desenvolvimento: Gerente de Projetos responsável pelo

acompanhamento das atividades das diferentes áreas, controle e

monitoramento dos riscos e interação com o cliente.

Nome do Colaborador: Beltrano Silva Cargo / Função: Gerente de Programa Data Inicial: 01/03/2013 Data Final: 01/03/2014 Horas Dedicadas: 800 Valor (R$): 115.000,00

Justificativa: Salários e encargos pagos ao colaborador, responsável pelo

desenvolvimento das seguintes atividades:

d) Etapa 1 - Levantamento de Processos: Principal responsável pelo

gerenciamento do projeto em nível internacional, atuou no acompanhamento

dos planos do projeto, acompanhamento das atividades das diferentes áreas,

controle do orçamento financeiro e interação com a empresa.

e) b) Etapa 4 - Desenvolvimento: Principal responsável pelo gerenciamento do

projeto em nível internacional. Acompanhamento dos planos do projeto,

acompanhamento das atividades das diferentes áreas, controle do orçamento

financeiro e interação com a empresa.

Nome do Colaborador: Ciclano José Cargo / Função: Analista Desenvolvimento Jr Data Inicial: 01/03/2013 Data Final: 01/03/2014 Horas Dedicadas: 2000 Valor (R$): 95.000,00

Justificativa: Salários e encargos pagos ao colaborador, responsável pelo desenvolvimento da seguinte atividade:

Etapa 4 - Desenvolvimento: Analista de desenvolvimento Junior (com papel

de desenvolvedor junior), responsável pelo desenvolvimento da aplicação

Web para visualização e manipulação dos dados da aplicação.

Nome do Colaborador: Pereira Freitas Cargo / Função: Analista Desenvolvimento Data Inicial: 12/03/2013 Data Final: 01/03/2014 Horas Dedicadas: 270 Valor (R$): 22.000,00 Justificativa: Salários e encargos pagos ao colaborador, responsável pelo desenvolvimento da seguinte atividade:

Etapa 3 - Prototipação: Analista de desenvolvimento Sênior (com papel de

especialista em design de interface e experiência de usuário), responsável

pelo desenvolvimento de protótipo animado, criação de recursos gráficos e

imagens para o projeto.

Nome do Colaborador: Silva Soares Cargo / Função: Analista Desenvolvimento Jr Data Inicial: 12/03/2013 Data Final: 01/03/2014 Horas Dedicadas: 2000 Valor (R$): 95.000,00 Justificativa: Salários e encargos pagos ao colaborador, responsável pelo desenvolvimento das seguintes atividades:

Etapa 4 - Desenvolvimento: Analista de Desenvolvimento Junior (com papel

de testador junior), colaborou na definição e revisão dos casos de testes e na

execução de casos de teste seguindo diversos métodos de execução.

16.2. Projeto de Capacitação

Estrutura mínima:

▪ Conteúdo do Curso

• Escopo e objetivo do curso

• O que o projeto espera alcançar?

• Descrição da ementa ou programa do curso

▪ Nível do Curso

• Identificação do nível do curso, se é um curso de nível superior,

médio ou tecnológico.

▪ Pessoal formado ou capacitado

• Identificação básica das pessoas que realizaram o curso;

• Justificativa da participação no curso, alinhada à habilitação para

executar de atividades de P&D.

▪ Descrição dos Dispêndios

16.2.1. PROJETO CAPACITAÇÃO

A EMPRESA atua no mercado de telecomunicações, desenvolvendo e produzindo no Brasil soluções que têm como premissa criar novos padrões para redes de acesso e novos serviços para o mercado de telecom. Apesar de ser uma empresa consolidada, com quase 50 anos desde sua fundação e um corpo técnico diferenciado, a empresa não tem uma cultura forte na área de Engenharia de Software, o que cria obstáculos para o desenvolvimento de grandes projetos envolvendo software. OBJETIVO: O objetivo deste projeto foi o treinamento e qualificação para técnicos e engenheiros para um aumento da produtividade no desenvolvimento dos sistemas de software produzidos dentro da EMPRESA. METODOLOGIA: O projeto teve duas etapas principais. Na primeira os instrutores prepararam material didático nos tópicos que abordados (Engenharia de Requisitos e Programação Orientada a Objetos em C++). Na segunda os instrutores ministraram cursos sobre esses temas para membros da equipe técnica da EMPRESA. Composição do Programa de Treinamento: Módulo 1 - Requisitos de Software e Modelos de Especificação - 30h 1. Engenharia de Software – conceitos básicos 1.1.Definição de cliente, usuário, projeto, marco 1.2.Tipos de software 1.3.Engenharia de requisitos 2. Requisitos de Software 2.1.Requisitos do usuário 2.2.Requisitos do sistema 2.3.Requisitos Funcionais 2.4.Requisitos Não funcionais 2.5.Qualidade dos requisitos 3. Processos de Engenharia de Requisitos 3.1.Estudo de viabilidade

3.2.Técnicas de Elicitação e análise de requisitos 3.2.1.Brainstorrming 3.2.2.Workshop 3.2.3.Entrevista 3.2.4.Questionário 3.2.5.Observação Direta 3.2.6.JAD 3.3.Validação de requisitos 3.4.Gerenciamento de Requisitos 4. Regras de negócio 5. Modelo de Casos de Uso 5.1.Motivação e objetivos 5.2.Definições preliminares: ator, caso de uso 5.3.Relacionamentos entre casos de uso: extensão, inclusão e generalização/especialização 5.4.Mapeamento de requisitos funcionais em casos de uso, vinculado às regras de negócio 5.5.Diagramas de casos de uso: definição, componentes, notação, especificação 5.6.Descrição de casos de uso 6. Diagrama de Atividades 6.1.Componentes: estados inicial e final, de ação e de atividade, fluxos de controle sequencial e paralelo, ramificação, notas/restrições, raias de natação (partition) 6.2.Diagrama de atividade no processo de desenvolvimento iterativo 7. Especificação de Requisitos de Software (ERSw) - IEEE/ANSI830-1993 Módulo 2 - Projeto e Implementação orientada a objetos usando C++ 60h

1. Conceitos básicos de orientação a objetos: a. classe b. objeto c. mensagem d. encapsulamento e. herança f. polimorfismo g. ligação dinâmica

2. Modelagem UML. 3. História da Linguagem C++; Biblioteca Padrão; Cabeçalhos Padrões. 4. Básico C++ 5. Estrutura do Programa; Exemplo de um Programa Orientado a Objetos; Compilador,

Link e Debug, Arquivo de Projeto; Variáveis, Expressões e Declarações de Atribuição; Identificadores; Variáveis; Declaração; Operadores; Operadores Aritméticos; Operadores Compostos; Operadores Relacionais; Operadores Lógicos; Operadores de Incremento e Decremento; Operador sizeof e size_t; Operador de resolução de escopo (::); Entrada e Saída (input/output); Biblioteca ; Biblioteca ; Biblioteca ; Exemplo de uso de Stream; Estrutura de Controle; Estrutura if; Estrutura if ... else; Estrutura switch...case; Estrutura for; Estrutura while; Estrutura break; Estrutura continue; Funções; Funções Pré-Definidas; Funções Definidas pelo Programador; Vetores; Declarando e referenciando vetores; Vetores em funções; String ou Vetor de Caracteres; Operações com Ponteiros; Ponteiro para Ponteiro; Ponteiro de Função; Exemplo; Conversão de Ponteiros; Ponteiro this; Memória Dinâmica; Manipulação de Objetos Dinâmicos; Referência; Estruturas e Enumerações;Estruturas (struct); Enumerações (enum).

6. Programação Orientada a Objetos 7. Classes; Objetos; Encapsulamento; Atributos; Métodos; Protótipo de Classes; .

Exemplo Prático; Herança; Protótipo para Herança; Polimorfismos; Métodos Virtuais; Exemplo Prático.

8. Bibliotecas 9. Namespaces; Input/Output Console; Classe ; Classe . 10. Introdução ao QT Designer 11. História do QT; Aplicação em Jogos e Interface

12. Estrutura QT Designer 13. Estrutura de Desenvolvimento; Aplicação Principal (Main); Estudo de Caso;

Desenvolvimento Inicial do Estudo de Caso; Instalando QT Designer em Windows; Criando Novas Classes; Iniciando o Programa Principal; Utilizando Compilador QT qmake; Utilizando o qmake..

14. Desenvolvimento Avançado 15. Utilizando Banco de Dados com QT; Etapa 5 do Estudo de Caso; Instalação do MySql

para Qt OpenSource; Configurando MySql para Estudo de Caso; Desenvolvimento do Sistema; Utilizando Vídeos; Plataforma Windows; Plataforma Linux; Etapa 6 do Estudo de Caso.

16. Referências 17. Linguagem C++; QT Designer.

Relação dos funcionários da EMPRESA que receberam o treinamento:

NOME CPF FUNçãO

FUNCIONÁRIO 1 99999999999 PROJETISTA SENIOR

FUNCIONÁRIO 2 88888888888 PROJETISTA PLENO


FUNCIONÁRIO 4 66666666666 PROJETISTA Jr





FUNCIONÁRIO 9 11111111111 ESTAGIARIO


RESULTADO

Campo de Ação do Projeto: Aumento da produtividade no desenvolvimento dos sistemas de

software produzidos dentro da Empresa.

Características Básicas: Treinamento nas áreas de Engenharia de Requisitos e Programação

Orientada a Objetos na Linguagem C++

Conclusão: A realização desses cursos proporcionou a empresa nivelar o conhecimento da equipe e ter uma equipe qualificada para absorver novas tecnologias a serem implementadas pela empresa. O programa de capacitação promoveu conhecimentos básicos essenciais para a equipe de P&D no que tange às técnicas de programação e desenvolvimento software. DESCRIÇÃO DO INVESTIMENTO Este projeto de capacitação teve como principal dispêndio os gastos pagamento de bolsas para os recursos humanos da instituição contratada. Abaixo constam as informações básicas, as atribuições no projeto e os valores recebidos por cada um deles. RH DIRETO: NOME: Fulano de Medeiros CARGO: Docente Função NO PROJETO: Coordenador ATIVIDADE EXECUTADA NO PROJETO: Coordenação do projeto Horas: 200 Valor Recebido: R$ 12.000,00 NOME: Ciclano José CARGO: Docente FUNçãO NO PROJETO: Instrutor

ATIVIDADE EXECUTADA NO PROJETO: Instrutor do Módulo 1-Requisitos de Software e Modelos de Especificação Horas: 180 Valor Recebido: R$ 10.000,00 NOME: Antônio Silva CARGO: Docente FUNçãO NO PROJETO: Instrutor ATIVIDADE EXECUTADA NO PROJETO: Instrutor do Módulo 2-Projeto e Implementação Orientados a Objetos em C++ Horas: 120 Valor Recebido: R$ 8.500,00 NOME: João da Silva CARGO: Aluno FUNçãO NO PROJETO: Monitor ATIVIDADE EXECUTADA NO PROJETO: Monitor dos módulos M1 e M2 Horas: 90 Valor Recebido: R$ 2.500,00 NOME: José de Carvalho CARGO (PROCEDêNCIA INTERNA): Aluno FUNçãO NO PROJETO: Monitor ATIVIDADE EXECUTADA NO PROJETO: Monitor dos módulos M1 e M2 Horas: 90 Valor Recebido: R$ 2.500,00

PERGUNTAS FREQUENTES (FAQ) E ORIENTAÇÕES PARA … · Caso julgar necessário, apresentar, no...

Documents

Transcript of PERGUNTAS FREQUENTES (FAQ) E ORIENTAÇÕES PARA … · Caso julgar necessário, apresentar, no...