Qualidade de Software Ltda

A Sociedade Brasileira de Computação (SBC), organizou um catálogo nacional dos cursos de computação, que está disponível em https://www.sbc.org.br/cnc/.

Neste site pode-se fazer pesquisas por instituição, que estão classificadas em públicas ou privadas, ou fazer pesquisas por nome do curso por estados da federação, sendo que os cursos estão classificados em diversos níveis, como graduação, especialização, mestrado, etc, e categorizados como gratuítos ou pagos.

É um bom lugar para se pesquisar, se você está buscando formação acadêmica na área de computação. Hoje em dia, há diversas opções de bons cursos na área de computação, e as vezes esses cursos podem ainda estarem perto da sua casa, ou perto do seu trabalho.

Se você já encontrou o curso desejado e a instituição em que irá estudar, uma última dica é pesquisar no site do IMEP como está a avaliação da instituição de ensino desejada. Consulte o IGC (Índice Geral dos Cursos da Instituição) disponível em http://www.inep.gov.br/areaigc/

Agora você tem um catálogo de cursos oferecidos e um indicador de qualidade dos cursos. Boa escolha!

Ao longo dos anos tenho estudado e praticado a modelagem de software com UML. Participei de vários foruns de discussão, li vários artigos acadêmicos, artigos do Gartner Group, medotologias como o RUP e livros. Muitos livros.

E como acredito que a teoria na prática é diferente, pratiquei muito do que estudei sobre modelagem seja no desenvolvimento de novos sistemas ou na manutenção de sistemas existentes. Os resultados? Nem sempre animadores…

Geralmente chegava ao final da modelagem com pressão sobre o prazo de entrega do projeto, e a pergunta que sempre ouvia era: quanto do código já está pronto? Eu ainda não tinha código pronto, “apenas” os modelos. E dá-lhe pressão de prazos…

Quando chegava à etapa de codificação e passava as especificações e modelos ao programador, era uma chuva de dúvidas geradas diariamente pelo programador, o que acaba atrasando, ou pelo menos dando a sensação de atraso no projeto.

Quando recebia o código pronto, pasmem; ele geralmente não correspondia aos modelos especificados nem as decisões de arquitetura tomadas.

Esse preambulo nada animador é para dizer que “sim há luz no fim do túnel” . Estou começando usar em projetos experimentais adaptações do processo ICONIX, o qual propõe o modelo da figura abaixo para se trilhar o caminho dos casos de uso ao código.

Esse processo está dividido nas seguintes etapas:

1. Requisitos

2. Análise e projeto preliminar

3. Projeto detalhado

4. Codificação

Entre as diversas técnicas propostas pelo ICONIX, destaco duas delas que tenho utilizado com sucesso durante a modelagem: iniciar o projeto com a análise de domínio (antes dos casos de uso) e a análise de robustez (antes dos diagramas de sequência)

Caso se interesse nesse assunto, recomendo adquirir o livro Use Case Driven Object Modeling with UML, Theory and Pratice. Os autores são Doug Rosenberg e Matt Stephens

Para os estudandes, praticantes e demais interessados no tema “Teste de Software”, aqui vai relação de livros e sites para consultas:

Bibliográficas

Paton, Ron. Software Testing. Sams Publishing. 2005.

H. Kan, Stephen. Metrics and Models in Software Quality Engineering. Second Edition. Addison Wesley. 2002

D. Everett, Gerald. McLeod Jr, Raymond. Software Testing Testing Across the Entire Software Development Life Cycle. IEEE Press. 2007

Eduardo Delamaro, Marcio. Carlos Maldonado, José. Jino, Mario. Introdução ao Teste de Software. Campus. 2007.

A. Menascé, Daniel. A.F.Almeida, Virgilio. Planejamento de Capacidade para Serviços na Web. Campus. 2003.

U.Smith, Connie. G. Williams, Lloyd. Performance Solutions A Practical Guide to Creating Responsive, Scalable Software. Addison-Wesley. 2002

Unhelkar, Bhuvan. Process Quality Assurance for UML-Based Projects. Addison-Wesley. 2003.

Kaner, Cem. Bach, James. Lessons Learned in Software Testing. John Wiley Consumer. 2001.

Falk, Jack. Quoc Nguyen, Hung. Kaner, Cem. Testing Software. John Wiley Professional. 1999.

Webgráficas

http://www.sqe.com/Default.aspx – Software Quality Engineering-Software Testing Conferences, Software Training & Certification

http://www.testingexcellence.com/ – Software Testing Tutorials and Articles – Test Techniques, Test Plan, Test Results…

http://www.spinsp.org.br/ – SPIN – Software Process Improvement Network

http://www.qaforums.com/ – Software Testing and Quality Assurance On-Line Forums

http://www.testingeducation.org/ – Center for Software Testing Education & Research

http://www.bstqb.org.br/ – Brazilian Software Testing Qualifications Board

http://www.istqb.org/ – International Software Testing Qualifications Board

http://www.alats.org.br/ – Associação Latino-Americana de Teste de Software

http://www.satisfice.com/kaner/ – Cem Kaner’s Blog

Um dos grandes desafios do desenvolvimento de um bom software, certamente está em se ter um processo consistente para se capturar as necessidades do cliente, traduzí-las em requisitos e a partir daí definir os casos de uso. A partir deste ponto, como chegar ao início da codificação?

Elaborei um mapa conceitual do que entendo ser uma abordagem prática de análise e projeto de software, contemplando os seguintes artefatos:

• Documento de Visão
• Modelo de Caso de Uso
• Protótipo de Telas e Especificação de Interface Visual
• Diagrama de Classes de Análise e de Projeto
• Documento de Arquitetura do Software
• Diagramas de seqüência
• Modelo de Dados

Com essa abordagem creio que se obtém um modelo de análise e projeto consistente para o início da codificação. Veja o mapa conceitual dessa abordagem na figura abaixo. O que você acha a respeito dessa abordagem?

Escrever casos de uso parece coisa simples, mas ao não se concentrar nos princípios fundamentais que orientam a elaboração de um bom caso de uso, acaba-se cometendo erros. Conheça os sete erros mais comuns:

 1. Escrever requisitos funcionais em vez de cenários de utilização

Os casos de uso são escritos em termos sobre o que o sistema deve fazer. Cenários de uso descrevem ações dos usuários e as respostas obtidas do sistema.
É importante que o texto do caso de uso permita claramente identificar como o sistema realizará um determinado comportamento. Deve-se manter uma clara distinção entre as descrições das ações (voz ativa) e os requisitos funcionais (voz passiva)
Exemplos:

Caso de uso: Editar conteúdo do carrinho de compras
(incorreto) - Fluxo Básico – Se o cliente modificar a quantidade de um item no carrinho de compras, e pressionar o botão de atualização, o sistema irá armazenar a nova quantidade, e exibir a novo custo para o item selecionado.
(correto) - Fluxo Básico – Na página do carrinho de compras, o cliente modifica a quantidade de um item e então pressiona o botão atualizar. O sistema armazena a nova quantidade e exibe o novo custo para o item selecionado.

2. Descrever atributos e métodos em vez de cenários de uso

Os casos de uso não devem conter muitos detalhes de telas e também estar livres de detalhes de campos de telas. Se você, por exemplo, estiver escrevendo um caso de uso e estiver relacionando vários campos da tela no texto de caso de uso, pare! O objetivo aqui é descrever o que o sistema deverá fazer, e não como será feito.
Exemplos:

Caso de uso: Processar Pedido

(incorreto) O operador do estoque certifica-se que os itens  relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema executa o método mudança de estado do pedido, para mudar o pedido para o estado de atendido, e então chama o método alterar quantidade em estoque, para cada um dos itens do pedido
(correto) O operador do estoque certifica-se que os itens relacionados no pedido conferem com o itens físicos. O operador passa o código de barras na leitora da estação. O sistema muda o estado do pedido, para atendido, e então atualiza a  quantidade em estoque, para cada um dos itens do pedido

3. Escrever casos de uso de forma muito resumida

O objetivo de um caso de uso é descrever todos os detalhes da ação do usuário e da resposta do sistema. É melhor que o texto seja o mais completo possível, do que ser um texto muito resumido que omite esses detalhes
Deve-se lembrar também que os casos de uso servirão para a elaboração do manual do usuário. Assim é melhor pecar por excesso do que por falta de detalhes no manual do usuário.
Exemplos:

Caso de uso: Criar conta do cliente

(incorreto) O cliente entra com a informação solicitada. O sistema valida as informações e cria uma nova conta para o usuário
(correto) O cliente entra com o seu nome, e-mail, e a senha (duas vezes) e então pressiona o botão criar conta. O sistema certifica que o cliente forneceu dados válidos e então cria uma nova conta usando esses dados. O sistema conduz o cliente à página principal do sistema.

4. Desconectar-se completamente da interface do usuário

Um dos fundamentos da notação de casos de uso, é que os desenvolvedores concordem em desenhar o sistema sob o ponto de vista dos usuários. Não é possível praticar isso, sem ser especifico as quais ações serão realizadas pelos usuários nas respectivas telas.

Entretanto não é necessário entrar em detalhes de campos ou detalhes cosméticos sobre a tela (trabalho do protótipo). O importante é citar pontos da interface que permite ao usuário dizer para o sistema fazer algo.

Exemplos:

Caso de uso: Procurar item

(incorreto) O cliente digita o nome do animal e então submete uma requisição de pesquisa. O sistema recupera detalhes importantes sobre cada animal e então exibe uma lista de animais.
(correto) O cliente digita o nome do animal na página de pesquisa e então pressiona o botão procurar. O sistema recupera detalhes importantes sobre cada animal, então o sistema exibe uma lista de animais em página de resultados da pesquisa.

5. Evitar explicitar o nome dos objetos de fronteira

Objetos de fronteira são objetos que os atores irão interagir. Exemplos – janelas, caixa de diálogos, menus, etc. Na diretriz de detalhar a navegação do usuário, é necessário dar nomes aos objetos de fronteira no texto do caso de uso

Os nomes desses objetos serão posteriormente úteis nas próximas fases do desenho do sistema

Exemplos:

Caso de uso: Acompanhar pedidos recentes

(incorreto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias. O cliente solicita detalhamento de um pedido. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura. O cliente retorna para a lista de pedidos, quando ele finalizou a leitura dos detalhes do seu pedido.
(correto) O sistema recupera e exibe os pedidos que o cliente solicitou nos últimos 30 dias, e exibe esses pedidos na página de acompanhamento de pedidos. Cada registro possui um numero de pedido (em forma de link) O cliente seleciona um link. O sistema recupera e exibe o conteúdo do pedido, apenas no modo de leitura na página de detalhamento do pedido. O cliente pressiona OK e retorna para a página de acompanhamento de pedido.

                           6. Descrever apenas as interações do usuário e esquecer as respostas do sistema

A narrativa de um caso de uso deve ser orientada por respostas a eventos, ou seja, “O sistema faz isto quando o usuário faz aquilo” O caso de uso deve capturar o que ocorre em decorrência a ação do ator: criação de registros em tabelas, validação de entrada de dados do usuário, mensagens de erros, etc.

O texto do caso de uso deve descrever os dois lados do diálogo entre o ator e o sistema, e todo o comportamento que se está buscando descobrir, ocorre do lado do sistema neste diálogo. Deixar a resposta do sistema de fora, significa ignorar o comportamento do sistema

Exemplos:

Caso de uso: Editar conteúdo do carrinho de compras

(incorreto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. Então o cliente pressiona o botão de continuar comprando

(correto) Na página do carrinho de compras, o cliente modifica a quantidade de um item do carrinho de compras, e então pressiona o botão de atualização. O sistema armazena a nova quantidade, calcula e exibe o novo custo para tal item. Então o cliente pressiona o botão de continuar comprando.

7.Omitir texto para os fluxos alternativos

Apesar dos fluxos básico serem mais fáceis de se identificar, não significa que se deva deixar de fora os fluxos alternativos. Geralmente os fluxos alternativos importantes só são descobertos na fase de codificação e depuração.

Nesta ocasião, o programador tende a encontrar uma solução que lhe seja mais conveniente, o que não é saudável para o projeto

Exemplos:

Caso de uso: efetuar logon

(incorreto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema conduz o cliente para a página inicial.
(correto) O cliente entra com a sua identificação e senha, e então o cliente pressiona o botão de log-in. O sistema valida as informações contra os dados da conta do usuário e então conduz o cliente para a página inicial

A comunidade de software livre tem ao longo dos anos influenciado a indústria de software tradicional, no sentido de forçá-la a oferecer alguma versão dos seus produtos para uso sem custo. Empresas grandes como a IBM já adotaram essa abordagem de ofertar uma versão livre de alguns de seus softwares pagos.

Para a modelagem de software utilizando UML tenho usado para fins acadêmicos o Visual Paradigm Community Edition, que é uma versão sem custo e com algumas limitações em relação à versão paga, como por exemplo, só poder criar um diagrama UML de cada tipo sem que apareça a marca d’água da empresa nos diagramas. Uma outra restrição é a de não ter uma funcionalidade que permita o desenho da interface gráfica (elaboração de protótipos de telas)

Essa versão suporta todos os diagramas da UML 2.1, permite a descrição detalhada de requisitos, análise textual dos requisitos para identificação de classes, análise através de cartões CRC e diversas outras funcionalidades relacionadas à etapa de projeto de software.

O Visual Paradigm Community Edition pode ser obtido a partir do endereço http://www.visual-paradigm.com/product/vpuml/communityedition.jsp

Se é de uma ferramenta para modelagem UML que você procura, vale a pena instalar essa versão e testar suas funcionalidades, antes mesmo se for o caso, de partir para a compra de uma versão paga

Nos últimos anos tenho trabalhado bastante com a utilização da técnica de caso de uso tanto para validação das funcionalidades com o usuário, quanto para apoiar a etapa de análise e projeto do software visando um desenvolvimento orientado a casos de uso e que resulte num conjunto de especificações do software que possa ser construído por um programador.

A questão que trago aqui é a que muitos autores recomendam que a descrição do caso de uso deva ser genérica, independente de tecnologia ocultando assim detalhes de implementação e no extremo da abstração, a descrição fica até desassociada da interface gráfica.

Tenho visto que quando se adota essa abordagem, a descrição do caso de uso acaba tendo pouca utilidade, só servindo muitas vezes para validar as funcionalidades de software com o usuário, e mesmo assim com algumas limitações. Para a etapa de análise onde se deseja identificar as classes, suas propriedades e comportamentos, a descrição do caso de uso se torna abstrata, ambígua e incompleta. Daí decorre um problema: ela não ajuda na análise, não é atualizada e daí em diante a análise e o projeto seguem sem as descrições dos casos de uso. Perde-se portanto um importante instrumento para dirigir a analise o projeto e os testes do software.

Penso que ao decidir orientar o desenvolvimento por casos de uso, e isso é muito forte, as descrições de caso de uso devam sim ser detalhadas, escritas na voz ativa, de forma clara e sem ambigüidades. Deve-se escrever os casos de uso mão só pensando no cliente, mas também como eles irão ser úteis na fase de análise de projeto do software. Não esquecer também que um caso de uso fica bem mais preciso quando escrito a partir de alguns esboços da interface gráfica.

Veja esses dois exemplos para um caso de uso RESERVAR VEÍCULO (para um sistema de locadora de veículos). Qual descrição lhe parece mais adequada tanto para a validação pelo cliente, quanto para orientar a análise, o projeto e o teste do software?

No desenvolvimento de software das grandes empresas as fábricas de software vem desempenhando cada vez mais um papel central. O modelo que se busca e o de delegar a programação para a fábrica e manter o foco das áreas de desenvolvimento na análise do negócio, na especificação do que será construído nos testes e implantação.

Para que um programador possa implementar um código ele necessita de uma boa solicitação, e como ela deve ser ?

Seria apenas um formulário de requisição para a fábrica onde as informações contidas nele não formam uma documentação do software, ou a requisição deve ser a própria documentação de requisito análise e projeto do sistema?

Haverá sempre a tentação de se preencher um formulário rápido e enviá-lo para a fábrica de software, pois elaborar uma documentação adequada de requisitos, análise e projeto dão um bocado de trabalho. Entretanto penso que o melhor seria elaborar uma documentação completa de requisitos e análise e projeto e essa mesma documentação passa a servir a dois propósitos: documentação do software e para envio à fábrica de software

Essa documentação deve certamente conter uma página que oriente claramente o programador sobre o que deverá ser feito para que ele não precise ler todos os documentos de requisitos análise e projeto do início ao fim. Essa página serviria como um índice rápido para que o programador pudesse localizar o tipo de informação que ele necessita na documentação existente.

Penso que esse tipo de abordagem além de atender a dois propósitos contribui ainda para a produção de um código de melhor qualidade. O você, o que pensa sobre esse assunto?

Eu em conjunto com a pró-reitoria de graduação e extensão da Universidade Camilo Castelo Branco, realizaremos o curso acima no mês de agosto de 2009.

O mercado de desenvolvimento de software tem cada vez mais especializado os papéis dos profissionais, separando as etapas de análise das necessidades de negócios, análise e projeto de sistemas, construção do software e testes. Dado a complexidade dos softwares atuais, não se admite mais  que um profissional possa desempenhar todas as etapas do desenvolvimento de um software.

Esse curso dá ao participante uma visão teórica consistente e associada a prática, do processo de especificação de um software utilizando técnicas de orientação a objetos abrangendo as etapas de elicitação de requisitos, análise e projeto do software, capacitando-o a elaborar uma especificação completa de software a ser construído por um programador ou por uma Fábrica de Software.

Conteúdo:
1-Visão Geral da Análise e Projeto de Sistemas com UML
2-Metodologia de Desenvolvimento de Sistemas
3-Mecanismos Gerais da UML
4-Modelagem de casos de uso
5-Modelagem de Classes de Análise
6-Modelagem das Interações
7- Arquitetura do Software
8- Projeto de Interface Gráfica
9 - Mapeamento dos objetos para o modelo relacional

Dados sobre o curso:

INSCRIÇÕES: até 14/08/2009 –
LOCAL: Processo Seletivo – Campus II – Itaquera – São Paulo
INÍCIO DO CURSO: 15/08/2009 – TÉRMINO: 03/10/2009
HORÁRIO: 8h às12h aos sábados
CARGA HORÁRIA: 32 horas – FREQÜÊNCIA: 75%
INVESTIMENTO: R$ 200,00
Mais informações: coord.cstinformatica.sp@unicastelo.br

É sabido que programas de certificação como o CMMI e o seu primo brasileiro MPS.BR tem colocado os olofotes sobre os processos de desenvolvimento. Muitas empresas denvolvedoras de software fizeram o seu trabalho de casa no que tange a definir, documentar, e divulgar seu processo de desenvolvimento. Feito isso o próximo passo e obter um nível de certificação. Obtida a certificação (nível 2, ou nível 3 ou…) aí e só alegria! Almoços de comemoração e muita publicidade, afinal de contas deu um bocado dc trabalho para conseguir a certificação. Mas e a qualidade do produto de software?

Bem, este é o ponto. Certificação do processo, não significa certificação do produto! É aí que mora o perigo! Deitado em berço esplêndido de uma certificação muitas empresas se esquecem da qualidade do produto.

Para garantir que um processo certificado produza um produto de software de qualidade será necessário uma boa equipe de qualidade assegurada, que não só execute checklists, mas faça inspeções em cada etapa do processo de desenvolvimento para se verificar a conformidade entre o que foi especificado e o que foi construído. Um produto de software pode ser produzido e até funcionar e mesmo assim não estar em conformidade com a especificação. Por exemplo, a especificação descreve uma arquitetura lógica de três camadas e o programador implementa em uma camada única. A especificacao descreve um determinado método de acesso e o programador implementa um método diferente, e assim vai sendo comprometida a qualidade do produto mesmo de uma empresa certificada.

E você o que pensa sobre a qualidade do produto de empresas certificadas? Dá para confiar cegamente?