UNIVERSIDADE LUTERANA DO BRASIL CURSO DE CIÊNCIA DA COMPUTAÇÃO CÂMPUS GRAVATAÍ SISTEMA DE PERFIL DE COMPETÊNCIAS - SPEC

Transcrição

1 UNIVERSIDADE LUTERANA DO BRASIL CURSO DE CIÊNCIA DA COMPUTAÇÃO CÂMPUS GRAVATAÍ SISTEMA DE PERFIL DE COMPETÊNCIAS - SPEC Whillian Duarte Brose Monografia desenvolvida durante a disciplina de Trabalho de Conclusão de Curso em Informática I e apresentada ao Curso de Ciência da Computação da Universidade Luterana do Brasil, câmpus Gravataí, como pré-requisito para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Carlos Morelli Dutra da Silveira

2 2 Gravataí, novembro de Universidade Luterana do Brasil ULBRA Curso de Ciência da Computação Câmpus Gravataí Reitor: Pastor Ruben Eugen Becker Vice-Reitor: Eng. Leandro Eugênio Becker Diretor do Câmpus Gravataí: Prof. Felício Korb Coordenadora do Curso de Ciência da Computação (Câmpus Gravataí): Prof.ª Patrícia Nogueira Hübler Coordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Gravataí): Prof. Roland Teodorowitsch Banca Avaliadora composta por: Prof. Carlos Morelli Dutra da Silveira (Orientador) Prof. Heitor Boeira dos Reis Filho Prof. Rafael Gastão Coimbra Ferreira CIP Catalogação na Publicação Brose, Whillian Duarte Sistema de Perfil de Competências para Empresas de TI SPEC / Whillian Duarte Brose; [orientado por] Carlos Morelli Dutra da Silveira. Gravataí: 2004, 124 p. Trabalho de Conclusão de Curso versão preliminar (Graduação em Ciência da Computação). Universidade Luterana do Brasil, Perfil de Competências. 2. Desenvolvimento de Software. 3. Engenharia de Software. I. Silveira, Carlos Morelli Dutra da. II. Título. Endereço: Universidade Luterana do Brasil Câmpus Gravataí Estrada Itacolomi, Bairro São Vicente

3 3 CEP Gravataí-RS Brasil

4 SUMÁRIO 1 INTRODUÇÃO Área de Recursos Humanos e Perfis de Competência PROCESSO de Desenvolvimento LEVANTAMENTO DE REQUISITOS Análise Orientada a Objetos PROJETO ORIENTADO A OBJETOS CONCLUSÃO...62

5 LISTA DE FIGURAS

6 LISTA DE QUADROS

7 LISTA DE ABREVIATURAS E SIGLAS GRH HTML OO PC RH TCC1 TCC2 TI ULBRA UML Gestão de Recursos Humanos HypertText Markup Language Orientação a Objetos Perfil de Competência Recursos Humanos Trabalho de Conclusão de Curso I Trabalho de Conclusão de Curso II Tecnologia da Informação Universidade Luterana do Brasil Unified Modeling Language

8 RESUMO O objetivo deste trabalho é Desenvolver um Sistema de Perfil de Competências, baseado nas necessidades da empresa de Tecnologia de Informação Meta Serviços em Informática. Este sistema visa dar subsídios à resolução de dificuldades encontradas na área de Recursos Humanos no que diz respeito ao conhecimento da empresa sob as capacidades de seus funcionários. Palavras-chaves: Perfil de Competências; Desenvolvimento de Software; Engenharia de Software.

9 ABSTRACT The object of this work is develop a Competence Profile System, based in the needs of an Information Technology company called Meta Serviços em Informática. This System intends to give assistance to solve difficulties from the Human Resources area concerning the company's knowledge about their employees capacities. Key-words: Competence Profile; Software Development; Software Engineering.

10 1 INTRODUÇÃO Dentro da área de Recursos Humanos, existe um tema tratado com muita ênfase nos dias de hoje chamado Perfil de Competências. Um Perfil de Competências consiste em um instrumento utilizado para atribuir aos cargos dentro das empresas informações relevantes ao mapeamento do crescimento profissional dos funcionários. Este mapeamento ocorre através de avaliações programadas dos funcionários sob características como: responsabilidades, conhecimentos técnicos, conhecimentos do negócio, habilidades, atitudes e formação. O método acima descrito é uma necessidade atual do departamento de Recursos Humanos (RH) da empresa Meta Serviços em Informática LTDA, situada em São Leopoldo/RS. Assim, o trabalho a ser realizado na disciplina de Trabalho de Conclusão de Curso I (TCC1) é analisar e projetar um Sistema de Perfis de Competência (SPEC). Um dos objetivos do desenvolvimento deste sistema é utilizar durante todas as etapas do ciclo de vida proposto o paradigma Orientado a Objetos (OO) definindo uma notação para realização das atividades propostas considerando a utilização da Unified Modeling Language (UML) como linguagem padrão para a Análise e Projeto do SPEC. Para garantir que o SPEC esteja alinhado não só as necessidades da Meta, mas com a área de Gestão de Recursos Humanos (GRH), no capítulo 2 desta monografia teremos uma revisão bibliográfica sobre Perfis de Competência (foco do SPEC), explicando o que é, como a mesma se enquadra dentro da área de RH, principais vantagens e aplicações. No capítulo 3 será apresentado o processo de desenvolvimento de software que será utilizado para construir o SPEC. Definiremos o paradigma OO, o ciclo de vida proposto, a notação que será utilizada em cada etapa do ciclo e um detalhamento de como serão realizadas as etapas de Levantamento de Requisitos, Análise OO e Projeto OO. Os capítulos seguintes possuem a abordagem prática de todos os conceitos e revisões bibliográficas apresentadas até momento. Iniciamos no capítulo 4 descrevendo o negócio a ser desenvolvido e que resultará no SPEC. Também será realizado o levantamento de requisitos, um detalhamento completo dos mesmos e um Diagrama de Atividades representando a Rastreabilidade dos Requisitos. No capítulo seguinte, Análise OO, criaremos os Diagramas de Caso de Uso a partir dos requisitos levantados para identificar as funcionalidades a serem implementadas. Com estes diagramas, desenvolveremos os Diagramas de Classe de Análise, mais comumente chamados de realização dos casos de uso com o objetivo de identificar as classes, interfaces e processos que devem ser desenvolvidos no SPEC.

11 11 Finalizamos a monografia com o Projeto OO, capítulo 6, criando o Diagrama de Classes de Projeto a partir das definições resultantes da etapa de Análise. Nesta etapa também será desenvolvido o Diagrama Entidade Relacionamento com as definições das estruturas do banco de dados, a definição preliminar da Arquitetura de Software que será utilizada no projeto e encerramos a mesma com o protótipo do SPEC. Os anexos de A a H contêm os quadros de requisitos identificados, árvore de rastreabilidade, os diagramas UML desenvolvidos, diagrama ER e as interfaces do protótipo do SPEC. Desta forma, o foco deste TCC1 será o desenvolvimento das etapas de Levantamento de Requisitos, Análise OO e Projeto OO do SPEC. Para o TCC2 será dado continuidade neste sistema desenvolvendo as etapas de Codificação OO, Testes, Refinamento da Arquitetura de Software e Diagrama de Classe representando os componentes desenvolvidos para este software aplicativo, tendo como resultado final um sistema apto a ser implantado na Meta ou outra empresa de TI que necessite promover o gerenciamento de suas competências internas.

12 12 2 ÁREA DE RECURSOS HUMANOS E PERFIS DE COMPETÊNCIA Nota inicial: dentro de uma empresa, dependendo da forma de contratação das pessoas, elas podem ter uma classificação diferenciada quando a forma com que a mesma é intitulada, como por exemplo: funcionário (quando é contratado via Carteira de Trabalho), colaborador (quando é contratado via Pessoa Jurídica ou como Cooperativa) ou simplesmente utilizando-se o termo recurso. Neste trabalho de conclusão de curso utilizaremos por padrão o termo funcionário para representar as pessoas de uma empresa, somente utilizaremos as outras classificações quando necessário. Nos dias de hoje, está cada vez mais claro que gerenciar de forma correta os recursos humanos de uma organização é fundamental para que a mesma tenha sucesso. As pessoas são fundamentais dentro deste contexto, e por mais informatizada que uma empresa seja, sempre haverá pessoas por trás da tecnologia. Gramigna (2003, p. 4) quando fala da importância em se investir nas pessoas, comenta que sem as pessoas qualquer tecnologia mesmo sendo extremamente inovadora não funciona. A área de Recursos Humanos é responsável por manter todas as questões relativas as pessoas dentro de uma instituição, empresa ou organização seja ela de qualquer porte ou área fim. Bohlander, Snell e Sherman (2003, p. 2), exemplificam algumas áreas dentro da GRH (Gestão de Recursos Humanos): Ocupação de cargos na empresa; Definir cargos e equipes; Qualificar os funcionários; Aprimorar o desempenho das pessoas; Recompensar sucessos. Empresas pequenas com um número de funcionários significativos, e organizações de médio e grande porte, normalmente possuem um departamento de RH (Recursos Humanos) específico dentro de sua estrutura. O número de pessoas que compõe este departamento depende da quantidade de funcionários que a empresa possui, e das áreas da GRH que a empresa necessita tratar, assim, ela pode variar de uma a várias pessoas lideradas por um gerente de RH. Dependendo do negócio de cada empresa e do foco que a mesma quer dar aos seus funcionários, os departamentos de RH podem abordar diferentes áreas dentro da GRH.

13 13 O assunto que será abordado nesta monografia Perfil de Competências - faz parte da área de Gestão de Competências dentro da GRH. Este é um assunto que diariamente vem recebendo uma ênfase maior na GRH devido a sua forma de repensar os métodos de gestão atuais das organizações. Gramigna (2003, p. 5) coloca que é necessário ser repensado a forma como o gerenciamento das pessoas é realizado, segundo ela, as pessoas devem capacitar-se para entrar numa nova era de RH onde este departamento deverá ser um centro de resultados focado em competências. Essa nova forma de pensar, administrando as competências, implica na revisão de processos internos e no realinhamento de estratégias da empresa, como resultado, poderemos ter respostas para perguntas como: Quem são os profissionais de nossa empresa? Quais suas habilidades? Temos uma estratégia que permita aproveitar o potencial das pessoas? Estamos investindo nas pessoas certas? Quem precisa de treinamento? Dispomos das competências essenciais para atingir os objetivos do negócio? Há mecanismos de acompanhamento do desenvolvimento individual que permitam identificar talentos em potencial? Somos capazes de gerenciar a carreira de nossos funcionários? Desta forma, vemos que existem diversas questões que podem ser trabalhadas quando se aplica uma Gestão por Competências de forma eficaz dentro de uma organização. A principal forma apresentada na Gestão de Competências para começar a conhecer as pessoas de uma empresa e a partir disso começar a criar uma base de dados que venha responder perguntas como estas. 2.1 PERFIL DE COMPETÊNCIAS Antes de ser apresentado o que vem a ser um Perfil de Competência (PC), chegaremos à definição do que vem a ser uma competência através de um exemplo. Exemplo: em uma escola, um professor de inglês não pode dar aula devido a problemas de saúde e faltou. Como se tratava de um curso básico de inglês, o professor de português substitui-o com sucesso naquela aula. Analisando o exemplo acima, vemos que o professor de português foi competente neste caso específico, mas isso não garante que ele terá o mesmo sucesso e que poderá substituir o professor de inglês sempre que o mesmo faltar. O professor de português, portanto, não tem as competências necessárias para substituir o professor de inglês em outras aulas de outros níveis. Como resultado desde exemplo, vemos que ser competente está relacionado com um desempenho correto numa determinada tarefa, o que não garante que esse desempenho será

14 14 sempre assim. Rabaglio (2001, p. 2) explana que ter competências para a realização de uma tarefa significa ter conhecimentos, habilidades e atitudes condizentes com a pessoa, e que esta devido a essas características será capaz de colocar esse potencial em prática sempre que houver necessidade. A partir da visão descrita acima por Rabaglio, chegasse à definição de que um Perfil de Competências é um conjunto de competências onde cada uma agrega conhecimentos, habilidades e atitudes necessárias a sua execução que permitem a uma pessoa ou funcionário de uma empresa desempenhar com eficácia as tarefas a ela propostas em qualquer situação. Assim: Perfil de Competência = Conjunto de Competências Uma Competência = Conhecimentos + Habilidades + Atitudes Gramigna (2003, p. 63) expõe que cada pessoa dentro da empresa para um determinado cargo possui conhecimentos específicos para sua execução e conhecimentos essenciais a empresa. Assim, como o foco do trabalho é utilizar um Perfil de Competências para utilização em uma empresa de TI, podemos então subdividir o conhecimento em dois: conhecimentos técnicos e conhecimentos de negócio. Desta forma, uma Competência é composta de informações sobre: 1. Conhecimentos Técnicos: são conhecimentos específicos e necessários para o desempenho de atividades. Exemplo: o cargo de programador necessita possuir o conhecimento técnico sobre a linguagem Java, HyperText Markup Language (HTML), Rational Unified Process (RUP) e Javascript. 2. Conhecimentos de Negócio: são conhecimentos sobre a companhia que o funcionário necessita para desempenhar suas atividades. Exemplo: o cargo de gerente necessita do conhecimento sobre diretrizes da empresa, políticas, normas, missão e procedimentos. 3. Habilidades: são as aptidões ou características individuais desenvolvidas que proporcionam melhor maneira de agir e/ou trabalhar. Rabaglio (2001, p. 3), quando fala sobre habilidades, expressa que uma pessoa pode ter adquirido um conhecimento mas nunca telo utilizado, isto é, esta pessoa não desenvolveu a habilidade necessária para usar esse conhecimento. Exemplo: o cargo de instrutor necessita da habilidade de capacidade em treinar pessoas. 4. Atitudes: são as posturas adotadas por um profissional frente às situações impostas no seu trabalho. Exemplo: o cargo de gerente possui as atitudes de ser pró-ativo, empreendedor e ter foco no resultado. Como vimos em todos os exemplos, os quatro tipos de informações acima que compõe uma Competência, estão intimamente relacionadas aos cargos que uma empresa possui. Bohlander, Snell e Sherman (2003, p. 30) em alguns momentos explicam que um cargo possui atividades relacionadas e que os selecionadores das vagas devem conhecer as especificações e atividades que cada cargo exige. Uma especificação de cargo segundo os autores consiste nos conhecimentos, habilidades e atitudes exigidas para o cargo. Assim, o departamento de RH antes de recrutar as pessoas para a empresa, deve definir um Perfil de Competência para o Cargo, detalhando os conhecimentos, habilidades e atitudes para cada competência do cargo que se deseja ocupar a vaga. Com essa

15 15 padronização as pessoas que vão compor as vagas serão todas avaliadas da mesma forma (sob os mesmos aspectos e características) proporcionando a definição e utilização de um processo de recrutamento formal Um Exemplo de Perfil de Competência Segue abaixo um pequeno exemplo de um Perfil de Competência para elucidar o assunto: Quadro 1 Exemplo de Perfil de Competência para Empresas de TI Perfil de Competência 001 Cargo Gerente Responsabilidades do Cargo Prospectar novos negócios no cliente; Garantir a execução das atividades dos seus funcionários; Repassar informações a seus gestores do andamento das atividades de sua equipe; Competências Liderança; Visão Sistêmica; Tomada de Decisão; Relacionamento Interpessoal; Negociação; Planejamento; Comunicação; Capacidade Empreendedora; Criatividade. A partir do detalhamento do Perfil de Competência acima, para cada competência identificada deverão ser detalhados as atitudes, habilidades e conhecimentos de negócio. Como o exemplo trata de uma empresa de TI, os conhecimentos técnicos serão relacionados aos cargos, aumentando a flexibilidade do modelo que será utilizado, pois segundo Gramigna (2003, p. 37), descrições rígidas de perfis devem ser ao máximo evitadas. Se relacionássemos os conhecimentos técnicos diretamente as competências a empresa teria praticamente um Perfil de Competência para cada pessoa dentro da organização devido à variação enorme de conhecimento técnico existente dentro da área de TI.

16 16 Atitudes Quadro 2 Exemplo de Detalhamento da Competência Liderança Habilidades Conhecimentos Negócio Empatia; Motivação pessoal; Iniciativa; Respeito às diferenças individuais; Respeito às pessoas; Capacidade de energizar grupos; Facilidade para identificar talentos; Uso da delegação de forma assertiva; Capacidade para orientar e treinar pessoas; Modelo de Práticas de Liderança da Empresa; Aplicações dos Perfis de Competências Os perfis de competência podem ser aplicados para diversos fins em uma corporação, segue abaixo alguns exemplos: 1. Definição de PC para seleção de pessoal: define-se um Perfil de Competência específico para cada cargo da empresa. A partir deste perfil o recrutador tenta buscar profissionais no mercado a partir de técnicas de seleção em RH. 2. Avaliação de desempenho de profissionais a partir de PC : tendo as informações dos funcionários da empresa e do Perfil de Competência que o mesmo se enquadrou para preencher a vaga do cargo proposto, o departamento de RH promove avaliações com os funcionários sobre todos os itens que contêm um PC (conhecimentos, habilidades, atitudes) e sobre outras informações relativas ao cargo como as responsabilidades, por exemplo. É checado percentualmente quanto o funcionário evoluiu sob cada item do PC e partir disso tem-se o desempenho de cada profissional na empresa. 3. Utilização de PC para definir remunerações e planos de benefícios : tem como base a avaliação de desempenho descrita no exemplo 2 acima. Define-se um nível percentual para cada item do PC de um cargo específico, e define-se quais os benefícios e remunerações que serão fornecidas quando um funcionário obter aquele nível percentual atribuído aos itens do seu Perfil de Competência. 4. Utilização de PC para identificar talentos na empresa : tem como base a avaliação de desempenho descrita no exemplo 2. A partir destas informações a empresa pode começar a medir quem dentro da empresa está evoluindo mais rapidamente e assim se tornar um talento em seu segmento. 5. Utilização de PC para planejamento de carreira: tem como base também a avaliação de desempenho descrita no exemplo 2 mais acima. Na medida que as avaliações mostrarem que um profissional está chegando em 100% de aproveitamento sob vários itens do Perfil de Competência de seu cargo atual, a empresa pode começar a enquadrar este profissional em cargos superiores. Quando o funcionário alcançar o nível desejado, o mesmo muda de cargo adquirindo agora o Perfil de Competência deste cargo para ser novamente trabalhada a evolução. Neste contexto, fica claro para

17 17 a empresa e para os funcionários como planejar a carreira das pessoas e o que estas devem aprimorar internamente para obterem o crescimento profissional. A partir dos exemplos citados acima, vemos que o uso de Perfis de Competência dentro de uma organização pode trazer diversos benefícios, e que o mesmo propicia aos gestores conhecerem melhor seus funcionários. Gramigna (2003, p. 44), em uma passagem expressa a importância dos gestores em conhecer sua equipe (pontos fortes e fracos) quando um modelo Perfis de Competência é adotado Vantagens da Utilização de PC A utilização de Perfis de Competência propicia vantagens a quem a utiliza. Segue abaixo alguns exemplos: Mapear os conhecimentos dos funcionários da empresa; Mapear as habilidades dos funcionários da empresa; Mapear as atitudes dos funcionários da empresa; Definir um conjunto de competências chave para as pessoas que compõe um cargo da organização; Conhecer o que cada profissional possui de bom e de ruim; Conhecer o que cada profissional necessita trabalhar para ter uma evolução profissional; Disponibilizar informações que levem os gestores a terem maiores subsídios para tomadas de decisão. Por exemplo, a demissão de pessoas; Possibilidade de realização de avaliações de desempenho que levem os profissionais a se conhecerem melhor; Possibilidade de criação de planos de talentos; Possibilidade de criação de planos de carreira Possibilidade de criação de planos de remuneração e benefícios; Desvantagens da Utilização de PC A utilização de Perfis de Competência pode trazer algumas desvantagens a quem a utiliza. Segue abaixo alguns exemplos: Necessidade de manter pessoas para trabalharem e manterem os Perfis de Competência; Se for realizada uma avaliação de PC, existirá a necessidade de alguém do departamento de RH que fique realizando as avaliações nos períodos e setores programados pela empresa;

18 18 Dificuldade de manter todas estas informações em papéis ou arquivos digitais dispersos; Necessidade de utilização de alguma ferramenta ou sistema que gerencie os cargos e PC da organização; Não se tem muitas opções de Software que tratem este assunto, as poucas opções são caras e normalmente não são focadas em uma área de conhecimento específica, como por exemplo empresas de TI;

19 19 3 PROCESSO DE DESENVOLVIMENTO Pressman (2002, p. 17), define considera um processo como uma abordagem adotada para a construção do software, sendo que para esta construção, um conjunto de tarefas definidas deve existir. Assim, antes de iniciar o desenvolvimento do Sistema SPEC, é fundamental definirmos como o sistema será desenvolvido, quais as etapas, qual o paradigma de desenvolvimento que será utilizado, qual o ciclo de vida que será utilizado, quais serão os Artefatos de Software que serão gerados após a conclusão de cada etapa do ciclo de vida, ou seja, neste capitulo será explorado o processo que será utilizado para a construção do Sistema. 3.1 PARADIGMA DE DESENVOLVIMENTO O paradigma de desenvolvimento de software que será utilizado para o desenvolvimento do Sistema SPEC será o Orientado a Objetos (OO). Para Pressman (2002, p. 532), este paradigma abrange de forma mais completa a Engenharia de Software pela possibilidade de utilização de praticamente todos os conceitos relevantes da Engenharia. Para Rumbaugh (1991) orientação a objetos é a maneira correta de pensar o mundo real para o entendimento dos problemas que deverão ser traduzidos posteriormente em software. Assim, este paradigma atualmente vem sendo utilizado com maior freqüência dentro das organizações por conseguir abstrair o mundo real sem perdas ou distorções como eram às vezes observadas em outros paradigmas. Furlan (1998, p.11) explica que a mudança de enfoque de análise estruturada para análise orientada a objetos é justificada por objetos existirem na natureza muito antes de haver qualquer tipo de aplicação ou programa que reflita a realidade, e assim, devemos desenvolver software seguindo o mesmo curso de como as coisas nascem na realidade, primeiro os objetos, depois os programas. Todas as etapas que contemplam um ciclo de vida de desenvolvimento de software podem ser realizadas utilizando-se o paradigma OO. No capitulo seguinte será apresentado o ciclo de vida que será utilizado para desenvolver o Sistema SPEC.

20 CICLO DE VIDA UTILIZADO PARA DESENVOLVIMENTO DO SISTEMA Define-se Ciclo de Vida como o conjunto de etapas a serem cumpridas ou realizadas que inicia normalmente com a necessidade do usuário e termina quando o software em sua totalidade estiver pronto. As etapas de um ciclo de vida podem variar dependo do tipo de software que se necessita desenvolver e o fluxo de troca de uma etapa para outra pode variar também dependendo do tipo de projeto que será desenvolvido. Como o Sistema SPEC será desenvolvido utilizando o paradigma OO, o ciclo de vida que melhor se adequa a este projeto é o Modelo de Processo Evolutivo. Segundo Pressman (2002, p. 533), este modelo agrupado a características que abordam o reuso de componentes é o melhor modelo para se construir software orientado a objetos. Segue abaixo portanto o desenho das Etapas e Atividades do Ciclo de Vida para a construção do Sistema SPEC que será utilizado: ETAPA 1 ATIVIDADE 1 ATIVIDADE 2 ATIVIDADE 3 Levantamento de requisitos ou refinamento de requisitos Identificar classes candidatas Procurar classes na biblioteca Extrair classes se disponível Desenvolver a engenharia das classes se não disponível NOVA ITERAÇÃO Construir n-ésima iteração do sistema ATIVIDADE 4 Colocar novas classes na biblioteca ETAPA 5 ETAPA 2 Testes Análise OO ETAPA 4 ETAPA 3 Codificação OO Projeto OO Figura 1 Ciclo de Vida do Sistema SPEC - Modelo de Processo Evolutivo O processo OO move-se ao longo de uma espiral evolutiva que inicia com o levantamento de requisitos junto com o usuário. Como Pressman (2002, p. 533) enfatisa o reuso, as classes necessárias para o desenvolvimento dos requisitos levantados com o usuário são procuradas em uma biblioteca antes de serem construídas. Se a classe não for encontrada, é aplicada a análise OO, o projeto OO, a codificação OO e os testes necessários para a construção desta classe que vem atender o solicitado. Após estas etapas, esta classe é colocada na biblioteca para futuro reuso e em seguida uma nova versão do software é gerada. A próxima iteração do processo evolutivo é realizada caso o sistema não esteja completamente pronto. O número de iterações neste ciclo de vida para a construção do Sistema SPEC tenderá a ser reduzido devido ao levantamento de requisitos do sistema estar sendo realizado nesta primeira fase do Trabalho de Conclusão de Curso. Desta forma, a maioria das iterações que ocorrerão no processo evolutivo será para a realização do refinamento dos requisitos e reutilização de código.

21 21 Como o Sistema SPEC será desenvolvido do zero, ou seja, sem se basear em qualquer outro sistema que permita o reuso de componentes, o levantamento de requisitos, a análise OO e o projeto OO serão desenvolvidos nesta primeira fase do Trabalho de Conclusão de Curso. Na segunda fase do trabalho, as etapas de codificação OO, etapa de testes e a inclusão dos componentes gerados em uma biblioteca para futuro reuso serão contemplados. Nos próximos capítulos segue um detalhamento nas etapas contempladas nesta primeira fase do trabalho, ou seja, no TCC ETAPA DE LEVANTAMENTO DE REQUISITOS Segundo Cardoso (2003, p.11) requisito é o nome dado a qualquer necessidade que se identifica para um sistema em desenvolvimento, manutenção ou outra etapa do processo. A identificação de requisitos é realizada normalmente por um analista de sistemas ou um analista de negócios, profissional que conhece profundamente o negócio do cliente e consegue detalhá-lo de forma mais precisa que o primeiro. Os requisitos são levantados através de reuniões e debates com a área de negócio, área usuária ou outros profissionais que entendam exatamente o que é necessário para a construção do Software. Para Pressman (2002, p. 250), a Engenharia de Requisitos traz a equipe do projeto à forma adequada para entender o que o cliente deseja, analisar as necessidades, avaliar a exeqüibilidade e administrar os requisitos à medida que eles são transformados num sistema em operação. Pressman também afirma que o processo de Engenharia de Requisitos pode ser descrito em cinco etapas distintas: 1. Elicitação de Requisitos: diz respeito à forma os requisitos de um sistema são levantados; 2. Análise e Negociação de Requisitos : a análise e negociação de requisitos é uma análise realizada nos requisitos levantados, onde segundo Pressman (2002, p. 252), objetiva-se categorizar requisitos e organizá-los mapeando suas dependências 3. Especificação de Requisitos: Pressman (2002, p. 252) deixa claro que existem várias formas de se especificar requisitos, essas formas podem variar em, por exemplo, um documento escrito, um modelo gráfico, uma coleção de cenários de uso ou qualquer agrupamento destes documentos citados. Mais adianta neste capítulo seguirá a forma como os requisitos deste sistema foram especificados. 4. Validação de Requisitos: Pressman (2002, p. 253) coloca que a validação dos requisitos visa garantir a partir de uma relação de requisitos, que seu detalhamento foi realizado com sucesso e de modo não-ambiguo. 5. Gestão de Requisitos: dentro do processo de Engenharia de Requisitos de Pressman (2002, p. 254), ele define que basicamente a gestão de requisitos são diversas atividades que propiciam a equipe identificar, controlar e rastrear os requisitos durante qualquer parte do processo de desenvolvimento.

22 Tipos de Requisito Cardoso (2003) deixa claro que ao levantarmos os requisitos de um sistema devemos classificá-los em 4 tipos fundamentais: Requisito Funcional: é o tipo de requisito que representa uma ação do sistema ou uma funcionalidade. Não são considerados os aspectos físicos de implantação ou ambiente como requisitos funcionais. Requisito de Dado: são requisitos que especificam como as estruturas estáticas físicas do software devem ser, ou seja, normalmente diz respeito a requisitos de uma tabela, visão, ou consulta deve ser implementada no banco de dados. Requisito de Interface: referem-se a requisitos que especificam as interfaces (telas) do sistema. Requisito Não-Funcional: estes requisitos descrevem questões de ambiente, infra-estrutura, performance, usuários simultâneos, ou seja, detalham todas as necessidades do software que não são diretamente funcionalidades que o mesmo deve possuir Notação para o Nome dos Requisitos A notação utilizada para colocar o nome dos requisitos seguiu a sugestão dada por Cardoso (2003, p.14), pois a mesma consegue detalhar no próprio nome informações úteis sobre o requisito analisado: Forma: ER[f a][f D I N].XXXX.N Onde: ER significa Especificação de Requisitos. [f a] significa um requisito futuro ou atual. [F D I N] significa o tipo de requisito: F = Requisito Funcional, este especifica uma ação que o sistema deverá ser capaz de executar; D = Requisito de Dado, este especifica um requisito de estrutura estática interna do software ou para vinculação de requisitos; I = Requisito de Interface, refere-se as interfaces do sistema com o usuário ou com outros sistemas; N = Requisito Não-Funcional, que especifica informações que não são funcionalidades do sistema, mas características que o mesmo deve possuir, como por exemplo número de usuários simultâneos ou questões de performance por exemplo. XXXX é o nome do sistema ao qual o requisito se refere.

23 23 N é um número seqüencial que diferenciará cada requisito. Exemplo de nome de um requisito funcional do sistema SPEC: ERaF.SPEC Quadro de Detalhamento de Requisitos O seguinte quadro foi utilizado para se detalhar todos os requisitos levantados para o desenvolvimento do Sistema SPEC. Quadro 3 Modelo de Quadro para Especificação de Requisitos ER[f a][f D I <descrição textual do nome do requisito> N].XXXX.N Descrição <descrição detalhada do requisito> Responsáveis pelo Requisito no Sistema <nome dos responsáveis pelo requisito no Sistema> Dependência de Requisitos <nome dos requisitos ao qual este requisito que se está detalhando é dependente. Listar os nomes do formato: ER[f a][f D I N].XXXX.N> Casos de Uso Relacionados <nome do caso de uso nível 1 que contempla este requisito> <nome do caso de uso nível 2 que contempla este requisito> Porquê da não implementação do Requisito <caso o requisito não seja desenvolvido neste momento detalhar o porque da não implementação.> O quadro acima foi baseado no Quadro de Detalhamento de Requisitos de Cardoso (2003), porém algumas modificações neste quadro foram realizadas para representação mais efetiva e unificada das informações geradas. As seguintes informações foram adicionadas ao quadro de Cardoso: Requisitos Dependentes; Casos de Uso Relacionados Artefatos Requisitos Gerados na Etapa de Levantamento de O quadro abaixo detalha os artefatos que serão gerados na etapa de Levantamento de Requisitos para o desenvolvimento do SPEC.

24 24 Quadro 4 Artefatos que serão Gerados na Etapa Levantamento de Requisitos Nro do Artefato Descrição Artefato 01 Descrição do Negócio É uma descrição que define o que se espera do sistema ser desenvolvido. Para o SPEC a descrição do negócio foi gerada a partir de entrevistas com analistas de RH da Meta Informática e a partir das revisões bibliográficas realizadas. 02 Detalhamento dos São os diversos quadros que detalham cada Requisitos do SPEC requisito individualmente seguindo o formato estabelecido no item Quadro de Detalhamento de Requisitos. 03 Lista de Requisitos do SPEC É um quadro um uma listagem de todos os requisitos encontrados e que devem ser considerados para o desenvolvimento do SPEC. 04 Árvore de Rastreabilidade É um Diagrama de Atividade da UML que dos Requisitos demonstra a dependência lógica de cada requisito identificado. Esta árvore serve para definir quais os requisitos que devem ser priorizados para uma correto desenvolvimento do sistema. 3.4 ETAPA DE ANÁLISE OO Segundo Larman (2000), a etapa de análise quando voltada ao paradigma OO visa identificar a partir de requisitos de negócio as classes de projeto, interfaces e processos que serão desenvolvidos para construção do sistema. Larman (2000) quando fala sobre a Análise OO também coloca que para se chegar a este estágio uma série de métodos devem ser seguidos. Estes métodos podem ser realizados utilizando-se várias técnicas, mas a mais comum e que tem se mostrado mais eficaz atualmente dentro da Análise Orientada a Objetos é a utilização da UML. Booch (2000) quando introduz ao assunto da UML, afirma que ela é adequada a modelagem de sistemas rotineiros, sistemas para Web e até mesmo sistemas de tempo real. Como o SPEC trata-se de um sistema rotineiro que será desenvolvido para a Web, utilizaremos esta linguagem de modelagem para realizar não só a etapa de Análise OO como alguns diagramas para o Projeto OO. Tanto Booch (2000) quanto Larman (2000) e Cardoso (2003) explicam que a UML é composta de uma série de Diagramas que podem ser utilizados para diversos fins. Fica claro nas bibliografias que dependendo da metodologia de desenvolvimento de software utilizada e do processo de análise de sistemas definido dentro dela, não necessariamente todos os diagramas devem ser utilizados. Na verdade a escolha dos diagramas depende do foco e da complexidade que o processo de análise necessita ter para cada projeto. Desta forma, para o desenvolvimento da etapa de Análise OO do projeto SPEC foram selecionados os Diagramas considerados mais importante pelos autores. São eles: Diagrama de Casos de Uso Nível 1;

25 25 Diagrama de Casos de Uso Nível 2; Diagrama de Classe de Análise (Realização dos Casos de Uso); Conforme descrito acima, serão detalhados os Diagramas de Caso de Uso do SPEC. Convencíamos para este trabalho de conclusão entrar em dois níveis de detalhamento e aprofundamento nos casos de uso, assim, chamamos de Nível 1 o detalhamento macro da análise dos requisitos e de Nível 2 o detalhamento detalhado de cada Caso de Uso dos diagramas de Nível 1. Esta convenção foi definida para este trabalho e não é uma regra dentro da UML, já que esta notação não especifica uma forma padrão de detalhar o nível de aprofundamento dado na análise. Os três diagramas listados acima serão utilizados na etapa de Análise OO para o desenvolvimento do SPEC e serão melhor detalhados nos capítulos seguintes. Para a etapa de Projeto OO outros diagramas da UML serão utilizados, no item 3.5 Etapa de Projeto OO eles serão apresentados. A etapa de Análise OO iniciará com a análise dos requisitos identificados na etapa de Levantamento de Requisitos. A partir dos requisitos criaremos os Diagramas de Caso de Uso Níveis 1 e 2 para expandir a visão das funcionalidades que o sistema deverá possuir. Após termos o conjunto de casos de uso desenvolvidos, faremos os Diagramas de Classes de Análise para descobrir as interfaces (telas), processos e as classes que o SPEC deverá possuir. A execução destas atividades resultarão em um conjunto de artefatos que serão o ponto de partida para o início da etapa de Projeto OO. Não é o foco desta monografia uma explicação mais detalhada da UML e de como deve ser feita à modelagem de cada diagrama que a mesma disponibiliza. Para uma análise mais aprofundada neste assunto sugerimos as referências de Booch (2000), Larman (2000) e Cardoso (2003) Artefatos Gerados na Etapa de Análise OO O quadro abaixo detalha os artefatos que serão gerados na etapa de Análise OO para o desenvolvimento do SPEC.

26 26 Quadro 5 Artefatos que serão Gerados na Etapa de Análise OO Nro do Artefato Descrição Artefato 05 Desenho dos Diagramas de É o desenho dos casos de uso primeiro nível Caso de Uso Nível 1 seguindo a notação expressa pela UML. 06 Desenho dos Diagramas de É o desenho dos casos de uso de segundo Caso de Uso Nível 2 nível, seguindo a notação expressa pela UML, obtidos a partir da análise realizada. 07 Listagem dos: A partir da análise dos Casos de Uso Nível 2, este artefato é um quadro apresentando para Diagramas de Caso de cada caso de uso as funcionalidades que Uso Nível 3; deverão ser implementadas (Nível 3) e um Requisitos Associados; Requisitos Dependentes; detalhamento dos requisitos que resolvem o caso de uso analisado. sob a análise dos Casos de Uso Nível 2 08 Desenho dos Diagramas de É o desenho das realizações dos casos de uso Classe de Análise segundo nível seguindo a notação expressa pela UML. 09 Listagem das: A partir da análise das realizações dos casos de uso, este artefato é um quadro apresentando Interfaces (telas); para cada caso de uso as interfaces, processos Processos; e as classes que deverão ser implementadas no Entidades (classes); sob a análise dos Diagramas sistema. de Classe de Análise 3.5 ETAPA DE PROJETO OO A etapa de Projeto OO segundo Larman (2000), visa detalhar em termos de tecnologia e implementação como o sistema a ser desenvolvido passará de uma visão lógica/conceitual para uma visão física, com foco na definição das soluções tecnológicas para a construção do sistema orientado a objetos. Nesta etapa, utiliza-se os artefatos gerados na etapa de Análise OO e se procura determinar principalmente como o sistema efetivamente será construído. Analisa-se muito nesta etapa também os requisitos não-funcionais determinados na etapa de Levantamento de Requisitos do sistema. Estes requisitos serão os principais subsídios que serão utilizados para se determinar nesta etapa a Arquitetura de Software que será utilizada no projeto. Analisando a referência de Mendes (2002), podemos concluir que uma Arquitetura de Software é um conjunto de componentes e características inter-relacionadas sob princípios e diretrizes bem definidas que apresentam como o software deve ser construído para que o mesmo atenda a necessidade proposta. Desta forma, durante esta etapa do projeto realizaremos as seguintes atividades: Relacionaremos que as classes identificadas na análise de acordo com os requisitos e casos de uso definidos;

27 27 Definiremos a estrutura de banco de dados (tabelas e relacionamentos) necessária para a persistência dos objetos; Definiremos uma arquitetura de software preliminar para utilização na etapa de desenvolvimento OO; Prototiparemos as interfaces (telas) que o SPEC possuirá; Assim como na etapa de Análise OO, a etapa de Projeto OO também necessita de uma notação para execução de algumas das atividades definidas acima. A UML pode novamente ser utilizada também para esta etapa, porém, ela não define uma forma de mapear as tabelas e seus relacionamentos em um banco de dados, desta forma, teremos que mesclar nesta etapa a utilização de um Diagrama Entidade Relacionamento. Este diagrama é amplamente utilizado em todo o mundo para este fim. Baseado na premissa de utilização dos principais e essenciais diagramas recomendados pelos autores Booch (2000), Larman (2000) e Cardoso (2003) em um processo de desenvolvimento, da mesma forma que foi feito na etapa de Análise, os seguintes diagramas serão utilizados: Diagrama de Pacotes Diagrama de Classes de Projeto Diagrama Entidade Relacionamento Segundo Booch (2000) os diagramas acima são fundamentais em um processo de desenvolvimento, porem outros diagramas UML também podem ser utilizados nesta etapa. A escolha de outros diagramas segundo o autor deve considerar diversos fatores no projeto, os principais são o nível de documentação que o cliente espera que seja desenvolvido e tempo que se tem no projeto para desenvolver tais documentos. Para esta etapa inicial do trabalho de conclusão de curso consideraremos o desenvolvimento dos diagramas acima por Booch (2000) os considerar essenciais e fundamentais ao processo e devido ao tempo que se tem para elaboração deste trabalho.

28 Artefatos Gerados na Etapa de Projeto OO O quadro abaixo detalha os artefatos que serão gerados na etapa de Análise OO para o desenvolvimento do SPEC. Quadro 6 Artefatos que serão Gerados na Etapa de Projeto OO Nro do Artefato Descrição Artefato 10 Diagrama de Pacotes e É o desenho do diagrama de classes do projeto Classes de Projeto detalhando para as classes os seus relacionamento e também seus atributos, métodos e pacotes seguindo a notação expressa pela UML. 11 Diagrama Entidade É o desenho das entidades (tabelas) que devem Relacionamento ser construídas no banco de dados que será utilizado com o objetivo de fornecer a estrutura necessária para o armazenamento das informações do SPEC. 12 Definição Macro da É uma definição em alto nível da arquitetura Arquitetura de Software que está sendo proposta para construção do SPEC. A definição detalhada da arquitetura será realizada no TCC2 antes da etapa de Desenvolvimento. 13 Protótipo das Interfaces do É um desenho das interfaces do SPEC. O SPEC objetivo deste protótipo é validar com os analistas de RH da Meta (usuários do sistema) se as mesmas atendem os requisitos e necessidades por elas apresentados na etapa de Levantamento de Requisitos.

29 29 4 LEVANTAMENTO DE REQUISITOS 4.1 INTRODUÇÃO Este trabalho de conclusão de curso focará no desenvolvimento de um Sistema de Perfil de Competências SPEC baseado nas necessidades do departamento de Recursos Humanos (RH) da empresa Meta Serviços em Informática. A Meta é uma empresa focada na venda de serviços em Tecnologia da Informação (TI). Possui Unidades de Negócio em São Leopoldo/RS, Porto Alegre/RS, Curitiba/PR e São Paulo/SP atendendo também clientes de estados como Distrito Federal, Rio de Janeiro e Bahia. Esta empresa possui aproximadamente 14 (quatorze) anos de existência, e conta atualmente com mais de 100 (cem) projetos ativos com aproximadamente 500 (quinhentos) funcionários e colaboradores espalhados por todo o Brasil. Seu conjunto de serviços abrange: Planejamento e Desenvolvimento de Software; Consultoria em Engenharia de Software (Processos e Metodologia); Fábricas de Software; Consultoria em TI; Outsourcing; Consultorias em ERP; Escritório Projetos; Alocação de Profissionais; As necessidades do departamento de RH da Meta foram levantadas através de entrevistas com funcionários do próprio departamento e com gerentes da empresa. O desenvolvimento deste sistema em todos os momentos levou em consideração se a necessidade levantada havia fundamentação teórica em referências bibliográficas da área de Gestão de Recursos Humanos (GRH). Em caso positivo o negócio era relacionado para ser analisado e projeto para futura implementação no TCC2, em caso negativo, foram buscadas alternativas com esta fundamentação para discussão com a pessoa entrevistada.

30 Descrição do Negócio Atualmente, a empresa Meta possui um departamento de RH descentralizado, ou seja, a equipe é formada por aproximadamente 8 pessoas. Destas, 3 funcionários trabalham na Unidade Rio Grande do Sul, 2 em São Paulo, 1 em Curitiba e as demais em clientes estratégicos da empresa. Um dos principais problemas expostos por essa equipe, é que a empresa não possui um sistema que gerencie seus recursos humanos, ou seja, não se tem um cadastro que possa ser utilizado pelo departamento de RH, em que estes possam trabalhar as informações dos funcionários para facilitar tarefas rotineiras como, por exemplo, consultar informações sobre o conhecimento dos funcionários, verificar os cargos que as pessoas já tiveram na empresa, checar onde a maioria das pessoas que possui um certo conhecimento está alocada no Brasil, controlar os currículos dos funcionários de forma a nunca perder uma informação relevante e outros. Todas as informações que o departamento possui sobre os funcionários estão dentro de planilhas de cálculo ou dentro de arquivos texto separados por diretórios específicos. Como não se tem um banco de dados estruturado e planejado especificamente para trabalhar questões da área de RH, as analistas do departamento não podem aplicar praticamente nenhum método de GRH. Em contrapartida, vemos que a realidade da empresa faz com que isso seja necessário, pois existe uma rotatividade muito grande de pessoas na empresa, o chamado TurnOver, e isso normalmente é atribuído pela falta de conhecimento que a empresa tem sobre seus funcionários. Conversando com pessoas da área de RH que trabalham em outras empresas de TI prestadoras de serviço, fica claro que isso não é um caso isolado. A maioria das empresas de TI atualmente possuem problemas na hora de contratar, manter, re-alocar pessoas, emitir relatórios de evolução dos funcionários, criar planos de carreira, remuneração, benefícios e outros métodos que julgamos ser fundamentais em qualquer empresa com um número de profissionais elevado. A partir do contexto apresentado, vemos a necessidade de desenvolver um sistema de RH que seja focado em empresas de TI. Este sistema deve dar subsídios ao departamento de RH da Meta ou ao departamento de outra empresa de TI, para consultar e armazenar informações sobre os funcionários provenientes dos seus currículos e que este sistema esteja preparado para trabalhar questões relevantes da GRH através dos Perfis de Competências conforme sugerido pela maioria das analistas de RH entrevistadas. A partir de uma revisão bibliográfica sobre o assunto realmente foi identificado que os Perfis de Competências são aplicáveis a serem mapeados como um sistema e que este pode ser utilizado para facilitar e dar a estes departamentos subsídios a um trabalho de maior qualidade proporcionando a empresa resolução para problemas relacionados a funcionários no seu dia-a-dia. Com a finalidade de facilitar o entendimento, esta descrição de negócio foi dividida em 3 áreas especificas: Pessoas Cargos e Perfis de Competência Avaliações

31 ETAPAS DO PROCESSO DE ENGENHARIA DE REQUISITOS Elicitação de Requisitos Para elicitar os requisitos para o Sistema SPEC foram utilizados as descrições de negócio da área de Gestão de Competências da GRH, e a partir de entrevistas com realizadas com gerentes e funcionários do departamento de RH da empresa Meta. Estas informações retiradas de bibliografias com descrições do negócio foram armazenadas inicialmente em arquivos eletrônicos no formato TXT para que uma compilação posterior destas informações fosse executada. As entrevistas com os funcionários da Meta geraram anotações diversas que também foram transferidas para um arquivo eletrônico no formato TXT. Foi gerada uma descrição textual simples para cada requisito identificado e cada um recebeu inicialmente um número seqüencial Análise e Negociação de Requisitos Para o Sistema SPEC, foram analisados cada requisito levantado e seus relacionamentos, onde a partir disso foram identificados as dependências entre os mesmos. Cada requisito agora possuía: um número seqüencial, uma descrição textual e o número dos requisitos relacionados Especificação de Requisitos A especificação de requisitos do Sistema SPEC foi realizada definindo-se uma notação para o nome dos requisitos e um quadro para o detalhamento de cada requisito. Esta notação foi detalhada no item Etapa de Levantamento de Requisitos Validação de Requisitos Desta forma, após o detalhamento de todos os requisitos na etapa anterior, os mesmos foram levados ao Departamento de RH Meta para que fossem validados e verificados se tudo o que realmente é necessário foi levantado e descrito de forma correta. Esta etapa é fundamental no processo para que não se tenha posterior re-trabalho no desenvolvimento do sistema Gestão de Requisitos Para garantir a rastreabilidade, controle e gerencia dos requisitos do Sistema SPEC foi gerado uma Árvore de Rastreabilidade de Requisitos que segue no ANEXO B. Esta árvore foi desenvolvida utilizando-se um Diagrama de Atividades da UML devido a sua característica de apresentar processos que podem ser executados em paralelo. Segundo Furlan (1998, p.218), o diagrama de atividade permite determinarmos a ordem pela qual as coisas devem ser realizadas utilizando-se dos conceitos de OO, diferentemente de fluxogramas padrão.

32 FERRAMENTAS UTILIZADAS As ferramentas que foram utilizadas para a Etapa de Levantamento de Requisitos estão listadas no quadro abaixo. Quadro 7 Ferramentas Utilizadas para o Levantamento de Requisitos Tipo de Nome Fornecedor Site Ferramenta Editor de Textos Microsoft Word 2000 Microsoft IDENTIFICAÇÃO DOS REQUISITOS Conforme descrito no item Elicitação de Requisitos, o levantamento de requisitos do Sistema SPEC foi realizado através de referências bibliográficas sobre as descrições de negócio da área de Gestão de Competências da GRH, e a partir de entrevistas com funcionários da Meta. Desta forma, este item apresentará uma descrição geral do negócio ao qual o Sistema de Perfil de Competências SPEC vem solucionar baseado nas necessidades da empresa Meta. A partir desta descrição de negócio, que é na verdade uma compilação de necessidades da empresa, revisões bibliográficas e entrevistas, foi realizado o levantamento de requisitos. Sempre que através de uma descrição textual de negócio um requisito for identificado, o nome do requisito equivalente seguindo a notação descrita no item Notação para o Nome dos Requisitos, será explicitado para mostrar a vinculação das regras de negócio do sistema com os requisitos do sistema. Como houve uma etapa de Análise e Negociação de Requisitos item 4.2.2, e como o ciclo de vida utilizado no projeto contempla um Modelo de Processo Evolutivo, os requisitos foram vinculados e relacionados através de suas numerações após cada incremento do processo, assim, os requisitos que aparecerão na descrição de negócio descrita abaixo não seguirão necessariamente uma ordem seqüencial de numeração. Poderão existir também requisitos que são relacionados e com numerações bem distantes, o que caracteriza um refinamento de requisitos, passo fundamental do Processo Evolutivo para a Engenharia de Requisitos Pessoas Desta forma, a primeira coisa que o Sistema de Perfil de Competências (SPEC) deve possuir segundo as entrevistas realizadas é um cadastro de pessoas que seja simples, ou seja, não se pretende através deste sistema gerenciar folhas de pagamento, informações cadastrais dos funcionários ou outras informações pessoais que não venham a agregar em um sistema de RH. Todas estas questões citadas que não estarão presentes no SPEC que estará sendo construído, já são tratadas por outros departamentos internos como o financeiro ou o de contratos. Assim, o cadastro de pessoas deve conter somente dados como: nome da pessoa, , seu telefone, a data do cadastro, o endereço contendo uma descrição do mesmo, complemento, bairro e a cidade (ERaF.SPEC.1 - Cadastro de Pessoas).