A Problemática da Avaliação e da Maturidade nos Processos de Desenvolvimento de Aplicações Informáticas Ilídio Antunes

Transcrição

1 INFORMAÇÃO & INFORMÁTICA A Problemtica da Avaliação e da Maturidade nos Processos de Desenvolvimento de Aplicações Informticas Ilídio Antunes Professor da UTL/ISEG 1 INTRODUÇÃO O estudo, anlise e avaliação dos sistemas de informação (SI) actuais obriga-nos a um enquadramento imediato das tecnologias de informação (TI) Nem sempre foi assim, mas actualmente estudar sistemas de informação sem estudar as tecnologias que os suportam é o mesmo que estudar economia e gestão sem considerar os mercados, as unidades económicas (UE) e os recursos: visão, estratégia, capital, trabalho, energia e tecnologia As tecnologias orientadas para os sistemas de informação, vulgarmente identificadas com a informtica, como ciência que se ocupa do tratamento automtico da informação, são hoje da mxima importância para o êxito de qualquer UE, seja ela de grande ou de pequena dimensão, de âmbito internacional ou regional As TI, como tratamento automtico da informação, desempenham seis funções fundamentais (ou processos) relativamente ao SI de cada UE: Captação processo de compilação dos dados referentes às actividades e negócios da unidade económica para tratamento posterior (inputs) Processamento processo de conversão, anlise, computação e síntese dos dados captados; transformação dos dados em informação e produção de outputs Gestão processo de organização e controlo do dados e da informação (números, registos, textos, grficos, imagens e sons) Armazenamento processo de salvaguarda dos dados e da informação em suportes adequados para posterior utilização (bandas e disquetes magnéticas, discos rígidos, CD-ROM s e microfichas) Recuperação processo de localização e cópia dos dados e da informação para reposição, (re)processamento e difusão Transmissão processo de envio dos dados e da informação de um local para outro através de redes A evolução dos SI e das TI leva-nos a reflectir sobre o papel da auditoria na problemtica da avaliação dos tratamentos automticos da informação no âmbito das actividades e negócios das UE, quer sobre a qualidade e a consistência dos programas aplicacionais, os chamados pacotes de software, quer sobre o próprio processo de produção das aplicações informticas, mais conhecido como processo de desenvolvimento de aplicações (PDA) Pretende-se com este trabalho abordar os principais desempenhos da auditoria (estudo, exame, avaliação e controle) no âmbito do processo de desenvolvimento de aplicações (PDA), também designado como processo de desenvolvimento de software (PDS), e descrever as acções fundamentais para avaliar e incrementar a maturidade nesse processo, quer em ambientes de software houses, quer nos próprios departamentos de organização e informtica das unidades económicas N º

2 2 AVALIAÇÃO DA MATURIDADE NO PROCESSO DE DESENVOLVIMENTO DAS APLICAÇÕES (PDA) O que entendemos por avaliação, por maturidade e qual o objectivo da avaliação da maturidade no processo de desenvolvimento das aplicações? A avaliação de qualquer ser, coisa ou sistema, é um acto isolado ou contínuo para determinar (estimar) o valor inerente (intrínseco) ou estimativo (extrínseco) desse ser, coisa ou sistema Como acto isolado não tem qualquer interesse para os nossos objectivos Como acto contínuo, cíclico e sistemtico, consideramos que é fundamental para as unidades económicas por representar as funções de exame, avaliação e controlo das suas actividades e negócios Nesta perspectiva consideramos que estamos perante um sistema de avaliação fundamentado num conjunto coerente de normas, metodologias e técnicas, universalmente aceites e aplicadas aos sistemas de controlo interno, e que visam examinar e avaliar, global e integradamente, todas as funções, sistemas, actividades e negócios inerentes às unidades económicas [Antunes93, Antunes99] Este sistema de avaliação visto numa perspectiva contínua, cíclica e sistemtica de funções de exame, diagnóstico e avaliação, com recomendações (terapias) para corrigir anomalias e insuficiências do objecto avaliado, deve-se fundamentar numa base metodológica que integre a infra-estrutura dos conhecimentos científicos da gestão e da tecnologia com o conceito e a substância do valor semiológico, como significação relativa dos vrios sintomas colhidos numa observação clínica A utilização da metfora da semiologia como estudo, exame, diagnóstico e avaliação dos sintomas e sinais de anomalias, insuficiências e disfunções à volta da maturidade no processo de desenvolvimento das aplicações só faz sentido se aplicada ciclicamente e a dois níveis e momentos distintos [Antunes93, Antunes99]: 1 º Avaliação geral e global 2 º Avaliação específica e especializada A maturidade pode ser definida como o grau ou capacidade de qualquer ser, coisa ou sistema, desempenhar totalmente as suas funções de forma harmoniosa, com a mximo de eficcia, eficiência e economicidade e de acordo os padrões estabelecidos Assim, pode-se considerar a maturidade do processo de desenvolvimento de aplicações como o grau ou a capacidade desse processo produzir e manter pacotes de software de forma harmoniosa, com a mximo de eficcia, eficiência e economicidade e de acordo com padrões previamente estabelecidos, quer os de âmbito específico do departamento de organização e informtica da unidade económica (UE), quer os de âmbito universal (normas e princípios geralmente recomendados pelas instituições relacionadas com a produção de software), nomeadamente: qualidade, adequacidade, portabilidade, manutenção e renovação Ou seja, o produto final (aplicação devidamente instalada e em exploração) deve ir ao encontro das necessidades e expectativas dos utilizadores; deve ser construído no menor tempo possível e a menor custos; sem defeitos, ou com o menor número possível, e de fcil manutenção Esta perspectiva implica o respeito por um vasto conjunto de normas e princípios, nomeadamente nas seguintes reas: Planeamento e arquitectura do sistema de informação da unidade económica Normativos no âmbito da gestão da função organização e informtica Gestão do projecto e enquadramento das necessidades e expectativas dos utilizadores Especificações funcionais e orgânicas (anlise, desenho, programação) Testagem, certificação, instalação, exploração e manutenção Contratos, prazos e preços A avaliação da maturidade de qualquer ser, coisa ou sistema, visa determinar as suas características e desempenhos, nomeadamente os seus pontos fortes e fracos em plena actividade Esta avaliação e respectivas recomendações vai possibilitar a implementação de um plano de acções para corrigir as anomalias e insuficiências 46 N º

3 INFORMAÇÃO & INFORMÁTICA detectadas Nesta perspectiva, a avaliação da maturidade do processo de desenvolvimento de aplicações permite criar as condições necessrias para estabelecer uma linha de orientação programtica para melhorar o próprio processo de desenvolvimento e simultaneamente a qualidade global do produto final, as aplicações informticas Existem alguns modelos para avaliar a maturidade do processo de desenvolvimento de aplicações informticas ou da qualidade do software, nomeadamente: o SEL (Software Engineering Laboratory) e o QIP (Quality Improvement Paradigm) da NASA (National Aeronautics and Space Administration) [Basili94, Basili95], o SPR (Software Produtivity Resarch) [Janes94] e o CMM (Capability Maturity Model) do Software Engineering Institute [Olson89] Neste trabalho adoptamos como modelo de referência o CMM (Capability Maturity Model) por se basear no conceito de estgio ou de nível de maturidade que evolui para o nível seguinte a partir da resolução dos problemas, omissões e insuficiências diagnosticados Esta situações são identificveis através de um conjunto de características associadas aos problemas a resolver e às recomendações sobre a sequência das acções a efectuar para o processo de desenvolvimento de aplicações daquela unidade económica transitar do nível de maturidade presente para o nível seguinte 3 BREVE DESCRIÇÃO DO MODELO CMM (CAPABILITY MATURITY MODEL) O modelo CMM nasceu no seio do campus universitrio da Carnegie Mellon University, graças aos trabalhos desenvolvidos pelo Software Engineering Institute, criado em 1984, para dar respostas às necessidades do Departamento de Defesa dos EUA Este modelo é baseado numa estrutura que enquadra e avalia a maturidade do processo de desenvolvimento de software nas unidades económicas Assim, é um modelo que permite a aplicação de métodos de avaliação e de assessoria nos processos de produção e de manutenção de software, quer em ambientes de software houses, quer nos próprios departamentos de organização e informtica das unidades económicas O modelo CMM fundamenta-se numa hierarquia de cinco níveis de maturidade no processo de desenvolvimento de software Cada um dos níveis é constituído por um conjunto de reas chave do processo (ACP) A cada ACP est associado um conjunto de objectivos e prticas chave (OPC) que possibilitarão a realização desses objectivos Ao alcançar todos os objectivos das ACP de um determinado nível completa-se esse nível, o que permite passar ao nível de maturidade seguinte A figura 1 e o quadro 1 procuram ilustrar o modelo CMM Logicamente, e de acordo com a figura e o quadro, os níveis 1 e 5 devem ser analisados com enquadramentos específicos, próprios e à imagem do nascimento de um sistema (processo inicial = primeira fase = nível 1) e da maturidade mxima desse sistema (processo optimizado = fase final = nível 5) Nível X $&31tYHO[ ACP1 ACP2 ACPx 23&$&3[ OPC1 OPC2 OPCn Figura 1 Relações no modelo CMM N º

4 Quadro 1 Níveis, ACP`s e Maturidade no modelo CMM 1,QLFLDO,QLWLDO Inexistência de processo de desenvolvimento de software (PDS) ou com PDS não formalizado 1 Os objectivos e prticas chave, OPC, das reas chave do processo, ACP, não são apresentados por estarem fora da razão de ser deste trabalho O PDS não existe ou é imprevisível, caótico e pobre. A falta de planeamento, de gestão de projectos e de gestão das configurações são as causas bsicas deste nível. A sua implementação é suficiente para se passar para o nível seguinte. Ï 5HSHWtYHO 5HSHDWDEOH 2.1 Gestão de requisitos 2.2 Planeamento do projecto 2.3 Supervisão do projecto 2.4 Gestão de subcontratos 2.5 Garantia da qualidade 2.6 Gestão da configuração Neste nível o PDS é intuitivo e dependente de indivíduos chave. É disciplinado, mas medíocre. A passagem para o nível seguinte ser alcançada através de melhores revisões e testes do software, de uma definição mais rigorosa do PDS e da implementação do trabalho de equipas por projectos. Ï 'HILQLGR 'HILQHG 3.1 Definição do PDS 3.2 Funcionamento do PDS 3.3 Programa de formação 3.4 Gestão integrada do PDS 3.5 Engenharia de produção 3.6 Coordenação intergrupo 3.7 Revisões O PDS est claramente definido e institucionalizado; é qualitativo, consistente e de maturidade média. As reas a desenvolver para evoluir para o nível seguinte são a avaliação e revisão do PDS e a implementação de valores quantitativos e qualitativos no planeamento. Ï *HULGR 0DQDJHG 4.1 Gestão qualitativa do PDS 4.2 Gestão da qualidade do software Neste nível de maturidade, o PDS e as aplicações são avaliadas e controlados qualitativamente, através de observações e anlises específicas. A gestão é previsível e de maturidade suficiente para evoluir para o nível seguinte através do alinhamento do planeamento e da arquitectura do SI com as aplicações, do melhor desempenho do PDS e da gestão estatística. Ï 2SWLPL]DGR 2SWLPL]HG 5.1 Prevenção de defeitos 5.2 Gestão da evolução tecnológica 5.3 Gestão da evolução do PDS Neste nível de optimização, a maturidade é boa, o PDS est sujeito a aperfeiçoamento e avaliação contínua com o enquadramento e teste de ideias inovadoras e de novas tecnologias. 48 N º

5 INFORMAÇÃO & INFORMÁTICA O CMM é deste modo um modelo evolutivo de avaliação, que possibilita a elaboração de um conjunto de recomendações sobre a sequência das acções a efectuar pela unidade económica para que esta possa transitar de nível de maturidade no seu processo de desenvolvimento de aplicações A determinação do nível de maturidade obedece a um algoritmo simples, baseado na percentagem de respostas afirmativas para o nível que se pretende atingir Se o nível for atingido, executase o algoritmo para o nível superior e assim sucessivamente até um dos níveis não ser atingido A avaliação para determinar o nível de maturidade dever ser feita através de diagnósticos produzidos pelo auditor a partir das respostas a questionrios estruturados em conjuntos de perguntas qualitativas (do tipo booleano = sim ou não) e/ou quantitativas As perguntas devem estar associadas ao nível de maturidade pré-estabelecido, podendo existir perguntas de maior significado e importância para melhor determinar o nível real em presença As respostas deverão ser validadas por entrevistas e revisão de normas e documentos mais significativos A aplicação desta metodologia dever passar por um conjunto de acções, nomeadamente: Elaboração dos questionrios Estudo e anlise das respostas Entrevistas e revisão de documentos Elaboração do diagnóstico Elaboração de conclusões e de recomendações com plano de acção e medidas concretas a desenvolver para incrementar o nível de maturidade Apesar da sua importância e significado para os auditores, o modelo CMM apresenta algumas limitações e fraca cobertura aos grandes problemas que se colocam quotidianamente, quer nos grandes departamentos de organização e informtica das unidades económicas (planeamento e controlo dos projectos de desenvolvimento de software, manutenção das aplicações face às das necessidades dos utilizadores, etc ), quer em ambientes de software houses (marketing, gestão da subcontratação, apoio a clientes, etc ) Neste sentido, o auditor deve reforçar o modelo CMM com alguns métodos específicos e em conformidade com as características da UE no seu processo de desenvolvimento e de manutenção das aplicações 4 PONTOS DE REVISÃO E AVALIAÇÃO NAS FASES DO DESENVOLVIMENTO DE APLICAÇÕES INFORMÁTICAS Pelo formação e experiência organizacional e tecnológica de que dispõe e pelas funções que exerce, o auditor deve ser o principal agente na avaliação da maturidade do processo de desenvolvimento de aplicações (PDA) Para isso deve ser envolvido nos pontos de revisão e avaliação das principais fases e etapas da concepção e desenvolvimento do software aplicacional [Antunes93, Antunes99] Nesses pontos de revisão e avaliação o auditor deve fazer um estudo e anlise do nível de maturidade CMM presente, classificando o processo de desenvolvimento de acordo com a escala de níveis deste modelo (inicial, repetível, definido, gerido, optimizado) Assim, o auditor pode diagnosticar o estado em que se encontra o PDA e recorrer às recomendações do modelo CMM sobre a sequência de acções a efectuar para se poder passar para o nível seguinte Deste modo consegue formular e recomendar um conjunto de acções para incrementar a maturidade do processo de desenvolvimento de aplicações O quadro 2 apresenta a nossa perspectiva dos pontos de revisão e avaliação e dos recursos humanos a envolver nas diferentes fases e etapas do PDA A compreensão e o entendimento deste quadro é da mxima importância para o desempenho da auditoria informtica Como o auditor participa activamente nos pontos de revisão e avaliação existentes ao longo das fases do PDA, pode aplicar questionrios equivalentes ao modelo CMM e construi-los com questões específicas a cada fase, de forma a avaliar a maturidade em cada fase e a recomendar as melhores formas e acções para incrementar a maturidade no PDA N º

6 Quadro 2 Pontos de Revisão e Avaliação no Processo de Desenvolvimento de Aplicações [Antunes99] )$6(6 Plano, Anlise e Arquitectura Concepção e Desenho do Sistema Construção do Software Testagem do Sistema Implementação (Instalação e Arranque) Evolução (Manutenção e Renovação) (7$3$6 1. Afectação de: Normas Planeamento Metodologia Ferramentas 2. Modelização 3. Decomposição 4. Revisão 5. Programação 6. Testes 7. Reprogramação 8. Testes globais e integrados 9. Revisão 10. Formação de 11. Adaptação dos postos de trabalho 12. Aceitação 13. Reanlise 14. Reprogramação '( 5(9,6 2( $9$/,$d 2 $SUHFLDomRJOREDO GRSURMHFWR $SUHFLDomR $YDOLDomRH UHFRPHQGDomR 9HULILFDomR 'HVHPSHQKR $YDOLDomR 9HULILFDomR 'HVHPSHQKRV $YDOLDomR 9HULILFDomR $YDOLDomRILQDOH FHUWLILFDomR $SUHFLDomR 'HVHPSHQKRV 15. Renovação do sistema $YDOLDomR 5HFRPHQGDomR 5(& $126$ (192/9(5 Auditores Responsveis do DOI Auditores Auditores Auditores Sistema de decisão 50 N º

7 INFORMAÇÃO & INFORMÁTICA As actividades da fase 0 são da mxima importância para os projectistas e para o êxito final dos projectos É nesta fase que os grandes cenrios e objectivos são definidos, nomeadamente o plano do projecto, a anlise e a arquitectura do sistema a construir Assim, a apreciação global do projecto é determinante para o êxito do mesmo e garantir um grau de satisfação elevado do utilizador final Na avaliação desta fase, procede-se a uma apreciação global, avaliando-se neste ponto a adequabilidade das metodologias e das ferramentas, as normas instituídas e o planeamento efectuado, que deve descrever os recursos envolvidos e as fases delineadas, com a distribuição em cronograma das actividades a desenvolver A afectação de recursos deve atender à curva da sua distribuição no tempo, de forma a minimizar turbulências e grandes desvios de custos e de calendrio Os responsveis pela gestão do SI e das TI devem assumir a responsabilidade do projecto Na fase 1 avalia-se a concepção do sistema, a arquitectura e a adequação dos modelos à realidade das actividades e negócios a representar no sistema, bem como a documentação produzida para estas componentes Esta é uma fase fundamental e a sua avaliação e consequentes recomendações, em caso de necessidade, são muito importantes para que se passe de seguida à fase de construção de software A fase 2, desenvolvimento do software, é a fase mais específica e técnica e própria do departamento de organização e informtica, não sendo necessrio envolver o auditor nesta avaliação Tipicamente, esta fase envolve muitos recursos (peopleware, mquina e tempo); tantos mais e maiores quanto menor for a qualidade de concepção e de planeamento nas fases anteriores A fase 3, referente à testagem do sistema, deve envolver a auditoria e os utilizadores finais para uma melhor e mais completa avaliação da adequacidade do software aos requisitos pretendidos, nomeadamente a qualidade do desempenho, a efectivação das validações e dos controlos, a segregação, e os impactos noutras aplicações e no próprio SI A avaliação desta fase 3, feita através de testes globais e integrados, é fundamental para garantir a qualidade e consistência da aplicação e fundamentar as correcções a fazer no software e na estrutura de dados ou até na própria arquitectura da aplicação Bem com para determinar o momento de passagem à fase seguinte, fase de instalação e arranque A fase de implementação (instalação e arranque) da aplicação deve garantir a adaptação dos postos de trabalho e a formação dos utilizadores, bem como o nível de aceitação da aplicação e a adequação da mesma A certificação, se for necessria, dever-se- fazer nesta fase Após a implementação considera-se que a aplicação j é um sistema aceite, onde o utilizador final j assumiu as responsabilidades inerentes ao seu bom desempenho A partir deste fase entra-se no processo de exploração da aplicação É normal surgir alguns problemas e algumas necessidades por imaturidade e inconsistência da própria aplicação, dos processos de negócio e até das próprias pessoas envolvidas Estes problemas e necessidades terão de ser analisados e resolvidos consoante a gravidade e a abrangência dos mesmos Entra-se na fase de evolução e manutenção da aplicação Nesta última fase aplica-se geralmente uma de duas formas de resolução para os problemas e necessidades que vão surgindo, em função da gravidade e da amplitude dos mesmos: Problemas e necessidades normais e menores no âmbito específico da aplicação Est-se perante a problemtica da manutenção tradicional que procura responder a pequenos problemas com pequenas alterações no software Esta prtica quase quotidiana de pequena manutenção, o ciclo dos remendos, é para dar resposta aos pedidos utilizadores e aos pequenos bugs e para fugir à renovação da aplicação, o que implicaria um novo projecto Problemas e necessidades de grande amplitude e significado no SI e nos processos de negócio Neste caso avança-se para a renovação da aplicação, o que pode obrigar à criação de um novo projecto para uma nova arquitectura de programas e de dados ou para uma profunda (re)anlise e (re)programação do software Em qualquer caso volta-se praticamente fase 0 do ciclo do problema à manutenção no desenvolvimento de aplicações [Antunes93, Antunes99] N º

8 5 CONCLUSÃO A avaliação da maturidade no processo de desenvolvimento das aplicações (PDA) deve ser feita através de acções de auditoria interna nos diferentes pontos de revisão e avaliação do desenvolvimento de projectos ou de manutenção de software aplicacional, quer se esteja no âmbito da inovação, da renovação ou da manutenção Esta avaliação da maturidade deve ter como base um modelo do tipo CMM (Capability Maturity Model) de forma a identificar e examinar os processos, as metodologias e as ferramentas aplicadas na bancada de concepção, desenho e construção de software, nomeadamente: Razão de ser dos projectos, custos e impactes previsionais com o seu desenvolvimento e implementação Plano de avaliação e de revisão dos pontos fortes e fracos do projecto: caderno de encargos ; estudos previsionais dos impactes no sistema de informação e nos processos de negócio; turbulência na arquitectura e estrutura geral das diferentes aplicações e dos dados (bases e ficheiros) Metodologias e ferramentas de planeamento e controlo de todas as fases do projecto, inerentes ao ciclo do problema à manutenção Metodologias e ferramentas de produção e testagem de software Plano de instalação e arranque da aplicação e da formação dos utentes Plano de aferição do grau de aderência e de satisfação dos utentes da aplicação n 6 REFERÊNCIAS [Antunes93] Antunes, Ilídio, Evolução e Tendências da Auditoria Informtica nas Unidades Económicas (tese de doutoramento) UTL/ISEG, 1993 [Antunes99] Antunes, Ilídio, Auditoria e Controlo de Sistemas de Informação (suporte da disciplina do curso de pós-graduação em Sistemas e Tecnologias de Informação para as Organizações) UTL/ISEG, 1999 [Basili94] Basili,V, e Green, S, Software Process Evolution at the SEL IEEE Software 11, 4 (Julho, 1994), 58 [Basili95] Basili,V, e Outros, SEL s Software Process-Improvement Program IEEE Software 12, 6 (Novembro, 1995), 83 [Janes94] James, C, Assessment and Control of Software Risks Yourdon Press Computing Series, Prentice-Hall, Inc, Englewood Cliffs, New Jersey, USA, 1994 [Olson89] Olson, T, e Outos, Conducting SEI- Assisted Software Process Assessments, CMU/SEI- 90-TR-7, Software Engineering Institute, Carnegie Mellon University, Pittsburg, Pennsylvania, USA, N º