Qualidade Manaus

Garantir qualidade necessita atenção especial e medidas práticas como definir, estruturar o processo de desenvolvimento de software e acima de tudo possibilitar a manutenibilidade do padrão estabelecido que por conseqüência irá provocar o melhor aproveitamento dos métodos, técnicas e ferramentas relacionados a esse padrão adotado.

Dependendo da dimensão de projetos, prevenir problemas em software pode trazer benefícios econômicos significativos como é apresentado por Teles:

O custo de se corrigir um problema em um software cresce exponencialmente ao longo do tempo. Um problema que poderia ter custado um dólar para ser corrigido se tivesse sido encontrado durante a análise pode custar milhares de dólares para ser resolvido depois que o software já estiver em produção (2004, p. 151).

Assim como Teles, Boehm e Papacio afirmam que a questão econômica é bastante significante, e dessa forma constataram que o custo para identificar e resolver um problema na etapa de identificação de requisitos custa 1 unidade monetária. Além disso, sofre um acréscimo em seu custo de 5 vezes se a solução ocorrer na fase de projeto, 10 vezes se ela ocorrer na fase de codificação, 20 vezes se ocorrer durante os testes e, 200 vezes ou mais se ela só ocorrer depois do sistema ter sido entregue e estiver em produção.

Figura: Custo Para identificar e resolver um problema. Fonte: Adaptado de Boehm

Pressman (1995) consegue resumir bem o que os autores afirmam: “pague agora ou pague depois muito mais”. Dessa forma é possível visualizar os benefícios da prevenção de defeitos em produtos acabados, e visualizar quanto custa caro corrigir defeitos detectados após a entrega para o cliente e o mesmo já estiver em ambiente de produção.

A implantação de controle de qualidade em todas as fases do processo de produção de software apesar de ter custo inicial elevado encontra justificativa lógica quando a longo prazo se consegue alcançar um software de ótima qualidade e seus custos de manutenção são claramente menores.

O CrowdTest é um serviço realizado organizando mão-de-obra disponível na Internet para execução de testes. Esse modelo de trabalho, conhecido como crowdsourcing, permite que as empresas tenham seus produtos testados por usuários reais e que as pessoas sejam recompensadas pelo seu trabalho de encontrar as falhas.

Nos projetos de CrowdTest temos três papéis: o cliente, a equipe do CrowdTest e os testadores. O CrowdTest recebe as demandas dos clientes, organiza o projeto e a equipe que irá participar, recebe as falhas, faz a validação e disponibiliza o resultado para os clientes. O diagrama a seguir detalha como são os passos dentro de um projeto.

O modelo  começou a operar em março deste ano no Brasil e já realizou cerca de 20 ações com empresas como Buscapé, Sul-América, Via6, CupomNow, entre outras. O site (http://www.crowdtest.me/) surgiu a partir da experiência anterior de Barros à frente da a Base2, empresa especializada em testar softwares.

O Site uTest (http://www.utest.com/) é um dos maiores do mundo e conta com um grande número de testadores ao redor do globo que testam segmentos da industria de software como Mobile, Web e Sistemas Desktop.

A conversa sobre Crowdsourcing começa a fazer parte das discussões nos grupos de teste espalhados pelo Brasil, já que isso pode colocar em xeque equipes de Testes dentro de empresas que podem contar com um serviço executado coletivamente fazendo frente ao trabalho de equipes reduzidas dentro das empresas que geralmente custam mais caro.

Fonte:

• Info
• Base 2
• uTest
• Grupo certificacoesqualidadetestedesoftware

Quando se pensa em segurança da informação o que lembramos de imediato é a segurança dos dados e informações em rede de computadores e internet. Não obstante, devemos lembrar que os computadores de grande porte (Mainframes) estão localizados em prédios e que estes podem ser acessados fisicamente por pessoas não autorizadas, que transportam equipamentos com grande capacidade de armazenamento e de pequeno porte, tais como: pen drive, DVD, CD, HD, relógios, máquina fotográfica digital, e podem conseguir armazenar dados e informações sigilosos e valiosos para a organização.

Um breve histórico de controle de acesso físico:

Desde os primórdios o homem se preocupou em defender-se do intemperismo e dos animais ferozes, abrigando-se em cavernas. Com essa atitude, a caverna representou a delimitação de uma área de acesso (perímetro), ou seja, ele poderia selecionar e controlar quem poderia acessar aquele ambiente, desde animais até outros indivíduos do grupo ou comunidade.

Na Idade média, surgiram a construção das fortalezas ou dos castelos para abrigar certa comunidade ou reinado. Como havia invasões constantes entre os reinos motivado pelas conquistas, para se denfender-se, o rei contruia um fosso ao redor do castelo, onde havia uma ponte movediça para acessá-lo. Desta maneira, mantinha o controle de acesso e servia como barreira às invações.

Durante o século XVIII, as indústrias eram protegidas contra invasores que eram contra o sistema de produção em larga escala e a longas horas de trabalho, colocando muros altos, cercas de arames e seguranças armados.

No mundo moderno, na era da informação e do conhecimento,  as ameaças físicas em ambiente protegidos continuam, porém aliadas a estratégias mais apuradas como a engenharia social e tecnologia de ponta, como armazenamento de dados e informações de tamanho diminuto.

Mas o que é controle de acesso físico?

É um conjunto de medidas de segurança que controla o acesso das pessoas nos ambientes, com ou sem equipamentos. Esse controle é realizado por restrições de acesso e registros que servem como barreira adicional ao acesso lógico.

Atualmente o controle de acesso em ambientes empresarias são realizados através portarias que contam com sistemas informatizados que geram registros de imagem e som. Desta forma, temos as mais variadas opções de controle e barreiras físicas de aceso disponíveis no mercado, tais como: portas blindadas, detectores de metais, cancelas, catracas com leitura biométricas, fechaduras com senhas, com leitura de cartão e/ou leitura biométrias, fechaduras eletro-magnéticas, portões elétricos, cerca elétrica, guaritas e como apoio, sensores e câmeras que geram registros dos acessos.

Com a motivação dos invasores em burlar os sistema de acesso, há a evolução da tecnologia. Nos dias atuais, os sistemas mais sofisticados é a leitura biométrica, ou seja, utilizar os traços singulares do corpo humano como chave de acesso. Assim, surgiu a biometria, com leitura de voz, face, digitais, íris e vasos sangüíneos das mãos.

Controle de acesso nas empresas de TI

Nas empresas de TI os ativos são representados pelas pessoas, tecnologias e ambiente, além dos processos internos. O principal alvo ou o maior desafio é a acessibilidade física não autorizada a sala do Mainframe. É possível instalar diversas barreiras de acesso a sala do mainframe, a começar pelo estabelecimento do perímetro em relação a sala, controle de acesso dos visitantes, fornecedores e colaboradores.

A regra é simplres, quanto menor a quantidade de acesso ao prédio, melhor e mais fácil será o controle de acesso, com menos dispêndio de capital de investimento em tecnologias. É possível adotar catracas com leitura de biométria digital para colaboradores, fornecedores e visitantes; caso haja possibilidade de investimentos, a criação um banco de imagens dos visitantes e fornecedores pode ser desenvolvido na portaria, gerando maior controle e rastreabilidade dos acessos, inclusive sendo integrado aos relatórios facilita a rastreabilidade.

Portas com fechaduras biométrias e/ou leitura de cartão por proximidade, para ter acesso as dependências onde está localizado a sala do Mainframe, é uma boa solução.

E finalmente, para se ter acesso a sala do Mainframe, fechadura com leitura biométria de digitais e íris, com a instalação de câmeras e sensores, e software compatível para gerar relatório.

Compatibilizar disponibilidade financeira com a disponibilidade de tecnologia no mercado, é o segredo de se obter a melhor relação custo/benefício para controle de acesso numa empresa de TI.

É bom lembrar que deve ter um estudo prévio do histórico de acesso sem permissão na empresa, com ou sem intenção de ter acesso a informações. Divulgar o máximo possível a importância da segurança da informação para os colaboradores (treinamento de conscientização), inclusive com ênfase na engenharia social. E lembre-se do velho ditado popular: “o seguro morreu de velho!”.

O Andar do Bêbado

Acredito que um dos motivos que me atraem para o Gerenciamento de Projetos é o seu envolvimento com outras áreas do conhecimento, tais como a Matemática, Estatística e Psicologia. Sei que não precisamos ser experts em todas, mas é bem interessante saber um pouco de cada uma. Devido a isso, busquei entender melhor o papel do Acaso na gestão de projetos, envolvendo assim conceitos de aleatoriedade, probabilidade e ciências humanas. Utilizei como base o livro O Andar do Bêbado, de Leonard Mlodinow, fazendo algumas analogias com Gerenciamento.

Primeiramente, uma síntese do Andar do Bêbado: os eventos aleatórios nos empurram continuamente em uma direção e depois em outra. Muito semelhante a uma pessoa voltando para casa após umas doses de Wisky.

Queremos estar no controle. Sentimos medo quando não estarmos. Experimente dar a direção do carro para a sua namorada . Por isso, antes e durante a execução do projeto, nós documentamos, registramos, analisamos dados históricos, tentando saber como o projeto irá acabar. O que, na maioria dos casos, é impossível. Segundo Mlodinow, o sucesso ou fracasso se deve muito mais ao acaso do que somos capazes de perceber. Mas isso não significa que habilidade e conhecimento não são fundamentais. Devemos tirar nossas próprias conclusões conforme as circunstâncias; porém, entendendo o funcionamento da aleatoriedade, ao menos nossas conclusões não seriam ingênuas.

“A questão é que se os eventos são aleatórios, nós não estamos no controle, e se estamos no controle dos eventos, eles não são aleatórios”

Isso induz dizer que, apesar de possuir dados e informações sobre o projeto, o GP não deve apenas se ater a eles. O GP deve usar sua percepção para definir que caminho seguir. E como ele faz isso? Imaginando! Para Faraday, a percepção humana não é uma conseqüência direta da realidade (fatos e dados), e sim um ato imaginativo. Todos os envolvidos devem estar cientes que antes de julgar se o GP e sua equipe estão fadados ao sucesso ou fracasso, listar critérios claros de avaliação bem como se o período é suficiente para a devida conclusão. Bem, isso talvez fosse o indicado, mas sabemos que normalmente não é o que acontece.

Não é minha intenção justificar o fracasso do projeto ou empreendimento, mas apenas informar que o mesmo é influenciado por forças que não podemos controlar. Afinal, trabalhamos com seres humanos e conseqüentemente com uma série complexa de eventos, e não com leis definidas e fundamentais, como na Física.

“Depois do evento, naturalmente um sinal se torna perfeitamente claro; conseguimos ver que desastre ele sinalizava… Mas, antes do evento, ele é obscuro e repleto de significados conflitantes”
Roberta Wohlstetter

Por conseguinte, devemos estar conscientes da existência de eventos aleatórios e quanto essa aleatoriedade interfere em nossos projetos, tirando assim proveito dela.

Link interessante relacionado ao assunto:
http://info.abril.com.br/noticias/rede/gestao20/gestao/processos-metodologias-e-o-cerebro-humano/

The Drunkard’s Walk

Criticidade de Testes de Software
Este item é utilizado dentro do processo de teste de software para dois fins:

• Definir a prioridade de execução de testes no caso de não haver disponibilidade da realização de todos os casos de testes definidos;

• Servir como instrumento para cálculo da severidade dos defeitos encontrados.

A tabela a seguir propõe os níveis de criticidades. Nela, a criticidade é representada por uma pontuação, que quanto mais alta mais prioritária e crítica se torna. Cabe ressaltar que o agrupamento aqui proposto é variável de acordo com as características de cada projeto de software.

Tabela de classificação de criticidade.

A lista de criticidades pode ser utilizada na composição do “Plano de Testes” para classificar os casos de teste.

Letalidade de Testes de Software

A letalidade dos casos de teste se baseia na classificação contida na tabela de classificação de letalidade de falhas, na qual quanto mais alta a pontuação mais grave é a natureza do defeito.

Severidade de falhas de Testes de Software

O cálculo da severidade de uma falha se dá pela formula:
Severidade = ( Criticidade + Letalidade )

Há algum tempo, tive a oportunidade de trabalhar como Analista de Vendas em uma empresa de Uniformes Profissionais. E para quem trabalha com vendas, sabe que a cobrança é diária:

- Precisamos bater a meta!
- Temos que vender mais!
- Qual a porcentagem de aumento com relação ao mês passado?
- Por que tal dia vendeu pouco?
- E por aí vai…

Sem falar que muitas vezes a comissão do vendedor depende do volume de vendas e superação da meta.

Atualmente, o software de vendas que se preze gera todo o tipo de gráfico e estudo. Afinal, estamos na era do Data Warehouse, Business Intelligence, CRM, etc. Mas, para você, mero mortal , que cuida de sua loja, de seu comércio, de seu departamento, que deseja saber como anda a venda diária e compará-la com o planejado, proponho aqui um exemplo simples de acompanhamento, feita no nosso famoso Excel.

Acompanhamento Diário - Vendas

A única necessidade será inserir o valor de sua meta mensal, fazendo a planilha distribuir diariamente (coluna Planejado Base) o quanto você precisa vender cada dia para atingir sua meta. O próximo passo é lançar o valor realizado de vendas diariamente e fazer o acompanhamento, motivando sempre sua equipe caso a tendência não seja tão positiva assim.

Você poderá acompanhar:

- Tendência a Realizar: Valor final, caso você continue vendendo o que planejou diariamente.
- Planejado Futuro: a partir da última data de lançamento, quanto você deverá vender diariamente para atingir sua meta no final.
- Gráfico: Acompanhamento Acumulado e Acompanhamento diário.

Acompanhamento Acumulado

Acompanhamento Diário

É claro que existe uma infinidade de maneira de estudar o que os números indicam, esse foi apenas uma delas.

Download da Planilha

Até aproxima.

Forte Abraço!

Post publicado simultaneamente em Blog Renato Borges.

Na disciplina de controle de projetos, tem a parte na qual o GP deve acompanhar a evolução das realizações das tarefas e lançar os custos das mesmas, bem como seu progresso. Nesse acompanhamento várias perguntas podem ser respondidas:

- O projeto ultrapassou o custo?
- O prazo está ok?
- O que já foi gasto realmente corresponde ao que foi realizado?
- Será necessário algum aditivo ao projeto?
- Houve algum desvio crítico?
- As entregas estão sendo realizadas no prazo?

Algumas das respostas devem ser verificadas junto a equipe de desenvolvimento, no qual o GP deve filtrar a melhor maneira de passá-las para o cliente, propondo alternativas, caso algo errado tenha ocorrido.

Gráfico Acompanhamento de Custo do Projeto

De acordo com alguns conhecimento adiquiridos nessa área, fiz uma planilha simples para acompanhamento do custo do projeto. A primeira representa algumas estimativas de custo dos recursos do projeto. Já na segunda aba é representado a distribuição dos custos nas mais diversas fases do mesmo (Ver figura). Lembro que o GP que decide o intervalo de acompanhamento: diário, semanal, quinzenal ou mensal.

Planilha de Acompanhamento de Custo do Projeto

As informações lançadas na planilha devem ser a mais real possível. Ela não deve ser utilizada somente para informações boas, mas também para as ruins. Sem máscara! Isso permitirá reduzir erros nas estimativas futuras. Por isso, muita atenção com o que o gráfico representa.

Em 21/09/2010:

1) Adicionei o campo de Estimativa de Custo final, logo abaixo da linha Schedule Performance Index, visando saber qual será a estimativa de custo final do projeto de acordo com o “Cost Performance Index“. O Cálculo é feito através da divisão do “Acumulado Planejado” pelo “Cost Performance Index”, distribuindo esse cálculo por toda a linha de Estimativa de Custo Final.

Download da Planilha

Desde já agradeço aos inúmeros e-mail através do Qualidade Manaus e pelo Blog Renato Borges.

Obter qualidade nos processos e produtos de engenharia de software não é uma tarefa trivial.  São vários os fatores que dificultam atingir os objetivos de qualidade.  No entanto, nada mais decepcionante do que produzir software que não satisfaça as necessidades dos clientes.  Grande volume de recursos são gastos, mas,  em muitos casos,  ocorre uma grande frustação por parte dos clientes, face a forma final apresentada pelo software encomendado.   Nossa  experiência indica que muitos desses problemas são derivados da falta de atenção para a tarefa de definir e acompanhar a evolução dos requisitos durante o processo de construção de software.
Reportaremos resultados iniciais sobre o conceito de  baseline de requisitos que toma por base as necessidades dos clientes, serve de referência para o desenvolvimento de software e está em constante evolução.  Acreditamos que ao atacarmos a definição e gerência de requisitos estaremos colaborando de maneira fundamental para a qualidade geral do software.

Leia o Artigo na íntegra
Texto de: Julio Cesar Sampaio do Prado Leite
http://www.inf.puc-rio.br/~julio