“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.
Contra 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.
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
April 28, 2009 at 3:38 pm
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)
May 11, 2009 at 11:02 pm
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
May 11, 2009 at 11:02 pm
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
May 19, 2009 at 2:22 pm
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