O Caso Abu Dhabi – Usuário Negligenciado

Bem amigos do blog QualidadeBR!

No último domingo, tivemos o encerramento da eletrizante temporada 2009 da F1. E o desfecho do campeonato ocorreu no mais novo circuito da temporada o Yas Marina, localizado no maior emirado dos Emirados Árabes Unidos, Abu Dhabi.

O intuito do post é fazer um breve estudo de caso, de algo que ocorreu na construção do circuito e que também ocorre em projetos de software.

Para começar o estudo de caso do circuito de Abu Dhabi, é preciso antes falar sobre o seu projeto, que custou a bagatela de 1,322 bilhões de dólares (segundo a Wikipedia).

A construção do circuito teve início em fevereiro de 2007, com o “modesto” desafio de construir um dos mais modernos circuitos da F1 no meio do deserto. Alguns números da “singela” construção:

  • Uma força de trabalho de 14.000 homens;
  • 35 milhões de hora-homem investidos;
  • 1,6 milhão de metros cúbicos de terra foram deslocados;
  • 720 mil metros quadrados de asfalto;
  • 25 quilômetros de cabeamento elétrico;
  • 5 mil árvores plantadas;
  • 430 mil metros quadrados de terreno foram ajardinados;
  • 40 quilômetros de blocos instalados;
  • Um hótel 5 estrelas foi construído no meio do circuito.

Ou seja, um construção daquelas que costumamos ver no programa Mega Construções do Discovery Channel.

E como todo projeto, há objetivos a serem alcançados ao término:

  • Construir um circuito moderno e de acordo com as novas premissas estabelecidas pela FIA;
  • Suportar um grande público e oferecer conforto ao mesmo;
  • Uma boa iluminação que permita a realização de corridas noturnas;
  • Encerrar o projeto em 2009, antes das inspeções da FIA para o grande prêmio de Abu Dhabi de F1.

Bem, esses são alguns objetivos que eu acredito que poderiam medir o nível de sucesso do projeto do circuito de Yas Marine. Abaixo, segue uma galeria de fotos, que mostra o circuito desde o início da construção até o término.

E além daqueles objetivos que citei, em uma reportagem divulgada no site PlanetF1, Richard Cregan, o administrador do circuito, revelou que os stakeholders do projeto esperavam algo incrível.

Portanto, de acordo com os objetivos citados e a expectativa dos stakeholders o projeto foi um sucesso, afinal o circuito ficou pronto no tempo e com certeza impressionou os stakeholders, dentre eles a FIA.

Eu mesmo comentei no twitter, após assistir os melhores momentos da classificação, que o circuito é fabuloso, nos faz perceber o quanto evoluímos em termos de construções, fazer um circuito daquele em pouco mais de 2 anos é um feito muito impressionante mesmo.

Porém…

Acho que faltou a opinião de alguém na história, não faltou?

Faltou “só” a opinião dos pilotos e dos espectadores.

Pelo que li pela internet e ouvi na narração da corrida, todos os pilotos ficaram impressionados com o circuito, porém poucos ficaram impressionados com o desafio que o circuito proporciona, tanto que o Rubinho disse que o ponto mais perigoso da pista é o túnel da saída do pit-stops, ou seja, pelo visto não é um circuito muito desafiador, até porque, se o piloto escapar em alguma curva, ele terá uma boa área de escape asfaltada para retornar a pista, o que vai causar apenas uma perda de tempo.

Como espectador, achei a pista bem sem graça, quase não há pontos de ultrapassagens, o que resultou numa corrida bem monótona.

Acredito que os stakeholders se esqueceram de dois ingredientes essenciais para uma corrida de F1: o desafio e ultrapassagens. Afinal, a ultrapassagem está para a F1, assim, como o gol está para o futebol.

E na lista de stakeholders da construção do circuito, acho que não foram incluídos os pilotos. (fail)

O ponto que quero chegar

O que ocorreu no projeto do circuito Yas Marina é algo que também ocorre em projetos de TI: a negligência em relação aos usuários.

Os projetos nascem e morrem de acordo com os interesses dos envolvidos, até aí tudo bem. O grande problema é quando esses interesses não incluem os interesses dos reais usuários do fruto daquele projeto. Quem participa do mundo da gerência de projetos ou já teve algum contato, sabe que nem sempre, o cliente será o usuário daquele determinado produto a ser desenvolvido, portanto o cliente tem um papel primordial de representar os usuários. Porém, nem sempre o cliente tem pleno conhecimento sobre o que os usuários esperam daquela determinada solução.

Algo que ocorre com uma certa frequência incômoda em projetos de software, é que eles não são centrados no usuário,  muitas vezes os usuários só terão contato com o sistema após o término do mesmo. E isso deve-se há vários motivos, dentre os quais um muito estranho é o medo do pessoal de TI de se envolver com os usuários, pois eles tem em mente que se forem conversar com os usuários eles irão pedir mais uma “trocentas” mudanças, e mudanças para esses profissionais é algo muito ruim. Afinal das contas, os interesses deles, às vezes se limitam em apenas obter o melhor ROI, e que se dane que a solução desenvolvida não solucione nada, seja difícil de utilizar, e que ainda tenha vários bugs. Para esses “profissionais” isso é até melhor, pois assim eles irão ganhar dando treinamentos e novos contratos de manutenção irão surgir. Ou seja, uma maneira de desenvolver software a lá Dick Vigarista e seguindo a Lei de Gérson, e que a médio e longo prazo não traz nem mais retorno financeiro, já que a fama da empresa já terá se espalhado entre os clientes.

Um outro ponto interessante de se comparar a construção do circuito de Yas Marina com a construção de um software, é que às vezes nós acabamos fazendo o mesmo que a FIA fez, burocratizar e criar padrões demais, e o mais preocupante, padrões fora do contexto da realidade, como por exemplo, criar circuitos que dificultem as ultrapassagens. Por isso, que é bom de vez em quando tirar a cabeça do prato. 😉

Lembre-se que a qualidade é uma questão de ponto de vista, e no desenvolvimento de software o ponto de vista mais importante é o do usuário.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://en.wikipedia.org/wiki/Yas_Marina_Circuit

http://www.itv-f1.com/Feature.aspx?Type=General&id=47272

http://www.planet-f1.com/story/0,18954,3213_5658598,00.html

Imagens:

http://www.architecturelist.com/wp-content/uploads/2009/05/yashotel-asymtote.jpg

http://www.ameinfo.com/images/news/1/80441-YasMarina.jpg

http://www.bustler.net/images/uploads/asymptote_yas_hotel_06x.jpg

http://www.thenational.ae/apps/pbcsi.dll/bilde?Site=AD&Date=20090918&Category=NATIONAL&ArtNo=709179849&Ref=AR

 

Como testamos o Basix? – Contratação

Como comentei neste post, na minha opinião, a contratação de um profissional é um processo de suma importância, para ambos os lados.

Falando mais especificamente do projeto Basix, eu não posso explicar como foi desde o começo, pois entrei no projeto após mais de 3 anos do seu início. Então, nada melhor do que conversar com o Antonio, que gerencia o projeto desde o seu início, e até já fez um post relacionado ao assunto: O que vale mais conhecimento técnico, ou características pessoais?

Abaixo, segue a entrevista que fiz com o Antonio, focada no assunto contratação e especificamente da área de Teste e Qualidade de Software. Espero que gostem.

Fabrício: Antonio, antes de mais nada, em qual momento você percebeu que o projeto necessitava de uma área de Teste e Qualidade de Software?

Antonio: Percebemos isto desde a concepção do projeto, pois vínhamos de experiências em desenvolvimento de software sem uma área de qualidade, e já que estávamos começando um novo projeto não podíamos errar novamente da mesma forma.

Fabrício: E como foi o processo de contratação?

Antonio: Foi complicado, pois há 5 anos atrás era muito difícil convencer profissionais a trabalhar na área de qualidade de software, pois esta área não tinha a ênfase que tem hoje no Brasil, e as faculdades de TI não tinham disciplinas que ensinavam qualidade de software, no geral elas preparam os estudante para serem desenvolvedores.

Fabrício: A pessoa para atuar na área, necessita ter características específicas? Se sim, quais?

Antonio: Precisa sim Fabrício, aqui vou reproduzir o perfil que divulgamos no último processo seletivo que fizemos para a área de qualidade:

  • Conhecimentos técnicos
    • Boa base de informática;
    • Raciocínio lógico;
    • Capacidade de abstração;
    • Capacidade de análise de problemas;
    • Inglês técnico (quanto mais experiente melhor).
  • Funcionamento do grupo
    • O grupo de qualidade é um grupo que trabalha com atividades rotineiras, pois sempre que é liberado uma nova versão do software é necessário refazer todos os testes, necessário muita acuidade no trabalho, pois é o controle de qualidade do produto. É um grupo de generalistas, pois é necessário ter conhecimento de muitos componentes que constroem o produto.
  • Personalidade que ajudaria a desenvolver o grupo
    • Perfeccionismo;
    • Organização;
    • Crítico;
    • Pesquisador.
  • Características pessoais
    • Boa auto estima;
    • Extrovertido;
    • Bom relacionamento interpessoal;
    • Estar aberto a aprender;
    • Pró atividade;
    • Estar aberto a receber criticas.

Fabrício: Qual foi a maior dificuldade encontrada na contratação dos profissionais?

Antonio: Por ser uma área relativamente nova, foi bem difícil encontrar pessoas que queriam trabalhar na área de testes, a grande maioria queria desenvolver, então o processo de contratação também era um processo de convencimento, pois procuramos as pessoas que tinham as características ideais para trabalhar com qualidade, e muitos destes nós tivemos que convencer que era uma boa trabalhar na área de qualidade, e de qualquer forma tivemos muitos profissionais que depois de um tempo decidiram ir para o desenvolvimento, esta rotatividade foi uma dificuldade muito peculiar da área de qualidade.

Fabrício: Na sua opinião, até que ponto uma certificação ou especialização (ex. Pós-Graduação) ajuda o candidato durante o processo seletivo?

Antonio: Acredito que certificação ou cursos de especialização são sempre bem vindos, principalmente porque se um profissional decidiu  por conta própria estudar para conseguir um titulo deste isto no mínimo significa que a pessoa está interessada na área, e teve competência para obter o título, mas existe um outro lado para mim certificações e títulos não são de forma alguma os principais fatores para avaliar um bom profissional, pois existem profissionais excelentes que não tem nem a graduação completa.

Fabrício: Para fechar, de 2005 até hoje, a contração de profissionais para a área de Teste e Qualidade de Software ficou mais fácil? Ou ainda é difícil encontrar pessoas com o perfil e conhecimento para entrar na área?

Antonio: Com certeza o panorama do mercado da área de qualidade de software mudou completamente nestes últimos 4 anos, hoje já temos faculdades ministrando disciplinas voltadas para qualidade de software, existem comunidades de  que fomentam a área, e isto já reflete no mercado como um todo, hoje é muito mais fácil você achar pessoas que querem trabalhar com teste de software, e posso falar isto com tranqüilidade pois até o problema de rotatividade que tivemos diminuiu muito ao longo do tempo, hoje temos uma equipe de qualidade bem estável e onde todos realmente gostam de testar!!!

Muito obrigado Antonio pela entrevista. 😀

No próximo post da série, irei falar sobre a complexidade do projeto e o papel da área de Teste e Qualidade de Software. Até lá! 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Precisa sim, Fabricio aqui vou reproduzir o perfil que divulgamos no ultimo processo seletivo que fizemos para a àrea de qualidade:

Conhecimentos técnicos:

Boa base de informática
Raciocinio lógico
Capacidade de abstração
Capacidade de análise de problemas
Inglês técnico (quanto mais experiente melhor)

Funcionamento do grupo:

O grupo de qualidade é um grupo que trabalha com atividades rotineiras, pois sempre que é liberado uma nova versão do software é necessário refazer todos os testes, necessário muita acuidade no trabalho pois é o controle de qualidade do produto, é um grupo de generalistas pois é necessário ter conhecimento de muitos componentes que constroem o produto.

Personalidade que ajudaria a desenvolver o grupo:

Perfeccionismo
Organização
Critíco
Pesquisador

Caracteristicas pessoais:

Boa auto estima
Extrovertido
Bom relacionamento interpessoal
Estar aberto a aprender
Pró atividade

Estar aberto a receber criticas

Impressões exame IBM 000-370

Foi hoje de manhã o meu exame da certificação IBM Certified Specialist – Software Quality. Acertei 67% (30 questões) e precisava ter acertado 71% (32 questões) das questões.

Mas mesmo com o resultado negativo, fiquei feliz e até surpreso com o resultado, pelo pouco tempo de estudo que dediquei. 🙂

Abaixo segue as impressões que tive do exame e também algumas dicas para aqueles que irão fazer o exame.

Dificuldade

O exame oferece um alto grau de dificuldade, devido as seguintes características:

  • Baseado em um conteúdo muito extenso;
  • Há muitas questões com alternativas parecidas, e você tem que escolher a melhor alternativa;
  • Os conceitos que caem no exame são de acordo com a IBM, e alguns são bem diferentes dos usados pela maioria.

Idioma

O exame é em Inglês, a maioria das questões usam termos técnicos, e se você não teve dificuldade com as questões existentes no material de estudo, o idioma não será um problema. Mas por via das dúvidas é bom levar um dicionário.

Duração

O exame tem duração de 60 minutos, é tempo suficiente para fazer as questões e até revisar as que você ficou em dúvida.

Resultado

O resultado sai na hora e mostra até a porcentagem de acertos em cada área (Engineering Quality in Software Development, Software Quality e Software Testing).

Dicas

Para o estudo para a certificação há basicamente duas táticas que podem ser seguidas:

  • Ler todo o material;
  • Ler o material de acordo com os objetivos do exame.

A primeira é boa para quem quer, além de obter a certificação, aumentar o conhecimento sobre as áreas de abordadas. E uma boa é que o material abrange muitos assuntos que nós que trabalhamos com Teste e Qualidade de Software, não vivenciamos, mas que são legais de saber.

Já a segunda tática é a ideal para quem objetiva a obtenção da certificação e não está com muito tempo para os estudos. Usando ela aconselho estudar os seguintes módulos, prestando atenção aos objetivos do exame [1]:

  • Engineering Quality in Software Development
    • Creating Secure Software
    • Essentials for Unit Testing
    • Estimating Effort for Development Tasks
    • In-Process Metrics for Software Developers
    • Inspections in the Software Lifecycle
    • Static Code Analysis
    • Topics in Design – Design Review Checklist
  • Software Quality
    • Todos os módulos
  • Software Testing
    • Todos os módulos

[1] http://www-03.ibm.com/certify/tests/obj370.shtml

Eu acabei usando uma terceira tática (rsrs), estava sem tempo de estudar, então só fiz as questões de cada módulo. O que até ajudou bastante na prova, pois essas questões são focadas geralmente nos objetivos das lições e algumas até apareceram no exame.

Agora é aguardar a volta da certificação aqui no Brasil! 🙂

Boa sorte aos que ainda irão prestar o exame!

Fique por dentro das novidades, assine o feed do QualidadeBR.

E quem quiser saber mais dicas sobre o exame, entre no grupo Certificações – Qualidade e Teste de SW, do Fábio Martinho Campos, lá ele deu várias outras dicas para o exame.

Certificação: IBM Certified Specialist – Software Quality

Pessoal,

Ontem eu recebi um e-mail, digamos que um pouco suspeito, sobre uma certificação na área de Qualidade de Software. Você pode está se perguntando, por que um e-mail sobre uma certificação pode ser suspeito?

O que eu achei suspeito foi o fato dela ser gratuita. Isso mesmo, sem nenhum custo, a não ser o tempo de estudo e o deslocamento para o centro de treinamento que irá aplicar o exame.

Trata-se da certificação IBM Certified Specialist – Software Quality, eu mesmo nunca tinha ouvido falar sobre tal, e o Fábio Martinho Campos, que é um especialista em certificações de qualidade e testes, me disse, no seu grupo de discussão dedicado as certificações de Qualidade e Teste de Software, que ele também não a conhecia. Portanto, pelo menos no Brasil, ela deve ter sido lançada agora.

Ela é uma certificação voltada para desenvolvedores, testadores e profissionais em Qualidade de Software que desejam melhorar seus conhecimentos em Qualidade de Software, e assim desenvolver um trabalho mais eficiente.

A prova é composta de 45 questões e o tempo de realização é de 1 hora e 15 minutos (segundo a ficha de confirmação da inscrição do exame, enviada pela Prometric), no site da IBM diz que o tempo da prova é de 60 minutos. A diferença de tempo deve ser por a prova ser em inglês, que não é a nossa linguagem nativa.

Para obter a certificação é preciso acerta 71% das questões, ou seja, 32 questões.

O estudo para a prova é feito com base em um material de uma instituição de e-Learning, a AzIT. O material também é obtido, de forma gratuita no site da AzIT, bastando fazer um simples cadastro (clicando no link Enroll).

O material disponibilizado no site está em formato de apresentação, você pode assistir pelo site ou baixar o arquivo do módulo que está sendo estudado. Eu reunir todo o material disponibilizado no site da AzIT, e estou compartilhando nos links abaixo, ele está separado por área de estudo, assim como está no site:

Engineering Quality in Software Development (78.27 MB)

Software Quality (56.7 MB)

Software Testing (76.96 MB)

Para fazer a inscrição do exame, basta acessar o site da Prometic, e seguir o passo a passo:

  1. Clicar no banner “START
  2. Clicar no link “Schedule an Appointment
  3. Selecionar no combo box Country a opção Brazil e clicar em <NEXT>
  4. No list box ‘Program’ selecione IBM (000,001) e clique em <NEXT>
  5. <NEXT>
  6. A prova é 000-370 e clique em <NEXT>
  7. Escolha o Test Sites mais próximo da sua casa.
  8. Login e confirm process

No site da IBM há um simulado do exame, que pode ser acessado no link abaixo:

http://www14.software.ibm.com/cgi-bin/pwdown/public/httpdl/certify/sam370.pdf

Bem, na minha opinião essa é uma excelente oportunidade para adquirir novos conhecimentos, e ainda poder tirar uma certificação de uma empresa reconhecida mundialmente, que é a IBM.

Eu já marquei o meu exame para o dia 31 de março, vou ver se consigo tirar a certificação. Mas pelo que vi nos objetivos da certificação e pelo material fornecido pela AzIT, a prova oferece um alto grau de dificuldade, principalmente por abordar tanto o Teste de Software, Qualidade de Software, como o Desenvolvimento de Software.

Portanto, acredito que será um grande desafio, e o mais importante será adquirir novos conhecimentos e poder colocá-los em prática.

Quem ficou interessado em fazer o exame, é melhor correr, pois a gratuidade do exame é somente por um tempo determinado, não sei até quando. Como pode ser conferido no texto abaixo, retirado do site da AzIT:

Information about the Test:
Cost of the exam: $0 (The test fee is waived for US Citizens during the grant period. If you are taking the test outside of the US Check with your local Authorized Prometric test center for testing fees.)

Fique por dentro das novidades, assine o feed do QualidadeBR.
Assine o feed

Saiba mais:

Página oficial da certificação

Fonte:

http://www-03.ibm.com/certify/tests/ovr370.shtml

http://br.groups.yahoo.com/group/certificacoesqualidadetestedesoftware/

Mercado atual – Teste e Qualidade de Software

Pessoal, dando uma passada no blog do GUTS encontrei uma interessante apresentação do Fernando Scarazzatto com o seguinte título “O Panorama do Mercado de TI e da Profissão de Testador de Software no Brasil”. Um dos assuntos abordados pelo Fernando na apresentação é a situação atual do mercado de TI, tendo em vista a área de Testes e Qualidade. Abaixo, comento sobre cada um dos itens citados nesta parte da apresentação:

  • Carência de profissionais especializados em testes de software – esse é um fato comum em diversas áreas de TI, por mais que pareça estranho em um país como o Brasil. E na área de teste de software é ainda mais comum, pois a maioria das faculdades e universidades ensinam como programar, mas não como testar. Além disso, muitas pessoas ainda desconhecem a área de Testes de Software.
  • Carência de ambientes estruturados para a execução dos testes – uma característica notável, principalmente em empresas que recentemente implantaram o processo de Teste de Software. O “jeitinho brasileiro” faz com que os profissionais realizem testes em ambientes bem diferentes do de produção, o que pode acarretar na descoberta de diversas falhas somente em produção.
  • Cobertura de testes insuficientes em relação as funcionalidades e adequação aos requisitos – em algumas empresas a etapa de testes é pensada somente no momento do desenvolvimento, quando não somente no final. O correto seria ela já se planejada e esperada na elaboração dos requisitos, pois muitos requisitos e funcionalidades acabam tendo um baixo valor de testabilidade, dificultando e até impossibilitando a realização do teste.
  • Alto índice de não atendimento aos requisitos – quando perguntamos a um tester se o que ele testou está de acordo com o requisito, ele poderá nos surpreender com a seguinte resposta “Que requisito?”. Tal fato não é difícil de ser observado, pois os requisitos são “traduzidos” muitas vezes durante o desenvolvimento de um software. Por exemplo, o critério de aceitação de um teste poderá estar totalmente diferente do requisito de uma determinada funcionalidade.
  • Informalidade do processo de testes (em geral executados pelos próprios desenvolvedores) – quando não há um processo de teste bem definido, o risco dos testes serem executados de maneira informal é grande, principalmente quando executados pelos próprios desenvolvedores, já que esses, geralmente, não possuem um conhecimento sobre o processo de teste.
  • Baixa relevância atribuída ao processo de testes – as empresas ainda tem percepções arcaicas do processo de teste, achando que ele irá apenas gerar mais custo e gastar tempo. Quando na verdade, ele é fundamental no processo do desenvolvimento e implicará no aumento da qualidade do produto final.
  • Necessidade de abordagem de teste diferenciada para novas tecnologias – novas tecnologias estão sempre surgindo e com ela novas abordagens de testes se fazem necessárias. Desta maneira, a Engenharia de Software está sempre em constante evolução e melhoria, e a área de Testes que é um dos ramos da Engenharia de Software também se vê necessitada de novos processos, métodos e artefatos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

“O Panorama do Mercado de TI e da Profissão de Testador de Software no Brasil” – Fernando Scarazzatto

Qualidade de Software – Processo ou Projeto?

Essa é uma daquelas perguntas que muitos responderiam começando com “Veja bem” e como já diria um amigo meu, quando você inicia uma resposta com “Veja bem” você provavelmente irá enrolar, o popular “encher lingüiça”.

Antes de responder a essa pergunta precisamos, definir e diferenciar projeto de processo:

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. (PMBOK)

Um conjunto de atividades, métodos, práticas e tecnologias que as pessoas utilizam para desenvolver e manter software e produtos relacionados. (CMM)
Pela própria definição já conseguimos notar a diferencia principal entre projeto e processo, que é a duração de cada um. O projeto tem início, meio e fim, já o processo é contínuo. Para exemplificar essa diferença, vou usar dois exemplos:
O casamento é um projeto, ele tem início com os requisitos (igreja, tipo de comemoração, lua-de-mel, etc), meio com a elaboração do projeto (tempo, pessoas envolvidas, etc) e com a execução (convite dos convidados, aluguel do local da festa) e por fim o casamento em si.
A vida de casal seria (ou deveria ser) um processo, pois é contínua, já possui procedimentos (ex. almoço na casa da sogra no domingo) e artefatos (ex. o próprio almoço na casa da sogra) estabelecidos.
Qualidade de Software como processo
A Qualidade de Software é vista como processo, quando ela já tem um processo definido, regular e previsível, todo input (entrada) feito para a Qualidade de Software respeitará esse processo. Um exemplo seria a área de Qualidade de uma fábrica de Software, cujos softwares desenvolvidos passam pela Qualidade seguindo o processo dessa área. Ou seja, o processo será sempre reusado, o máximo que haverá será customizações e melhorias.
Qualidade de Software como projeto
Um grande projeto será desenvolvido pela empresa XPTO e será necessário o envolvimento da equipe de Qualidade atual da empresa e a contratação de novos funcionários. A equipe de Qualidade notou que o seu processo não está adequado para a magnitude do projeto, portanto ele terá que sofrer grandes modificações.
No caso citado acima, a Qualidade de Software será um “subprojeto” do projeto, portanto ele pode ser classificado como projeto de Qualidade de Software, afinal os esforços a serem dedicados serão temporários (o período do projeto). Haverá necessidades de renovação, mudança, criação e inovação, e o fluxo estabelecido poderá ser válido só para aquele projeto, e muitas vezes ele não será reusado em sua integridade em outros projetos, portanto ele se torna singular.
Conclusão
A visão de Qualidade de Software muitas vezes é confundida entre projeto e processo, ambos podem ser associados a Qualidade de Software. O diferencial para ela ser um processo ou um projeto será a maneira que ela é implantada na empresa. O importante é definir as atividades, métodos, práticas e tecnologias, pois são eles os componentes tanto de um processo quanto de um projeto.

Fique por dentro das novidades, assine o feed do QualidadeBR.
Subscribe

O que é Qualidade de Software?

Para definir Qualidade de Software (QS), necessitamos primeiro saber o que é qualidade:
Segundo a Wikipédia: “Qualidade é um conceito subjetivo que está relacionado diretamente às percepções de cada indivíduo. Diversos fatores como cultura, modelos mentais, tipo de produto ou serviço prestado, necessidades e expectativas influenciam diretamente nesta definição”.
Como podemos perceber, qualidade é um substantivo que pode ter muitos significados. Isso acontece pela forte ligação com as percepções das pessoas, que tem pensamentos e gostos diferentes.

Então, qual seria a definição para QS? Estaria ela também fadada às percepções do ser humano?

A QS assim como as outras está ligada diretamente as opiniões das pessoas, que neste caso, são representadas pelos clientes, usuários e envolvidos com o projeto de software. Possuindo as seguintes características:
• QS está fortemente relacionada à conformidade com os requisitos;
• Ela caracteriza o grau de satisfação do cliente;
• Não é responsabilidade de apenas uma área da empresa, e sim de todos;
• Deve está presente desde o planejamento do software.

Atualmente, QS vem ganhando um grande foco nas empresas de TI, pois percebeu-se que a Qualidade de Software não é um gasto e sim um investimento. E com a evolução constante da tecnologia, os clientes estão cada vez mais exigentes. Podemos até fazer uma analogia com o mundo dos games: antigamente (10 anos atrás), The Legend of Zelda: Ocarina of Time, lançado para o Nintendo 64, era “o game”. Hoje, se você der a uma criança o cartucho (nada de DVD, muito menos Blu-Ray), ela provavelmente vai achar os gráficos “toscos” e ainda vai perguntar porquê, movendo o controle ela não move o personagem.

Espero que vocês tenham gostado do primeiro tópico do blog QualidadeBR. Fiquem à vontade para comentarem.

Fique por dentro das novidades, assine o feed do QualidadeBR.