UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia
PIM VII
Brasília 2013
UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia
PIM VII
Marcelo Neves de Sá RA 1127767 Gestão da Tecnologia da Informação 3º semestre
Brasília 2013
RESUMO
O presente artigo reporta-se a uma pesquisa de análise de impacto, planejamento, desenvolvimento e implantação de melhorias nos processos de TI da empresa Software Developer, correlacionando às matérias propostas pelo projeto, utilizando como ferramenta de apoio a Governança de TI, Gestão da Qualidade e Sistemas para Internet e Software Livre. Onde objetivo geral é desenvolver um novo comparativo de sucesso aonde a tecnologia da informação vem aprimorando a forma das empresas operarem e obter lucro. Quanto à metodologia, trata-se de uma pesquisa quantitativa e qualitativa, viabilizada por meio de análise de conteúdo. No referencial teórico foram abordados os seguintes temas: Governança de TI, Gestão da Qualidade e Sistemas para Internet e Software Livre. Palavras-Chave: Governança de TI, Gestão de Qualidade e Sistemas para Internet e Software Livre. ABSTRACT
This article refers to a survey of impact analysis, planning, development and implementation of improvements in IT processes of Software Developer, correlating to the matters proposed by the project, using as a tool to support IT Governance, Quality Management and Internet Systems and Free Software. Where overall goal is to develop a new comparative success where information technology is improving the way businesses operate and make a profit. Regarding the methodology, it is a quantitative research and quality, made possible through content analysis. In the theoretical framework were discussed the following topics: IT Governance, Quality Management Systems and Internet and Free Software. Keywords: IT Governance, and Quality Management Systems for Internet and Free Software.
Sumário 1.
INTRODUÇÃO ............................................................................................................... 5
1.1.
Objetivo geral................................................................................................................... 5
1.2.
Objetivos específicos ....................................................................................................... 5
1.3.
Metodologia ..................................................................................................................... 6
2.
Governança de TI ............................................................................................................. 6
2.1.
Governança Tecnológica.................................................................................................. 6
2.2.
A Diferença entre CMM E CMMI ................................................................................... 7
2.3.
CMMI .............................................................................................................................. 7
2.3.1.
Níveis do CMMI .............................................................................................................. 9
2.3.1.1.
Nível 1 (Inicial) ................................................................................................................ 9
2.3.1.2.
Nível 2 (Repetitivo) ......................................................................................................... 9
2.3.1.3.
Nível 3 (Definido) ............................................................................................................ 9
2.3.1.4.
Nível 4 (Gerenciado)...................................................................................................... 10
2.3.1.5.
Nível 5 (Otimizado) ....................................................................................................... 10
2.3.2.
Processo de implantação do modelo CMMI .................................................................. 11
2.3.2.1.
Início .............................................................................................................................. 11
2.3.2.2.
Análise de riscos ............................................................................................................ 11
2.3.2.3.
Cronograma.................................................................................................................... 12
2.3.2.4.
Treinamento e preparação .............................................................................................. 12
3.
Gestão da qualidade ....................................................................................................... 13
3.1.
O processo GQM ........................................................................................................... 13
3.2.
Implantando um processo de Melhoria Contínua .......................................................... 15
4.
Sistemas para Internet e Softwares Livres ..................................................................... 15
4.1.
Sistema de Informação Distribuído................................................................................ 15
4.2.
Servidores de arquivos distribuídos ............................................................................... 16
4.3.
Linux e Software Livre .................................................................................................. 17
5.
Resultados obtidos ......................................................................................................... 19
6.
Conclusão....................................................................................................................... 19
7.
Referências..................................................................................................................... 19
5
1. INTRODUÇÃO
Dentre os valores que as organizações dispõem, a informação possibilita identificar tanto as oportunidades quanto as ameaças que o ambiente oferece. É importante que os gestores conheçam profundamente a organização que está sob sua responsabilidade, assim como o mercado e o ambiente competitivo no qual ela está situada, com inúmeros objetivos, dentre os quais o de desenvolver o cenário para uma solução eficaz e competitiva (SILVA JR. apud GONÇALVES, 2002). Com toda evolução que está ocorrendo no mercado surge a necessidade de as empresas buscarem meios que as auxiliem a, conhecer e entender os desejos e/ou necessidades de seus clientes, para tornarem-se cada vez mais competitivas. A empresa tendo essa visão, conseqüentemente, obterá bons resultados. Este trabalho apresenta uma consultoria chamada Consulting localizada em Brasília DF, onde a mesma foi contratada pela empresa desenvolvedora de software chamada Software Developer, localizada também em Brasília-DF, tendo um embasamento teórico de vários autores que serão citados no decorrer do estudo.
1.1. Objetivo geral
O objetivo geral deste projeto é demonstrar um estudo de análise de impacto, planejamento, desenvolvimento e a viabilidade da implantação de um processo contínuo de avaliação dos processos de TI na empresa Software Developer, que atenda não só as expectativas em relação a uma melhora da qualidade dos produtos, mas também a um incremento na produtividade das equipes de trabalho.
1.2. Objetivos específicos
Desenvolver e aplicar os conhecimentos adquiridos em aula sobre Governança de TI, Gestão da Qualidade e Sistemas para Internet e Software Livre; Evidenciar os pontos culminantes de sucesso ou fracasso, decorrentes do bom ou mau uso da Tecnologia da Informação como fonte para aquisição de vantagem competitiva.
6
1.3. Metodologia
Esta pesquisa utiliza uma abordagem qualitativa tendo como embasamento a pesquisa bibliográfica.
2. Governança de TI
2.1. Governança Tecnológica
Governança é um temo analítico que envolve conceitos como colaboração, parceria, compartilhamento, aprendizagem em grupo, regulação, e melhores práticas de “governo”. Segundo Parreiras (2005): Criar estruturas de governança é o mesmo que definir uma dinâmica de papéis e interações entre membros da organização, de tal maneira a desenvolver participação e engajamento dos membros no processo decisório estratégico, valorizando estruturas descentralizadas. Entretanto, em TI, este conceito tem servido de cobertura para uma lista de acrônimos. Entre eles, se destacam ITIL, Cobit e CMM. Parreiras (2005, p.2). De fato o termo governança pode ser empregado em qualquer área da organização, contudo, na área de TI mostra-se extremamente útil dada a sua dinamicidade e, muitas vezes, distanciamento técnico entre profissionais da área e demais usuários. Neste sentido, as práticas de governança tendem a romper estas barreiras e aproximar o usuário para o centro das decisões de TI. A Governança de TI como parte integrante da Governança Corporativa evidencia a divisão da responsabilidade com relação à determinação do que é crítico e garante que as decisões de TI são tomadas e impulsionadas pelo negócio, e não o contrário (mesmo que a TI seja uma direcionadora de processos de negócio, as decisões a respeito de seguir ou não a direção são tomadas no âmbito da Governança Corporativa). A lei Sarbanes Oxley inicialmente se aplica às empresas de capital aberto que possuem operações financeiras com a Bolsa de Valores Americana, porém torna-se uma ferramenta importante de controle administrativo direcionadora das atitudes dos gestores podendo ser adotada em qualquer tipo de organização. Para o atendimento as exigências impostas pela lei Sarbanes Oxley - SOX, a administração das organizações, precisa conhecer profundamente as seções da lei, para planejar e implantar a melhor estrutura de controles internos, e dessa forma é importante dar ciência sobre os textos legais das seções ressaltadas nesse trabalho. Seção 404 da SOX - Essa seção reforça a obrigação, como também determinada na seção 302, de uma avaliação anual das práticas de controles e procedimentos internos das
7
organizações, exigindo a inclusão de um relatório que ateste a eficácia da estrutura de controles quando da divulgação das informações anuais das empresas. Desde a sua formação, a Software Developer tem sua história marcada por ser uma empresa de desenvolvimento de software para bancos com os principais produtos em Sistema de Consórcio, Financiamento e Empréstimos. Recentemente, a empresa concluiu um processo de análise de seus ativos e processos de TI para azeitar esse processo. A empresa Software Developer avaliou e mapeou o grau de maturidade de cada um de seus processos e agora acredita estar preparada para realizar a integração da área de TI. Uma das áreas mais importantes nesse processo de análise foi a de gerenciamento de projetos vital quando o desenvolvimento de um sistema tem valor forte para a estratégia de negócios da empresa.
2.2. A Diferença entre CMM E CMMI
O CMM (Capability Maturity Model ) é uma iniciativa do Software Engineering Institute (SEI), desenvolvido na Carnegie Mellon University e serve para avaliar a capacidade que uma organização possui para desenvolver software com qualidade, custo e prazo pequeno e previsibilidade confiável. A partir de 1991, o SEI emitiu vários documentos baseados no CMM voltados para setores específicos da indústria de engenharia de software como, Gestão de Recursos Humanos (P-CMM), Engenharia de Sistemas (SE-CMM) e Aquisição de Software (SA-CMM). Embora todos os modelos derivados do CMM tenham eficiência comprovada na prática, usar vários modelos em uma empresa é complicado, em 2002 o SEI iniciou um novo projeto em 2002, chamado CMMI (Capability Maturity Model Integration). Com o objetivo de gerar uma nova versão do CMM, como um modelo mais evoluído em relação ao modelo anterior, combinando várias disciplinas em uma única estrutura que fosse flexível e que pudesse ser utilizada de forma integrada por empresas que precisassem de processos de melhoria em âmbito corporativo. Uma das áreas mais importantes nesse processo de análise foi a de gerenciamento de projetos vital quando o desenvolvimento de um sistema tem valor forte para a estratégia de negócios da empresa.
2.3. CMMI
Para que uma empresa seja considerada mais madura e aumente seu nível de maturidade, ela deve cumprir metas específicas, chamadas áreas de processo ( Key Process Área – KPA). O modelo CMMI é um processo que consiste de atividades reconhecidas como a implantação
8
das práticas do modelo. À medida que a empresa vai se tornando madura, o processo fica mais definido. Quando uma empresa não possui CMMI, o processo é caracterizado de baixa qualidade por geralmente possuir as seguintes características:
Processos improvisados durante o projeto; Falta de rigor no cumprimento dos processos estabelecidos; Falta de controle; Grande dependência dos profissionais envolvidos no processo; Inexistência ou poucas atividades de revisão e teste; Estar focada no em soluções de problemas imediatos.
Por isso, uma empresa que não possui CMMI, tende a ter pouca produtividade e qualidade, um alto custo com manutenção, falta de comprometimento no quesito de prazos e custos, gerando cronogramas e orçamentos fora do combinado e um grande risco de ter que adotar novas tecnologias. Quando uma empresa é madura, ou seja, esta envolvida nas práticas de CMMI, o processo é considerado de alta qualidade, por possuir as seguintes características:
Processo de acordo com as linhas de ação da empresa; O processo é conhecido por todos os envolvidos; Existe apoio da alta administração; Auditoria dos processos que garante os bons resultados; Adoção disciplinada de tecnologia.
Com isso, uma empresa que possui CMMI, tende a ter suas responsabilidades e documentos claramente definidos, além de acompanhar a qualidade do produto e a satisfação do seu cliente, atendendo as expectativas de custos, cronogramas, funcionalidades e qualidade, atingindo o objetivo inicial. O CMMI está dividido em duas formas de representação diferentes, estagiada e contínua. A estagiada divide as áreas de processo em cinco níveis de maturidade à maneira do CMM enquanto a representação contínua define níveis de capacidade. As diferenças entre ambos são meramente organizacionais e o conteúdo é equivalente. Ambos podem ser usados para conseguir níveis em suas respectivas caracterizações.
9
2.3.1. Níveis do CMMI
2.3.1.1. Nível 1 (Inicial)
O primeiro nível é marcado pela desorganização do processo de desenvolvimento e pessoa, ou seja, podemos considerar um processo caótico, onde poucos processos são definidos e o sucesso depende dos esforços individuais. Normalmente, quando uma empresa esta no nível 1 de maturidade, ela não da garantia de prazo, funcionalidade e nem de custo.
2.3.1.2. Nível 2 (Repetitivo)
No segundo nível os processos básicos de gerenciamento de projeto estão estabelecidos e permite acompanhar custos, funcionalidades e cronograma. Podemos dizer que o processo já é disciplinado, onde é possível repetir o sucesso de um processo já utilizado antes em outros projetos parecidos. Nesse nível a empresa já consegue produzir bons softwares, dentro do prazo e a um custo previsível.
2.3.1.3. Nível 3 (Definido)
No terceiro nível as atividades de gerenciamento e engenharia de processo de desenvolvimento de software estão documentadas, padronizadas e integradas em um padrão de desenvolvimento da empresa. Podemos dizer que o processo é padronizado e consistente, onde todos os projetos utilizam uma versão aprovada e adaptada de um processo padrão de desenvolvimento da empresa. Nesse nível a empresa garante um excelente nível de qualidade no produto e no processo de desenvolvimento no geral.
10
2.3.1.4. Nível 4 (Gerenciado)
No quarto nível são reunidas medidas detalhadas da qualidade do produto e do processo de desenvolvimento. Podemos dizer que o processo é previsível, onde o produto e o processo de desenvolvimento são entendidos e controlados. Dificilmente uma empresa consegue chegar a esse nível. Hoje em dia são poucas empresas no mundo que conseguiram chegar aos níveis de maturidade 4 e 5 do CMMI.
2.3.1.5. Nível 5 (Otimizado)
No quinto nível o melhoramento é a continuação do processo, onde é conseguido através de “feedback” quantitativo dos mesmos e pelo uso de ideais e tecnologias inovadoras.
Os cinco níveis da maturidade. A decisão de implantar o CMMI e contratar a Consulting ajudou a empresa a planejar suas ações de TI. Quem irá decidir é a empresa, baseada em suas reais necessidades. Outra razão forte para se render ao modelo CMMI é a necessidade de atender às exigências da lei Sarbanes Oxley.
11
2.3.2. Processo de implantação do modelo CMMI
2.3.2.1. Início
O primeiro passo rumo ao CMMI nível 3, foi à escolha da equipe, definição do cronograma e do orçamento inicial. Outro importante critério para a escolha da equipe era que, de alguma forma, eles já tivessem participado da implantação dos processos de Fábrica de Códigos e de Software. A definição do orçamento inicial destinado a esta fase foi definido pela alta gerência. A consultoria da COPPE/UFRJ foi solicitada para ajudar na validação das planilhas construídas ao longo da fase, que são o mapeamento do processo padrão, e a validação das planilhas de 5 projetos concluídos. O Projeto Rumo ao CMMI engloba as seguintes fases: 1) Adaptação do processo definido inicialmente; 2) Treinamento nas áreas de processo específicas do nível 3; 3) Criação de novas ferramentas para apoiar as áreas de processo do nível 3 do CMMI no ambiente cujo objetivo é apoiar a utilização do processo; 4) Consultoria da ISD Brasil auxílio nas adaptações e utilização das ferramentas de apoio.
2.3.2.2. Análise de riscos
Através de um trabalho de análise de risco, foram identificados como potenciais:
Atraso na adequação da ferramenta de RH para permitir a seleção dos profissionais de projeto levando-se em conta seus skills e habilidades; As atividades executadas atualmente nos processos são desempenhadas por papéis que na prática não tem conhecimento ou envolvimento suficiente, tornando estas atividades ineficazes. O Coordenador desempenha um papel de analista e gerencia o projeto. O PCP gerencia o projeto, mas não tem autonomia. O gerente de projeto atua como um gerente de negócio e não se envolve com as questões operacionais do projeto; Não utilização de um processo comum para 3 áreas, sendo que para área de Outsourcing há 2 grupos distintos; Institucionalização dos processos em tempo superior ao estimado; Não adequação de ferramentas internas em tempo hábil (dependência interna); Concorrência do programa de melhoria com os demais projetos da organização (patrocínio e priorização); Indisponibilidade de profissionais de outras áreas;
12
Não manter a institucionalização dos processos com base no SW-CMM nível 2 nas áreas Fábrica e Cartões; Resistência dos analistas na adoção de processos de engenharia de software; Mudança de recursos humanos (áreas escopo) durante a execução do plano; Mudança da equipe de Consultores; Mudança no quadro de consultores da empresa (EPG); O número de horas contratadas e estimadas para a fase de definição de processos pode não ser suficiente para cobrir as atividades de definição para o escopo fábrica de programas;
2.3.2.3. Cronograma
Como forma de disseminar esta preparação como um projeto, foram definidas atividades e sua duração, responsáveis, custos e resultados esperados. As seguintes atividades foram previstas para este projeto:
Treinamento e preparação; Mapeamento processo padrão e indicadores CMMI nível 3; Preparação e avaliação no CMMI nível 3.
As atividades de “Treinamento e Preparação” e “Mapeamento do processo padrão e indicadores CMMI nível 3” foram concluídas, bem como a atividade “Preparação e Avaliação do CMMI nível 3”, tendo sido realizado o preenchimento da planilha para os projetos que serão avaliados (5 projetos concluídos). A equipe alocada para o projeto foi composta de um Gerente do Projeto, cujo papel foi desempenhado pelo Diretor Técnico da Organização, comprovando o comprometimento da alta gerência; dois integrantes da equipe de processos em tempo integral e um integrante da equipe de processos em tempo parcial. Para a atividade de preparação para a avaliação do CMMI nível 3, foram envolvidos mais dois recursos com perfil de Qualidade de Processo e Produto.
2.3.2.4. Treinamento e preparação
O principal objetivo desta primeira atividade era a obtenção de treinamento formal em CMMI e SCAMPI. Era necessário não só o treinamento e o entendimento das práticas, mas algo mais prático e profundo. Três pessoas responsáveis pelos processos da empresa fizeram como ouvintes, durante 3 meses o curso de Aprofundamento em CMMI na ISD Brasil. Neste curso, foram discutidas as práticas e os a indicadores diretos e indiretos apropriados para cada área de processo, bem como a apresentação de ferramentas (futuras e atuais) do ambiente, que
13
auxiliariam na implantação. Durante estes meses, consolidaram o entendimento do CMMI e, de maneira informal, já apontavam e discutiam quais seriam os indicadores diretos e indiretos do processo padrão da empresa para o CMMI nível 3.
3. Gestão da qualidade
A busca da excelência empresarial não pode está ligada somente a determinadas áreas ou processos de atuação da empresa, mas sim a um modelo sistêmico de gestão abrangente, inovador e em contínua evolução. Há vários anos, as empresas buscam continuamente a excelência nos conceitos da gestão da qualidade. Nesta evolução o foco da Gestão da Qualidade foi se tornando cada vez mais abrangente passando de uma gestão focada no produto de software. Este capítulo visa os modelos de qualidade da empresa no desenvolvimento de softwares mais aplicados, produtores de software que de algum modo se preocupam em implementar e manter procedimentos de avaliação e medição, visando uma melhora na qualidade e produtividade dos projetos e sistemas desenvolvidos pela empresa. Identificando assim os reais problemas existentes na Software Developer em relação aos seus clientes. A futura norma ISO/IEC 15504 define processos e práticas que podem ser implementados para estabelecer e aprimorar a capacidade de aquisição, desenvolvimento, manutenção, operação e suporte de software na organização. Estas práticas são organizadas utilizando-se uma arquitetura que combina duas perspectivas: uma perspectiva funcional (análoga à perspectiva da norma ISO/IEC 12207), compreendendo quais os processos que devem existir numa organização e outra perspectiva que avalia o nível de capacitação de cada um desses processos. O uso da norma permite que a empresa possa perceber a existência ou não de processos específicos, bem como a capacitação dos que existem traçando caminhos para a melhoria.
3.1. O processo GQM
O modelo GQM é desenvolvido a partir de um conjunto de objetivos acerca de qualidade e/ou produtividade definida pela empresa para o projeto, tais como satisfação do cliente, entrega do serviço no prazo e melhoria de desempenho. A partir da identificação dos objetivos e com base em moldes do objeto em avaliação, derivam-se questões que possam definir esses objetivos de forma mais completa. Por exemplo, se o objetivo é caracterizar um software quanto a determinadas qualidades, então se faz necessária a escolha de um modelo para o produto que qualifique esses interesses.
14
O próximo passo consiste em especificar as medidas que devem ser correlatas a fim de responder as questões e acompanhar a conformidade dos produtos e processos aos objetivos. Por fim, a que se desenvolverem os meios de coleta de dados, incluindo-se mecanismos de avaliação e análise. O processo de identificação de objetivos é crítico para o sucesso da aplicação da abordagem GQM, e será apoiado por passos metodológicos específicos. Para a consecução de um objetivo concorrerão três fontes básicas de informação; A primeira fonte diz respeito à política e a estratégia da empresa que aplica a abordagem GQM. A partir desta fonte, como a análise da política da corporação, dos planos estratégicos e, ainda, levando-se em conta os interesses relevantes na empresa, derivam-se o aspecto e o propósito para o objetivo a ser perseguido. A segunda fonte de informações é a descrição dos processos e produtos da organização, ou, pelo menos, daqueles que estão dentro do escopo do programa de medidas que se pretende efetuar. A partir desta fonte, com a especificação dos modelos de processos e produtos, dentro da maior formalidade possível, deriva-se a coordenada do objeto para o objeto em questão. A terceira fonte de informações é o modelo do negócio da empresa, que fornece a coordenada “ponto de vista”. É evidente que nem todos os assuntos e processos são relevantes para todos os pontos de vista na organização. Assim, há que se fazer uma análise de relevância dos objetos para a organização, antes de se considerar concluída a lista de objetos. Dessa forma, conclui-se a definição dos objetos para o modelo GQM, tornando-se conta a estrutura e os objetivos da empresa. A partir da especificação de cada objetivo, podem-se derivar questões significantes que quantificam o objetivo. G1. Como se pode caracterizar o objeto (produto, processo ou recurso) com o respeito ao objetivo global do determinado modelo GQM. Q1: Qual o prazo corrente no atendimento as solicitações de mudanças num sistema em manutenção? Q2: Existe um processo (documentado) no atendimento às solicitações de mudanças? G2. Como podem ser avaliados os incidentes nos ambientes de trabalho. Q1: O desempenho tem sido satisfatório sob o ponto de vista da empresa? Q2: Há melhoria visível no desempenho? Com a aplicação do GQM apresenta-se em que se pretenda melhorar o prazo no atendimento às solicitações de mudança para um determinado sistema em fase de manutenção. O objetivo definido explica o propósito (melhorar), o processo (atendimento de solicitações de mudança), o ponto de vista (gerente do projeto) e o aspecto observado (prazo de execução). Esse objetivo deve ser refinado em uma série de questões, que serão respondidas a partir da comparação do tempo de coleta.
15
3.2. Implantando um processo de Melhoria Contínua
Modelar os processos existentes na empresa Software Developer pode servir para vários propósitos e agregar diversos benefícios. No contexto de melhoria de processos, modelos de processos descritivos são úteis para se entender a maneira como as coisas funcionam e para comunicar este entendimento. Os modelos de processos que foram desenvolvidos serão usados em passos subseqüentes do processo de melhoria. Um bom sinal é quando os desenvolvedores perduram parte dos moldes em seus ambientes de trabalho, significa que estão sendo úteis para o dia a dia dos seus trabalhos mudando assim o paradigma do mau atendimento em relação á alguns funcionários da empresa Software Developer. Na empresa Software Developer, os prováveis processos informatizados, foram modelados e descritos de forma a explanar claramente as atividades intrínsecas de cada um, a dependência entre estas atividades, o tempo de duração de cada uma delas.
4. Sistemas para Internet e Softwares Livres
4.1. Sistema de Informação Distribuído
Para o entendimento do conceito de sistemas de arquivos distribuídos e suas aplicações em sistemas de informação distribuídos, precisamos ter algumas definições fundamentais. A primeira definição é de serviço, que é um conjunto de facilidades oferecidas aos nós de uma rede por um software que opera em uma ou mais máquinas. Um servidor por suas vez é o software que opera em uma máquina e que trata de oferecer o serviço. Outra definição é a de cliente, que nesse caso utiliza o serviço do servidor em uma ou várias máquinas. Por último, um sistema de arquivos é uma parte de um sistema operacional que trata de oferecer um repositório de dados de longa duração. Com esse contexto podemos definir um Sistema de Arquivos Distribuído, que é um sistema onde vários servidores são responsáveis por oferecer o serviço de arquivos para vários clientes instalados em diferentes máquinas. Uma curiosidade sobre sistemas de arquivos é que existem sistemas operacionais que utilizam o mesmo interfaceamento dos sistemas de arquivos para outras funcionalidades além do armazenamento de dados. Um exemplo disso é o UNIX que possui certos arquivos especiais que, na verdade, funcionam como uma interface para dispositivos de entrada e saída. São arquivos “virtuais” para a manipulação fácil destes dispositivos. Já faz muito tempo que a estrutura de árvore de diretórios é utilizada para organizar o acesso dos usuários aos arquivos em disco. Hoje em dia é a estrutura mais difundida embora
16
existam outras possibilidades em estudo. O uso de árvores de diretórios se popularizou com os sistemas UNIX e DOS. Por exemplo, no UNIX cada arquivo é identificado pelo seu nome e pelo caminho até ele. O caminho é uma seqüência de diretórios separados pelo caractere “/” (barra) que indicam a localização lógica do arquivo. Agrupando os arquivos em diretórios e subdiretório facilita-se a sua manipulação por parte dos usuários. Acrescentando-se o nome do arquivo ao path obtêm o pathname. Dada a localização lógica de um arquivo, isto é, o caminho até ele, é necessário analisar os componentes deste caminho a fim de encontrar a localização física do arquivo. É preciso descobrir em quais blocos de quais discos de quais servidores se encontra o arquivo em questão. Quando os arquivos de um sistema estão distribuídos entre vários servidores localizados em diferentes máquinas, é desejável que a localização destes arquivos seja transparente aos usuários do sistema. Em outras palavras, quando o usuário desejar ter acesso a um determinado arquivo, ele não deve ter que se preocupar com a localização física do arquivo. Assim, não precisaria saber em qual disco de qual servidor ele esta guardado. Da mesma forma, quando um cliente deseja guardar informações em um arquivo em disco, ele deve apenas fornecer o caminho e o nome do arquivo no qual elas devem ser gravadas. Algumas características são desejáveis em um sistema de arquivos distribuídos:
Disponibilidade; Escalabilidade; Heterogeneidade; Segurança; Tolerância a Falhas; Operações atômicas; Acesso concorrente.
4.2. Servidores de arquivos distribuídos
Abaixo temos sucintamente características dos principais sistemas de arquivos distribuídos.
NFS: O Network File System, desenvolvido pela SUN Micro systems, é o sistema de arquivos distribuídos mais utilizado em ambiente UNIX. Isto ocorre graças à iniciativa da SUN de lançar publicamente a especificação do protocolo NFS que permitiu que qualquer fabricante fosse capaz de lançar os seus próprios clientes e servidores NFS. Atualmente, existem implementações do NFS para praticamente todas as plataformas relevantes e todas elas podem compartilhar o sistema de arquivos entre si. No entanto, o NFS apresenta uma série de problemas dentre os quais se destacam a sua velocidade relativamente baixa e a falta de consistência entre os cachês dos clientes. ANDREW: Desenvolvido na Universidade Carnegie-Mellon, o Andrew File System foi o primeiro sistema de arquivos a oferecer um serviço de alta
17
escalabilidade possibilitando que dezenas de milhares de clientes compartilhassem os arquivos oferecidos por centenas de servidores. Este era o objetivo principal do projeto e foi alcançado através da adoção da semântica de sessão e da utilização de grandes cachês em discos locais dos clientes. A fim de limitar a possível falta de segurança em um sistema tão grande, o ANDREW adota uma série de mecanismos como, por exemplo, o Kerberos Authentication Server que permite a autenticação mútua de servidores e clientes. CODA: Desenvolvido a partir do ANDREW, o CODA oferece uma alta disponibilidade através da adoção de uma técnica otimista de replicação. A grande peculiaridade deste sistema são as ferramentas que permitem o acesso ao sistema de arquivos a partir de computadores portáteis. Existe até a possibilidade de operação desconectada durante a qual clientes podem acessar o sistema de arquivos sem estabelecer contato com os servidores.
4.3. Linux e Software Livre
É, ao mesmo tempo, um kernel (núcleo) e o sistema operacional que roda sobre ele, dependendo do contexto em que você encontrar a referência. O kernel Linux foi criado em 1991 por Linus Torvalds, então um estudante finlandês, e hoje é mantido por uma comunidade mundial de desenvolvedores (que inclui programadores individuais e empresas como a IBM, a HP e a Hitachi), coordenada pelo mesmo Linus, agora um desenvolvedor reconhecido mundialmente e mais representativo integrante da Linux Foundation. O Linux adota a GPL, uma licença de software livre o que significa, entre outras coisas, que todos os interessados podem usá-lo e redistribuí-lo, nos termos da licença. Aliado a diversos outros softwares livres, como o KDE, o GNOME, o Apache, o Firefox, os softwares do sistema GNU e o OpenOffice.org, o Linux pode formar um ambiente moderno, seguro e estável para desktops, servidores e sistemas embarcados. Como o Linux é um software livre, a maior parte dos produtores disponibiliza imagens ISO contendo exatamente o mesmo conteúdo dos CDs vendidos em lojas ou na Internet, e você pode fazer o que quiser com elas até mesmo gravar em CDs para revendê-las (e se você quiser comprar CDs deste tipo, lojas virtuais brasileiras como a Tempo Real e a LinuxMall estão à disposição). Quando se trata de Linux, este tipo de cópia e revenda não é irregular nem antiético, pois é da essência do software livre. Os clientes da empresa Software Developer estão desenvolvendo o sistema Linux o sistema por ser um software livre os usuários tem a liberdade de usá-lo, ou seja, se o mesmo tiver acesso ou de posse do programa. O sistema garante ser seguro e estável não havendo nenhum risco frente aos concorrentes.
18
[pic] Acima você vê 4 telas do sistema operacional Linux em ambiente PC desktop.Um sistema operacional Linux completo (ou uma “distribuição de Linux”) é uma coleção de softwares (livres ou não) criados por indivíduos, grupos e organizações ao redor do mundo, tendo o Linux como seu núcleo. Software Livre se refere à existência simultânea de quatro tipos de liberdade para os usuários do software, definidas pela Free Software Foundation. Veja abaixo uma explicação sobre as 4 liberdades, baseada no texto em português da Definição de Software Livre publicada pela FSF. As 4 liberdades básicas associadas ao software livre são:
A liberdade de executar o programa, para qualquer propósito (liberdade nº 0); A liberdade de estudar como o programa funciona, e adaptá-lo para as suas necessidades (liberdade nº 1). Acesso ao código-fonte é um pré-requisito para esta liberdade; A liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo (liberdade nº 2); A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo que toda a comunidade se beneficie (liberdade nº 3). Acesso ao códigofonte é um pré-requisito para esta liberdade;
Um programa é software livre se os usuários têm todas essas liberdades. Portanto, você deve ser livre para redistribuir cópias, seja com ou sem modificações, seja de graça ou cobrando uma taxa pela distribuição, para qualquer um em qualquer lugar. Ser livre para fazer essas coisas significa (entre outras coisas) que você não tem que pedir ou pagar pela permissão, uma vez que esteja de posse do programa. A liberdade de utilizar um programa significa a liberdade para qualquer tipo de pessoa física ou jurídica utilizar o software em qualquer tipo de sistema computacional, para qualquer tipo de trabalho ou atividade, sem que seja necessário comunicar ao desenvolvedor ou a qualquer outra entidade em especial. A liberdade de redistribuir cópias deve incluir formas binárias ou executáveis do programa, assim como o código-fonte, tanto para as versões originais quanto para as modificadas. De modo que a liberdade de fazer modificações, e de publicar versões aperfeiçoadas, tenha algum significado, deve-se ter acesso ao código-fonte do programa. Portanto, acesso ao código-fonte é uma condição necessária ao software livre.
19
5. Resultados obtidos
De todo trabalho realizado e esforço dedicado até o presente momento, o resultado mais significativo foi à obtenção do Cobit. Porém, cabe ressaltar outros importantes tópicos:
Obtenção da capacitação, do pessoal interno da empresa Software Developer; Integração entre as áreas da organização nas atividades conjuntas para o atendimento de um objetivo comum; A adoção de um processo de melhoria de software integrado e adaptado pelo modelo de gestão da qualidade total.
6. Conclusão
Este projeto apresentou a experiência, estruturação e aplicação da Gestão da Qualidade de Software em uma organização já certificada e com uma estrutura de Gestão da Qualidade baseada em conceitos de Qualidade Total – TQM. Dúvidas como a aplicação ou não de um modelo de Gestão de Software já possuindo outra estrutura de gestão, os benefícios de se adotar um modelo de gestão de software como o linguajar das pessoas envolvidas no desenvolvimento e a possibilidade de adaptação de práticas já existentes para o atendimento de requisitos de modelo de software ficam esclarecidos. Este trabalho apresenta uma experiência e os conhecimentos focam o modelo Cobit adotado com a ISO/IEC 15504, desenvolvido pela empresa Software Developer.
7. Referências
ANDRADE, A.; ROSSETTI, J.P; Governança Corporativa: Fundamentos, Desenvolvimento e Tendências, 2. ed., São Paulo: Atlas, 2006. BLOEM, J. DOORN, M.V.; MITTAL, P.; Making It Governance Work in a Sarbanes-Oxley World, New York/USA: ed. John Wiley & Sons, Inc., 2005. Consultoria Delloite Touche Tohmatsu. Lei Sarbanes Oxley: Pu blicação do ”Guia para melhorar a governança corporativa através de eficazes controles internos”. FERNANDES, A.; ABREU, V.; Implantando a Governança de TI: da Estratégia dos Processos e Serviços, Rio de Janeiro: Brasport, 2006. PARREIRA. F. S.; BAX, M. P. Geração de Sistemas de Gestão de Conteúdos com softwares livres. IN: Conferencia Latino-Americana de Informática, Dez de 2005, Cali, Colômbia.
20
REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Rio de Janeiro: Brasport, 1999. ROCHA, A. C. Qualidade de Software – Teoria e pratica. Prentice Hall. São Paulo: 2001. SALVIANO, C. F. Contribuições da Melhoria de Processos de Gerência de Projetos: Transformando Boas Idéias em Resultados – Textos acadêmicos, p. 01-04.
