“Software em produção” e “erro” uma relação que não combina

Imagine que você comprou uma TV em cores e ao ligá-la (pela primeira vez) a imagem só aparece em branco e preto.

Imagine que você comprou um carro bi-combustível e ao abastecê-lo (pela primeira vez) com álcool o carro para de funcionar.

Em ambos os casos, nós consumidores voltamos à loja e solicitamos que o produto seja trocado.

Agora imagine a seguinte situação: Uma empresa qualquer compra um software, em muitos casos no contrato de compra ele é feito sob encomenda, e ao solicitar o processamento de X, a empresa recebe como resposta Y (isto quando existe o processamento…).

Quais as atitudes tomadas por esta classe de consumidores?

Neste caso a maioria das empresas liga para a “loja” que vendeu o software e relata o problema. Na maioria das vezes, o problema relatado leva tempo demais para ser solucionado.

Você gostaria de comprar uma TV em cores e assistir a imagem em branco e preto por 6 meses?

Infelizmente, a garantia da qualidade do software  não é um fator crítico de sucesso para grande parte das “lojas de software”, instaladas no Brasil.

Durante estes últimos 15 anos, cansei de ver software de má qualidade. Veja só algumas das aberrações que já presenciei:

Aberração 1: Que pena, não consegui trocar a senha do root.  

if (($_REQUEST[“login”]  == “admin”) && ($_REQUEST[“senha”]  == “1234”)) {

    header(“Location: index_autenticado.php”);

} else {

    header(“Location: index.php?mensagem=Login%20invalido”);

}

Aberração 2: Feita em Clipper.

O programador indexava todos os arquivos todas as vezes que o software era carregado.

Aberração 3: Veja que maneira inusitada de atribuir valores em variáveis. Imagine o restante do código.

x = 5 + 3;

Pior, em todas as aberrações relatadas, o software estava em produção (isto é rodando). Ah… que tal realizarmos um concursos de aberrações? Enviem-nas nos comentários, prometo publicar um post com todas elas.

A questão neste caso é a qualidade ou a falta dela.

Sommerville deixa claro que a qualidade de software é algo complexo. Classicamente, o principal atributo de qualidade de software tem sido de que o produto desenvolvido deve processar, de maneia correta, todas as funcionalidades especificadas. Além disso, um software deve atender de maneira satisfatória os requisitos não funcionais, por exemplo: facilidade de uso.

Para delinear as minhas prerrogativas sobre o tema em questão, vou partir do princípio que a maioria dos processos de produção de software é composta pelo seguinte conjunto de atividades: levantamento de requisitos, analise de sistemas, projeto de software, implementação, teste, implantação e manutenção (se todas as empresas de software encarassem a atividade de manutenção como melhoria, grande parte do problema estaria resolvido, voltarei a este assunto em um momento oportuno). Saliento, também, que existem diversas técnicas que possibilitam as empresas de produção de software a institucionalizarem o seu processo, uma delas seria a utilização de padrões.

Padrões de processos: São os padrões que definem os processos a serem seguidos durante o desenvolvimento de software. Eles podem incluir definições de especificações, processos de projetos e validação, e uma descrição dos documentos que devem ser gerados no curso desses processos.

Padrões de produtos: São padrões que se aplicam ao produto de software em desenvolvimento. Eles incluem padrões de documentos, como a estrutura do documento de requisitos a ser produzido, padrões de documentação, como um cabeçalho-padrão de comentário para uma definição de classe de objeto, e padrões de codificação, que definem como uma linguagem de programação deve ser utilizada.” (Trecho extraído de Sommerville, Ian. Engenharia de Software. 2003, página 461).

Padrões do processo se alinham com as normas propostas pela IEEE (no final do texto você encontra uma relação destas) e padrões de produtos se alinham com a idéia de padronização de código, por exemplo: java code convention.

A utilização desses padrões requer um pouco de bom senso, ou seja, em algumas vezes devemos customizá-los para que eles compactuem com as particularidades produtivas de nossa empresa. Por exemplo: 1 – posso customizar o java code convention e inserir as particularidades sobre o meu padrão de código.  A IEEE 830-1998, norma que contempla a atividade levantamento de requisitos, define que todo requisito deve ser rastreado durante o processo de software. A concepção desta rastreabilidade (tema de nosso próximo post) será delineada por mim, enquanto empresa. A institucionalização de padrões, e conseqüentemente do processo, requer:

Envolvimento: todos os envolvidos com o processo de software devem participar ativamente da escolha e customização dos padrões.

Evolução: o processo ou o documento criado deve evoluir para atender as necessidades da empresa de produção de software. Lembre-se que a evolução do processo e de seus respectivos artefatos são controlados pela atividade de gestão de configuração.

Ferramenta: é necessário possuir um conjunto básico de ferramentas que facilite a execução das atividades do processo e o preenchimento de seus artefatos.

qualidade-de-processo-e-qualidade-do-produtoContra fatos não há argumentos, a institucionalização de um processo que prima pela qualidade me possibilita construir produtos de qualidade. A qualidade do produto passa, e muito, pela qualidade do processo. A figura ao lado espelha exatamente a relação entre qualidade de processo e qualidade de produto.

Lembre-se que um dos principais atributos de qualidade de software tem sido de que o produto desenvolvido deve processar, de maneia correta, todas as funcionalidades especificadas (requisitos). Na engenharia de software, existe um longo fio condutor entre requisito e produto. Ao garantir a consistência desse fio, você estará garantindo a consistência qualitativa de um produto caracterizado como software.

Por fim, gostaria de registrar que software não foi feito para dar defeito. Garantia de qualidade é o termo que “quebra” a relação delineada no título do post.

J.A.

fabri@femanet.com.br

1465-1998 Adoption of International Standard  ISO/IEC 12119: 1994(E) Information Technology Software  packages Quality requirements  and testing

610.12-1990 IEEE Glossary of Software Engineering Terminology

1490-1998 IEEE Guide Adoption of PMI Standard A Guide to the Project Management Body of  Knowledge

1175.1-2002 IEEE Guide for CASE Tool Interconnections Classification and Description

1233-1998 IEEE Guide for Developing System Requirements Specifications

1362-1998 IEEE Guide for Information  Technology  System Definition Concept of  Operations (ConOps) Document

830-1998   IEEE Recommended Practice for  Software Requirements  SpeciÞcations

1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

1062-1998 IEEE Recommended Practice for Software Acquisition

1016-1998 IEEE Recommended Practice for Software Design Descriptions

2001-2000 IEEE Recommended Practice for the Internet Web Site Engineering, Web Site Management, and Web Site Life Cycle

1044-1993 IEEE Standard ClassiÞcation for  Software Anomalies

982.1-1998 IEEE Standard Dictionary of  Measures to Produce Reliable Software

1061-1998 IEEE Standard for a Software Quality Metrics Methodology

1220-1998 IEEE Standard for Application and Management of the Systems Engineering Process

1320.2-1998 IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X97 (IDEFobject)

1074-1997 IEEE Standard for Developing  Software Life Cycle Processes

1320.1-1998 IEEE Standard for Functional Modeling Language-Syntax and Semantics for IDEF0

1517-1999 IEEE Standard for Information Technology Software Life Cycle Processes Reuse Processes

1420.1-1995 IEEE Standard for Information Technology Software Reuse Data Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM)

828-1998  IEEE Standard for Software ConÞguration Management Plans

1540-2001 IEEE Standard for Software Life Cycle Processes Risk Management

1219-1998 IEEE Standard for Software Maintenance

1045-1992 IEEE Standard for Software Productivity Metrics

1058-1998 IEEE Standard for Software Project Management Plans

630-1998  IEEE Standard for Software Quality Assurance Plans

1028-1997 IEEE Standard for Software Reviews

1228-1994 IEEE Standard for Software Safety Plans

829-1998  IEEE Standard for Software Test  Documentation

1008-1987 (R1993) IEEE Standard for Software Unit Testing

1063-2001 IEEE Standard for Software User Documentation

1012-1998 IEEE Standard for Software Verification and Validation

1420.1b-1999 IEEE Trial-Use Supplement to IEEE Standard for Information Technology Software Reuse Data Model for Reuse Library Interoperability: Intellectual Property Rights Framework

14143.1-2000 Implementation Note for IEEE Adoption of ISO/IEC 14143-1:1998 Information Technology Software Measurement  Functional Size Measurement  Part 1: Definition of Concepts

12207.1-1996 Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207) Standard for Information Technology

12207.0-1996 Industry Implementation of International Standard ISO/IEC 12207: 1995

1462-1998 Information Technology  – Guideline for the evolution and selection os CASE tools

1420.1a-1996 Supplement to IEEE Standard for Information Technology  Software Reuse Data Model for Reuse Library Interoperability: Asset Certification Framework

1012a-1998 Supplement to IEEE Standard for Software VeriÞcation and Validation: Content Map to IEEE/EIA 12207.1-1997

4 Responses to ““Software em produção” e “erro” uma relação que não combina”

  1. A afirmação final diz tudo: “software não é feito para dar defeito”, portanto, garantia não deve fazer parte do “pacote” comprado.
    Se não pode dar defeito, temos que ter em mente que para produzir um produto com qualidade e sem defeitos, temos que ter um processo bem definido, como você ilustrou muito bem na figura sobre o processo.
    Quem define o processo é o gerente de projetos, portanto, vemos aqui como o principal ator responsável pelo produto final é o gerente.
    Ele deverá além de definir processos, definir os padrões (codigo, produto, etc) adotados.
    Então, quem “garante” o produto, é o gerente.

    Quanto as aberrações, peguei um codigo indiano que abria conexoes com o banco de dados dentro de um loop e as finalizava dentro to try do mesmo. Acontece que sempre estava dando erro, caíamos no catch, a conexao não era finalizava.
    Depois de 500 linhas processadas tinhamos 500 conexoes com o banco de dados.
    Tudo caía!
    (Não, não era usado a conexao via Servidor de App, era uma conexao simples direto no código fonte)

  2. Não resisti em deixar de enviar minha contribuição. Achei isto em um sistema em Clipper também em produção:

    IF FACA = GARFO
    EXIT
    ELSE
    LOOP
    ENDIF

  3. Não resisti em enviar minha contribuição. Achei isto em um sistema em Clipper também em produção:

    IF FACA = GARFO
    EXIT
    ELSE
    LOOP
    ENDIF

  4. gustavomanso Says:

    Uma coisa que temos que ter em mente é que todo software tem falhas. Por isso não podemos garantir nada.
    Claro que podemos ter qualidade no processo, e é um grande passo para a qualidade do produto, mas não garante absolutamente nada.

    Eu acho que a “culpa” por falta de padronizações, processos bem definidos, etc não é somente do gerente. O bom desenvolvedor propõe boas soluções. Desenvolvedores têm que ter iniciativa. E isso é a grande reclamação dos gerentes, que muitas vezes não têm idéia da importância de itens já citados.

    Quanto à POG (aberrações), já vi uma tabela do bd chamada “Marcos”. Isso mesmo! Não precisa dizer mais nada né!

    []’s

    Gustavo manso

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: