Normas de Qualidade nos Processos de Desenvolvimento de Software

Transcrição

1 Normas de Qualidade nos Processos de Desenvolvimento de Software 1ª edição: Maio/2006 RICARDO J. MACHADO (DEng, MSc, PhD, MOEng, MIEEE) URL: /~rmac Departamento de Sistemas de Informação

2 Sumário 1. Normas em TIC (ICT standards) 2. Normas Abertas (open standards) 3. Qualidade no Software (software quality) 4. Melhoria do Processo (process improvement) 2

3 1. Normas em TIC (1/5) Definição de norma [Jacobs 2000] Questões... publicly available sempre desejável? procedures, rules and requirements cobre todo o tipo de objecto alvo? normas emitidas somente por legitimate and recognized authority não será limitativo?... 3

4 1. Normas em TIC (2/5) Definição de norma [ISO/IEC 2004] Questões... deixa dúvidas em relação ao tipo de organizações que pode emitir normas parece aplicar-se a áreas como o direito 4

5 1. Normas em TIC (3/5) Definição de norma [De Vries 1999] Questões... resolve, aparentemente, todos os problemas das definições anteriores será? 5

6 1. Normas em TIC (4/5) normas devem ser vistas como soluções para determinados problemas a norma estabelece uma correspondência entre as propriedades das entidades correlacionadas (solução e problema) uma entidade pode ser uma pessoa ou grupo de pessoas um objecto, um acontecimento, uma ideia ou um processo uma combinação dos anteriores 6

7 1. Normas em TIC (5/5) desta forma, uma norma pode estabelecer diferentes tipos de correspondências: entre coisas e coisas (ex. fichas e tomadas) entre pessoas e coisas (ex. normas de segurança a ou de ergonomia) entre pessoas e pessoas (ex. procedimentos para sistemas de gestão) em normas TIC, pelo menos uma das entidades está relacionada com sistemas (ou partes) de TIC normas TIC que relacionam coisas com coisas são normas técnicas normas TIC que contemplam entidades do tipo pessoa terminologia e simbologia modelos de referência, frameworks e linguagens interfaces HCI e ergonomia biometria e indentificação pessoal 7

8 2. Normas Abertas (1/9) sistemas abertos (open systems) arquitectura aberta (open architecture) norma aberta (open standard) código aberto (open source) está na moda falar em aberto, mas o que significa isso? ou o que deveria significar? 8

9 2. Normas Abertas (2/9) Proto-história da confusão a X/Open Company, Ltd., fundada em 1984, propõe-se desenvolver uma variante aberta e normalizada do UNIX para permitir que as 10 empresas accionistas consigam competir no mercado com o sistema operativo proprietario dos mainframe da IBM em 1996, a X/Open funde-se com a Open Software Foundation (OSF) para dar origem ao The Open Group o The Open Group Architecture Framework (TOGAF) constitui uma arquitectura e métodos para o planeamento e implementação de sistemas de informação organizacioanais 9

10 2. Normas Abertas (3/9) Pré-história da confusão a coincidência nos nomes da Open Software Foundation (OSF) e da Free Software Foundation (FSF) poderá estar na génese da confusão entre software aberto e código livre a Open Software Foundation (OSF) pretendia desenvolver uma variante aberta e normalizada do UNIX a Free Software Foundation (FSF) pretendia promover a utilização, cópia, estudo e modificação livre de software todo o software licenciado pela FSF, através de licenças GNU, é do tipo código aberto (open source) 10

11 2. Normas Abertas (4/9) código aberto (open source) ) designa um processo aberto de desenvolvimento de software por vezes, as iniciativas de código aberto recorrem a normas abertas de sistemas operativos, de interfaces ou de ferramentas de desenvolvimento o propósito de uma iniciativa de código aberto é o suporte à melhoria contínua nua do software uma arquitectura aberta (open architecture) ) refere-se a um sistema cujas interfaces internas e/ou externas estão definidas por normas abertas e/ou implementadas à custa de soluções de software aberto 11

12 2. Normas Abertas (5/9) norma aberta visão dos criadores 12

13 2. Normas Abertas (6/9) norma aberta visão dos implementadores os implementadores pretendem competir no mercado em pé de igualdade com os seus competidores directos os implementadores consideram que uma norma é aberta quando a sua implementação não implica custos directos se adequa ao mercado que pretendem em que se pretendem posicionar não torna obsoletas as suas implementações anteriores não impõe inovações consequentes não favorece os outros competidores 13

14 2. Normas Abertas (7/9) norma aberta visão dos utilizadores os utilizadores pretendem obter o máximo retorno possível no investimento (ROI) feito na aquisição de uma implementação de uma determinada norma os utilizadores consideram que uma norma é aberta quando a implementação cumpre as imposições legais inerentes à sua utilização a utilização de novas implementações da norma não implica descontinuidade (por falta de compatibilidade) com versões anteriores existem diversas implementações distintas da mesma norma realizadas por diferentes entidades a implementação é suportada ao longo de todo o ciclo de utilização 14

15 2. Normas Abertas (8/9) norma aberta visão da Comissão Europeia 15

16 2. Normas Abertas (9/9) critérios rios desejáveis para normas abertas open meetings: : reuniões abertas a todos os interessados consensus: : decisões por consenso dos participantes due process: : aprovação faseada open world: : aplicabilidade generalizada no espaço open IPR: : propriedade intelectual liberalizada open change: : alterações à norma cumprem critérios rios anteriores open documents: : documentação intermédia e versões finais agilmente disponibilizadas open interface: : interface não escondida e não controlada open use: : cumprimento de directivas de utilização não danosa ongoing support: : suporte da norma até que o interesse do utilizador cesse 16

17 3. Qualidade no Software (1/15) Definições de qualidade A totalidade dos aspectos e características de um produto ou serviço que suportam a sua capacidade de satisfazer as necessidades explícitas e implícitas. [ISO/IEC 1994] A conformidade com os requisitos de desempenho, os requisitos funcionais explicitamente declarados, as normas de desenvolvimento explicitamente documentadas e, finalmente, as características implícitas esperadas em todo o software desenvolvido de uma forma profissional. [Pressman 1997] 17

18 3. Qualidade no Software (2/15) Definições de qualidade (cont.) As organizações de software devem observar e analisar os seus produtos e processos de desenvolvimento. Devem sintetizar e empacotar o que aprenderam de modo a compreender o que tem que ser feito para melhorar os seus esforços os de desenvolvimento de software. [Basili 2004] Se estamos sérios sobre a qualidade, eu recomendo que [Pressman 1997]: se requeira planos detalhados e realistas do trabalho se realizem medições e se gira a qualidade se estabeleça a como meta organizacional que cada produto tenha melhor qualidade que o anterior se planeie a realização de trabalho de qualidade 18

19 3. Qualidade no Software (3/15) Observações os requisitos explícitos são a origem incontroversa da medição das características de qualidade do produto final as normas documentadas permitem definir orientações e critérios rios de validação de todo o desenvolvimento e avaliar o desempenho do processo os requisitos não explicitamente declarados têm um papel muitas vezes esquecido na satisfação do cliente e, por isso, devem também m ser considerados na medição das características de qualidade do produto 19

20 3. Qualidade no Software (4/15) Modelo de McCall [McCall et al.,, 1977] contempla três grupos de características de qualidade segundo uma perspectiva externa do software relaciona as características externas com as características internas do produto propõe métricas subjectivas e indirectas para estimar os factores de qualidade em análise 20

21 3. Qualidade no Software (5/15) Modelo de McCall 21

22 3. Qualidade no Software (6/15) Modelo GQM (Goal/Question/Metric) [Basili e Rombach 1988] explicita o porquê da recolha de dados inerente à aplicação de métricas como forma de caracterizar a semântica recomendável para a interpretação das medições exemplo: G1: dentro de 1 ano, reduzir a duração dos testes em 10%, mantendo o nível de defeitos Q1.1: qual é a duração média dos testes? Q1.2: quanto tempo é gasto no teste dos componentes, de integração e final? Q1.3: Qual é o nível de defeitos final? M1.1.1: duração média dos testes... 22

23 3. Qualidade no Software (7/15) Modelo GQM 23

24 3. Qualidade no Software (8/15) Modelo Nance e Arthur [Nance e Arthur 2002] todas as métricas propostas estão relacionadas com os princípios pios que orientam o processo de desenvolvimento e contribuem para o cumprimento de um determinado objectivo ao nível do projecto de software abordagem sistémica para examinar a qualidade do produto e do processo contrasta com os 2 modelos de qualidade anteriores (McCall e GQM) 24

25 3. Qualidade no Software (9/15) Modelo Nance e Arthur 25

26 3. Qualidade no Software (10/15) Normas ISO/IEC JTC1/SC7 ( sc7.org/) ISO committee responsible to develop ISO standards in the area of Software and Systems Engineering WG 2 System software documentation WG 4 Tools and environment WG 6 Evaluation and metrics WG 7 Life cycle management WG 9 Software integrity WG 10 Process assessment WG 12 Functional size measurement WG 13 Process measurement framework WG 17 ODP - Enterprise language WG 18 Quality management WG 19 Open distributed processing and modelling languages WG 20 Software Engineering Body of Knowledge WG 21 Software assessment management 26

27 3. Qualidade no Software (11/15) Normas IEEE S2ESC ( IEEE software and systems engineering standards committee WG 730 Software Software Quality Assurance Plans WG 829 Software Test Documentation WG Dictionary of Measures to Produce Reliable Software WG 1008 Software Unit Testing WG 1012 Software Verification and Validation WG 1016 Software Design Descriptions WG 1028 Software Reviews WG 1045 Software Productivity Metrics WG 1062 Software Acquisition WG 1074 Developing Software Life Cycle Processes WG Various CASE tool 27

28 3. Qualidade no Software (12/15) WG 1644 Software Nomenclature - Software Naming Conventions for Application Software WG 1648 Establishing and Managing Software Development Efforts Using Agile Methods WG 2063 Software and System Life Cycle Processes - Requirements Engineering WG Industry Implementation of International Standard ISO/IEC 12207:1995 Standard for Information Technology-Software life cycle processes Software Life Cycle Processes WG Software Maintenance WG Software Life Cycle Processes - Risk Management WG Information Technology - Software Engineering - Software Project Management WG Software and Systems Engineering - Guidelines for the Application of ISO 9001:2000 to Computer Software 28

29 3. Qualidade no Software (13/15) Destaque de algumas normas ISO/IEC JTC1/SC7 a norma ISO/IEC 9126:1991 deu origem a duas normas ISO/IEC 9126: 2001 (product quality) define um modelo de qualidade do produto de software pode ser utilizada para identificação de requisitos identificação de crit érios de aceitação para o produto final identificação de crit érios para a garantia da qualidade definir objectivos para os testes do software ISO/IEC 14598: (software product evaluation) define um processo de avaliação fornece orientações para três situações distintas empresas que desenvolvem sw e pretendem melhorar a qualidade empresas que compram sw e pretendem avaliar aquisição empresas que certificam sw de terceiros 29

30 3. Qualidade no Software (14/15) ISO/IEC 9126 Software engineering - Product quality ISO/IEC :20011:2001 Part 1: Quality model ISO/IEC :20032:2003 Part 2: External metrics ISO/IEC :2003 Part 3: Internal metrics ISO/IEC :2004 Part 4: Quality in use metrics ISO/IEC Information technology - Software product evaluation ISO/IEC :19991:1999 Part 1: General overview ISO/IEC :2000 Part 2: Planning and management ISO/IEC :2000 Part 3: Process for developers ISO/IEC :19994:1999 Part 4: Process for acquirers ISO/IEC :19985:1998 Part 5: Process for evaluators ISO/IEC :2001 Part 6: Documentation of evaluation modules 30

31 3. Qualidade no Software (15/15) Relacionamento entre as normas ISO/IEC 9126 e

32 4. Melhoria do Processo (1/16) Visão holística do processo de software definição dos processos: especificação das actividades, procedimentos, infra-estruturas e recursos necessários institucionalização do processo: transferência do conhecimento (aprendizagem) para os recursos humanos responsáveis pela execução visão dos resultados: recolher dados que permitam avaliar o desempenho do processo e que possam ser utilizados para elaborar acções de melhoria 32

33 4. Melhoria do Processo (2/16) Visão holística do processo de software 33

34 4. Melhoria do Processo (3/16) ISO/IEC 12207:1995 Information technology - Software life cycle processes primeira norma internacional a apresentar, de uma forma detalhada, os processos, tarefas e actividades do ciclo de vida do software foi emendada em 2002 e 2004 para alinhar com a ISO/IEC processos propostos organizados em três camadas: primários, rios, de suporte e organizacionais 34

35 4. Melhoria do Processo (4/16) ISO/IEC

36 4. Melhoria do Processo (5/16) Paradigma do Benchmarking se não sabemos onde estamos, um mapa não vai ajudar [Humphrey 1989] assenta na premissa de que o processo para desenvolver um produto tem um grande impacto na qualidade final do produto baseia-se na identificação de organizações excelentes, numa área, e na documentação das suas boas práticas exemplos de modelos de melhoria de processo: CMM, SPICE e ISO/IEC 15504, SPIRE, ISO 9001:

37 4. Melhoria do Processo (6/16) CMM - Capability Maturity Model ( CMM desenvolvido pelo SEI em 1993 deu origem ao CMMI em 2000 baseia-se num referencial de maturidade que fornece orientações efectivas para um programa de melhoria do processo utiliza um questionário de maturidade que permite caracterizar a capacidade da organização a melhoria do processo de software é feita em pequenos passos evolutivos e não em inovações revolucionáriasrias 37

38 4. Melhoria do Processo (7/16) Os 5 níveis de maturidade do CMM 38

39 4. Melhoria do Processo (8/16) Desafios chave/níveis veis de maturidade no CMM 39

40 4. Melhoria do Processo (9/16) Perfil de maturidade CMM 40

41 4. Melhoria do Processo (10/16) ISO/IEC Information technology - Process assessment ( resultou do trabalho da WG10 do ISO/IEC JTC1/SC7, na altura designado de software process improvement and capability determination (SPICE) originalmente publicada como um relatório rio técnico organizado em 9 partes (ISO/IEC TR 15504:1998) após alinhamento com ISO/IEC e com ISO 9001:2000 passou a norma formal, tendo, também, m, dado origem a duas emendas na ISO/IEC

42 4. Melhoria do Processo (11/16) ISO/IEC como norma formal actualmente publicada como norma formal em 5 partes ISO/IEC :20041:2004 Part 1: Concepts and vocabulary ISO/IEC :2003 Part 2: Performing an assessment ISO/IEC :2004 Part 3: Guidance on performing an assessment ISO/IEC :20044:2004 Part 4: Guidance on use for process improvement and process capability determination ISO/IEC :20065:2006 Part 5: An exemplar Process Assessment Model CT128 do IIMF publicará, via IPQ, durante 2006 as 4 primeiras partes em Português como normas NP ISO/IEC 42

43 4. Melhoria do Processo (12/16) Abordagem da ISO/IEC fornece uma abordagem estruturada para a avaliação dos processos com um dos seguintes objectivos compreender o estado dos processos para melhoria do processo global de software determinar a adaptação dos processos para uma necessidade particular determinar a adaptação dos processos de outra organização para um determinado contrato enquanto que no CMM, cada nível define KPAs (key process areas), na ISO/IEC são definidas PAs (process atributes) 43

44 4. Melhoria do Processo (13/16) Os 6 níveis de maturidade da ISO/IEC

45 4. Melhoria do Processo (14/16) Relacionamento entre as partes da ISO/IEC

46 4. Melhoria do Processo (15/16) Eficácia cia da melhoria do process há uma evidência significativa que mostra que um projecto de melhoria do processo de software com sucesso resultará em melhorias na qualidade do produto e no valor do negócio mas há também m evidência que grande parte destes projectos falha no atingir dos seus objectivos porque será? 46

47 4. Melhoria do Processo (16/16) Eficácia cia da melhoria do process [Kolmel e Eisenbiegler 2000] 47

48 Bibliografia Key Jacobs. Standardization Processes in IT: Impact, Problems and Benefits of User Participation,, Braunschweig: Vieweg, Key Jacobs. Advanced Topics in Information Technology Standards and Standardization Research,, Volume 1, Idea Group, De Vries. Standardization: A Business Approach to the Role of National Standardization Organizations,, Dordrecht, Kluwer AP, International Organization for Standardization (ISO) & International Electrotechnical Comission (IEC). ISO/IEC 8402: Quality Management and Quality Assurance - Vocabulary,, International Organization for Standardization (ISO) & International Electrotechnical Comission (IEC). ISO/IEC Guide 2: Standardization and Related Activities General Vocabulary,, 8th edition, Michael Schmidt. Implementing the IEEE Software Engineering Standards, SAMS Publishing, IEEE Software Engineering Standards,, IEEE Press, Guide to the Software Engineering Body of Knowledge (SWEBOK),, IEEE Computer Society Press,