domingo, 30 de outubro de 2011

Sistema de Arquivos EXT3



O EXT3/4 é atualmente o sistema de arquivos mais utilizado no mundo Linux. Usado por padrão pela grande maioria das distribuições. 

Tudo começou com o sistema EXT (Extended File System), introduzido em 1992. Nos estágios primários de desenvolvimento, o Linux utilizava um sistema de arquivos bem mais antigo, o MinixFS (o Minix é um sistema Unix, que Linux Torvalds usou como base nos estágios primários do desenvolvimento do Linux). Entretanto, o MinixFS possuía pesadas limitações, mesmo para a época. Os endereços dos blocos de dados tinham apenas 16 bits, o que permitia criar partições de no máximo 64 MB. Além disso, o sistema não permitia nomes de arquivos com mais de 14 caracteres. 



Não é de se estranhar que, em pouco tempo o Linux ganhou seu sistema de arquivos próprio, o "Extended File System", ou simplesmente EXT, que ficou pronto em Abril de 92 a tempo de ser incluído no Kernel 0.96c.

Nesta primeira encarnação, o EXT permitia a criação de partições de até 2 GB e suportava nomes de arquivos com até 255 caracteres. Foi um grande avanço, mas o sistema ainda estava muito longe de ser perfeito. O desempenho era baixo e ele era tão sujeito a fragmentação de arquivos quanto o sistema FAT. Além disso, logo começaram a surgir HDs com mais de 2 GB, de forma que em 1993 surgiu a primeira grande atualização, na forma do EXT2.

O EXT2 trouxe suporte a partições de até 32 TB, manteve o suporte a nomes de arquivos com até 255 caracteres, além de diversos outros recursos. 

O maior problema do EXT2 é que ele não inclui nenhum sistema de tolerância a falhas. Sempre que o sistema é desligado incorretamente, é necessário utilizar o fsck, um utilitário similar ao scandisk do Windows, que verifica todos os blocos do sistema de arquivos, procurando por inconsistências entre as estruturas e descrições e os dados efetivamente armazenados. 

O teste do fsck demora bastante (bem mais que o scandisk) e o tempo cresce proporcionalmente de acordo com o tamanho da partição. Em um HD atual, o teste pode, literalmente, demorar horas.

Este problema foi corrigido com o EXT3, que foi introduzido em 1999. A principal característica do EXT3 é o uso do recurso de journaling, onde o sistema de arquivos mantém um journal (diário) das alterações realizadas, um recurso similar ao LFS usado no NTFS. 

Este "diário" armazena uma lista das alterações realizadas, permitindo que o sistema de arquivos seja reparado de forma muito rápida após o desligamento incorreto. O fsck continua sendo usado, mas agora ele joga de acordo com as novas regras, realizando o teste longo apenas quando realmente necessário.

O EXT3 possui três modos de operação:

No modo ordered (o default), o journal é atualizado no final de cada operação. Isto faz com que exista uma pequena perda de desempenho, já que a cabeça de leitura do HD precisa realizar duas operações de gravação, uma no arquivo que foi alterada e outra no journal (que também é um arquivo, embora especialmente formatado) ao invés de apenas uma.

No modo writeback o journal armazena apenas informações referentes à estrutura do sistema de arquivos (metadata) e não em relação aos arquivos propriamente ditos, e é gravado de forma mais ocasional, aproveitando os momentos de inatividade. Este modo é o mais rápido, mas em compensação oferece uma segurança muito menor contra perda e corrompimento de arquivos causados pelos desligamentos incorretos.

Finalmente, temos o modo journal, que é o mais seguro, porém mais lento. Nele, o journal armazena não apenas informações sobre as alterações, mas também uma cópia de segurança de todos os arquivos modificados, que ainda não foram gravados no disco. A cada alteração, o sistema grava uma cópia do arquivo (no journal), atualiza as informações referentes à estrutura do sistema de arquivos, grava o arquivo e atualiza novamente o journal, marcando a operação como concluída. Como disse, isso garante uma segurança muito grande contra perda de dados, mas em compensação reduz o desempenho drasticamente. Justamente por causa disso, este é o modo menos usado.

Para usar o modo writeback ou o modo journal, você deve adicionar a opção "data=writeback", ou "data=journal" nas opções referentes à partição, dentro do arquivo "/etc/fstab". 

Desta forma, ao invés de usar "/dev/hda5 /mnt/hda5 ext3 defaults 0 2", por exemplo, você usaria "/dev/hda5 /mnt/hda5 ext3 data=writeback 0 2"

O EXT3 (assim como o EXT2) utiliza endereços de 32 bits e blocos (análogos aos clusters usados no sistema FAT) de até 8 KB. Tanto o tamanho máximo da partição, quanto o tamanho máximo dos arquivos são determinados pelo tamanho dos blocos, que pode ser escolhido durante a formatação:

Tamanho dos blocos    Tamanho máximo da partição    Tamanho máximo dos arquivos

1 KB                                2 TB                                            16 GB

2 KB                                8 TB                                            256 GB

4 KB                                16 TB                                            2 TB

8 KB                                32 TB                                            2 TB


Uma observação é que, em versões antigas do Kernel, o limite para o tamanho máximo de arquivos no EXT2 já foi de 2 GB e em seguida de 16 GB, mas ambas as limitações caíram a partir do Kernel 2.6, chegando à tabela atual.

Por padrão, o tamanho do bloco é determinado automaticamente, de acordo com o tamanho da partição, mas é possível forçar o valor desejado usando o parâmetro "-b" do comando mkfs.ext3 (usado para formatar as partições EXT3 no Linux), como em "mkfs.ext3 -b 2048 /dev/hda1" (cria blocos de 2 KB) ou "mkfs.ext3 -b 4096 /dev/hda1" (para blocos de 4 KB).

Assim como no caso do NTFS, usar clusters maiores resulta em mais espaço desperdiçado (sobretudo ao guardar uma grande quantidade de arquivos pequenos) mas, além do aumento no tamanho máximo dos arquivos e partições, resulta em um pequeno ganho de desempenho, já que reduz o processamento e o número de atualizações na estrutura do sistema de arquivos ao alterar os dados gravados. 

Embora o limite de 32 TB para as partições EXT3 não seja um problema hoje em dia, ele tende a se tornar um obstáculo conforme os HDs crescerem em capacidade, assim como os limites anteriores. Para evitar isso, o EXT4, legítimo sucessor do EXT3, incorporou o uso de endereços de 48 bits, o que permite endereçar um volume virtualmente ilimitado de blocos. Só para referência, o EXT4 permite criar partições de até 1024 petabytes :). O limite de 2 TB para os arquivos também foi removido, abrindo espaço para o armazenamento de bases de dados gigantes e outros tipos de arquivos que eventualmente venham a superar esta marca.

Embora existam diversos outros sistemas de arquivos para o Linux, como o ReiserFS, XFS, JFS e assim por diante, o EXT3 continua sendo o sistema de arquivos mais utilizado, já que ele atende bem à maioria e é muito bem testado e por isso bastante estável. A tendência é que o EXT3 seja lentamente substituído pelo EXT4 e os demais sistemas continuem entrincheirados em seus respectivos n

CMMI

Capability Maturity Model (CMM)

Capability Maturity Model (CMM), também conhecido como Software CMM (SW-CMM) pode ser definido como sendo uma soma de "melhores práticas" para diagnóstico e avaliação de maturidade do desenvolvimento de softwares em uma organização. "CMM" não deve ser entendido como sendo uma metodologia, pois o "CMM" não diz exatamente como fazer, mas sim o que deve ser feito (melhores práticas).


Ele descreve os principais elementos de um processo de desenvolvimento de software. O CMM descreve os estágios de maturidade por que passam as organizações enquanto evoluem no seu ciclo de desenvolvimento de software, através de avaliação contínua, identificação de problemas e ações corretivas, dentro de uma estratégia de melhoria dos processos. Este caminho de melhoria é definido por cinco níveis de maturidade:Inicial;Repetível;Definido;Gerenciado;Otimizado
  
O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.
O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção. A versão atual do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 e apresenta três modelos:
CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e serviços.
CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização de bens e serviços.
CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de serviços.


O CMMI é um modelo de maturidade para o desenvolvimento e manutenção de software e dos serviços que abrangem o ciclo de vida do produto, desde sua concepção até a sua entrega e manutenção. Este modelo dá ênfase às disciplinas de engenharia de sistemas e também à engenharia de software e à integração necessária para construir e manter os produtos de forma abrangente. Este modelo oferece um conjunto de boas práticas agrupadas de acordo com áreas de atividades correlatas e níveis de maturidade. Estes níveis correspondem a etapas progressivas de eficácia gerencial e se apresentam como um caminho evolucionário para qualquer organização que pretenda melhorar seus processos de desenvolvimento e manutenção de software .Implantar um determinado nível do CMMI dentro de uma organização constitui, entretanto, um processo penoso e demorado. Além disso, a qualidade da implementação do CMMI afeta diretamente os benefícios obtidos.


Do ponto de vista organizacional, as empresas vêm buscando cada vez mais explicitar os princípios que as governam através das chamadas Regras de Negócio. As Regras de Negócio são uma forma de se expressar o conhecimento organizacional. Elas determinam como o negócio deve operar, mantendo a estrutura do negócio, controlando ou influenciando algum aspecto do negócio, sob o ponto de vista do desenvolvimento de software, as Regras de Negócio podem ser consideradas como requisitos de um projeto, pois deverão ser implementadas nas aplicações informatizadas que dão suporte às operações de um negócio. Assim, a abordagem ao desenvolvimento de software baseada em Regras de Negócio consiste, basicamente, em tratá-las como requisito prioritário.
Esta abordagem tem duas motivações principais. Em primeiro lugar, a explícita consideração das Regras de Negócio como requisito prioritário tende a assegurar o alinhamento entre os objetivos da organização e os seus sistemas Em segundo lugar, as Regras de Negócio são naturalmente mais familiares aos clientes e usuários do que os modelos usuais de captura de requisitos. Tal familiaridade tende a aumentar sua participação e responsabilidade na especificação dos requisitos e, ao mesmo tempo, tende a reduzir as falhas de tradução dos mesmos.
A adoção das práticas recomendadas pelo CMMI por uma organização implica na implantação, implícita ou explícita, de novas Regras de Negócio. .
Para apoiar esta abordagem baseada em Regras de Negócio foi desenvolvida uma ferramenta chamada. A ferramenta provê uma forma estruturada para capturar, armazenar e recuperar as informações sobre as Regras de Negócio, facilitando o trabalho de especificação e implementação destas regras.
O principal objetivo é contribuir para a disseminação do CMMI, facilitando sua adoção e certificação.
O CMMI consiste nas melhores práticas direcionadas ao desenvolvimento e à manutenção de produtos e dos serviços, abrangendo todo o ciclo de vida do produto, desde sua concepção até a sua entrega e manutenção Muitas organizações no mundo todo têm adotado este modelo com o objetivo de possibilitar a elevação da maturidade da capacidade de suas equipes nas atividades relacionadas ao software.
O modelo de maturidade CMMI descreve um caminho evolucionário, que começa com processos imaturos (inicial) e segue até um processo maduro e disciplinado (otimizado), onde é possível o controle do processo de produção de software por meio de métricas e modelos estatísticos. No nível 2 de maturidade de software (gerenciado), os projetos da organização garantem que os requisitos são gerenciados e que os processos são planejados, executados, medidos e controlados. A disciplina do processo refletida pelo nível de maturidade 2 ajuda a garantir que as práticas existentes sejam mantidas mesmo em situações de stress.

SIX Sigma

Uma das grandes dificuldades do desenvolvimento de software é adequar, de forma sistemática, os esforços na resolução de problemas e nas melhorias dos processos internos aos objetivos do negócio. O Seis Sigma é uma metodologia estruturada que incrementa a qualidade dos processos e o alinhamento com as estratégias empresariais, proporcionando altos ganhos financeiros para quem o utiliza. Surgido inicialmente na manufatura, o Seis Sigma vem sendo aplicado também noutros setores. No desenvolvimento de software, o seu uso é ainda restrito, mas há indícios de que possa ser utilizado com o mesmo sucesso. O objetivo desta dissertação de mestrado é propor um roteiro específico para a implementação do Seis Sigma nas organizações desenvolvedoras de software.






Além do levantamento teórico, foi realizado um estudo de casos múltiplos para analisar as razões da sua adoção, as modalidades de seu uso, os seus benefícios e as suas limitações para os processos de software. Os resultados observados mostram que o Seis Sigma pode ser aplicado total ou parcialmente na melhoria dos processos de software. Além disso, é necessário alguma customização nos processos do Seis Sigma convencional, uma vez que os projetos de melhoria podem estar orientados para novos produtos, novos clientes ou, ainda, que os trabalhos de desenvolvimento fiquem a cargo de novas equipes, que muitas vezes são terceirizadas.
O trabalho conclui que o Seis Sigma pode contribuir efetivamente para a melhoria dos processos de software, independentemente da organização objetivar níveis superiores de maturidade. O estudo sugere também um roteiro específico, chamado SW-DMAIC, para a aplicação do Seis Sigma em empresas desenvolvedoras de software. Este roteiro é composto por três etapas: implementação da filosofia do Seis Sigma, reciclagem desta filosofia, quando necessário e execução de projetos específicos.


1.  




Introdução a Qualidade de Software

 O conceito de qualidade foi introduzido por Deming e Juran. Joseph Juran nasceu em 1904, na Romênia. Emigrou para os Estados Unidos em 1912. Licenciado em Engenharia e Direito, começou a sua atividade como gestor de qualidade na Western Eletric Company. Professor de Engenharia na New York University Iniciou a carreira de consultor em 1950. Juran é considerado o outro pai da revolução da Qualidade do Japão com Deming. “Desempenho do produto que resulta em satisfação do cliente; livre de deficiências do produto, o qual evita a não  satisfação do cliente”. (Juran)

 Edward Deming

Deming é amplamente reconhecido pela melhoria dos processos produtivos nos Estados Unidos durante a segunda guerra (1939-1945)  l, sendo, porém mais conhecido pelo seu trabalho desenvolvido no Japão.   Lá, a partir de 1950, ele ensinou altos executivos como melhorar projeto, qualidade de produto, teste e vendas (este último por meio dos mercados globais) através de vários métodos, incluindo a aplicação de métodos estatísticos como análise estatística de hipótesesDeming fez contribuições significativas para o Japão tornar-se notório pela fabricação de produtos inovadores de alta qualidade. Deming é considerado o estrangeiro que gerou o maior impacto sobre a indústria e a economia japonesa no século XX.Texto


Deming foi instrutor de engenharia na universidade do estado do Wyoming  (1921-22), professor assistente de Física na Escola de Minas do Colorado (1922-24), e exerceu este mesmo cargo na    Universidade do Colorado (1924-25). Foi instrutor de Física na   em Yale entre 1925 e 1927.
Entre 1927 e 1939, Deming trabalhou como Físico Matemático no Laboratório de Pesquisas de Fixação de Nitrogênio do Departamento de Agricultura (USDA). Produziram 38 publicações sobre o assunto durante esse período, todas mostrando seu interesse pela metodologia estatística. Trabalhou como conselheiro estatístico no United States Census Bureau (1939–45). Foi professor de estatística na   Universidade de New York  1946 até 1993. Foi consultor em pesquisa e em indústria (1946-1993).
Durante seu trabalho no Departamento de Agricultura conheceu Walter A. Shewhart. Deming se inspirou muito no trabalho de Shewhart, considerado o pai do CEP (Controle Estatístico do Processo) As idéias dele tiveram grande influência na teoria da administração de Deming.
Durante a segunda guerra  Deming fez parte do Comitê Técnico Emergencial, composto por cinco pessoas (H.F. Dodge, A.G. Ashcroft, Leslie E. Simon, R.E. Wareham, e John Gaillard) e ensinou controle estatístico do processo para os trabalhadores da guerra. Os métodos estatísticos foram muito utilizados durante a guerra, mas caíram em desuso alguns anos após o termino da guerra.

Os quatorze pontos de gestão


Os 14 pontos para a gestão descrevem o caminho para a qualidade total, o qual deve ser continuamente aperfeiçoado. 
  1. Criar constância de propósito de aperfeiçoamento do produto e serviço, a fim de torná-los competitivos, perpetuá-los no mercado e gerar empregos.
  2. Adotar uma nova filosofia. Vivemos numa nova era econômica. A administração ocidental deve despertar para o desafio, conscientizar-se de suas responsabilidade e assumir a liderança em direção à transformação.
  3. Acabar com a dependência de inspeção para a obtenção da qualidade. Eliminar a necessidade de inspeção em massa, priorizando a internalização da qualidade do produto.
  4. Acabar com a prática de negócios compensador baseado apenas no preço. Em vez disso, minimizar o custo total. Insistir na idéia de um único fornecedor para cada item, desenvolvendo relacionamentos duradouros, calcados na qualidade e na confiança.
  5. Aperfeiçoar constante e continuamente todo o processo de planejamento, produção e serviços, com o objetivo de aumentar a qualidade e a produtividade e, conseqüentemente, reduzir os custos.
  6. Fornecer treinamento no local de trabalho.
  7. Adotar e estabelecer liderança. O objetivo da liderança é ajudar as pessoas a realizar um trabalho melhor. Assim como a liderança dos trabalhadores, a liderança empresarial necessita de uma completa reformulação.
  8. Eliminar o medo.
  9. Quebrar as barreiras entre departamentos. Os colaboradores dos setores de pesquisa, projetos, vendas, compras ou produção devem trabalhara em equipe, tornando-se capazes de antecipar problemas que possam surgir durante a produção ou durante a utilização dos produtos ou serviços.
  10. Eliminar slogans, exortações, e metas dirigidas aos empregados.
  11. Eliminar padrões artificiais (cotas numéricas) para o chão de fábrica, a administração por objetivos (APO) e a administração através de números e metas numéricas.
  12. Remover barreiras que despojem as pessoas de orgulho no trabalho. A atenção dos supervisores deve voltar-se para a qualidade e não para números. Remover as barreiras que usurpam dos colaboradores das áreas administrativas e de planejamento/engenharia o justo direito de orgulhar-se do produto de seu trabalho. Isso significa a abolição das avaliações de desempenho ou de mérito e da administração por objetivos ou por números.
  13. Estabelecer um programa rigoroso de educação e auto-aperfeiçoamento para todo o pessoal.
  14. Colocar todos da empresa para trabalhar de modo a realizar a transformação. A transformação é tarefa de todos.

Joseph juran

 Após  1945 (término da segunda guerra) , Juran decide deixar a empresa e iniciar sua carreira como consultor, além de dedicar-se ao estudo da gestão da qualidade. Atuou também como professor em New  York   onde lecionava cursos de controle de qualidade e promovia seminários para executivos. Também desenvolveu projetos de consultoria para Gilette  , Hamilton Watch Company e Borg-Warner. Sua obra mais clássica, Quality Control Handbook, publicada pela primeira vez em  1951  e ainda considerada como referência para todo gestor de qualidade, despertou o interesse dos japoneses que, no periodo que segue a segunda guerra preocupados com a reconstrução de sua economia, convidaram-no para ensiná-los os princípios de gestão de qualidade. Juntamente com Deming  , é considerado o pai da revolução da qualidade da ilha principal que forma o Japão  e um dos colaboradores na sua transformação em potência mundial. Em 974  , Juran funda o Juran Institute para facilitar a disseminação de suas idéias através de livros, vídeos e outros materiais. É considerada atualmente uma das mais importantes consultorias de gestão de qualidade do mundo. Mesmo após a morte de seu idealizador, em 2008,   o instituto continua a auxiliar empresas na otimização da qualidade, além de manter acessíveis as contribuições de Joseph Juran.Resultado de mais de 50 anos de estudos, este sistema, cujo desenvolvimento iniciou-se em meados da década de 50 na Toyota, continua a aperfeiçoar-se com o decorrer do tempo, sendo caracterizado como o primeiro a atribuir a qualidade à estratégia empresarial . Para Juran, existem duas formas de se definir qualidade. A primeira delas é utilizada para designar um produto que possui as características procuradas pelo consumidor e, portanto, é capaz de satisfazê-los.De acordo com esta perspectiva, a alta qualidade implica altos custos. No entanto, qualidade também pode caracterizar a existência mínima ou ausência de falhas e deficiências e, portanto, menores custos. Juran também classifica qualidade nas seguintes categorias:

Qualidade do Projeto
        I.            Pesquisa de mercadológica   
      II.            Concepção do produto
    III.            Especificações do projeto
Qualidade de conformidade:
        I.      Tecnologia
      II.            Potencial humano
    III.      Gerenciamento
Serviço de campo:
        I.            Pontualidade
      II.            Competência
    III.            Integridade

Genichi Taguchi

De 1982 em diante, Genichi Taguchi, foi assessor da Japanese Standards Institute e diretor executivo do American Supplier Institute, uma organização internacional de consultoria. Seu filho, Shin Taguchi, é apontado como o seu sucessor na liderança do instituto.Em 1990 recebeu do imperador japonês a Blue Ribbon Award pela sua contribuição para o desenvolvimento da indústria japonesa. Taguchi, que foi o criador do movimento Robust Design, ganhou quatro vezes o Prêmio Deming, do Japão. Ele recebeu o primeiro destes prêmios de excelência pela sua contribuição para o desenvolvimento da estatística aplicada à qualidade.


Durante a década de 1950, ele colaborou amplamente para estudos da qualidade e, em 1954-1955 foi professor no Indian Statistical Institute, onde trabalhou com R. A. Fisher e Walter A. Shewhart. Ao completar o seu doutorado na Universidade de Kyushu em 1962, ele deixou ECL. Em 1964 ele se tornou professor de engenharia na Universidade Aoyama Gakuin, em Tóquio. No ano de 1966 ele iniciou um trabalho com Yuin Wu, que mais tarde imigrou para os EUA e, em 1980 convidou Taguchi para palestrar. Durante a visita dele lá, Taguchi financiou seu retorno a Bell Labs    onde seu ensino inicial teve um pequeno e duradouro impacto. Nesta segunda visita começou uma colaboração com Madhav Phadke e um crescente entusiasmo com sua metodologia na Bell Labs e em outro lugar, incluindo a empresa FORD.



Ishikawa aprendeu os princípios do controle estatístico da qualidade desenvolvido por americanos. Kaoru traduziu, integrou e expandiu os conceitos de gerenciamento do Dr. Deming  e do Dr. Juran    para o sistema japonês. Talvez a contribuição a mais importante de Ishikawa foi seu papel chave no desenvolvimento de uma estratégia especificamente japonesa da qualidade. A característica japonesa é a ampla participação na qualidade, não somente de cima para baixo dentro da organização, mas igualmente começa e termina no ciclo de vida de produto. No final dos anos 50 e no início dos anos 60, Ishikawa desenvolveu cursos de controle da qualidade   para executivos e gerentes. Igualmente ajudou o lançamento da Conferência Anual do Controle da Qualidade para gerência, diretores em 1963.Em conjunto com a JUSE, em 1962, Ishikawa introduziu o conceito de Circulo de Qualidade. Em 1982, viria o Diagrama de Causa-e-Efeito, também conhecido como Diagrama de Ishikawa   a. A melhor contribuição do Diagrama de Ishikawa: forneceu uma ferramenta poderosa que facilmente pudesse ser usada por não-especialistas para analisar e resolver problemas
Com seu diagrama de causa e efeito, este líder da gerência fez avanços significativos na melhoria de qualidade. Os diagramas de Ishikawa são úteis como ferramentas sistemáticas para encontrar, classificar e documentar as causas da variação da qualidade na produção e organizar a relação mútua entre eles.


Fig 5- Ishikawa
Sua noção do controle empresarial da qualidade era voltada ao atendimento pós venda. Isto significa que um cliente continuaria a receber o serviço mesmo depois de receber o produto. Este serviço se estenderia através da companhia em todos os níveis hierárquicos e até mesmo no cotidiano das pessoas envolvidas. De acordo com Ishikawa, a melhoria de qualidade é um processo contínuo, e pode sempre pode ser aperfeiçoada.
Técnica criada por Ishikawa em 1943, é conhecida por vários nomes: diagrama causa-efeito, diagrama espinha de peixe, diagrama 4P, diagrama 6M.Ferramenta de grande utilidade, pois permite conhecer os problemas cada vez mais a fundo. Pode ser facilmente aprendida e imediatamente posta em prática por pessoas de qualquer nível dentro da empresa. É útil quando necessitasse identificar, explorar e ressaltar todas as causas possíveis de um problema ou situação específica.

Como tal, enfatiza uma comunicação aberta do grupo como crítica à construção dos diagramas Dr. W. Edwards Deming, um dos colegas de Isikawa, adotou este diagrama e usou-o para ensinar o controle de qualidade no Japão. Ishikawa e Deming usaram este diagrama como um as primeiras ferramentas no processo da gerência de qualidade.
Kaoru Ishikawa quis mudar a maneira das pessoas pensarem a respeito dos processos de qualidade. Para Ishikawa, “a qualidade é uma revolução da própria filosofia administrativa, exigindo uma mudança de mentalidade de todos os integrantes da organização, principalmente da alta cúpula”.

Qualidade Total é uma técnica de administração multidisciplinar formada por um conjunto de Programas, Ferramentas e Métodos, aplicados no controle do processo de produção das empresas, para obter bens e serviços pelo menor custo e melhor qualidade, objetivando atender as exigências e a satisfação dos clientes.
Os princípios da Qualidade Total estão fundamentados na Administração Científica de Frederick  Taylor   (1856-1915), no Controle Estatístico de Processos de Walter A. Shewhart    (1891-1967) e na Administração por Objetivos de Peter Drucker    (1909-2005).
Seus primeiros movimentos surgiram e foram consolidados no Japão após o fim da II Guerra Mundial com os Círculos de Controle da Qualidade, sendo difundida nos países ocidentais a partir da década de 1970.
Armand Vallin Feigbaum
Em 1951, concluiu o doutorado em ciências no MIT   . Em 1958 foi nomeado diretor mundial de produção da GE e vice-presidente da American Society for Quality Control (ASQC). Em 1961 foi eleito presidente da ASQC. Em 1968 escreveu seu primeiro livro, que se tornou um best-seller e lhe conferiu notoriedade mundial, “Controle Total de Qualidade”. Neste mesmo ano fundou a General Systems , da qual é presidente.
Feigenbaum é considerado o “pai” da qualidade e afirma que esta é um trabalho de todos na organização, e que não é possível fabricar produtos de alta qualidade se o departamento de manufatura trabalha isolado. Segundo ele diferentes departamentos devem intervir nas parcelas do processo que resultam no produto, esta colaboração varia desde o projeto do produto ao controle pós-venda, para que assim não ocorram erros que prejudiquem a cadeia produtiva, causando finalmente problemas ao consumidor.

 ITIL

Information Technology Infrastructure Library (ITIL) é um conjunto de melhores praticas  s a serem aplicadas na infraestrutura, operação e manutenção de serviços de  (TI). Foi desenvolvido no final dos anos 1980 pela CCTA (Central Computer and Telecommunications Agency) e atualmente está sob custódia da OGC   (Office for Government Commerce) da Inglaterra.
A ITIL busca promover a gestão com foco no cliente e na qualidade dos serviços de tecnologia da  informação  uma organização de TI apresentando um conjunto abrangente de processos e procedimentos gerenciais, organiza-dos em   disciplinas, com os quais uma organização pode fazer sua gestão tática e operacional em vista de alcançar o alinhamento estratégico com os negócios

Qualidade de Software




Métricas técnicas, nas quais se encaixam aspectos como funcionalidade, modularidade, manutenibilidade, etc.

Métricas da produtividade, baseadas na saída do processo de desenvolvimento do software com o objetivo de avaliar o próprio processo;
Métricas da qualidade, que permitem indicar o nível de resposta do software às exigências explícitas e implícitas do cliente;


Métricas Orientadas ao Tamanho: A medida de software mais familiar é a contagem de linhas de código. Esta métrica pode parecer simples, mas existe discordância sobre o que constitui uma linha de código. A medida de linhas de código não deveria contar linhas de comentário e linhas em branco, pois não afeta a sua funcionalidade.
Métricas Orientadas à Função: Em vez de contar as linhas de código, a métrica orientada à função concentra-se na funcionalidade do software. Em 1979, Allan Albrecht, introduziu uma técnica de Análise de pontos por função.



A FPA - Análise por Pontos por Função é uma destas técnicas. Ela dimensiona uma aplicação na perspectiva do usuário final, ao invés de levar em consideração as características técnicas da linguagem utilizada.
Uma aplicação, vista sob a óptica do usuário, é um conjunto de funções ou atividades do negócio que o beneficiam na realização de suas tarefas.
Uma função específica do usuário em uma aplicação é avaliada em termos do que é fornecido pela aplicação e não de como é fornecido.text


No início da década de 70, pesquisadores do Serviço de Processamento de Dados da IBM, a pedido do grupo de usuários (GUIDE), começaram a analisar centenas de programas para isolar as variáveis críticas, que determinam a produtividade da programação.


Descobriram que poderiam basear a avaliação de um sistema, medindo-se o valor das funções executadas pelos programas, em vez de utilizar como base o volume ou a complexidade do código dos programas. Em 1979 Allan J. Albrecht ( IBM White Plains ), prosseguindo essas pesquisas, introduziu uma técnica de avaliação conhecida como FPA - Function Point Analysis. A técnica está baseada na visão externa do usuário, sendo, portanto, independente da linguagem utilizada, permitindo calcular o esforço de programação e auxiliando o usuário final a melhorar o exame e avaliação de projetos.


Em 1986, foi formado o Grupo Internacional de Usuários de FPA ( IFPUG - International Function Point User Group ) destinado a divulgar informações e novas implementações da técnica a todos os seus associados.






Características da FPA-Function Point Analysis  

  • Esforço de desenvolvimento de software;
  • Custo de software;
  • Taxa de produção de software;
  • Taxa de manutenção de software.
  • Nível de produtividade da equipe;




Medidas Diretas

  1. Custo
  2. Esforço
  3. Linhas de Código
  4. Velocidade de Execução
  5. Memória
  6. Número de Erros
  7. Complexidade ciclomática
Medidas Indiretas

  1. Funcionalidade
  2. Qualidade
  3. Complexidade
  4. Eficiência
  5. Confiabilidade
  6. Manutenibilidade
Análise Ponto Por Função 


Mede o tamanho funcional do software, subsídios para o cálculo da produtividade do processo de desenvolvimento com base na funcionalidade ou utilidade dos programas. Esta avaliação é realizada sob o ponto de vista do usuário que avalia o tamanho e a complexidade de um software. Nesta contagem são considerados os seguintes itens da aplicação (software):
Arquivos Lógicos Internos, Arquivos de Interface Externa, Entradas Externas, Consultas Externas e Saídas Externas. Cada item deste define um peso que no final determina a quantidade de pontos de função da aplicação,

COCOMO:
Primeiras métricas baseadas em linhas de códigos para linguagem PL/I - IBM
O método COCOMO (ou COnstructive COst MOdel) é um modelo de estimativa do tempo de desenvolvimento de um produto. Criado por Barry Boehm. É baseado no estudo de sessenta e três projetos. Os programas examinaram de 2.000 a 100.000 linhas de código em linguagens de programação de Assembly a PL/I.

Análise de Risco: constitui em uma métrica bastante utilizada na realização de sistemas Os cinco pontos são:
• Identificação e Classificação dos Processos de Negócio
• Identificação e Classificação dos Ativos

        I.            Utilizam-se como métrica as melhores práticas de segurança da informação do mercado, apontadas na norma ISO/IEC 17799. A partir destas informações faz-se possível a elaboração do perfil de risco, que segue a fórmula: (Ameaça) x (Vulnerabilidade) x (Valor do Ativo) = RISCO. Atenção: a ISO/IEC 17799 não ensina a analisar o risco, serve apenas como referência normativa. O que mais incomoda aos consultores exigentes, é o crescente número de empresas “de segurança da informação” que dizem preparar a “análise de risco”, mas na verdade fazem, quando muito, uma “análise de vulnerabilidades”.”.

       I.          
  AnálResumo da FPA (Function Point Analysis) 

                                I.   Pontos de função é uma medida funcional de tamanho de software, introduzida em 1979 por Alan Albrecht da IBM , (falecido em 2010)

                             II.            Medida funcional de tamanho de software é um conceito definido pelo padrão ISO/IEC 14143-1:1998 e refere-se à medição do tamanho do software considerando-se apenas a funcionalidade solicitada e recebida pelos respectivos usuários. Nesse sentido, uma medida funcional de tamanho é uma medida externa, pois mede somente aquilo que é percebido pelos usuários do produto de software, independentemente da forma de implementação escolhida.

                           III.            A contagem dos pontos de função é regulamentada pelo International Function Point Users Group (IFPUG), organização internacional sem fins lucrativos sediada nos Estados Unidos da América. O IFPUG publica o Counting Practices Manual (Manual de Práticas de Contagem), atualmente em sua versão 4.2.1, que estabelece os padrões para o cálculo dos pontos de função. Para garantir a padronização dos procedimentos de contagem, o IFPUG oferece certificação na técnica e divulga os profissionais certificados através de seu site na Internet – www.ifpug.org.
                           IV.            O método do IFPUG foi oficializado através do padrão internacional ISO/IEC 20926 de 2002.

                             V.            A contagem dos pontos de função é realizada com base em cinco tipos de componentes de software: arquivos internos, arquivos externos, entradas, saídas e consultas. Esses termos possuem um sentido específico na FPA - Function Point Analysis (Análise de Pontos de Função) e a identificação e classificação dos componentes exige conhecimento especializado.

                           VI.            Os pontos de função são utilizados como fator normalizador do tamanho do software, permitindo o estabelecimento de métricas tais como produtividade (pontos de função produzidos por pessoa-mês), taxa de entrega (homens-hora para a produção de um ponto de função), densidade de defeitos (defeitos encontrados por ponto de função) e outras. A taxa de entrega também pode ser  denominada produtividade, o que pode causar confusão. A melhor opção é deixar clara a nomenclatura utilizada em cada caso.

                        VII.            Vem crescendo a utilização, pelas empresas brasileiras, dos pontos de função nos contratos de fornecimento de software, seja através da cotação de preços por ponto de função, ou através da quantificação dos serviços através de medições de pontos de função.No mundo, os pontos de função do IFPUG são utilizados pela grande maioria das organizações que realizam algum tipo de medição funcional de tamanho de software.

Métr




segunda-feira, 24 de outubro de 2011

Paradigmas de Análise de Sistemas


Paradigmas de Linguagens de Programação

Imperativo, Orientado a Objetos, Funcional e Lógico


Paradigma de programação, nada mais é do que seguir determinadas regras na busca do “norte” que o programador necessita seguir na montagem da estrutura e execução de um programa. Assim como existem várias metodologias de construções de sistemas, diferenciar paradigmas é falar em técnicas diferenciadas de programação, onde muitas vezes tais técnicas podem até dificultar uma correta construção de sistemas. Abaixo temos Nikalus Wirth (Pascal), Bertrand Meyers (Eiffel) e Matz (Ruby).

INDICE TIBOE


Niklaus Emil Wirth (Natural de Winterthur, 15 de Fevereiro de 1934) foi um professor de ciência da Computação suiço. Criador da línguagem de programação Pascal. Graduado em engenharia electrônica pela Swiss Federal Institute of Technology (ETH) em Zurique (1959), M.Sc. na universidade Laval, Canadá em 1960, e Ph.D. na Universidade da Califórnia, Berkeley (1963). Wirth foi um Professor/Assistente na ciência de computadores na Universidade de Stanford (1963 - 1967), e em seguida na Universidade de Zurique. Em 1968 tornou-se professor de informatica na ETH Zurique. Ele permaneceu dois anos na Xerox PARC, na Califórnia, e aposentou-se em abril de 1999.
Ruby é uma linguagem de programação interpretada multiparadigma, de tipagem dinâmica e forte, com gerenciamento de memória automático, originalmente planejada e desenvolvida no Japão em 1995, por Yukihiro "Matz" Matsumoto, para ser usada como linguagem de script. Matz queria uma linguagem de script que fosse mais poderosa do que Perl, e mais orientada a objetos do que Python. Ruby suporta programação funcional, orientada a objetos, imperativa e reflexiva.  


Bertrand Meyer é um dos grandes nomes das linguagens de programação e  especificamente das linguagens de programação por objetos. É o  mentor da linguagem de programação Eiffel que é percursora das  atuais linguagens por objetos como o Java e o C#.Bertrand Meyer é autor de uma extensa bibliografia,assim como de uma grande atividade acadêmica e um consultor reputado no campo das linguagens ;de programação.O seu livro sobre Programação Orientada aos Objetos é considerado dos que melhor expõe o paradigma e as suas implicações e vantagens.Bertrand Meyer foi o arquiteto inicial da linguagem e método denominado por Eiffel, tendo acompanhado a sua evolução e desempenho comercial,e foi o mentor do método de desenvolvimento designado por "Design by Contract".

Conceito de Linguagem de Programação
Uma linguagem de programação é um método padronizado para expressar instruções para um computador. É um conjunto de regras sintáticas e semânticas usadas para definir um programa de computador. Uma linguagem permite que um programador especifique precisamente sobre quais dados um computador vai atuar, como estes dados serão armazenados ou transmitidos e quais ações devem ser tomadas sob várias circunstâncias.

Programação Estruturada

Situando-se na programação estruturada, pode-se dizer que busca a criação de estruturas simplificadas usando para isso sub-rotinas e funções. É por sua vez a linha divisória entre a programação linear e a programação orientada a objetos, em se falando de criação de softwares. Na prática, pode-se dizer também que a programação estruturada transformou- se em uma programação modular, onde cada parte de tal programação busca resolver uma necessidade única.

Programação Orientada a Objetos

Já na programação orientada a objetos, a base do pensamento na hora da construção de um programa, é a busca de uma total interação entre diversas unidades de software, chamados objetos. A busca; na hora de fazer a análise e o projeto de orientação a objetos, tem como consequência a procura do melhor conjunto de objetos para formar tal sistema. Com isto, o resultado é a necessidade da troca de mensagens entre tais objetos. O que gera o correto e eficaz funcionamento do sistema. Nesta programação, as classes contidas em certo sistema/ programa, definem os objetos presentes e trabalhados. Cada classe também determina o comportamento que é definido pelos métodos e seus estados possíveis, chamados de atributos. Talvez o exemplo mais fácil de ser citado é a linguagem java, tão utilizada, mas com poucos profissionais dominando esta tecnologia. Linguagem Eiffel Eiffel é uma linguagem de programação puramente orientada a objeto, que implementa as teorias sobre a orientação a objeto de Bertrand Meyer.Sendo Bertrand Meyer um teórico francês da orientação a objeto, o nome da linguagem obviamente é uma alusão à famosa Torre Eiffel, um dos símbolos de Paris e, portanto, da França.Dr. Bertrand Meyer, fundador da Eiffel Software, concebeu o compilador Eiffel 1. Ele foi apresentado ao público na primeira The International Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA) em outubro de 1986, onde ele atraiu considerável atenção, levando o Dr. Meyer a divulgá-lo como um produto comercial, no final de 1986. A última iteração envolvendo a tecnologia original do Eiffel foi a versão 2.3, lançada em meados de 1990. A próxima versão, Eiffel 3, foi escrito inteiramente em Eiffel. Eiffel 3 apresenta o Melting Ice Technology para recompilação rápida, um ambiente gráfico com interface totalmente inovadora para o usuário, com base em conceitos e avanços consideráveis em bibliotecas (gráficos, rede ...) e otimização do código gerado. As primeiras versões foram lançadas em Unix e seguido pelo Linux, VMS, OS / 2, Windows (Windows 3.1, Windows 95, Windows NT),. NET, e Mac OS X. Hoje, a tecnologia Eiffel continua a empurrar as fronteiras do desenvolvimento de software. Com a introdução do EiffelStudio ™, os programadores podem tirar partido de uma IDE eficiente para alcançar a mais alta qualidade, robustez, escalabilidade de aplicações reutilizáveis - em todas as principais plataformas. Com EiffelEnvision ™, os programadores podem ainda usar o poder da linguagem Eiffel dentro do popular ambiente do Microsoft Visual Studio. NET
A orientação a objetos é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos. Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de programação. De fato, o paradigma "orientação a objeto", tem bases conceituais e origem no campo de estudo da cognição, que influenciou a área de inteligência artificial e da linguística, no campo da abstração de conceitos do mundo real. Na qualidade de método de modelagem, é tida como a melhor estratégia para se eliminar o "gap semântico", dificuldade recorrente no processo de modelar o mundo real do domínio do problema em um conjunto de componentes de software que seja o mais fiel na sua representação deste domínio.

Linguagens de Script

Shell é um poderoso interpretador de comandos que é utilizado nos sistemas UNIX. Ele oferece uma gama muito grande de comandos e possibilidades tornando-o uma linguagem muito flexível. Normalmente é utilizado para automatizar diferentes tipos de tarefas.
Shell script é uma linguagem de script usada em vários sistemas operacionais (operacionais), com diferentes dialetos, dependendo do interpretador de comandos utilizado. Um exemplo de interpretador de comandos é o bash, usado na grande maioria das distribuições GNU/Linux.
Perl
Practical Extraction and Report Languag (PERL). Uma das grandes vantagens desta linguagem é a possibilidade de trabalhar com grandes volumes de dados como imagens em alta definição e terabytes de dados. Possui uma grande versatilidade no processamento de strings, utiliza expressões regulares e ainda permite um tempo de desenvolvimento relativamente curto.
Javascript
JavaScript é uma linguagem de script (embora alguns digam que é uma linguagem de programação, W3Schools afirma que que se trata de uma linguagem de script, podendo ser considerada uma "leve linguagem de programação").
James Gosling 
ActionScript
ActionScript é uma linguagem de programação orientada a objetos baseada em ECMAScript, utilizada principalmente para construção de aplicações RIA (do inglês RIA: Rich Internet Applications (Aplicações Ricas de Internet)). É executada em uma máquina virtual (AVM - "ActionScript Virtual Machine"), atualmente na versão 3 que está disponível no Adobe Flash Player (plug-in encontrado em navegadores web) e também no ambiente Adobe AIR.

AJAX

AJAX (acrônimo em língua inglesa de Asynchronous Javascript and XML, em português "Javascript e XML Assíncronos") é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornar páginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. Foi inicialmente desenvolvida pelo estudioso Jessé James Garret e mais tarde por diversas associações.

Python

Python oferece uma sintaxe simples mas ao mesmo tempo suporta a maior parte das características importantes de linguagens de mais alto nível como Java e C++. Oferece orientação a objetos, mecanismo de tratamento de erros e possibilidade e executar o mesmo programa, sem alterações em plataformas de hardware e sistema operacionais diferentes.

PHP

Perl que ele usava no desenvolvimento de sua página pessoal. Em 1997 foi lançado o novo pacote da linguagem com o nome de PHP/FI, trazendo a ferramenta Forms Interpreter, um interpretador de comandos SQL.A linguagem surgiu por volta de 1994, como uns pacotes de programas CGI criados por Rasmus Lerdorf, com o nome Personal Home Page Tools, para substituir um conjunto de scripts.
    Ramus Ledorf

ASP.NET

ASP.NET é a plataforma da Microsoft para o desenvolvimento de aplicações Web e é o sucessor da tecnologia ASP. É um componente do IIS que permite através de uma linguagem de programação integrada na. NET Framework criar páginas dinâmicas. Não é nem uma linguagem de programação como VBScript, PHP, nem um servidor web como IIS ou Apache.
O ASP.NET é baseado no Framework .NET herdando todas as suas características, por isso, como qualquer aplicação .NET, as aplicações para essa plataforma podem ser escritas em várias linguagens, como C# e Visual Basic .NET. Embora se possa desenvolver aplicações ASP.NET utilizando somente o notepad e o compilador .NET, o ambiente de desenvolvimento mais comum das aplicações ASP.NET é oVisual Studio .NET já que possui algumas características que facilitam o trabalho do programador, como os componentes visuais para criação de formulários de páginas Web. Uma aplicação para web desenvolvida em ASP.NET pode reutilizar código de qualquer outro projeto escrito para a plataforma .NET, mesmo que em linguagem diferente.

Microsoft Redmon
Uma página ASP.NET escrita em VB.NET pode chamar componentes escritos em C# ou Web Services escritos em C++, por exemplo. Ao contrário da tecnologia ASP, as aplicações ASP.NET são compiladas antes da execução, trazendo sensível ganho de desempenho.

Paradigmas de IMPERATIVO

Paradigma imperativo, também conhecido como paradigma procedimental, representa o enfoque tradicional para o processo de programação. De fato, é no paradigma imperativo que se baseia o nosso pseudocódigo, bem como a linguagem de máquina. Como o nome sugere, o paradigma imperativo define o processo de programação como o desenvolvimento de uma sequencia de instruções que, quando executada, manipula dados para obter o resultado desejado. Assim, o paradigma imperativo diz-nos que a abordagem ao processo de programação é encontrar um algoritmo para resolver o problema e então expressá-lo como uma sequencia de instruções.





 
Em contraste com o paradigma imperativo, que requer do programador um algoritmo para resolver o problema, está o paradigma declarativo, que requer a descrição do problema. A estratégia aqui consiste em descobrir e implementar um algoritmo geral para solucionar problemas. Feito isso, será possível resolver problemas simplesmente apresentando-os problemas em forma de algoritmo.
O principal obstáculo ao desenvolvimento de um ambiente de programação baseado no paradigma declarativo é descobrir um algoritmo subjacente de resolução de problemas. Por isso, as principais linguagens declarativas eram por natureza de propósito especifico.
Emprego do  Paradigma Imperativo
No início de 1990, Naughton, Gosling e Sheridan começaram a definir as bases para o projeto de uma nova linguagem de programação, apropriadas para eletrodomésticos, sem os problemas já tão conhecidos de linguagens tradicionais como C e C++. O consumidor era o centro do projeto, e o objetivo era construir um ambiente de pequeno porte e integrar esse ambiente em uma nova geração de máquinas para "pessoas comuns". A especificação da linguagem terminou em agosto de 1991, e a ela deu-se o nome de "Oak" "Carvalho". Por problemas de copyrigth (já existia uma linguagem chamada Oak) o nome foi mudado em 1995 para Java, em homenagem à ilha de Java, de onde vinha o café consumido pela equipe da Sun.
Em 1992, Oak foi utilizada pela primeira vez em um projeto chamado Projeto Green, que tinha por propósito desenvolver uma nova interface de usuário para controlar os aparelhos de uma casa.
Niklaus Wirth recebeu o grau de Engenheiro Eletrônico do Instituto Federal Suíço de Tecnologia (ETH) em Zurique, em 1959. Posteriormente, ele estudou na Universidade Laval, em Quebec, no Canadá, e na Universidade da Califórnia em Berkeley, onde recebeu o Ph.D. grau em 1963. Até 1967, ele foi professor assistente no recém-criado Departamento de Ciência da Computação da Universidade de Stanford. Atualmente o Pascal tem continuidade através do Delphi.
Stroustrup, nas suas próprias palavras, "inventou a C++, escreveu as suas definições iniciais e produziu a sua primeira implementação, (…) escolheu e formulou os critérios de projecção da linguagem C++, desenhou todas as suas facilidades principais e foi responsável pelo processo de propostas de extensão no comité de padrões de C++." Stroustrup também escreveu o que muitos consideram a obra padrão de introdução à linguagem, "A linguagem de programação C++", que se encontra na terceira edição. A obra possui revista para reflectir a evolução da linguagem e o trabalho do comité de padrões de C++.
Ele desempenhou o cargo de diretor do Departamento de Investigação de Programação em Grande Escala dos Laboratórios Bell da AT&T, desde a sua criação até aos finais de 2002
Gosling é apontado como sendo o inventor da linguagem de programação Java (lançada em Maio de 1995). Ele fez o projeto original do Java e implementou o seu primeiro compilador e sua máquina virtual.
James Gosling (Calgary, 19 de Maio de 1955) é um programador canadense, mais conhecido como o pai da linguagem de programação Java . Em 1977, James Gosling se formou Bacharel em Ciência da Computação pela Universidade de Calgary , e em1983 tornou-se PhD em Ciência da Computação pela Universidade Carnegie Mellon.