pim 4

UNIVERSIDADE PAULISTA - UNIP

CURSO SUPERIOR DE TECNOLOGIA

GESTÃO DE SISTEMAS DE INFORMAÇÃO

JOSÉ LUIS FERNANDES PINEIRO R. A. 090051-7

MARIO PEREIRA DE ALMEIDA R. A. 090175-2

CRISTIANO ALVES DE MACEDO R. A. 090089-3

SANDRO LORENÇO DO PRADO R.A. 090432-1

PIM IV

Projeto Integrado Multidisciplinar

Grupo JLC

SÃO PAULO

2º Período – 2009/2

JOSÉ LUIS FERNANDES PINEIRO R. A. 090051-7

MARIO PEREIRA DE ALMEIDA R. A. 090175-2

CRISTIANO ALVES DE MACEDO R. A. 090089-3

SANDRO LORENÇO DO PRADO R.A. 090432-1

Projeto Integrado Multidisciplinar IV

Grupo JLC

Projeto Integrado Multidisciplinar – PIM IV, apresentado como um dos pré-requisitos para aprovação do 2º Semestre, no Curso Superior de Formação Tecnológica em Gestão.

Orientadores: Prof. Luiz Antonio

Prof.Ricardo Shitsuka

Prof.Adrane Colosseti

SÃO PAULO

2º Período – 2009/2

RESUMO

O Grupo pesquisado para este trabalho vem ao longo dos tempos aprimorando seus métodos, técnicas e ferramentas em busca de qualidade, produtividade, escalabilidade, contingência nos seus processos internos bem como gerenciamento de toda a sua rede LAN e WAN.

Investimentos estão sendo feitos bem como novas tecnologias estão sendo instaladas em virtude do seu crescimento no mercado. É sabido que a informatica sempre teve um custo muito alto para as companhias, porem é impossível viver sem ela hoje em dia, a sem uma documentação correta se torna ainda mais difícil.

Neste contexto, a documentação de software tem grande importância, pois pode influenciar tanto na qualidade quanto na produtividade do Grupo. A falta ou o excesso de documentação pode colocar em risco o desenvolvimento e a manutenção do software. Encontrar um ponto de equilíbrio na quantidade de documentação gerada é de fundamental importância.

Palavras Chaves: documentação, tecnologia, produtividade.

ABSTRACT

The used Group in this work comes during years improving its methods, techniques and tools in quality search, productivity, scalability, contingency in its internal processes and the management of all its LAN and WAN networks. Investments are being made and new technologies are being installed in virtue of its growth in the market. It is known that computer science always had a high cost for the company, but is impossible to live without it nowadays, and without a correct documentation it becomes more difficult. In this context, the software documentation has great importance, therefore it can influence in such a way in the quality and in the productivity of the Group. The lack or the excess of documentations can be a risk for

the development and the maintenance for the software. Find a balance in the amount of generated documentation is the main importance for the group.

Keywords: documentation, technology, productivity.

LISTA DE FIGURAS

Figura 1 – Processo de Engenharia

Figura 2 – Evoluçao

Figura 3 – Categoria 1




SUMÁRIO

INTRODUÇÃO VII

1 - Modelagem de Processos VIII

2 – RDM X

3 - Estudos de Viabilidade XI

4 - Identificação XIII

4.1 - Atividades envolvidas XIII

4.2 - Dificuldades XIV

4.3 - Técnicas para elicitação de requisitos XIV

4.3.1 - Entrevistas e Questionários XIV

4.3.2 - Workshops de requisitosXV

4.3.3 – Cenários XVI

4.3.4 – Prototipagem XVI

4.3.5 - Estudo etnográfico XVII

5 - Análise e negociação dos requisitos XVII

5.1 - Atividades envolvidas XVII

5.2 – Dificuldades XVIII

5.2 - Negociações XIX

6 - Validação XX

6.1 - Técnicas de validação XXI

6.1.1 - Revisões dos requisitos XXI

6.1.2 – Prototipificação XXII

6.1.3 - Geração de casos de teste XXII

6.1.4 - Análise de consistência automática XXIII

6.2 – Recomendações XXIII

6.3 - Gestão de requisitos XXIII

7 - Portal do Grupo XXVI

7.1 - Gestão de Desenvolvimentos XXVI

7.2 - Especificação e documentação dos requisitos(SRS) XXVI

7.3 - Especificação Funcional e Técnica XXVII

7.4 - Especificação de Configuração para módulos SAP XXVII

7.5 - Descrição dos campos que compõe o nome dos arquivos: XXVII

8 – Redes de Computadores e Telecomunicações XXIX

8.1 - Evolução XXIX

8.2 – Recursos computacionais do Grupo XXX

8.2.1 – Normas Técnicas Gerais XXXI

8.2.1.1 – Cabeamento XXXI

8.2.1.1 – Arquitetura XXXII

8.2.1.1 – Categorias XXXII

9 – Conclusão XXXVI

REFERENCIA BIBLIOGRAFICA XXXVII

INTRODUÇÃO

Hoje em dia a documentação tem uma importância muito grande para as empresas, sejam elas desenvolvedoras de software ou empresas que se utiliza de sua área de tecnológica para fazer os seus próprios sistemas.

Experiências e pesquisas mostram que existem duas razões básicas para documentar, uma serve para auxiliar a comunicação durante o projeto e outra para auxiliar o entendimento nas atividades de manutenção.

A documentação é necessária quando é preciso estabelecer uma comunicação com uma equipe externa de trabalho. Ela serve como mecanismo de suporte à comunicação quando é combinada com reuniões, teleconferência, correio eletrônico e ferramentas colaborativas.

1 - Modelagem de Processos

O controle sobre os processos envolvidos na gestão corporativa é um fator essencial para que uma empresa possa atender às normas e regulamentações do setor em que atua, alem de seguir procedimentos fundamentais para os objetivos e metas definidos em seu planejamento estratégico.

Uma modelagem de processos ideal abrange vários aspectos ao mesmo tempo independentes e complementares, todos relevantes para que as empresas possam identificar necessidades, definir padrões, diagnosticar problemas e programar correções, colocando-se assim num caminho seguro de evolução de sua gestão.

Existe uma grande dificuldade das empresas que desenvolvem software cumprirem suas metas de prazo e orçamento. Segundo o “Standish Group”, somente 16,2% dos projetos de software terminaram dentro do prazo e orçamento estimados.

Muitas vezes o prazo de entrega pode significar a sobrevivência ou não de uma organização. Na tentativa de minimizar este problema, estudos são realizados na área da Engenharia de Software. Neste contexto, a abordagem da documentação tem grande importância, onde o prazo de entrega do projeto pode variar de acordo com a quantidade e qualidade dos artefatos de software a serem entregues.

Segundo Scott W.Ambler [1], duas razões são básicas para documentar “uma serve para auxiliar a comunicação durante o projeto e outra para auxiliar o entendimento nas atividades de manutenção. A documentação é necessária quando é preciso estabelecer uma comunicação com uma equipe externa de trabalho. Ela serve como mecanismo de suporte à comunicação quando é combinada com reuniões, teleconferência, correio eletrônico e ferramentas colaborativas. A documentação de software tem um efeito significante no entendimento do programa”.

[1] Brasileiro, escreveu vários livros sobre o objeto de desenvolvimento de software, orador de conferencias em todo mundo sobre organizações internas.

As empresas atualmente não podem perder muito tempo para encontra-se no padrão de qualidade ISO 9000, onde estes padrões querem dizer “planejar seus trabalhos e trabalhar seus planos”, com a função extra de “documentar sempre seus planos e fazer sempre seus documentos”.

Com a grande rotatividade de seus profissionais tanto internamente como para o mercado, as empresas se preocupam muito com as suas documentações internas, porem parece ser um sonho impossível. Ultimamente as empresas estão gastando bilhões de dólares, mas qual o motivo? Pode-se dizer que é a falta de uma “documentação” apropriada, ou a não existência da mesma.

Em entrevista com o responsável por documentações do Grupo “a documentação é essencial e apropriada para desenvolver e migrar sistemas, através dela conseguimos gerenciar os projetos, educar, antecipar, executar planejamento de capacidade”.

Atualmente o grupo tem utilizado algumas ferramentas para administração dos seus documentos como: RDM, PMBOOK, WorkFlow.

2 – RDM

A RDM “Requirements Development Management” (engenharia de requisitos) é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.

Figura 1 – Processo de Engenharia

Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. O processo de engenharia de requisitos é composto por quatro atividades de alto nível:

Identificação

Análise e negociação

Especificação e documentação

Validação

Uma outra atividade que se pode considerar que faz também parte deste processo, se incluir a fase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos, sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos requisitos), entre outras).

3 - Estudos de Viabilidade

Antes de avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo de viabilidade.

Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e organizacional, o projeto é viável.

Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com “as partes interessadas do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões”:

• Será que o sistema contribui para os objetivos da organização?

• Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado?

• Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?

A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvio, são frequentemente desenvolvidos sistemas que não contribuem para os objetivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da organização.

Deve, portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta informação, procedendo-se de seguida a recolha de todos os dados disponíveis para clarificar ao máximo o âmbito do projeto e avaliar a sua viabilidade.

Tipicamente, quem poderá fornecer esta informação serão os utilizadores dos sistemas actuais e do sistema a implementar, os responsáveis pelos departamentos nos quais o sistema será

usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados).

Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo:

• Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?

• Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas?

• De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?

• É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)?

• Com que facilidade é que se consegue partilhar informação entre estes sistemas?

O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível. Alem da opção acima, para projetos grandes usar os “templates” (estudo da viabilidade e Visão do Negócio) fica mais abrangente e claro (link em anexo).

4 - Identificação

Caso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.

4.1 - Atividades envolvidas

Algumas das atividades envolvidas nesta fase incluem:

• Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas.

• Identificação das partes interessadas: Estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos utilizadores do sistema.

• Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema.

• Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.

4.2 - Dificuldades

Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas:

• O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo.

• Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo).

• Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações.

4.3 - Técnicas para elicitação de requisitos

Existem diversas técnicas de identificação de requisitos, e que são adequadas a diferentes situações, entre as quais podemos citar nos itens abaixo:

4.3.1 - Entrevistas e Questionários

Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns factores:

• Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida.

• Relação pessoal entre os intervenientes na entrevista.

• Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afectado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação.

• Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).

4.3.2 - Workshops de requisitos

O WORKSHOP de Requisitos consiste numa técnica usada para através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, obter um conjunto de requisitos bem definidos.

Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontracção como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários intervenientes (ainda que não tenha realmente poder de decisão).

As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador.

Uma técnica que é também útil em workshops é o uso de brainstorming (tempestade de idéias) como forma de gerar um elevado número de ideias numa pequena quantidade de tempo.

Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar.

4.3.3 – Cenários

Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:

• Estado do sistema no início do cenário.

• Sequência de eventos esperada (na ausência de erros) no cenário.

• Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados.

• Outras atividades que podem estar a ser executadas ao mesmo tempo que as deste cenário.

• Estado do sistema depois de o cenário terminar.

4.3.4 – Prototipagem

O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na prototipificação evolutiva, isto é, aquela que mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os utilizadores é, para eles, um aspecto crítico.

4.3.5 - Estudo etnográfico

Os Estudos Etnográficos são uma análise do componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para levá-las a cabo. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para processá-los pode ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo.

5 - Análise e negociação dos requisitos

Após a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dos mesmos.

5.1 - Atividades envolvidas

Algumas das atividades envolvidas na análise de requisitos incluem:

• Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema.

• Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível.

• Prioritização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um factor gerador de conflitos.

• Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema).

Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir inclusive para as demais fases.

A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.

5.2 – Dificuldades

As dificuldades encontradas na análise são de diversas naturezas:

• Factores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema).

• O ambiente (económico e/ou organizacional) em que a análise é feita é possue fatores dinâmicos, e como tal os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis).

5.2 - Negociações

Relativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Para tanto, faz-se algumas sugestões:

• Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos.

• Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação.

• Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos.

• Relatar restrições, quando se torna óbvio que as actuais não conseguem levar a um consenso.

6 - Validação

Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de facto, ao sistema que o cliente pretende.

À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.

A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projecto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído.

Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos:

• Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como

tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida.

• Consistência: não devem existir conflitos entre os requisitos identificados.

• Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.

• Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.

• Realismo: dadas as restrições do projecto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.

• Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de

modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.

• Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.

• Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento.

6.1 - Técnicas de validação

Para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser empregues:

6.1.1 - Revisões dos requisitos

Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadores finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros requisitos).

6.1.2 – Prototipificação

A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com a versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação).

6.1.3 - Geração de casos de teste

Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado.

6.1.4 - Análise de consistência automática

Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as ferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas.

6.2 – Recomendações

A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito importante na engenharia de requisitos e da qual dependem elevados custos a médio e longo prazo.

Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em validação de requisitos) é bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase posterior, já com o documento validado e o projeto em desenvolvimento ou concluído. Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado.

6.3 - Gestão de requisitos

Os requisitos de um sistema, em especial em sistemas minimamente grandes, estão em evolução constante.

De um modo geral, isto pode suceder por o problema abordado não conseguir ficar completamente definido antes da produção do documento de requisitos (ou mesmo antes de o sistema ser implementado) ou, por outro lado, pode também acontecer por os próprios requisitos se alterarem no decorrer do projecto (reflectindo evoluções tecnológicas ou alterações na organização na qual é usado).

É natural que surjam requisitos por parte dos utilizadores por diversos motivos:

• Conforme já foi referido, a resolução de conflitos entre requisitos resulta num compromisso que procura equilibrar as necessidades das diferentes partes interessadas. Este equilíbrio pode ter de ser modificado e só com o uso do sistema é que é possível avaliá-lo convenientemente. Para além de conflitos

entre requisitos de diferentes utilizadores do sistema, há ainda a considerar os conflitos entre utilizadores e "elementos executivos" da

organização, isto é, aqueles que têm o poder de decisão e que podem impôr requisitos perante os analistas (que podem não contribuir para os objectivos da organização).

• A orientação do negócio da organização pode-se alterar, nova legislação ou regulamentação pode pôr em causa alguns dos requisitos do sistema, alterações a nível tecnológico podem surgir na organização (afectando particularmente, no caso de alterações de hardware, os requisitos não-funcionais), podem surgir novos sistemas que precisem de suporte, a nível de

interação, por parte do sistema implementado, e toda uma série de alterações imprevisíveis pode surgir levando a que o sistema tenha de se adaptar a todo este tipo de requisitos.

Existem requisitos que, tipicamente, são mais voláteis do que outros (como por exemplo requisitos que dependam da entidade política governante num dado momento), enquanto que outros são relativamente estáveis (os que se referem à natureza do negócio (domínio) propriamente dita).

Na prática, a gestão de requisitos acaba por coincidir com o início de novos processos de engenharia de requisitos (para os "novos" requisitos, isto é, os "antigos" que sofreram alterações). Como tal, o planejamento é uma parte importante da gestão de requisitos. Devem estar definidas desde o início da gestão de requisitos políticas para:

• Identificação de requisitos: identificação unívoca em especial para facilitar a rastreabilidade.

• Processo de gestão de mudanças a utilizar: conjunto de atividades que permitem avaliar o custo e impacto das alterações.

• Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas podem precisar de manter associada a cada requisito informação como a parte interessada que a propôs, dependências de outros requisitos e associação a módulos específicos do design do sistema.

• Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar pode ser elevada, sendo o uso de ferramentas CASE aconselhado.

Para manter a consistência entre as várias alterações pedidas (e para estas serem feitas de um modo controlado), é importante que o processo de gestão de mudanças esteja definido de um modo formal, sendo que deverá incluir as seguintes três fases:

• Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos originais e proposta de

alteração a fazer aos requisitos do sistema.

• Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do impacto da alteração no sistema.

• Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e implementação.

É importante seguir este processo conforme foi enunciado já que cair na tentação de implementar a alteração directamente e só depois, retrospectivamente, actualizar os requisitos pode levar a dessincronização entre requisitos e implementação.

7 - Portal do Grupo

Todas as documentações dos desenvolvimentos são arquivadas no Portal (intranet) do Grupo.

Dentro deste portal foi criada uma biblioteca, com a seguinte estrutura:

7.1 - Gestão de Desenvolvimentos

RDM-EEE-PPPPPPPP-Descrição do projeto

o Estudo de Viabilidade

o Identificação

Atividades Envolvidas

Dificuldades

o Análise e negociação

Atividades Envolvidas

Dificuldades

Elicitação

o Validação

Revisões dos requisitos

Prototipificação

Geração de casos de teste

o Gestão de Requisitos

Identificação de requisitos

Processo de gestão de mudanças a utilizar

Custo e impacto das alterações.

Rastreabilidade

Análise do problema e especificação da alteração a fazer

Análise da alteração e seu impacto

Implementação da alteração

7.2 - Especificação e documentação dos requisitos(SRS)

Esta área é utilizada para a guarda do documento de especificação de requisitos de um sistema. Em geral o documento é gerado em tempo de projeto. O arquivo de especificação de requisitos deve ter a seguinte nomenclatura:

SRS-EEE-PPPPPPPP-Descrição do projeto

7.3 - Especificação Funcional e Técnica

Esta área deve ser utilizada para guarda do documento de especificação de requisitos de um sistema. Em geral o documento é gerado em tempo de projeto.

O arquivo de especificação de requisitos deve ter a seguinte nomenclatura:

EFT-XXX-PPPPPPPP-Descrição do desenvolvimento

7.4 - Especificação de Configuração para módulos SAP

Template modelo é utilizado para configurações SAP funcionais e técnicas (MM/SD / BASIS / PI / BC)

7.5 - Descrição dos campos que compõe o nome dos arquivos:

SRS – é uma literal fixa

EEE – é um código para identificar a empresa. Utilizar:

o SGB Corporativo SGBrasil

o VID Vidros

o ABR ABRASIVOS

o CAN CANALIZAÇÃO

o TEL TELHANORTE

o QUA QUARTZOLI

o BRA BRASILIT

o MCE MATERIAIS CERAMICOS

o CPL CERÂMICAS E PLASTICOS

o ELD ELDORADO

o PLC PLACO

o DVO VIDRO OCO

PPPPPPP – meneumônico com o nome do Projeto ou Grupo confirme criado no Módulo exemplo: Dados Mestres

Descrição do projeto: Campo livre para identificar com clareza o nome do projeto (não utilizar a palavra “projeto” somente o nome dele. Exemplo: Nota Fiscal Eletrônica

EFT – é uma literal fixa

Descrição do desenvolvimento: Campo livre para identificar com clareza o nome do desenvolvimento (não utilizar a palavra “projeto” ou a palavra “desenvolvimento” somente o nome deste).

Exemplos:

o SRS:VID: NFELETR Nota Fiscal Eletrônica (Vidros)

o EFT:VID:NFELETR:Geração e Impressão do Formulário DANFE de Vidros.

8 – Redes de Computadores e Telecomunicações

Uma rede de computadores consiste de 2 ou mais computadores e outros dispositivos conectados entre si de modo a poderem compartilhar seus serviços, que podem ser: dados, impressoras, mensagens (e-mails), etc. A Internet é um amplo sistema de comunicação que conecta muitas redes de computadores. Existem várias formas e recursos de vários equipamentos que podem ser interligados e compartilhados, mediante meios de acesso, protocolos e requisitos de segurança.

Telecomunicações é a transmissão, emissão ou recepção, por fio, radioeletricidade, meios ópticos ou qualquer outro processo eletromagnético, de símbolos, caracteres, sinais, escritos, imagens, sons ou informações de qualquer natureza.

8.1 - Evolução

Figura 2 – Evolução

A informática é um dos maiores avanços já dado pelo homem, ela revolucionou todos os setores da sociedade e ainda modificou as formas de realizar as atividades. A área começou a ganhar projeção na década de 50 e o seu termo resulta da associação das palavras informação e automática.

O primeiro sistema de computação era precário quando a informática começou a ser desenvolvida, prova disso é o fato do primeiro computador ter uma estrutura gigante e apenas efetuar as funções de uma calculadora. Com o tempo, os dispositivos se tornaram mais compactos e os cientistas descobriram novas linguagens de programação.

Foi somente na década de 90 que a informática tomou uma proporção impressionante, devido ao sistema operacional Windows criado pela Microsoft. Os programas tinham um formato simplificado e isso facilitava as ações do usuário. A rede mundial de computadores também cresceu assim a internet se tornou a melhor meio de comunicação e informação.

8.2 – Recursos computacionais do Grupo

A utilização dos recursos computacionais e das redes de comunicação é um fator primordial no crescimento e desenvolvimento das empresas do Grupo.

Sem dúvida, essas ferramentas de trabalho promovem o acesso mais rápido e eficiente a um número maior de informações, e fornecem uma melhor comunicação com clientes e fornecedores. Para a empresa e seus usuários, a segurança e a confiabilidade dos sistemas de informação merecem interesse prioritário e contínuo. Assim, a proteção de dados confidenciais, a conformidade com a legislação vigente, especialmente com relação à propriedade intelectual e ao processamento de dados eletrônicos, e a lealdade para com a empresa são parte integrante das obrigações e responsabilidades de todo usuário. Não há dúvidas de que preservar os interesses industriais, comerciais e financeiros da empresa e do Grupo, assim como de nossa imagem corporativa, depende da conformidade com estas regras e do uso adequado das inúmeras tecnologias.

Estas regras aplicam-se a todos os funcionários da empresa que, ao desenvolver tarefas sob suas responsabilidades, precisam organizar instalar, modificar ou utilizar, sejam de forma direta ou indireta, os recursos computacionais e as redes de comunicação. A utilização dos recursos computacionais e deres de comunicação é restrita a finalidades profissionais.

Os recursos computacionais (desktops, laptops, palmtops, servidores, etc.); as redes de comunicação de dados (redes internas, internet, intranet, etc.) e os sistemas de telefonia (telefones digitais, máquinas de fax, celulares, etc.) são ferramentas de trabalho disponibilizadas pela empresa para ajudar os usuários a realizar suas tarefas. Portanto, os recursos computacionais e as redes de comunicação necessariamente possuem o uso restrito a tarefas profissionais. O usuário é, em todo tempo, responsável pelo uso dos recursos computacionais e redes de comunicação da empresa, e precisa estar em conformidades com as normas da empresa.

O Grupo tem presença em 57 países, com 207.000 funcionários e 1.200 empresas consolidadas, mais de 5.300 sites interconectados.

Para manter esta estrutura o Grupo criou e determinou alguns padrões, gerando gerenciamento centralizado, alta disponibilidade, e documentações.

8.2.1 – Normas Técnicas Gerais

A implementação de normas de organização e arquitetura na rede LAN e WAN de todo o Grupo permite uma redução da complexidade técnica e custo destas redes, bem como um aumento no níveis de serviço e segurança para os negócios do Grupo.

8.2.1.1 – Cabeamento

Ethernet é o único método de acesso aceito o meio físico. Token Ring, FDDI e outras variações (TPDDI) não são métodos de acesso padrão e deve ser usado somente se a sua substituição por Ethernet envolve riscos operacionais, em aplicações de negócios (SNA) ou não é possível.

Par de cobre trançado (UTP / STP / FTP, 4 pares) e sistemas de fibra óptica são os únicos meios de variedades Ethernet aceito. Conectores BNC e cabos coaxiais não são compatíveis com as normas IPT.

Categoria 5e são cabos esperados como um padrão mínimo de cabeamento na LAN. O uso de categorias inferiores do cabo impede o fornecimento de equipamentos de rede de largura de banda total para as estações finais.

8.2.1.1 – Arquitetura

As especificações de roteadores na rede Wan são definidas pela equipe de Telecom junto com a operadora.

Na rede Lan não são permitidos “hubs”, deve-se implementar equipamentos de camada 2, no intuito de evitar colisões e retransmissões desnecessárias bem como tornar a rede local capaz de suportar a qualidade de serviço e Telefonia IP.

O endereçamento IP varia dependendo do uso de cada negócio do grupo.

Os equipamentos de rede LAN com funcionalidades diferentes por negócio devem ser logicamente separados utilizando VLAN (IEE 802.1q), onde o particionamento é necessário, o encaminhamento deve ser feito através de equipamentos de camada 3.

8.2.1.1 – Categorias

Categoria 1 refere-se a locais menores (menos de 5 computadores) com exigência de criticidade baixa (showrooms, pequenos sites de vendas) Estações terminais devem estar fisicamente ligado a um switch de acesso único. Cumprimento e configuração de 802.1x, 802.1Q, 802.1p, 802.1d, 802.1w não é esperado. Pares de cobre trançado deve ser utilizado como a única mídia media interface Ethernet

See table below for an explanation of technical acronyms


Categoria 2 refere-se à maioria dos locais de distribuição (lojas e sites de vendas entre 5 e 20 usuários) com exigência de criticidade padrão. Também pode se referir ao escritório e locais de vendas.

As normas específicas aplicáveis à categoria 2 os locais são:

Passiva de fail-over

Presença de pelo menos um Switch camada 3


Categoria 3 refere-se aos locais polivalentes de tamanho médio (de 20 a 250 usuários, sites de distribuição maiores). Estes locais têm condições de criticidade padrão. Categoria 3 é configurado para que diferentes tipos de terminais (servidores, estações,etc.) compartilhando o mesmo meio de transmissão pertencem a domínios de broadcast separado.

As normas específicas aplicáveis à categoria 3 sites são:

Fail-over passivo

Presença de pelo menos um Switch camada 3

Presença de pelo menos um Switch camada 3 no núcleo

Uso do Protocolo Spanning Tree (IEEE 802.1d STP


Categoria 4 refere-se ao maior site com exigência de alta criticidade. Esses sites têm mais de 250 usuários, aplicativos de host central, podem hospedar equipamentos industriais. Sites de categoria 4 podem implementar conexões WAN dupla e geralmente são divididos por vários edifícios. Esta categoria se destina a descrever uma sede e as maiores plantas do Grupo.

As normas técnicas específicas para a categoria 4 sites são os seguintes:

Presença de switch camada 3 é obrigatório na rede central

Fail-over ativo

Protocolo de roteamento OSPF

Uso do Protocolo Spanning Tree (IEE 802.1d STP)

Encaminhamento de pacotes deve ser executado na camada 3

Fail-over dinâmico, VRRP, deve ser aplicado nos equipamentos de camada 3.

See table below for an explanation of technical acronyms


9 – Conclusão

A explosão observada na utilização das redes de computadores e documentação só foi possível graças à acelerada expansão verificada nas últimas décadas nas Telecomunicações e na Tecnologia da Informação. Necessidades criadas pelo processo de Globalização que se observa nos últimos anos na economia, na política e no comportamento das Nações tem transformado as redes em ferramentas indispensáveis no relacionamento do dia-a-dia das organizações e das pessoas.

Em entrevista com as áreas de TI:

“A documentação é mais importante do que aquilo sobre o que ela trata. O Grupo esta trabalhando arduamente na validação de todos os processos junto a IBM, pois nem sempre as equipes de suporte estão disponíveis de imediato a resolver problemas de usuários, programas, servidores, redes LAN e WAN, então é importante escrever guias de como solucionar certos problemas e como realizar tarefas básicas. Percebemos que documentar é quase que uma tarefa diária para este Grupo, sempre aparece alguma coisa que é interessante documentar, então não podemos perder tempo”.

REFERENCIA BIBLIOGRAFICA

AMBLER, Scott W. Agile Documentation. 2001-2004, The Official Agile Modeling (AM) Site, 2001, Disponível em : , Acesso em: 02 abr. 2001.

GALLO, MICHAEL A., HANCOCK, W. M.: “Comunicação entre Computadores e Tecnologías de Rede”, São Paulo, 2003.

SOARES, L. F. G., LEMOS,G. e COLCHER, S.: “Redes de Computadores: das LANs, MANs e WANs às Redes ATM”, 2ª Ed., Rio de Janeiro, Ed. Campus, 1995.

TANENBAUM, A. S.: “Redes de Computadores”, Tradução da 4ª edição, Rio de Janeiro, Ed. Campus, 2003.

Wikipédia, a enciclopédia livre. Ensino Fundamental

http://pt.wikipedia.org/wiki/Ensino_fundamental

pim 4

Documents