UNIVERSIDADE PAULISTA - UNIPCURSO SUPERIOR DE TECNOLOGIAGESTÃO DE SISTEMAS DE INFORMAÇÃOJOSÉ LUIS FERNANDES PINEIRO R. A. ...
Orientadores: Prof. Luiz AntonioProf.RicardoShitsuka                                        Prof.AdraneColosseti  SÃO PAUL...
the development and the maintenance for the software. Find a balance in the amount ofgenerated documentation is the main i...
4.3.4 – Prototipagem    XVI4.3.5 - Estudo etnográfico      XVII5 - Análise e negociação dos requisitos XVII5.1 - Atividade...
9 – Conclusão XXXVIREFERENCIA BIBLIOGRAFICA       XXXVIIINTRODUÇÃOHoje em dia a documentação tem uma importância muito gra...
Segundo Scott W.Ambler *1+, duas razões são básicas para documentar “uma serve paraauxiliar a comunicação durante o projet...
       Análise e negociação       Especificação e documentação       ValidaçãoUma outra atividade que se pode considera...
usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema edos sistemas existentes), respo...
•       Identificação das partes interessadas: Estes já deverão ter sido identificados nosestudos de viabilidade, porém pa...
•        Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a serafectado pela introdução de ...
•       Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de comoestes erros serão tratados.•      ...
5.1 - Atividades envolvidasAlgumas das atividades envolvidas na análise de requisitos incluem:•      Classificação: agrupa...
Relativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra semproblemas, chegando-se logo a cons...
•     Compreensibilidade / Ambiguidade: os requisitos devem poder                        sercompreendidos de forma inequív...
A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para osutilizadores finais (e demais ...
6.3 - Gestão de requisitosOs requisitos de um sistema, em especial em sistemas minimamente grandes, estão emevolução const...
•       Processo de gestão de mudanças a utilizar: conjunto de        atividades que permitem avaliar o custo e impacto da...
o       Análise e negociação       Atividades Envolvidas       Dificuldades       Elicitaçãoo       Validação       Re...
7.4 - Especificação de Configuração para módulos SAPTemplate modelo é utilizado para configurações SAP funcionais e técnic...
      EFT – é uma literal fixa      Descrição do desenvolvimento: Campo livre para identificar com clareza o nome dodese...
O primeiro sistema de computação era precário quando a informática começou a serdesenvolvida, prova disso é o fato do prim...
Para manter esta estrutura o Grupo criou e determinou alguns padrões, gerandogerenciamento centralizado, alta disponibilid...
8.2.1.1 – CategoriasCategoria 1 refere-se a locais menores (menos de 5 computadores) com exigência decriticidade baixa (sh...
       Presença de pelo menos um Switch camada 3       Presença de pelo menos um Switch camada 3 no núcleo       Uso do...
A explosão observada na utilização das redes de computadores e documentação só foi possívelgraças à acelerada expansão ver...
Próximos SlideShares
Carregando em…5
×

Pim 4

2.207 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
2.207
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
49
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Pim 4

  1. 1. UNIVERSIDADE PAULISTA - UNIPCURSO SUPERIOR DE TECNOLOGIAGESTÃO DE SISTEMAS DE INFORMAÇÃOJOSÉ LUIS FERNANDES PINEIRO R. A. 090051-7MARIO PEREIRA DE ALMEIDA R. A. 090175-2CRISTIANO ALVES DE MACEDO R. A. 090089-3SANDRO LORENÇO DO PRADO R.A. 090432-1PIM IVProjeto Integrado MultidisciplinarGrupo JLC SÃO PAULO2º Período – 2009/2JOSÉ LUIS FERNANDES PINEIRO R. A. 090051-7MARIO PEREIRA DE ALMEIDA R. A. 090175-2CRISTIANO ALVES DE MACEDO R. A. 090089-3SANDRO LORENÇO DO PRADO R.A. 090432-1Projeto Integrado Multidisciplinar IVGrupo JLCProjeto Integrado Multidisciplinar – PIM IV, apresentado como um dos pré-requisitos paraaprovação do 2º Semestre, no Curso Superior de Formação Tecnológica em Gestão.
  2. 2. Orientadores: Prof. Luiz AntonioProf.RicardoShitsuka Prof.AdraneColosseti SÃO PAULO2º Período – 2009/2RESUMOO 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 nosseus 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 emvirtude do seu crescimento no mercado. É sabido que a informatica sempre teve um customuito alto para as companhias, porem é impossível viver sem ela hoje em dia, a sem umadocumentação correta se torna ainda mais difícil. Neste contexto, a documentação de software tem grande importância, pois pode influenciartanto na qualidade quanto na produtividade do Grupo. A falta ou o excesso de documentaçãopode colocar em risco o desenvolvimento e a manutenção do software. Encontrar um pontode equilíbrio na quantidade de documentação gerada é de fundamental importância. Palavras Chaves: documentação, tecnologia, produtividade.ABSTRACTThe used Group in this work comes during years improving its methods, techniques and toolsin quality search, productivity, scalability, contingency in its internal processes and themanagement of all its LAN and WAN networks. Investments are being made and newtechnologies are being installed in virtue of its growth in the market. It is known that computerscience 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 softwaredocumentation has great importance, therefore it can influence in such a way in the qualityand in the productivity of the Group. The lack or the excess of documentations can be a risk for
  3. 3. the development and the maintenance for the software. Find a balance in the amount ofgenerated documentation is the main importance for the group.Keywords: documentation, technology, productivity.LISTA DE FIGURASFigura 1 – Processo de EngenhariaFigura 2 – EvoluçaoFigura 3 – Categoria 1Figura 4 – Categoria 2Figura 5 – Categoria 3Figura 6 – Categoria 4SUMÁRIOINTRODUÇÃO VII1 - Modelagem de Processos VIII2 – RDM X3 - Estudos de Viabilidade XI4 - Identificação XIII4.1 - Atividades envolvidas XIII4.2 - Dificuldades XIV4.3 - Técnicas para elicitação de requisitos XIV4.3.1 - Entrevistas e Questionários XIV4.3.2 - Workshops de requisitosXV4.3.3 – Cenários XVI
  4. 4. 4.3.4 – Prototipagem XVI4.3.5 - Estudo etnográfico XVII5 - Análise e negociação dos requisitos XVII5.1 - Atividades envolvidas XVII5.2 – Dificuldades XVIII5.2 - Negociações XIX6 - Validação XX6.1 - Técnicas de validação XXI6.1.1 - Revisões dos requisitos XXI6.1.2 – Prototipificação XXII6.1.3 - Geração de casos de teste XXII6.1.4 - Análise de consistência automática XXIII6.2 – Recomendações XXIII6.3 - Gestão de requisitos XXIII7 - Portal do Grupo XXVI7.1 - Gestão de Desenvolvimentos XXVI7.2 - Especificação e documentação dos requisitos(SRS) XXVI7.3 - Especificação Funcional e Técnica XXVII7.4 - Especificação de Configuração para módulos SAP XXVII7.5 - Descrição dos campos que compõe o nome dos arquivos: XXVII8 – Redes de Computadores e Telecomunicações XXIX8.1 - Evolução XXIX8.2 – Recursos computacionais do Grupo XXX8.2.1 – Normas Técnicas Gerais XXXI8.2.1.1 – Cabeamento XXXI8.2.1.1 – Arquitetura XXXII8.2.1.1 – Categorias XXXII
  5. 5. 9 – Conclusão XXXVIREFERENCIA BIBLIOGRAFICA XXXVIIINTRODUÇÃOHoje em dia a documentação tem uma importância muito grande para as empresas, sejam elasdesenvolvedoras de software ou empresas que se utiliza de sua área de tecnológica para fazeros seus próprios sistemas.Experiências e pesquisas mostram que existem duas razões básicas para documentar, umaserve para auxiliar a comunicação durante o projeto e outra para auxiliar o entendimento nasatividades de manutenção.A documentação é necessária quando é preciso estabelecer uma comunicação com umaequipe 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 ProcessosO controle sobre os processos envolvidos na gestão corporativa é um fator essencial para queuma empresa possa atender às normas e regulamentações do setor em que atua, alem deseguir procedimentos fundamentais para os objetivos e metas definidos em seu planejamentoestratégico.Uma modelagem de processos ideal abrange vários aspectos ao mesmo tempo independentese complementares, todos relevantes para que as empresas possam identificar necessidades,definir padrões, diagnosticar problemas e programar correções, colocando-se assim numcaminho seguro de evolução de sua gestão.Existe uma grande dificuldade das empresas que desenvolvem software cumprirem suasmetas de prazo e orçamento. Segundo o “StandishGroup”, somente 16,2% dos projetos desoftware 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 deSoftware. Neste contexto, a abordagem da documentação tem grande importância, onde oprazo de entrega do projeto pode variar de acordo com a quantidade e qualidade dosartefatos de software a serem entregues.
  6. 6. Segundo Scott W.Ambler *1+, duas razões são básicas para documentar “uma serve paraauxiliar a comunicação durante o projeto e outra para auxiliar o entendimento nas atividadesde manutenção. A documentação é necessária quando é preciso estabelecer umacomunicaçã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 eferramentas colaborativas. A documentação de software tem um efeito significante noentendimento do programa”.[1] Brasileiro, escreveu vários livros sobre o objeto de desenvolvimento de software, orador deconferencias em todo mundo sobre organizações internas.As empresas atualmente não podem perder muito tempo para encontra-se no padrão dequalidade ISO 9000, onde estes padrões querem dizer “planejar seus trabalhos e trabalharseus planos”, com a função extra de “documentar sempre seus planos e fazer sempre seusdocumentos”.Com a grande rotatividade de seus profissionais tanto internamente como para o mercado, asempresas se preocupam muito com as suas documentações internas, porem parece ser umsonho impossível. Ultimamente as empresas estão gastando bilhões de dólares, mas qual omotivo? Pode-se dizer que é a falta de uma “documentação” apropriada, ou a não existênciada mesma.Em entrevista com o responsável por documentações do Grupo “a documentação é essencial eapropriada para desenvolver e migrar sistemas, através dela conseguimos gerenciar osprojetos, educar, antecipar, executar planejamento de capacidade”.Atualmente o grupo tem utilizado algumas ferramentas para administração dos seusdocumentos como: RDM, PMBOOK, WorkFlow.2 – RDMA RDM “RequirementsDevelopment Management” (engenharia de requisitos) é um processoque engloba todas as atividades que contribuem para a produção de um documento derequisitos e sua manutenção ao longo do tempo.Figura 1 – Processo de EngenhariaEste processo deve ser precedido de estudos de viabilidade que, a partir das restrições doprojeto, determinam se este é ou não viável e se deve prosseguir para a identificação dosrequisitos. O processo de engenharia de requisitos é composto por quatro atividades de altonível: Identificação
  7. 7.  Análise e negociação Especificação e documentação ValidaçãoUma outra atividade que se pode considerar que faz também parte deste processo, se incluir afase posterior à produção do documento (isto é, a sua "manutenção"), é a gestão dosrequisitos, sendo que as alterações podem ser causadas pelos mais diversos fatores desdeinovações tecnológicas a mudanças na natureza do negócio (e consequentemente nosrequisitos), entre outras).3 - Estudos de ViabilidadeAntes de avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feitoum estudo de viabilidade.Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vistatecnológico e organizacional, o projeto é viável.Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com “as partesinteressadas do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintesquestõ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 serimplementado?• 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 daorganização não lhe traz qualquer valor acrescentado e como tal a sua existência não sejustifica. Apesar de parecer óbvio, são frequentemente desenvolvidos sistemas que nãocontribuem 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 equem possui esta informação, procedendo-se de seguida a recolha de todos os dadosdisponí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 actuaise do sistema a implementar, os responsáveis pelos departamentos nos quais o sistema será
  8. 8. usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema edos 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 aorganização?• Quais são os problemas que os sistemas atuais apresentam e como é que um sistemanovo irá resolver estas falhas?• De que forma é que o sistema irá contribuir diretamente para os objetivos daorganização?• É possível a integração com os outros sistemas da organização (de um ponto de vistatecnoló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á determinara 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 eVisão do Negócio) fica mais abrangente e claro (link em anexo).4 - IdentificaçãoCaso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.4.1 - Atividades envolvidasAlgumas das atividades envolvidas nesta fase incluem:• Compreensão do domínio: é muito importante para o analista compreender o domíniono qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca dodomínio, mais eficaz será a comunicação entre o analista e as partes interessadas.
  9. 9. • Identificação das partes interessadas: Estes já deverão ter sido identificados nosestudos de viabilidade, porém para efeitos de identificação de requisitos convém concentraras 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 suadefinição deve ser consensual) e devem ser propostas soluções em conjunto com as partesinteressadas.4.2 - DificuldadesEsta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estãoassociadas:• O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas nãoconseguir articulá-lo.• Os requisitos identificados podem não ser realistas (do ponto de vista econômico outecnoló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 requisitosExistem diversas técnicas de identificação de requisitos, e que são adequadas a diferentessituações, entre as quais podemos citar nos itens abaixo:4.3.1 - Entrevistas e QuestionáriosEntrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastanteeficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumasdú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.
  10. 10. • Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a serafectado pela introdução de um sistema na organização, este pode propositadamentedificultar 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 quea entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiadolonga, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos daentrevista abordados de forma superficial (ou podem nem chegar a ser abordados).4.3.2 - Workshops de requisitosO WORKSHOP de Requisitos consiste numa técnica usada para através de uma reuniãoestruturada, da qual devem fazer parte um grupo de analistas e um grupo representando ocliente, obter um conjunto de requisitos bem definidos.Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes noworkshop fomentando momentos de descontracção como forma de dinamizar o trabalho emequipe, existindo um facilitador neutro cujo papel é conduzir a workshop e promover adiscussã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 umprocesso de negociação, mediado pelo facilitador.Uma técnica que é também útil em workshops é o uso de brainstorming (tempestade deidéias) como forma de gerar um elevado número de ideias numa pequena quantidade detempo.Como resultado dos workshops deve ser produzida documentação que reflita os requisitos edecisõ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 usode cenários. Através de exemplos práticos descritivos do comportamento de um sistema, osseus utilizadores podem comentar acerca do seu comportamento e da interação que esperamter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo desistema. 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.
  11. 11. • Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de comoestes erros serão tratados.• Outras atividades que podem estar a ser executadas ao mesmo tempo que as destecenário.• Estado do sistema depois de o cenário terminar.4.3.4 – PrototipagemO uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (porexemplo 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 cedofalhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo deabordagem apenas são desenvolvidas algumas funcionalidades sendo normalmentedesenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador eque 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ótiposdeve ser considerado apenas mediante uma análise custo-benefício, já que os custos dedesenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis emsituações em que a interface com os utilizadores é, para eles, um aspecto crítico.4.3.5 - Estudo etnográficoOs Estudos Etnográficos são uma análise do componente social das tarefas desempenhadasnuma dada organização. Quando um dado conjunto de tarefas se torna rotineiro para umapessoa, é de esperar que esta sinta dificuldade em articular todos os passos que segue outodas as pessoas com as quais interage para levá-las a cabo. Através de uma observação diretadas atividades realizadas durante um período de trabalho de um funcionário é possívelencontrar requisitos que não seriam observáveis usando técnicas convencionais. Estaobservação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los emdemasia visto que o tempo necessário para processá-los pode ser demasiado. Nesta técnicaassume-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 requisitosApós a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dosmesmos.
  12. 12. 5.1 - Atividades envolvidasAlgumas das atividades envolvidas na análise de requisitos incluem:• Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global dofuncionamento pretendido para o sistema.• Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partesinteressadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitosnos requisitos identificados; é importante resolver estes conflitos o mais breve possível.• Prioritização: consiste na atribuição de uma "prioridade" a cada requisito (por exemploelevada/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 podeservir inclusive para as demais fases.A identificação e análise de requisitos é um processo iterativo que se inicia com afamiliarizaçã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 – DificuldadesAs dificuldades encontradas na análise são de diversas naturezas:• Factores externos (políticos) podem influenciar os requisitos (alguma parteinteressada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seusinteresses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demaisinteressados que irão operar o sistema).• O ambiente (económico e/ou organizacional) em que a análise é feita é possue fatoresdinâmicos, e como tal os requisitos estão sujeitos a alterações em decorrência destes (porexemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos eorçamentos disponíveis).5.2 - Negociações
  13. 13. Relativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra semproblemas, 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 suaresoluçã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 nanegociação.• Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todosos envolvidos.• Relatar restrições, quando se torna óbvio que as actuais não conseguem levar a umconsenso.6 - ValidaçãoNesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, defacto, ao sistema que o cliente pretende.À semelhança do que sucede na análise dos requisitos, pretende-se encontrarproblemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lidacom uma especificação completa dos requisitos.A validação é especialmente importante em sistemas de grandes dimensões uma vez que errosencontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar aser usado) no documento de requisitos têm repercussões proporcionais à dimensão doprojecto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior aalterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidadede 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) osseguintes atributos dos requisitos:• Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas. Comotal, requisitos identificados individualmente (isto é, junto de cada parteinteressada) podem diferir da especificação final que se atinge após ocruzamento de informação e é necessário que cada cliente compreenda e aceitea especificação final obtida.• Consistência: não devem existir conflitos entre os requisitos identificados.
  14. 14. • Compreensibilidade / Ambiguidade: os requisitos devem poder sercompreendidos de forma inequívoca pelas partes interessadas.• Completude: todas as funcionalidades pretendidas devem fazer parteda 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 demodo a que seja possível verificar se foram ou não concretizados, isto é, se osistema final corresponde à especificação inicial.• Rastreabilidade: a origem dos requisitos, em relação ao cliente, deveestar claramente identificada. Entre outros motivos, isto é importante parafacilitar 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çãoPara tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser empregues:6.1.1 - Revisões dos requisitosUma equipe de revisores pode analisar sistematicamente a especificação produzida de forma agarantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe derevisores pode simplesmente ter uma conversa, envolvendo o maior número possível derepresentantes 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 osrequisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dosutilizadores finais), rastreabilidade (a origem dos requisitos deve ser identificável) eadaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outrosrequisitos).6.1.2 – Prototipificação
  15. 15. A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para osutilizadores finais (e demais interessados), já que se trata do elemento do sistema final com oqual 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 seuuso, pode enviesar os utilizadores (levando a desilusões com a versão final do sistema, no casode esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair natentaçã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 pelosistema, eliminando por completo esta tentação).6.1.3 - Geração de casos de testeUma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) osrespectivos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimode que a implementação deste requisito será difícil e que este poderá ter de serreconsiderado.6.1.4 - Análise de consistência automáticaAtravés da especificação formal de modelos para o sistema é possível, recorrendo aferramentas adequadas (como as ferramentas CASE), testar de forma automática aconsistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que temde ser complementada com uma das outras técnicas referidas.6.2 – RecomendaçõesA fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muitoimportante na engenharia de requisitos e da qual dependem elevados custos a médio e longoprazo.Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos emvalidação de requisitos) é bastante falível e regra geral há erros que não são encontrados numprimeiro momento, o que leva inevitavelmente a discordâncias numa fase posterior, já com odocumento 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 errodetectado.
  16. 16. 6.3 - Gestão de requisitosOs requisitos de um sistema, em especial em sistemas minimamente grandes, estão emevolução constante.De um modo geral, isto pode suceder por o problema abordado não conseguir ficarcompletamente definido antes da produção do documento de requisitos (ou mesmo antes deo sistema ser implementado) ou, por outro lado, pode também acontecer por os própriosrequisitos se alterarem no decorrer do projecto (reflectindo evoluções tecnológicas oualteraçõ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 resultanum compromisso que procura equilibrar as necessidades dasdiferentes partes interessadas. Este equilíbrio pode ter de ser modificado e só com ouso 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" daorganização, isto é, aqueles que têm o poder de decisão e que podem impôrrequisitos perante os analistas (que podem não contribuir para os objectivos daorganização).• A orientação do negócio da organização pode-se alterar, nova legislação ouregulamentação pode pôr em causa alguns dos requisitos do sistema,alterações a nível tecnológico podem surgir na organização (afectandoparticularmente, 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 dealterações imprevisíveis pode surgir levando a que o sistema tenha de se adaptar atodo este tipo de requisitos.Existem requisitos que, tipicamente, são mais voláteis do que outros (como por exemplorequisitos que dependam da entidade política governante num dado momento), enquanto queoutros 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 deengenharia de requisitos (para os "novos" requisitos, isto é, os "antigos" que sofreramalterações). Como tal, o planejamento é uma parte importante da gestão de requisitos. Devemestar 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 arastreabilidade.
  17. 17. • 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 edesign; estas podem precisar de manter associada a cada requisito informaçãocomo a parte interessada que a propôs, dependências de outrosrequisitos e associação a módulos específicos do design do sistema.• Ferramentas a utilizar: para sistemas grandes, a quantidade de informação aprocessar 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 ummodo controlado), é importante que o processo de gestão de mudanças esteja definido de ummodo 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 dealteração a fazer aos requisitos do sistema.• Análise da alteração e seu impacto: através das políticas de rastreabilidadedefinidas 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 deimplementar a alteração directamente e só depois, retrospectivamente, actualizar osrequisitos pode levar a dessincronização entre requisitos e implementação.7 - Portal do GrupoTodas 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 DesenvolvimentosRDM-EEE-PPPPPPPP-Descrição do projetoo Estudo de Viabilidadeo Identificação Atividades Envolvidas Dificuldades
  18. 18. o Análise e negociação Atividades Envolvidas Dificuldades Elicitaçãoo Validação Revisões dos requisitos Prototipificação Geração de casos de testeo 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ção7.2 - Especificação e documentação dos requisitos(SRS)Esta área é utilizada para a guarda do documento de especificação de requisitos de umsistema. Em geral o documento é gerado em tempo de projeto. O arquivo de especificação derequisitos deve ter a seguinte nomenclatura:SRS-EEE-PPPPPPPP-Descrição do projeto7.3 - Especificação Funcional e TécnicaEsta área deve ser utilizada para guarda do documento de especificação de requisitos de umsistema. 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
  19. 19. 7.4 - Especificação de Configuração para módulos SAPTemplate 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  Corporativ SGBrasil oo VID  Vidroso ABR  ABRASIVOSo CAN  CANALIZAÇÃOo TEL  TELHANORTEo QUA  QUARTZOLIo BRA  BRASILITo MCE  MATERIAIS CERAMICOSo CPL  CERÂMICAS E PLASTICOSo ELD  ELDORADOo PLC  PLACOo DVO  VIDRO OCO PPPPPPP – meneumônico com o nome do Projeto ou Grupo confirme criado noMódulo  exemplo: Dados Mestres Descrição do projeto: Campo livre para identificar com clareza o nome do projeto (nãoutilizar a palavra “projeto” somente o nome dele. Exemplo: Nota Fiscal Eletrônica
  20. 20.  EFT – é uma literal fixa Descrição do desenvolvimento: Campo livre para identificar com clareza o nome dodesenvolvimento (não utilizar a palavra “projeto”ou a palavra “desenvolvimento” somente onome deste).Exemplos:o SRS:VID: NFELETR Noa Fiscal Eletrônica (Vidros) to EFT:VID:NFELETR:Geração e Impressão do Formulário DANFE de Vidros.8 – Redes de Computadores e TelecomunicaçõesUma rede de computadores consiste de 2 ou mais computadores e outros dispositivosconectados 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 queconecta muitas redes de computadores. Existem várias formas e recursos de váriosequipamentos 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çãoFigura 2 – EvoluçãoA informática é um dos maiores avanços já dado pelo homem, ela revolucionou todos ossetores da sociedade e ainda modificou as formas de realizar as atividades. A área começou aganhar projeção na década de 50 e o seu termo resulta da associação das palavras informaçãoe automática.
  21. 21. O primeiro sistema de computação era precário quando a informática começou a serdesenvolvida, prova disso é o fato do primeiro computador ter uma estrutura gigante e apenasefetuar as funções de uma calculadora. Com o tempo, os dispositivos se tornaram maiscompactos 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, devidoao sistema operacional Windows criado pela Microsoft. Os programas tinham um formatosimplificado e isso facilitava as ações do usuário. A rede mundial de computadores tambémcresceu assim a internet se tornou a melhor meio de comunicação e informação.8.2 – Recursos computacionais do GrupoA utilização dos recursos computacionais e das redes de comunicação é um fator primordial nocrescimento e desenvolvimento das empresas do Grupo.Sem dúvida, essas ferramentas de trabalho promovem o acesso mais rápido e eficiente a umnúmero maior de informações, e fornecem uma melhor comunicação com clientes efornecedores. Para a empresa e seus usuários, a segurança e a confiabilidade dos sistemas deinformação merecem interesse prioritário e contínuo. Assim, a proteção de dadosconfidenciais, 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 aempresa 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 doGrupo, assim como de nossa imagem corporativa, depende da conformidade com estas regrase do uso adequado das inúmeras tecnologias.Estas regras aplicam-se a todos os funcionários da empresa que, ao desenvolver tarefas sobsuas responsabilidades, precisam organizar instalar, modificar ou utilizar, sejam de formadireta ou indireta, os recursos computacionais e as redes de comunicação. A utilização dosrecursos computacionais e deres de comunicação é restrita a finalidades profissionais.Os recursos computacionais (desktops, laptops, palmtops, servidores, etc.); as redes decomunicaçã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 trabalhodisponibilizadas pela empresa para ajudar os usuários a realizar suas tarefas. Portanto, osrecursos computacionais e as redes de comunicação necessariamente possuem o uso restrito atarefas profissionais. O usuário é, em todo tempo, responsável pelo uso dos recursoscomputacionais e redes de comunicação da empresa, e precisa estar em conformidades comas normas da empresa.O Grupo tem presença em 57 países, com 207.000 funcionários e 1.200 empresasconsolidadas, mais de 5.300 sites interconectados.
  22. 22. Para manter esta estrutura o Grupo criou e determinou alguns padrões, gerandogerenciamento centralizado, alta disponibilidade, e documentações.8.2.1 – Normas Técnicas GeraisA implementação de normas de organização e arquiteturana rede LAN e WAN de todo o Grupopermite uma redução da complexidade técnica e custo destas redes, bem como um aumentono níveis de serviço e segurança para os negócios do Grupo.8.2.1.1 – CabeamentoEthernet é 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çãopor 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 meiosde variedades Ethernet aceito. Conectores BNC e cabos coaxiais não são compatíveis com asnormas IPT.Categoria 5e são cabos esperados como um padrão mínimo de cabeamento na LAN. O uso decategorias inferiores do cabo impede o fornecimento de equipamentos de rede de largura debanda total para as estações finais.8.2.1.1 – ArquiteturaAs especificações de roteadores na rede Wan são definidas pela equipe de Telecom junto coma operadora.Na rede Lan não são permitidos “hubs”, deve-se implementar equipamentos de camada 2, nointuito de evitar colisões e retransmissões desnecessárias bem como tornar a rede local capazde 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 serlogicamente separados utilizando VLAN (IEE 802.1q), onde o particionamento é necessário, oencaminhamento deve ser feito através de equipamentos de camada 3.
  23. 23. 8.2.1.1 – CategoriasCategoria 1 refere-se a locais menores (menos de 5 computadores) com exigência decriticidade baixa (showrooms, pequenos sites de vendas) Estações terminais devem estarfisicamente 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 utilizadocomo a única mídia media interface Ethernet See table below for an explanation of technical acronymsFigura 3 – Categoria 1Categoria 2 refere-se à maioria dos locais de distribuição (lojas e sites de vendas entre 5 e 20usuários) com exigência de criticidade padrão. Também pode se referir ao escritório e locais devendas.As normas específicas aplicáveis à categoria 2 os locais são: Passiva de fail-over Presença de pelo menos um Switch camada 3Figura 4 – Categoria 2Categoria 3 refere-se aos locais polivalentes de tamanho médio (de 20 a 250 usuários, sites dedistribuiçã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.) compartilhandoo 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
  24. 24.  Presença de pelo menos um Switch camada 3 Presença de pelo menos um Switch camada 3 no núcleo Uso do Protocolo SpanningTree(IEEE 802.1d STPFigura 5 – Categoria 3Categoria 4 refere-se ao maior site com exigência de alta criticidade. Esses sites têm mais de250 usuários, aplicativos de host central, podem hospedar equipamentos industriais. Sites decategoria 4 podem implementar conexões WAN dupla e geralmente são divididos por váriosedifí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 SpanningTree (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 acronymsFigura 6 – Categoria 49 – Conclusão
  25. 25. A explosão observada na utilização das redes de computadores e documentação só foi possívelgraças à acelerada expansão verificada nas últimas décadas nas Telecomunicações e naTecnologia da Informação. Necessidades criadas pelo processo de Globalização que se observanos últimos anos na economia, na política e no comportamento das Nações tem transformadoas redes em ferramentas indispensáveis no relacionamento do dia-a-dia das organizações edas pessoas. Em entrevista com as áreas de TI:“A documentação é mais importante do que aquilo sobre o que ela trata. O Grupo estatrabalhando arduamente na validação de todos os processos junto a IBM, pois nem sempre asequipes 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 comosolucionar 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 é interessantedocumentar, então não podemos perder tempo”.REFERENCIA BIBLIOGRAFICAAMBLER, Scott W. AgileDocumentation. 2001-2004, The OfficialAgileModeling (AM) Site, 2001,Disponível em : , Acesso em: 02 abr. 2001.GALLO, MICHAEL A., HANCOCK, W. M.: “Comunicação entre Computadores e Tecnologías deRede”, 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 Fundamentalhttp://pt.wikipedia.org/wiki/Ensino_fundamental

×