O teste parte fundamental no ciclo de vida de um software. Abaixo esto listados 7 princpios fundamentais que envolvem o processo deteste e devem servir como um guia geral, tanto para testadores quanto para desenvolvedores. Afinal, ambos participam efetivamente doprocesso de amadurecimento do sistema.1 Prncipio: Testes apontam a presena de falhas Testes conseguem identificar a existncia de falhas, mas no pode garantir a ausncia delas. Mesmo se nenhum erro for identificado em uma bateria de testes, no possvel afirmar que o software est livre de falhas.2 Princpio: Teste exaustivo impossvel A menos que a aplicao sendo testada tenha uma estrutura lgica muito simples e valores de entrada limitados, teste exaustivo invivel pois seria extremamente custoso cobrir todos os cenrios possveis. Deve-se calcular o esforo dos testesbaseando-se nos riscos e prioridades.3 Princpio: Teste antecipado Ao desenvolver um software, asatividades de testedevem comear o quanto antes. Assim que os requisitos ou modelagem do sistema estiverem prontos, possvel comear o trabalho de modelagem do plano de testes. O quanto antes uma falha for identificada no ciclo de vida de um sistema, mais barata e mais simples ser a correo.4 Princpio: Agrupamento de falhas A maioria das falhas encontradas durante a execuo dos testes est concentrada em um nmero pequeno de mdulos. Sempre existe uma rea do software que responsvel pelo maior nmero de erros.5 Princpio: Paradoxo do pesticida Um conjunto de testes, se executado vrias vezes, pode no mais detectar novas falhas. Para contornar esse problema, os casos de teste devem ser frequentemente revisados e atualizados. Elesdevem ser reformulados para abordar novas reas do sistema e assim aumentar a chance de detectar novas falhas.6 Princpio: Teste depende de contexto Os testes devem ser elaborados de acordo com o tipo do software. Por exemplo, um sistema bancrio deve ser testado de maneira diferente de uma rede social. H questes de segurana que devem ser mais precisamente abordadas no primeiro caso. Da mesma forma que testes web so elaborados com foco diferente dos testes de aplicaes desktop.7 Princpio: Ausncia de erros uma iluso Identificar e corrigir os problemas de um software no garantem que ele est pronto. Os testes foram elaborados para identificar todas as possveis falhas? O sistema atende s necessidades e expectativas dos usurios? Ou seja, existem outros fatores que devem ser considerados para garantir a qualidade do sistema.Fonte:http://crowdtest.me/7-principios-fundamentais-teste-software/1 dimenso - Estgios ou nveis de teste(quando testar) Teste de Unidade - estgio mais baixo da escala de teste. Costuma ser feito pelos programadores. Teste de integrao - Teste do sistema ao trmino de cada iterao. Geralmente realizado pelo analista de sistema. Teste de Sistema - Execuo do sistema como um todo. Costuma ser realizado pelo analista de teste em ambiente de teste. Teste de aceitao - Testes antes da implantao do software. Em geral feito pelo usurio em ambiente de homologao.

2 dimenso - Tipos de teste(o que testar) De acordo com a metodologia de qualidade FURPS: Funcionalidade: Teste funcional, Teste de regresso, Teste de volume, Teste de segurana. Usabilidade: Teste de interface, Teste de usabilidade. Confiabilidade: Teste de integridade, Teste de estrutura, Teste de estresse, Smoke test. Desempenho: Teste de avaliao de desempenho ou benchmark, Teste de conteno, Teste de carga, Perfil de desempenho. Suportabilidade: Teste de configurao, Teste de instalao. 3 dimenso - Tcnicas de teste(como testar) Estrutural - Verificar se o sistema desenvolvido e os programas funcionam. ...Pretende determinar se a tecnologia utilizada foi apropriada e se, quando montados, os componentes funcionam como uma unidade coesa. Funcional - Assegurar que as especificaes e os requisitos do software foram atendidos.------------------------------------------------Ento de acordo com a questoa) Teste de Aceitao (NVEL DE TESTE) Teste de Regresso (TIPO DE TESTE) Teste Estrutural(TCNICA DE TESTE) b) Teste de Funcionalidade(TIPO DE TESTE) Teste de Desempenho (TIPO DE TESTE) Teste de Unidade(NVEL DE TESTE)c) Teste de Interface(TIPO DE TESTE) Teste de Carga(TIPO DE TESTE) Teste de Segurana(TIPO DE TESTE) d) Teste Funcional(TCNICA DE TESTE) Teste de Volume (TIPO DE TESTE) Teste de Sistema (NVEL DE TESTE)e) Teste de Usabilidade (TIPO DE TESTE) Teste de Funcionalidade(TIPO DE TESTE) Teste de Integrao (NVEL DE TESTE)

No contexto das redes de computadores e telecomunicaes, o Multi Protocol Label Switching (MPLS) um mecanismo de transporte de dados pertencente famlia das redes de comutao de pacotes. O MPLS padronizado pelo IETF - Internet Engineering Task Force atravs da RFC-3031 e opera numa camada OSI intermediria s definies tradicionais do Layer 2 (Enlace) e Layer 3 (Rede), pelo que se tornou recorrente ser referido como um protocolo de "Layer 2,5".O label um identificador curto, de tamanho fixo e significado local. Todo pacote ao entrar numa rede MPLS recebe um label. Este pode ser pensado como uma forma abreviada para o cabealho do pacote. Desta forma os roteadores s analisam os labels para poder encaminhar o pacote. O cabealho MPLS deve ser posicionado depois de qualquer cabealho da camada 2 e antes do cabealho da camada 3, ele conhecido como Shim Header e est apresentado na figura desta pgina.Uma assinatura digital garante as seguintes propriedades: Autenticidade: o receptor deve poder confirmar que a assinatura foi feita pelo receptor;Integridade: qualquer alterao da mensagem faz com que a assinatura no corresponda ao documento;No repudio ou irretratabilidade: o emissor no pode negar a autenticidade da mensagem.Ou seja, o sigilo da mensagem.Pseudo-cabealho so para algumas coisas, mas dentre elas no tem checksum. Tem duas extenses para segurana que so: Authentication Header e Encapsulating Security Payload.

Na extenso hop-by-hop h controle de fluxo atravs do tipo Jumborgram. Mas importante ver que o protocolo que faz esse controle de fluxo no Jumborgram o RSVP e no o UDP.

Mtricas e Estimativas de Software A medio de software se dedica a derivar um valor numrico para algum atributo de um produto ou processo de software. Comparando-se esses valores uns com os outros e aos padres que se aplicam em sua organizao, voc pode ser capaz de tirar concluses. Sobre a qualidade de software ou os processos de software [Sommerville]. Ou seja, uma mtrica de software uma medio que se refere a um software, processo ou documentao. Existem vrias classificaes para as mtricas de software. Algumas delas esto listadas a seguir.Internas ou Externas Mtricas Internas ou Estticas: medies de um produto de software a partir de suas prprias caractersticas internas sem a necessidade de execuo dos programas. Por exemplo, linhas de cdigo, nmeros de erros encontrados em revises, dados coletados na documentao, etc. Mtricas Externas ou Dinmicas: so medies de um produto de software a partir do comportamento do sistema ou do seu efeito no ambiente durante a execuo dos seus programas.Diretas ou Indiretas Mtricas Diretas, Bsicas ou Quantitativas: no dependem da medio de outros atributos. Exemplo: custo/esforo do desenvolvimento, linhas de cdigo, velocidade de execuo, quantidade de memria, nmero de erros, quantidade de defeitos. Concentram-se na sada do processo de engenharia de software. Mtricas Indiretas, Derivadas ou Qualitativas: dependem da medio de outros atributos. Exemplo: produtividade, qualidade e tcnicas (funcionalidade, manutenabilidade, complexidade, eficincia, confiabilidade, modularidade, portabilidade). Indicam o quanto o software atende aos requisitos definidos pelo usurio.Orientadas a Tamanho, Funo ou Pessoas Mtricas Orientadas a Tamanho: baseadas no nmero de linhas de cdigo produzidas (LOC) Mtricas Orientadas a Funo: baseadas na funcionalidade de software, tais como a Analise de Pontos de Funo. Mtrica Orientadas a Pessoas: indicam a forma como as pessoas devem desenvolver os programas.Objetivas ou subjetivas Objetivas: independem do autor da medio ou julgamento humano. Exemplo: quantidade de defeitos. Subjetiva: dependem do autor da medio ou julgamento humano. Exemplo: classificar a criticidade de um defeito.Produtividade, Qualidade ou Tcnica Produtividade: resultado do processo de desenvolvimento Qualidade: nvel de exigncia ou satisfao do usurio Tcnica: funcionalidade, manutenabilidade, modularidade, complexidade, eficincia, confiabilidade, portabilidade.

Exemplos de Mtricas Fan-in e Fan-out: Fan-in o nmero de funes que chamam a funo X. Fan-out o nmero de funes chamadas pela funo X. Extenso de Cdigo: quanto maior for o tamanho do cdigo de um componente, mais complexo e propenso a erros este componente ser Complexidade Ciclomtica: complexidade de controle do programa. Utiliza grafos e a seguinte frmula: M=E-N+2P, onde: M = complexidade ciclomtica E = quantidade de setas N = quantidade de ns P = quantidade de componentes conectados Extenso de Identificadores: extenso mdia de identificadores distintos de um programa. Quanto maiores forem os identificadores, mais eles sero significativos e mais compreensvel ser o programa. Profundidade de aninhamento das declaraes condicionais: declaraes IF profundamente aninhadas so difceis de compreender e so potencialmente propensas a erros. ndice de Fog: extenso mdia das palavras e sentenas nas documentaes Mean Time To Failure (MTTF): tempo que o software roda sem falhar Densidade do defeito: quantidade de defeitos (durante um perodo de tempo) pelo tamanho do software Mean Time Between Failures (MTBF): tempo mdio entre as falhas. Ajuda a prever quando ocorrer a prxima falha.

O TCU assegura s partes o exerccio da ampla defesa em todas as etapas da apreciao e julgamento dos processos. Essa matria est disciplinada na Resoluo no 36/95 do Tribunal.O art. 202 do Regimento Interno do TCU estabelece que, se verificada irregularidade, o Tribunal ou o Relator, havendo dbito, ordena a citao do responsvel para apresentar defesa ou recolher a quantia devida. No havendo dbito, determina a audincia do responsvel para apresentar razes de justificativa.A deciso do Tribunal da qual resulte imputao de dbito ou cominao de multa torna a dvida lquida e certa e tem eficcia de ttulo executivo. Nesse caso, o responsvel notificado para, no prazo de quinze dias, recolher o valor devido. Se o responsvel, aps ter sido notificado, no recolher tempestivamente a importncia devida, formalizado processo de cobrana executiva, o qual encaminhado ao Ministrio Pblico junto ao Tribunal para, por meio da Advocacia-Geral da Unio (AGU) ou das unidades jurisdicionadas ao TCU, promover a cobrana judicial da dvida ou o arresto de bens.

Condenao de ResponsveisEntre as funes bsicas do Tribunal est a funo sancionadora (incisos VIII a XI do art. 71 da Constituio Federal), a qual configura-se na aplicao de penalidades aos responsveis, em caso de ilegalidade de despesa ou irregularidade de contas. As sanes esto previstas na Lei n 8.443/92 e podem envolver desde aplicao de multa e obrigao de devoluo do dbito apurado, at afastamento provisrio do cargo, o arresto dos bens de responsveis julgados em dbito e a inabilitao para o exerccio de cargo em comisso ou funo de confiana no mbito da administrao pblica.Cumpre destacar que essas penalidades no excluem a aplicao de sanes penais e administrativas pelas autoridades competentes, em razo das mesmas irregularidades constatadas pelo Tribunal de Contas da Unio. Entre elas est a declarao de inelegibilidade por parte da Justia Eleitoral.Periodicamente, o TCU envia ao Ministrio Pblico Eleitoral os nomes dos responsveis cujas contas foram julgadas irregulares nos cinco anos anteriores, para os fins previstos na Lei Complementar no 64/90, que trata da declarao de inelegibilidade.O Tribunal pode, ainda, conforme disposto nos incisos IX e X do art. 71 da Constituio, fixar prazo para que o rgo ou entidade adote as providncias necessrias ao exato cumprimento da lei, caso haja alguma ilegalidade, ou sustar o ato impugnado.No caso de contratos, se no atendido, o Tribunal comunica o fato ao Congresso Nacional, a quem compete adotar o ato de sustao.

O PMBOK 5 define 3 tipos de Ciclo de Vida de Projeto:a) Previstos ou previsveis: escopo, tempo e custos so definidos mais cedo, em funo da estabilidade da rea de negcio na qual o projeto est sendo desenvolvido. Estes projetos progridem atravs de uma srie de fases sequenciais ou sobrepostas.So preferidos quando a rea de atuao bem conhecida e estvel, exige-se que o produto seja entregue por inteiro.b) Iterativos e incrementais: as fases (iteraes) repetem uma ou mais atividades, a medida que aumenta a compreenso sobre o projeto.Preferidos quando a organizao necessita administrar mudanas dos objetivos e escopo, reduzir a complexidade de um projeto ou quando a entrega parcial do produto benfica.c) adaptativos: direcionadas mudanas ou geis, reage a altos nveis de mudanas e envolvimento contnuo das partes interessadas; so tambm iterativos e incrementais, com a diferena que as iteraes so muito rpidas (2 a 4 semanas) com tempo e recursos fixos.Preferidos em ambientes em rpida mutao, requisitos e escopo difceis de definir antecipadamente, possvel definir pequenas melhorias incrementais que entregaro valor s partes interessadas.

O padro ISO/IEC 38500:2008 Governana corporativa da tecnologia da informao baseia-se em seis princpios bsicos.Princpios do ISO/IEC 38500: 1 PRINCPIO - RESPONSABILIDADE2 PRINCPIO - ESTRATGIA3 PRINCPIO - AQUISIO4 PRINCPIO - DESEMPENHO5 PRINCPIO - CONFORMIDADE6 PRINCPIO - COMPORTAMENTO HUMANOPara mais informaes de como o COBIT 5 apoia a adoo dos princpios e abordagem de implementao do padro ISO/IEC 38500:2008 Governana corporativa da tecnologia da informao ver APNDICE E do COBIT 5 Fonte: COBIT 5 (pg 61 a 64)

Construir, Adquirir e Implementar (BAI) - este domnio cobre identificao, desenvolvimento e/ou aquisio de solues de TIpara executar a estratgia de TI estabelecida, assim como a sua implementao e integrao junto aos processos de negcio. Mudanas e manutenes em sistemas existentes tambm esto cobertas por este domnio, para assegurar a continuidade dos respectivos ciclos de vida.BAI01 Gerenciar programas e projetosBAI02 Gerenciar a defi nio de requisitosBAI03 Gerenciar a identifi cao e a construo de soluesBAI04 Gerenciar disponibilidade e capacidadeBAI05 Gerenciar a habilitao da mudana organizacionalBAI06 Gerenciar mudanasBAI07 Gerenciar o aceite e a transio das mudanasBAI08 Gerenciar o conhecimentoBAI09 Gerenciar ativosBAI10 Gerenciar a confi guraoEntregar, Reparar e Suportar (DSS) - este domnio cobre a entrega propriamente dita dos servios requeridos, incluindo gerenciamento de segurana e continuidade, reparo de equipamentos e demais itens relacionados, suporte aos servios para os usurios, gesto dos dados e da infraestrutura operacional.DSS01 Gerenciar operaesDSS02 Gerenciar requisies de servios e incidentesDSS03 Gerenciar problemasDSS04 Gerenciar a continuidadeDSS05 Gerenciar os servios de seguranaDSS06 Gerenciar controles de processos de negcios

Tunning BD = otimizao de uso de recursos para aumentar o througput e minimizar a conteno, possibilitando o maior workload possvel de ser processado.Galera encontrei o seguinte trecho em uma monografia e quero compartilhar. Peo desculpas por no encontrar uma fonte consagrada da rea. Mas como solucionou minha dvida, segue abaixo.Segundo a monografia abaixo,"Entretanto, para este ajuste necessrio estar ciente dos fatores determinantes para a sintonia do SGBD que so:a) Workload - a carga de trabalho imposta;b) Throughput: - a capacidade e/ou velocidade de processamento de dados do computador;c) Recursos - hardware disponvel e as ferramentas de softwares a serem empregados;d) Otimizao - o otimizador do banco de dados, componente responsvel pela identificao da melhor forma de execuo de um comando SQL;e) Conteno - a condio em que h dois ou mais pedidos conflitantes ao mesmo tempo, algo como duas atualizaes no mesmo dado por exemplo.**Com isto, pode-se definir Sintonia em Banco de Dados como uma otimizao nos recursos usados para aumentar throughput e diretamente diminuir a conteno, fazendo com que se tenha a capacidade de executar um workload maior em um mesmo tempo x ."http://periodicos.unesc.net/index.php/sulcomp/article/viewFile/787/740

Lista contendo as mais importantes regras de sintaxe da XML:1 - Um documento XML deve possuir raiz nica.2 - Todas as tags devem ser fechadas (elementos devem possuir tag inicial e tag final)3 - Os nomes de elementos (tags) e atributos so sensveis caracteres maisculos e minsculos.4 - Os elementos devem ser bem-aninhados (tags fecham em ordem oposta a que foram abertas).5 - Atributos no se repetem em um mesmo elemento.6 - Todo atributo deve possuir algum valor e este valor deve ser especificado entre aspas.7 - Alguns caracteres especiais, como < , & e > devem ser especificados com o uso de entidades pr-definidas (no caso & lt; , & amp; e & gt; , respectivamente).8 - Nomes de tags no podem conter espaos em branco nem os caracteres !"#$%&'()*+,/;?@[\]^`{|}~. Alm disso, no podem comear com um nmero, . (ponto) ou - " (trao).

A habilidade de se modificar a definio de um esquema (nvel de abstrao) sem afetar a definio de esquema em um nvel mais alto chamada de independncia de dados, essa independncia dividida em dois nveis: Independncia fsica de dados: a habilidade de modificar o esquema fsico sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel fsico so ocasionalmente necessrias para melhorar o desempenho. Independncia lgica de dados: a habilidade de modificar o esquema conceitual sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel conceitual so necessrias quanto a estrutura lgica do banco de dados alterada (por exemplo, a adio de contas de bolsas de mercado num sistema bancrio)A independncia lgica dos dados mais difcil de ser alcanada do que a independncia fsica, porm os programas so bastante dependentes da estrutura lgica dos dados que eles acessam. O conceito de independncia dos dados similar em muitos aspectos ao conceito de tipos abstratos de dados em modernas linguagens de programao. Ambos escondem detalhes de implementao do usurio. Isto permite ao usurio concentrar-se na estrutura geral em vez de detalhes de baixo nvel de implementao.

Existem muitas motivaes para os bancos NoSQL, como por exemplo usar um modelomais adequado para os seu dados ou facilitar alteraes de schema; ou ainda alm, melhorar o desempenho e simplificar a replicao para ter a to sonhada escalabilidade linear.O teorema CAPClaro que todos os benefcios no vem sem custo, comparado com os bancos de dados tradicionais vamos perder alguma funcionalidade/garantia para ganhar outra. O tradeoff arquitetural descrito no bem conhecido CAP theorem.

A palestra famosa do Dr. Eric Brewer introduz o teorema e explica que em qualquer sistema distribudo stateful preciso escolher entre consistncia forte (C Consistency), alta disponibilidade (A availability) e tolerncia a particionamento dos dados na rede(P Network Partition Tolerance). Segundo o teorema CAP, entre as trs propriedades, somente duas podem ser garantidas ao mesmo tempo:Partition-TolerancePoder particionar nossos dados em diferentes ns de um cluster um dos recursos que aparecem com frequncia nos bancos NoSQL. Saber lidar com a separao/particionamento das dados devido uma falha na rede conhecido comoPartition-Tolerant.No entanto,segundo o teorema CAP, em troca elesiro sacrificar a consistncia forte ou a alta disponibilidade. Isso diferente dos bancos tradicionais, que no possuem essa caracterstica no design do sistema ou delegam isso para o filesystem.NoSQL 1: Sistemas CPPara sistemas que precisam da consistncia forte e tolerncia aparticionamento(CP) necessrio abrir a mo da disponibilidade (um pouco). Pode acontecer, caso haja particionamento e o sistema no entre em consenso, que uma escrita seja rejeitada. Claro que os sistemas tentam evitar isso ao mximo, tanto que no costuma existir, por exemplo, uma transao distribuda e sim um protocolo de consensos para garantir a consistncia forte. Exemplos desses sistemas CP so BigTable, HBase ou MongoDB entre vrios outros.NoSQL 2: Sistemas APPor outro lado existem sistemas que jamais podem ficar offline (24/7), portanto no desejam sacrificar a disponibilidade. Para ter alta disponibilidade mesmo com um tolerncia aparticionamento(PA) preciso prejudicar a consistncia (eventual-consistency). A ideia aqui que os sistemas aceitam escritas sempre e tentam sincronizar os dados em algum momento depois (read-consistency). Ento pode ter uma janela de inconsistncia. Exemplos aqui so Amazon Dynamo, Cassandra ou Riak.Sistemas CAOs sistemas com consistncia forte e alta disponibilidade (CA) (alta disponibilidade de um n apenas) no sabem lidar com a possvel falha de uma partio. Caso ocorra, sistema inteiro pode ficar indisponvel at o membro do cluster voltar. Exemplos disso so algumas configuraes clssicas de bancos relacionais.Qual a diferena entra CA e CP?Vimos brevemente o teorema CAP e a escolha que os sistemas NoSQL fazem (CP ou AP) comparado com os bancos tradicionais (CA). importante mencionar que para o desenvolvedor no haver tantas diferenas entre CA ou CP. SEMPRE teremos consistncia forte, no entanto, um sistema fica indisponvel (CA) quando h particionamento pois tem apenas alta disponibilidade por n e o outro sistema (CP) tente chegar a um consenso se aceita uma escrita ou no, que no pior dos casos tambm pode significar a indisponibilidade para uma parte dos dados. Seguindo desse raciocnio podemos perceber que a consistncia e disponibilidade so extremos quando h particionamento. Isso foi uma dvida que me incomodou bastante antes da minha palestra no Caelumday 2009. Podemos concluir que quando h particionamento (P) ter alta disponibilidade (A) ou consistncia (C) forte: P?(A|C)Mas o que acontece se NO h particionamento? uma pergunta que o CAP no responde. A primeira resposta poderia ser: claro que vai ser consistente j que ningum gosta de lidar com dados desatualizados. Mas olhando para os sistemas NoSQL nem sempre isso verdade. Existem sistemas que SEMPRE so eventually-consistent. Mas porque?Consistncia ou LatnciaH mais um motivo porque poderia fazer sentido sacrificar a consistncia: O tempo da resposta ou a latncia. Da mesma maneira que um sistema offline pode custar caro, um sistema lento tambmpode. Por isso pode fazer sentido abrir a mo da consistncia para diminuir a latncia.De CAP para PAC/CLO artigo do blog do Prof. Daniel Abadi explica o tradeoff com parties e sem. Ele sugere substituir a sigla CAP com PAC/CL (ou P?(A|C):(C|L)), traduzindo levemente modificado do artigo dele: se h particionamento (P), o sistema pode valorizar a disponibilidade (A) ou a consistncia (C), seno, quando o sistema roda sem parties, o sistema pode favorecer o tempo da resposta/latncia (L) ou a consistncia (C).Exemplos de PAC/CLSeguindo dessa linha PC/C significa que o sistema valoriza a consistncia sempre, com ou sem parties. Banco de dados tradicionais so sempre fortemente consistentes, ou seja PC/C. Amazon Dynamo ou Cassandra so sempre fracamente consistente, favorecendo a alta disponibilidade e o tempo da resposta (latncia), ou seja PA/L. Mas existem misturas como o GenieDB (PA/C), que s trabalha consistente em caso de nenhuma parties. Quando h parties valoriza a alta disponibilidade. Exemplo contrrio disso o Yahoo Sherpa, que usa PC/L, ou seja com parties favorece consistncia, sem parties diminuir a latncia.Durante o curso FJ-91, diversas questes e decises arquiteturais so abordadas e discutidas, sendo que uma delas envolve o teorema CAP e os bancos de dados NoSQL.

Um NAS (Network Attached Storage), por sua vez, roda um sistema operacional completo e funciona como um servidor de arquivos, ligado diretamente na rede.Muitas vezes, eles so chamados de "network storage", ou simplesmente de "storage", termos que so mais descritivos para o pblico no tcnico do que "NAS". Entre o pblico tcnico, eles so tambm chamado de "filers" (arquivadores). O termo "storage" na verdade um termo tcnico genrico para solues de armazenamento, que usado tambm em outras situaes, como no caso das SANs.

SAN se comporta como se fosse uma nica unidade de armazenamento, que o servidor pode acessar diretamente, de forma transparente. Ou seja, como se voc conectasse um nico HD de 100 TB (por exemplo) no servidor, diferente de um NAS, que se comporta como um servidor de arquivos e pode ser acessado simultaneamente por vrios clientes.Apesar disso, na grande maioria dos casos, o objetivo de usar uma SAN no simplesmente obter um grande espao de armazenamento, mas sim obter ganhos de desempenho e de confiabilidade para aplicaes crticas.

As fases do TDD so:

1 - Adicione um teste no TDD para a nova funcionalidade. Este teste tem que falhar.

2 - Execute todos os testes e verifique se algum falhou. Verifica se o novo teste no traz um erro j existente, logo no decorrente da nova funcionalidade

3 - Escreva o cdigo. Pode no ser perfeito e pode passar no teste de forma no elegante. Ser melhorado depois.4 - Execute todos os testes automatizados5 - Refatore o cdigo6 - Repita tudoA ordem no est certa e faltam os passos 4 e 5.