Baixe o app para aproveitar ainda mais
Prévia do material em texto
Indaial – 2020 Segurança aplicada no deSenvolvimento de Software Adriana de Souza Vettorazzo Aline Zanin Evandro Manara Miletto Silvia de Castro Bertagnolli 1a Edição 2020 Elaboração: Adriana de Souza Vettorazzo Aline Zanin Evandro Manara Miletto Silvia de Castro Bertagnolli Revisão, Diagramação e Produção: Centro Universitário Leonardo da Vinci – UNIASSELVI Conteúdo produzido Copyright © Sagah Educação S.A. Impresso por: III apreSentação Caro acadêmico! Estamos iniciando o estudo da disciplina Segurança aplicada no desenvolvimento de Software. Esta disciplina objetiva conhecer os conceitos básicos e fundamentos do segurança e sua aplicação no processo de desenvolvimento de Software, abordando valor da informação e qualidade no processo da construção de Software. Além disso serão destacados os fatores envolvidos na confiabilidade de Software e política de segurança. Recomendamos fortemente que você realize todos os exemplos e exercícios resolvidos para um aproveitamento excepcional da disciplina. Neste contexto, o livro de estudos de Segurança aplicada no desenvolvimento de Software está dividido em três unidades de estudo: Unidade 1 – Valor da Informação e Confiabilidade de Software; Unidade 2 – Segurança e Vulnerabilidades; Unidade 3 – Qualidade de software e política de segurança. Aproveitamos a oportunidade para destacar a importância de desenvolver as autoatividades, lembrando que essas atividades não são opcionais. Elas objetivam a fixação dos conceitos apresentados. Em caso de dúvida na realização das atividades, sugiro que você entre em contato com o seu tutor externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades sem ter sanado todas as suas dúvidas. Sucesso na sua trajetória acadêmica e profissional! Bons estudos! Prof. Nader Ghoddosi IV Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material. Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura. O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo. Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão. Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade. Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos! NOTA V VI Olá, acadêmico! Iniciamos agora mais uma disciplina e com ela um novo conhecimento. Com o objetivo de enriquecer seu conhecimento, construímos, além do livro que está em suas mãos, uma rica trilha de aprendizagem, por meio dela você terá contato com o vídeo da disciplina, o objeto de aprendizagem, materiais complementares, entre outros, todos pensados e construídos na intenção de auxiliar seu crescimento. Acesse o QR Code, que levará ao AVA, e veja as novidades que preparamos para seu estudo. Conte conosco, estaremos juntos nesta caminhada! LEMBRETE VII UNIDADE 1 – VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE ................1 TÓPICO 1 – CONCEITO E VALOR DA INFORMAÇÃO .................................................................3 1 INTRODUÇÃO .......................................................................................................................................3 2 A INFORMAÇÃO NO CONTEXTO ORGANIZACIONAL ..........................................................3 3 CICLO DE VIDA DA INFORMAÇÃO ..............................................................................................5 4 CLASSIFICAÇÃO DAS INFORMAÇÕES ........................................................................................6 RESUMO DO TÓPICO 1..........................................................................................................................8 AUTOATIVIDADE ...................................................................................................................................9 TÓPICO 2 – QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS...............................................................................11 1 INTRODUÇÃO .....................................................................................................................................11 2 CONCEITOS ..........................................................................................................................................11 3 BENEFÍCIOS ..........................................................................................................................................14 4 APLICANDO A QUALIDADE DE SOFTWARE ............................................................................16 RESUMO DO TÓPICO 2........................................................................................................................19 AUTOATIVIDADE .................................................................................................................................20 TÓPICO 3 – QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE ..............................25 1 INTRODUÇÃO .....................................................................................................................................25 2 QUALIDADE DE PROCESSO E QUALIDADE DE PRODUTO ................................................25 3 GARANTIA DA QUALIDADE DE SOFTWARE ...........................................................................27 4 REVISÕES E INSPEÇÕES EM SOFTWARE ...................................................................................28 5 REVISÕES TÉCNICAS FORMAIS ..................................................................................................30 6 DIRETRIZES DE REVISÃO ...............................................................................................................30 7 O CHECKLIST.......................................................................................................................................31 RESUMO DO TÓPICO 3........................................................................................................................33 AUTOATIVIDADE .................................................................................................................................34 TÓPICO 4 – CONFIABILIDADE DE SOFTWARE ...........................................................................37 1 INTRODUÇÃO .....................................................................................................................................37 2 CONFIABILIDADE DE SOFTWARE ...............................................................................................37 3 DIMENSÃO CONFIANÇA ................................................................................................................40 4 APLICAÇÃO DA DIMENSÃO CONFIANÇA ...............................................................................44 LEITURA COMPLEMENTAR ...............................................................................................................46 RESUMO DO TÓPICO 4........................................................................................................................48AUTOATIVIDADE .................................................................................................................................49 UNIDADE 2 – SEGURANÇA E VULNERABILIDADES ................................................................51 TÓPICO 1 – INTRODUÇÃO À SEGURANÇA EM SISTEMAS WEB..........................................53 1 INTRODUÇÃO .....................................................................................................................................53 2 ATRIBUTOS DE SEGURANÇA ........................................................................................................55 Sumário VIII 2.1 AUTENTICIDADE .........................................................................................................................55 2.2 CONFIDENCIALIDADE ................................................................................................................55 2.3 INTEGRIDADE ................................................................................................................................55 2.4 DISPONIBILIDADE ........................................................................................................................55 3 MANUTENÇÃO DA SEGURANÇA ................................................................................................56 3.1 POLÍTICA DE SEGURANÇA DA INFORMAÇÃO (PSI) ..........................................................56 3.2 MECANISMOS ................................................................................................................................56 3.3 CULTURA .........................................................................................................................................56 4 COMPROMETIMENTO DE SEGURANÇA EM SISTEMAS WEB ...........................................57 RESUMO DO TÓPICO 1........................................................................................................................58 AUTOATIVIDADE .................................................................................................................................59 TÓPICO 2 – TIPOS COMUNS DE INVASÃO....................................................................................61 1 INTRODUÇÃO .....................................................................................................................................61 2 INVASÕES COMUNS E PRINCIPAIS TÉCNICAS ......................................................................61 3 ATAQUES DE NEGAÇÃO DE SERVIÇOS .....................................................................................65 3.1 ATAQUE ICMP (INTERNET CONTROL MESSAGE PROTOCOL) ........................................66 3.2 OUTROS ATAQUES DE NEGAÇÃO DE SERVIÇO ...................................................................66 3.3 NEGAÇÃO DE SERVIÇO DISTRIBUÍDA ...................................................................................67 3.4 BUGS EM SERVIÇOS E SISTEMAS OPERACIONAIS ..............................................................68 3.5 FRAGMENTAÇÃO DE PACOTES DE IP ....................................................................................69 4 ATAQUES NA WEB (CLIENTES E SERVIDORES) .......................................................................70 5 ATAQUES A CLIENTES ......................................................................................................................74 6 ATAQUES A SERVIDORES ...............................................................................................................75 RESUMO DO TÓPICO 2........................................................................................................................78 AUTOATIVIDADE .................................................................................................................................79 TÓPICO 3 – CONCEITOS DE SEGURANÇA LÓGICA FÍSICA ...................................................81 1 INTRODUÇÃO .....................................................................................................................................81 2 ELEMENTOS DE SEGURANÇA LÓGICA FÍSICA ......................................................................81 3 MECANISMOS DE DETECÇÃO DE INTRUSÃO FÍSICA .........................................................84 4 FATOR HUMANO E ENGENHARIA SOCIAL ..............................................................................85 5 FATOR HUMANO E ENGENHARIA SOCIALTECNOLOGIAS PARA A .................................. IMPLEMENTAÇÃO DE SEGURANÇA LÓGICA FÍSICA ..........................................................87 5.1 FECHADURAS DE PINOS.............................................................................................................88 5.2 FECHADURAS TUBULARES........................................................................................................88 5.3 FECHADURAS DE COMBINAÇÃO ............................................................................................89 5.4 FECHADURAS DE COMBINAÇÃO ELETRÔNICA .................................................................89 5.5 COFRES .............................................................................................................................................90 5.6 CÓDIGO DE BARRAS ....................................................................................................................90 5.7 CARTÕES COM TARJA MAGNÉTICA .......................................................................................90 5.8 SMARTCARDS.................................................................................................................................91 5.9 RFID ...................................................................................................................................................91 5.10 BIOMETRIA ....................................................................................................................................91 LEITURA COMPLEMENTAR ...............................................................................................................93 RESUMO DO TÓPICO 3........................................................................................................................97 AUTOATIVIDADE .................................................................................................................................98 UNIDADE 3 – QUALIDADE DE SOFTWARE E POLÍTICA DE SEGURANÇA .....................101 TÓPICO 1 – MODELOS DE QUALIDADE DE SOFTWARE .......................................................103 1 INTRODUÇÃO ...................................................................................................................................103 IX 2 GERENCIAMENTO DA QUALIDADE DE SOFTWARE ..........................................................103 3 PLANEJAMENTO DA QUALIDADE DE SOFTWARE ..............................................................104 4 QUALIDADE DE SOFTWARE ........................................................................................................105 5 PADRÕES, NORMAS E MODELOS DE QUALIDADE DE SOFTWARE ..............................106 RESUMO DO TÓPICO 1......................................................................................................................108 AUTOATIVIDADE ...............................................................................................................................109 TÓPICO 2 – POLÍTICA DE SEGURANÇA DA INFORMAÇÃO NA ADMINISTRAÇÃO DE USUÁRIOS E GRUPOS ....................................................111 1 INTRODUÇÃO ...................................................................................................................................111 2 O QUE É A POLÍTICA DE SEGURANÇA DA INFORMAÇÃO ..............................................111 3 ESTRUTURA DA POLÍTICA DE SEGURANÇA DA INFORMAÇÃO ..................................114 3.1 ESTABELECER OS RESPONSÁVEIS..........................................................................................1143.2 TIPO DE INFORMAÇÃO .............................................................................................................115 3.3 NÍVEIS DE ACESSO ......................................................................................................................116 3.4 INDICAR OS PADRÕES MÍNIMOS DE QUALIDADE ..........................................................117 3.5 EVIDENCIAR AS CONSEQUÊNCIAS DA VIOLAÇÃO DAS NORMAS ............................117 4 ITENS DA ESTRUTURA POLÍTICA DE SEGURANÇA DA INFORMAÇÃO .....................117 4.1 OBJETIVOS .....................................................................................................................................117 4.2 GERAL .............................................................................................................................................118 4.3 ESPECÍFICO ...................................................................................................................................118 4.4 APLICAÇÕES .................................................................................................................................118 4.5 TIPOS ...............................................................................................................................................118 4.6 NÍVEIS ............................................................................................................................................119 4.7 RESPONSABILIDADES ................................................................................................................119 4.8 CUSTÓDIA .....................................................................................................................................119 4.9 MONITORAMENTO E AUDITORIA .........................................................................................120 4.10 USO DA REDE .............................................................................................................................120 4.11 USO DE EQUIPAMENTOS ........................................................................................................120 4.12 SEGURANÇA ...............................................................................................................................121 4.13 DISPOSIÇÕES FINAIS ................................................................................................................121 5 ESTRUTURA POLÍTICA DE SEGURANÇA DA INFORMAÇÃO – EXEMPLO ..................121 RESUMO DO TÓPICO 2......................................................................................................................125 AUTOATIVIDADE ...............................................................................................................................126 TÓPICO 3 – PLANO DE CONTINGÊNCIA ....................................................................................129 1 INTRODUÇÃO ...................................................................................................................................129 2 CARACTERÍSTICAS DE PLANOS DE CONTINGÊNCIA PARA INCIDENTES DE SEGURANÇA ....................................................................................................129 3 CONSTRUÇÃO DE PLANOS DE CONTINGÊNCIA PARA INCIDENTES DE SEGURANÇA ....................................................................................................132 4 ORGANIZAÇÃO DE PROCESSOS DE MANUTENÇÃO PARA PLANOS DE CONTINGÊNCIA ......................................................................................................135 LEITURA COMPLEMENTAR .............................................................................................................140 RESUMO DO TÓPICO 3......................................................................................................................142 AUTOATIVIDADE ...............................................................................................................................143 REFERÊNCIAS .......................................................................................................................................145 X 1 UNIDADE 1 VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE OBJETIVOS DE APRENDIZAGEM PLANO DE ESTUDOS A partir do estudo desta unidade, você deverá ser capaz de: • entender o valor da informação; • identificar os benefícios da qualidade de software; • compreender os conceitos básicos de segurança; • entender e conceituar a confiabilidade de software. Esta unidade está dividida em quatro tópicos. No decorrer da unidade você encontrará autoatividades com o objetivo de reforçar o conteúdo apresentado. TÓPICO 1 – CONCEITO E VALOR DA INFORMAÇÃO TÓPICO 2 – QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS TÓPICO 3 – QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE TÓPICO 4 – CONFIABILIDADE DE SOFTWARE Preparado para ampliar seus conhecimentos? Respire e vamos em frente! Procure um ambiente que facilite a concentração, assim absorverá melhor as informações. CHAMADA 2 3 TÓPICO 1 UNIDADE 1 CONCEITO E VALOR DA INFORMAÇÃO 1 INTRODUÇÃO As informações têm importância significativa para as empresas, estando relacionadas a aspectos estratégicos, de fidelização e atração de clientes e de orga- nização interna. Devido a essa relevância, as informações estão sujeitas a ameaças como perda ou roubo, que podem gerar grandes transtornos para as empresas. Assim, torna-se importante compreender em quais momentos as informações estão sob maior risco e quais os tipos de informação que exigem maiores esforços de segurança da informação. Neste tópico, você estudará os conceitos fundamentais de segurança da informação, sendo eles o valor da informação para as organizações, o ciclo de vida da informação e a classificação da informação. 2 A INFORMAÇÃO NO CONTEXTO ORGANIZACIONAL Para definirmos a importância da informação para as organizações, primeiramente é necessário entender o seu conceito. Distinguiremos dados e informação: dados são fatos brutos que não receberam tratamento; já informações são o resultado dos dados já tratados e organizados de uma forma lógica, conforme lecionam Laudon e Laudon (2007). A Figura 1 traz um esquema desses conceitos. FIGURA 1 – CONCEITOS DE CONHECIMENTO, INFORMAÇÃO E DADOS FONTE: Adaptado de Oliveira (2014) UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 4 Em uma empresa, a informação é uma ferramenta-chave que está diretamente associada ao seu sucesso ou insucesso. Uma informação ou um conjunto de informações pode representar uma parte ou o todo do negócio de uma empresa. Por exemplo: uma determinada marca de refrigerantes tem um grande faturamento e uma grande quantidade de vendas e tem como diferencial a fórmula utilizada para a produção do refrigerante da marca. Nesse contexto, a fórmula de produção da bebida é a informação principal da empresa, e a perda ou a divulgação dessa informação para a concorrência pode representar o fracasso da organização. As empresas também se utilizam da informação para conquistar novos clientes e fidelizar clientes antigos, uma vez que, por meio da análise de dados e informações, é possível construir o perfil consumidor e habitual dos clientes. Assim, uma empresa pode, por exemplo, posicionar produtos em um supermercado de acordo com as possibilidades de compra do público que frequenta o local. Outro exemplo similar é a oferta de produtos em lojas virtuais ou o anúncio de produtos em sites em geral: ao analisar as informações de pesquisas recentes e acessos a páginas web feitos pelo cliente, é possível ofertar anúncios que sejam atraentes para ele. Assim, existem diversos aspectos que tornam a informação de grande importância para as empresas. Dentre eles, podemos citar: • o impacto no negócio da empresa; • a fidelização de clientes; • a conquista de novos clientes; • a organização dos processos internos; e • o estabelecimento de uma cultura organizacional.Com o crescimento da oferta de tecnologia da informação e a consequente necessidade das empresas de se reinventarem e de inovarem em seus processos e produtos para se manterem competitivas, as informações empresariais passaram a ser armazenadas e manipuladas, em sua maioria, por meio de softwares e bancos de dados. O uso das informações diminui as incertezas na tomada de decisões e garante a competitividade dos negócios. Atualmente, em muitas empresas, a informação é tratada como ativo de informação e, como todo ativo, faz parte do patrimônio da empresa; como tal, tem valor próprio, conforme leciona Cunha (2012). O valor da informação para as organizações está descrito nas chamadas sete leis da informação, organizadas por Moody e Walsh e abordadas por Beal (2004, p. 21-24): TÓPICO 1 | CONCEITO E VALOR DA INFORMAÇÃO 5 • 1º Lei – A informação é infinitamente compartilhável: diferentemente de ativos comuns, como equipamentos, móveis etc., a informação pode ser compartilhada infinitamente e simultaneamente por inúmeras pessoas, aumentado cada vez mais o seu valor, à medida que mais pessoas forem usando. Assim como o compartilhamento aumenta o valor, a replicação da informação, através da reinserção de dados não agrega valor algum, só tende a aumentar os custos da organização. • 2º Lei – O valor da informação aumenta com o uso: diferente dos ativos comuns da organização que quanto mais usam mais perdem valor, a informação quanto mais usada, maior o valor a ela associado. Mas para ser bem utilizada, para que seu uso seja efetivo todos da organização devem saber que ela existe, saber onde ela está organizada, ter acesso a ela e saber como utilizá-la. Além disso essas informações devem estar adequadas às necessidades de seus usuários. • 3º Lei – A informação é perecível: a informação perde parte do seu valor à medida que o tempo for passando. Ela deve ser utilizada na hora correta, pois corre o risco de perder o valor da descoberta. • 4º Lei – O valor da informação aumenta com a precisão: quanto mais precisa for à informação, mais valor ela terá. O contrário, ou seja, a utilização da informação imprecisa, inexatas, pode levar a tomadas de decisões equivocadas ou provocar graves erros prejudicando seu usuário. • 5º Lei – O valor da informação aumenta quando há combinação de informações: a integração das informações permite uma visão sistêmica da organização em substituição à visão setorial, fragmentada. Quando mais integrada estiver, maior potencial de valor. • 6º Lei – Mais informação não é necessariamente melhor: assim como a insuficiência de informação, a sobrecarga dela também é prejudicial. Muitas vezes o excesso de informação, ultrapassa a capacidade humana de processamento. Para ser útil, a informação precisa ser filtrada, usando critérios de relevância, quantidade e qualidade de seu conteúdo. • 7º Lei – A informação se multiplica: a informação é autogenerativa, pois ela possui a capacidade de se multiplicar através de novas operações de síntese, análise e combinações, podendo ser reciclada e reutilizada. Conforme leciona Gurgel (2006), citando os ensinamentos de Drott (2001), “o fato de informações poderem ser estruturadas não quer dizer que o seu valor possa ser medido. As tomadas de decisões em uma organização são realizadas com base no conhecimento pessoal de seus colaboradores, bem como das informações corporativas existentes”. NOTA 3 CICLO DE VIDA DA INFORMAÇÃO O ciclo de vida da informação representa todo o “histórico” dessa informação, desde o momento de sua criação. O ciclo de vida descreve, inclusive, as mudanças na criticidade da informação, isto é, as variações quanto à relevância da informação para a empresa: uma informação que, em um dado período, era extremamente UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 6 importante para uma empresa, pode hoje não ter mais valor de negócio, ou vice- versa. Por exemplo: há cinco anos, uma marca criou um smartphone com uma funcionalidade inovadora; até o lançamento deste, o processo de fabricação e a ideia de negócio eram informações de alta criticidade. Após o lançamento, essas informações passaram a ser insignificantes para o negócio da empresa. O ciclo de vida da informação se divide nas seguintes fases, segundo Sêmola (2003): • Manuseio: trata-se do momento da criação e da manipulação da informação, seja esta física ou virtual. • Armazenamento: trata-se do armazenamento da informação, seja ele em arquivos físicos ou em bancos de dados de sistemas computadorizados. • Transporte: momento em que a informação é transportada, seja ao encaminhar informações por e-mail, via correspondência ou via telefone, por exemplo. • Descarte: ato de descartar a informação, quando esta deixa de ser relevante; por exemplo: apagar informações de computadores ou depositar documentos na lixeira. As etapas do ciclo de vida da informação representam os momentos em que a informação pode estar sob ameaça e, por isso, sua segurança demanda maior atenção. Segundo Sêmola (2003), na etapa de manuseio, a informação está sob ameaça, por exemplo, ao se fazer anotações em uma reunião e não zelar pelo sigilo das anotações. NOTA 4 CLASSIFICAÇÃO DAS INFORMAÇÕES Conforme destacado anteriormente, a informação tem um valor fundamental em todas ou, pelo menos, na maioria das empresas. Ela pode ser representada de diversas maneiras, por exemplo, digitalizada, em banco de dados, ou física, em arquivos de papel. Além da forma de representação, as informações também se diferenciam pelas suas restrições de acesso, isto é, as definições de quem pode acessar e do nível de segurança demandado. Uma vez que uma política de classificação é elaborada pela empresa, torna-se possível tomar decisões adequadas para a avaliação e o tratamento de riscos. Com isso, segundo Palma (2018), podem ser adotadas medidas preventivas, visando, por exemplo, a: • reduzir o risco de que informações classificadas como sensíveis sejam acessadas por pessoas não autorizadas; • garantir a divulgação adequada para informações públicas; TÓPICO 1 | CONCEITO E VALOR DA INFORMAÇÃO 7 • reduzir o risco de perda de integridade das informações que criam maior valor para o negócio; entre outras. Nesse contexto, é pertinente que as empresas categorizem as informações conforme suas necessidades e prioridades, classificando-as como informações públicas, internas, confidenciais e secretas, conforme leciona Laureano (2005 apud CUNHA, 2012). 1. Pública: é o tipo de informação que demanda menos trabalho de segurança; isso porque uma informação pública é aquela cuja integridade não é vital e que pode ser de senso comum, dentro e fora da empresa, sem prejudicar o negócio. 2. Interna: é o segundo tipo de informação que exige menos trabalho de segurança. Para informações internas, o sigilo deve ser mantido, e devem ser impostas restrições de acesso; contudo, os danos causados por um acesso não autorizado não são demasiadamente sérios. A integridade da informação interna é importante, mesmo que não seja vital. 3. Confidencial: esse tipo de informação deve ser mantido nos limites da empresa; por isso, devem ser investidos esforços de segurança nessas informações. O acesso não autorizado, o dano ou a perda desse tipo de informação pode trazer prejuízos e levar ao desequilíbrio operacional. Além disso, pode ocorrer uma quebra de confiabilidade perante o cliente, além de permitir vantagem expressiva ao concorrente. 4. Secreta: essas informações são críticas para a empresa; elas devem ser preservadas, e deve ser investido nelas o maior esforço possível para a sua segurança. O acesso a esse tipo de informações deve ser restrito, e sua manipulação deve ser extremamente cuidadosa. De acordo com a ISO 27001, essa classificação deve ser feita em um contexto organizacional, e não setorial. Portanto, ao classificar uma informação, devem ser levados em conta todos os setores da empresa, e não apenas o setorao qual, a princípio, essa informação pertence. No entanto, muito frequentemente, uma organização pode ter dois esquemas de classificação diferentes, no caso de trabalhar tanto com o setor governamental quanto com o privado. A norma ISO 27001 fala sobre a gestão da segurança da informação. Nessa norma estão descritos conceitos, práticas e informações sobre segurança da informação e, inclusive, sobre a classificação da informação. Saiba mais sobre a ISO 27001 acessando o link ou código a seguir: https://goo.gl/2qnTiB. NOTA 8 Neste tópico, você aprendeu que: RESUMO DO TÓPICO 1 • É possível identificar a importância e o valor da informação no contexto organizacional e sua importância para os profissionais que desejam trabalhar na área de segurança, bem como para as equipes gestoras das empresas. • Existem conceitos sobre o valor da informação no contexto organizacional. • As fases do ciclo de vida da informação representam os momentos em que a informação pode estar sob ameaça e, por isso, sua segurança demanda maior atenção. • É possível descrever a classificação das informações (pública, interna, confidencial, secreta). 9 1 Em uma empresa, a informação é uma ferramenta-chave que está diretamente associada ao seu sucesso ou insucesso. Você é gestor de uma grande empresa do setor calçadista e precisa preocupar-se em garantir a manutenção e a rentabilidade de seu negócio. Assim, analise as seguintes informações e classifique-as de acordo com o seu grau de criticidade, justificando a sua resposta: a) Design de novos sapatos. b) Código utilizado para formulação da tinta que colore uma determinada linha de sapatos. c) Número de funcionários da empresa. d) CNPJ da empresa. e) Tecnologia inovadora que está sendo inserida para melhorar o amortecimento de sapatos da linha esportiva. f) Calendário de datas de lançamentos de novos produtos. 2 Os ativos de informação são considerados os meios que a empresa utiliza para armazenar, processar e transmitir as informações, incluindo a própria informação. Diante disso, analise os itens a seguir: I- Sistemas operacionais. II- Sala-cofre. III- Banco de dados. IV- Documentação de sistemas. V- CNPJ da empresa . Sobre quais opções representam o ativo de informação, assinale a alternativa CORRETA: a) ( ) I e II. b) ( ) II e II c) ( ) I, II e III d) ( ) II e IV. e) ( ) III e IV. 3 A informação deve ser protegida por todo o seu ciclo de vida, pois ela passa por transformações durante este período. Assim, informações que eram confidenciais na concepção de um projeto, com o término deste, podem ser patenteadas, tornando-se, assim, informações públicas. Desse modo, o ciclo de vida das informações é dividido em quatro etapas. Sobre as quatro etapas do ciclo de vida da informação, assinale a alternativa CORRETA. AUTOATIVIDADE 10 a) ( ) Manuseio, armazenamento, transporte e descarte. b) ( ) Criação, alteração, manutenção e exibição. c) ( ) Descarte, manutenção, transporte e armazenamento. d) ( ) Manuseio, armazenamento, descarte e criação. e) ( ) Manuseio, armazenamento, transporte e descarregamento. 4 A Segurança de Informação protege a informação de diversos tipos de ameaças para garantir a continuidade dos negócios, minimizar os danos e maximizar o retorno de investimentos e as oportunidades de negócio. A Segurança da Informação é composta por três conceitos básicos. Assinale a alternativa que indica corretamente esses três conceitos básicos. a) ( ) Disponibilidade, integração e confidencialidade. b) ( ) Integridade, disponibilidade e confiança. c) ( ) Confidencialidade, integridade e disponibilidade. d) ( ) Confiabilidade, disponibilidade e integridade. e) ( ) Segurança, integridade e confidencialidade. 5 Existem vários tipos de sistemas de informações e cada um pode atender a uma necessidade específica da empresa. Os sistemas de informações podem se dividir em quatro grupos. Assinale a alternativa que indica corretamente os quatro grupos. a) ( ) Sistemas de nível operacional, conhecimento, gerencial e estratégico. b) ( ) Sistemas de nível gestacional, gerencial, conhecimento e estratégico. c) ( ) Sistemas de nível gerencial, informação, operacional e estratégico. d) ( ) Sistemas de nível gerencial, conhecimento e operacional e integrador. e) ( ) Sistemas de nível estratégico, operacional, gerencial e conhecimento. 11 TÓPICO 2 QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS UNIDADE 1 1 INTRODUÇÃO Ao adquirir um produto ou serviço, o cliente deseja que esse produto seja entregue em pleno funcionamento, de acordo com aquilo que foi solicitado e livre de falhas. No contexto de software, essa realidade é exatamente a mesma: quando o cliente solicita um software, cria-se uma expectativa e, por isso, faz-se necessário garantir que o software atenda a ela. O produto deve ser entregue em funcionamento e deve atender aos requisitos solicitados pelo cliente. O responsável pela garantia dessa entrega eficaz é o setor de qualidade de software. A qualidade de software atua em dois segmentos distintos: qualidade de produto e qualidade de processo. Neste tópico, você vai estudar os conceitos fundamentais desses dois segmentos, bem como conhecer os benefícios da qualidade de software e como aplicá-la nos projetos de desenvolvimento de sistemas. 2 CONCEITOS A palavra qualidade parece ter um significado bastante óbvio, contudo, trata-se de um elemento complexo e de difícil mensuração, dado que a qualidade é relativa e pode assumir diversos valores, de acordo com a pessoa que a observa. Nesse sentido, a qualidade do software pode ser medida de acordo com o quanto ele está em conformidade com o que o cliente solicitou, ou seja, mensura-se se o software está em conformidade com os requisitos funcionais e não funcionais especificados explicitamente pelo cliente, conforme leciona Basu (2015). UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 12 Façamos uma analogia: suponha que você tenha preferência por chocolate do tipo meio amargo, e seu irmão tenha preferência por chocolate ao leite; ao chegar em casa, se seu pai trouxer um chocolate ao leite, muito provavelmente seu irmão dirá que esse chocolate é de alta qualidade, enquanto você dirá que o chocolate não tem qualidade, porque não atende ao seu gosto, a sua expectativa. NOTA Embora a qualidade do software seja uma prática recente, que ganhou evidência com o advento da tecnologia, a qualidade, no geral, é uma preocupação bem antiga. Existem registros de que há mais de quatro mil anos os egípcios estabeleceram um padrão de medida para realizar seus trabalhos de forma apurada, chamado de cúbito, que equivalia ao tamanho do braço do faraó reinante, conforme Koscianski e Soares (2007). Entretanto, mesmo a qualidade sendo um conceito tão antigo, os projetos de software contam com vários desafios para entregar o software em perfeito funcionamento, devido a uma série de fatores — em especial, a complexidade. Isso porque construir um sistema envolve diversas habilidades, como comunicação e interpretação, para conseguir entender o que o cliente deseja, além de habilidades específicas para as etapas de programação, análise da qualidade, entre outras, que são de grande complexidade. Dada a multidisciplinariedade envolvida no processo de desenvolvimento de software e a complexidade de todo o processo, o segmento de qualidade se divide em duas áreas relacionadas, porém distintas: qualidade de processos e qualidade de produtos. A área de qualidade de processos trata da organização sistemática dos processos da empresa, visando ao melhor andamento dos projetos de desenvolvimento de sistemas, otimizando o tempo, tornando os processos repetitivos e evitando problemas em situações críticas para os projetos, por exemplo: estimativa, custo, entrada e saída de recursos humanos. Ao buscargarantir a qualidade de um software, estamos diante do desafio de estabelecer uma cultura de não tolerância a erros, por meio de processos que objetivem inibir ou impedir falhas, segundo Bartié (2002). É a área de qualidade de processos que se responsabiliza pela definição da metodologia ou do ciclo de vida de software que a equipe utilizará, podendo optar, por exemplo, por trabalhar com métodos ágeis ou métodos tradicionais. Independentemente da metodologia escolhida, o importante é que um processo seja seguido, para que a equipe tenha um padrão para se basear. Isso melhora a comunicação e influência na qualidade dos produtos desenvolvidos pela equipe. TÓPICO 2 | QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS 13 A área de qualidade de produtos tem por objetivo garantir a qualidade do produto tecnológico gerado durante o ciclo de desenvolvimento. Para esse fim, são realizadas atividades com o objetivo de estressar as funcionalidades do sistema, identificando o comportamento dele nesse contexto. Essas atividades são chamadas de testes de software. Essa área possui algumas divisões, sendo a mais importante a subdivisão entre testes que fazem uso do código-fonte do programa, chamados de caixa branca, e testes que não fazem uso do código- -fonte do programa, chamados de caixa preta. Além disso, os testes podem ser feitos de forma manual ou automatizada e fazendo uso das mais diversas técnicas, conforme Bartié (2002). A eficiência de um processo de testes é afetada diretamente por alguns fatores, que devem ser considerados para evitar problemas nas organizações, aponta Bartié (2002): falta de planejamento das atividades de testes, ausência de testes que validem funcionalidades antigas e ausência de processos de automação de testes. Uma terminologia bastante importante e comum na área de testes de qualidade de software é o conceito de bug, que abrange erros, defeitos e falhas. Por curiosidade, o termo bug corresponde à palavra inseto em inglês e começou a ser utilizado justamente quando um inseto causou uma falha em um equipamento. É importante entender que os termos erro, defeito e falha se referem a coisas distintas. Defeito é um comportamento inesperado de um produto. O defeito está em uma parte do produto e, em geral, refere-se a uma funcionalidade que está implementado no código de maneira incorreta. Erro é aquilo que foi cometido pelo programador e que gerou um código defeituoso, enquanto a falha se dá quando o programa defeituoso é executado e interfere no funcionamento do sistema para o usuário final. Falhas também podem ocorrer por fatores externos ao programa, como corrupção de bases de dados ou invasões de memória por outros programas, conforme Koscianski e Soares (2007). Considere, por exemplo, o código a seguir, conforme Koscianski e Soares (2007): a = input (); c = b/a; d = a ? b/a : 0; A linha de código que calcula o valor para a variável c pode apresentar um problema, dado que não é feita uma verificação para validar se o valor de a é 0. Dessa forma, pode acontecer um erro ao tentar realizar uma divisão por zero. O comportamento anormal do programa, que provavelmente gera um bug ou uma interrupção da execução, é provocado pela divisão b/a. Em um primeiro momento, podemos dizer que essa linha de código é defeituosa. UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 14 Existe, entretanto, outra hipótese: o defeito pode estar na rotina input (). Imagine que a especificação dessa rotina estabeleça que ela não deve jamais retornar um valor nulo. Nesse caso, o erro foi cometido pelo programador responsável por essa rotina. Essa segunda hipótese é bastante razoável, pois, para a maioria dos programas, não é recomendado preceder cada operação de divisão com um teste if. Nesse caso, um erro cometido pelo programador na rotina input fez com que o programa apresentasse um defeito ao executar a divisão de a por b. 3 BENEFÍCIOS Inúmeros são os benefícios que as empresas podem ter ao demandar uma atenção especial para a área de qualidade de software. Os benefícios vão muito além de valores financeiros, podendo estar relacionados inclusive com evitar transtornos legais ou preservar vidas. Empresas que desenvolvem sistemas de semáforos têm uma responsabilidade muito grande, uma vez que um erro de programação pode causar um grande acidente de trânsito ou, na melhor das hipóteses, um transtorno no trânsito NOTA É por isso que o controle de qualidade é totalmente importante e benéfico nos dias atuais. A qualidade de software possui diversos benefícios que ajudam os usuários a não sofrerem com falhas de software e as empresas a oferecerem produtos melhores, impedindo até mesmo grandes catástrofes. Vamos verificar alguns dos benefícios da qualidade de software, com base em Basu (2015): 1. Economiza dinheiro — quanto dinheiro um projeto de software defeituoso lhe custa? Custa usuários e clientes. E é bem sabido que, quanto mais tempo leva para um bug ser detectado em seu software, mais difícil e caro é consertá- lo. Ao empregar testes de controle de qualidade durante o processo de desenvolvimento do software, você economizará tempo e dinheiro após a implantação. 2. Impede emergências corporativas catastróficas — com o software corporativo, as apostas são ainda maiores. Bugs no software corporativo podem levar a blecautes do sistema, falta de dados e falhas de comunicação. Se você estiver empregando software em toda a empresa ou lidando com informações confidenciais, é melhor ter certeza de que o software funcionará exatamente como ele precisa funcionar. Não há margem para erro. TÓPICO 2 | QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS 15 3. Inspira a confiança do cliente — ao tornar o teste de software de controle de qualidade uma prioridade clara para o desenvolvimento de software, você está enviando uma mensagem para seus clientes de que deseja que o software deles seja o mais bem-sucedido possível. Isso é extremamente importante quando você busca oferecer qualidade e criar relacionamentos de longo prazo. 4. Mantém o nível de experiência do usuário elevado — está se tornando cada vez mais claro hoje em dia que a experiência do usuário pode quebrar ou impulsionar um negócio. Se o software estiver com problemas ou estiver lento, isso impedirá a experiência do usuário com o produto. Má experiência do usuário resulta em insatisfação e frustração. A boa experiência do usuário, que você obtém quando testa meticulosamente um produto de software, resulta em um usuário satisfeito — que tem muito mais probabilidade de recomendar o produto e sua empresa a outras pessoas. 5. Traz mais lucro — se você está criando um software para comercializar ou vender, investir em qualidade de software significa que você pode vender seu produto a uma taxa maior. Não há nada pior do que um usuário irritado que pagou por um produto que não funciona. 6. Aumenta a satisfação do cliente — relacionado ao ponto anterior, esse benefício está focado na reputação que a satisfação do cliente traz à sua empresa, não apenas no lucro. Ao oferecer um software de qualidade, que funciona quando e como você quer que ele funcione, você estará aumentando sua reputação, produzindo clientes satisfeitos. Não sobrecarregue a paciência dos seus clientes com um software defeituoso, que você precisa consertar constantemente. Dê- lhes qualidade desde o início, e eles lhe recompensarão com lealdade. 7. Promove organização, produtividade e eficiência — o que você menos deseja é o caos de um software defeituoso, uma comunicação frenética e correções apressadas. Ser organizado com o teste de controle de qualidade, desde o início de sua estratégia de desenvolvimento, permitirá que você trabalhe em paz e seja mais produtivo com seu tempo. Ao utilizar metodologias ágeis, nas quais os desenvolvedores de software criam e entregam pequenos trechos de um produto em uma linha do tempo clara, você podecomeçar a testar o software à medida que ele é criado, em vez de sempre esperar até o final. Existe uma regra que vigora desde os princípios do teste de software, chamada regra 10 de Myers. Essa regra estipula que o custo de encontrar um defeito no sistema aumenta 10 vezes a cada etapa do processo em que esse erro avançar, conforme aponta Myers (1979). Essa regra é mais aplicada para o contexto de projetos com ciclo de vida em cascata, em que as etapas são executadas sequencialmente, dado que, em equipes ágeis, não existe essa divisão exata de etapas. A Gráfico 1 ilustra essa regra. UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 16 GRÁFICO 1 – REGRA 10 DE MYERS FONTE: Os autores 4 APLICANDO A QUALIDADE DE SOFTWARE Conforme vimos anteriormente, a área de qualidade de software pode ser dividida em qualidade de produtos e qualidade de processos e é uma importante área no desenvolvimento de sistemas. Para a garantia da qualidade de processos, as empresas podem buscar certificações. Essas certificações fazem com a empresa seja, de certa forma, obrigada a seguir um processo que implemente a qualidade de processos de forma prática. As principais certificações são CMMI e MPS.BR. O CMMI, sigla para Capability Maturity Model Integration, é um modelo de maturidade utilizado para medir a maturidade dos processos de uma empresa. Ele serve também como um guia para a melhoria dos processos das organizações. Esse modelo classifica as empresas em cinco níveis, conforme Koscianski e Soares (2007), sendo eles: • Inicial: processos caóticos; em geral, não existe um ambiente propício para o desenvolvimento de software. • Gerenciado: nesse nível, já é perceptível uma melhoria em relação ao nível 1. Aqui já existem requisitos gerenciados e processos planejados, medidos e controlados. • Definido: nesse nível, a maturidade da empresa já está em um nível considerável. Aqui os processos são caracterizados e entendidos. • Gerenciado quantitativamente: nesse nível, os processos são controlados usando métodos estatísticos e outras técnicas quantitativas. • Otimizado: nesse nível, os processos são continuamente melhorados com base em análises feitas pela equipe. TÓPICO 2 | QUALIDADE DE SOFTWARE – MÉTODOS DE DESENVOLVIMENTO SEGUROS 17 O MPS.BR — sigla para Melhoria do Processo de Software Brasileiro — também é um modelo de maturidade, similar ao CMMI e com o mesmo objetivo. O MPS.BR foi proposto no Brasil e é utilizado por empresas brasileiras. Esse modelo considera seis níveis, sendo eles: • A: processo em otimização. • B: processo gerenciado quantitativamente. • C: processo definido. • D: processo largamente definido. • E: processo parcialmente definido. • F: processo gerenciado. • G: processo parcialmente gerenciado. Já para a qualidade de produto, diversas são as técnicas que podem ser empregadas. A área de testes de software é bastante abrangente e completa, sendo sempre recomendado que o trabalho de testes seja feito em conjunto com o desenvolvedor e durante o desenvolvimento do sistema, isto é, sem esperar que o sistema seja concluído para, então, testar. Vamos falar aqui de alguns tipos de testes e como aplicá-los, com base em Graham et al. (2008): Teste unitário — é um tipo de teste realizado diretamente no código fonte do programa em teste. Nesse tipo de teste, são criadas funcionalidades de testes que validam o comportamento dos métodos ou funções implementadas pelo programador. No teste unitário, são identificados os primeiros erros e, quando obtido sucesso nos testes (ou seja, quando não forem localizadas falhas), as funcionalidades principais do programa devem estar funcionando. Um exemplo de técnica para teste unitário é o TDD — test driven development —, que tem por objetivo o desenvolvedor criar primeiro o código de teste, para depois criar a funcionalidade e, então, executar o teste que valida essa funcionalidade. Teste funcional — é um tipo de teste realizado após o desenvolvimento do sistema ou de um módulo do sistema. O teste funcional pode ser automatizado ou manual. No caso de teste automatizado, são utilizados scripts de teste, que simulam o comportamento de um usuário no sistema, por exemplo, clicando em botões e inserindo valores em campos, e verificam a resposta do sistema para esses comportamentos. Para testes automatizados, esses scripts são executados automaticamente, e os defeitos localizados são sinalizados também de forma automática. No caso de testes manuais, os scripts são substituídos por casos de teste. Caso de teste é um documento em que é descrita a ação do usuário e a resposta esperada do sistema para ela. Nesse caso, a execução do caso de teste é feita manualmente, e o registro dos defeitos também. Teste de aceitação — esse teste é realizado junto com o cliente e visa a verificar se o sistema que foi ou está sendo construído é realmente o que foi solicitado. Teste exploratório — esse tipo de teste é muito comum, mais rápido de ser realizado e se torna uma alternativa para projetos com cronograma apertado. Nesse tipo de teste, o testador usa a sua experiência para navegar no sistema visando a localizar erros. A principal vantagem desse tipo de testes é localizar UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 18 defeitos que não seriam localizados nos demais testes; por exemplo, casos em que o usuário tem um comportamento incomum, como clicar duas vezes em um botão de salvar. Para organizar esses testes e garantir que as funcionalidades principais sejam testadas, é comum criar um checklist, que nada mais é do que uma lista que registra os principais pontos que devem ser testados nas telas do sistema. Leitura recomendada: LEWIS, W. E. Software testing and continuous quality improvement. Boca Raton: CRC Press, 2016. DICAS 19 RESUMO DO TÓPICO 2 Neste tópico, você aprendeu que: • A área de qualidade de software pode ser dividida em qualidade de produtos e qualidade de processos e é uma importante área no desenvolvimento de sistemas. • É possível identificar os benefícios da qualidade de software. • É possível realizar a aplicação dos conceitos de qualidade. • É importante conhecer alguns tipos de testes e sobre a maneira de aplicá-los. • Conhecer alguns modelos de maturidade é importante para classificar as empresas em níveis. • Os diversos benefícios da segurança e qualidade de software ajudam os usuários a não sofrerem com falhas de software. 20 1 Um dos grandes problemas que traz transtornos para as empresas desenvolvedoras de software é a presença de bugs no sistema. Isso porque eles afetam a satisfação do cliente com o sistema. Analise as alternativas a seguir e assinale a que define corretamente erro, defeito e falha: a) ( ) João é programador e inseriu por engano uma função infinitamente recursiva. João cometeu uma falha que pode prejudicar a empresa. b) ( ) Por causa da atitude errônea de João (que inseriu por engano uma função infinitamente recursiva no programa), quando Ana efetuou testes unitários no código fonte, ela identificou um defeito (uma linha defeituosa) no código. c) ( ) Juca é usuário do sistema e, ao cadastrar uma nova nota fiscal, deparou-se com um erro no software. d) ( ) Pedro estava fazendo um teste unitário no sistema e descobriu que Antônio cometeu uma falha, efetuou a declaração de uma variável com o tipo de dado errado. e) ( ) Lucas, usuário do sistema, deixou um campo em branco ao cadastrar um novo usuário para o sistema e fez com que o sistema travasse. Lucas estava diante de um erro de software. 2 A área de qualidade de software é a principal responsável por garantir a satisfação do cliente para com o software que foi entregue, desta forma, essa área se preocupa não apenas em entregar o software funcionando, mas em entregar o software em conformidade com os requisitos estabelecidos pelo cliente. Para ajudar nesse processo de garantia da qualidade, a área dequalidade de processos norteia a organização da estrutura de trabalho da empresa. Sobre qualidade de processos, classifique V para as sentenças verdadeiras e F para as falsas: ( ) CMMI e ISO9001 são modelos de maturidade que fornecem informações para os funcionários sobre como fazer o seu trabalho de forma eficiente. ( ) Um exemplo de processo que pode ser utilizado para garantia da qualidade de processos são as metodologias rápidas. ( ) A utilização de ciclo de desenvolvimento em cascata garante que a empresa atingirá o nível máximo de maturidade no CMMI. ( ) Um dos critérios para ser promovido em nível de maturidade é a comunicação eficiente e, por isso, o uso de metodologias ágeis é um pré- requisito. ( ) O nível V do CMMI é o último nível de maturidade, ele considera que todos os processos já estão definidos e são seguidos pela empresa, estando em constante otimização. AUTOATIVIDADE 21 Assinale a alternativa que apresenta a sequência CORRETA: a) ( ) V – F – V – V – F. b) ( ) V – F – V – F – F. c) ( ) F – F – V – V – V. d) ( ) F – F – F – F – V. 3 A regra 10 de Myers estima que o prejuízo causado por um defeito no sistema aumenta 10 vezes a cada etapa do processo de desenvolvimento que é avançado. Desta forma, é de extrema importância encontrar precocemente os defeitos antes que estes se tornem falhas e sejam visíveis para o cliente. Esta é uma função do segmento de qualidade de produto. Sobre qualidade de produto, analise as alternativas a seguir e assinale a alternativa CORRETA: a) ( ) É parte da atribuição do segmento de qualidade de produto realizar junto ao cliente uma verificação antes da entrega do software para garantir que o software entregue está de acordo com o solicitado. b) ( ) O profissional que trabalha com qualidade de produto, também chamado de QP, tem, entre suas funções, que garantir que o desenvolvimento do produto seja feito de acordo com uma metodologia, como, por exemplo, metodologia ágil Scrum. c) ( ) A realização de testes de software só é possível após o final do desenvolvimento do produto, isto porque é necessário que toda a funcionalidade tenha sido desenvolvida para poder testá-la. d) ( ) A qualidade de produto não interfere na confiança do cliente, esta é uma responsabilidade burocrática aliada à qualidade de processos. e) ( ) O teste exploratório deve ser sempre o primeiro teste a ser realizado, ainda durante o processo de desenvolvimento, pelo programador. 4 Os modelos CMMI e MPS-BR têm por objetivo auxiliar as empresas na organização de seus processos e avaliar a maturidade a qual os processos das empresas se encontram. Sobre esses dois modelos, assinale a alternativa CORRETA: a) ( ) Pode-se dizer que uma empresa que utiliza métodos ágeis de desenvolvimento de sistemas é automaticamente mais madura do que uma empresa que utiliza métodos tradicionais. b) ( ) O modelo MPS-BR pode ser considerado uma extensão do CMMI, uma vez que ele replica os níveis do CMMI complementando os níveis intermediários. c) ( ) Processo largamente definido é um nível de maturidade do modelo CMMI. d) ( ) O modelo CMMI é utilizado apenas dentro do Brasil, embora tenha sido criado fora. e) ( ) Tanto o CMMI quanto o MPS-BR são ferramentas para organização de processos empresariais. 22 5 A qualidade da entrega dos produtos é fundamental para a fidelização do cliente e o ganho de confiança. Isso se aplica para software e para qualquer outro produto ou serviço que seja fornecido por uma empresa para clientes. Diante disso, analise as afirmativas a seguir: I- Embora conquistar o cliente seja bastante importante para a empresa fornecedora de software, caso este cause danos financeiros ao cliente, não é responsabilidade da fornecedora. II- A regra 10 de Myers se aplica ao modelo ágil de desenvolvimento de sistemas. III- A regra 10 de Myers considera que o custo de um defeito localizado aumenta 100 vezes a cada etapa avançada no ciclo de desenvolvimento. IV- Um dos benefícios aliados à qualidade de usuário é melhorar a experiência deste. V- Qualidade de software é útil apenas em momentos de catástrofes. No que se refere a importância da qualidade de software, assinale a alternativa CORRETA: a) ( ) I e II. b) ( ) II, III e V. c) ( ) I e IV. d) ( ) I, II e III. e) ( ) Somente opção IV. 6 Testes de software são uma atividade de extrema importância para a garantia da qualidade do produto de software. Diversos tipos de testes podem ser realizados, sejam estes feitos diretamente no código fonte do software ou por meio da execução do software que está sendo testado. Um dos tipos de teste que podem ser executados é o exploratório. Esse tipo de teste se baseia no conhecimento do testador do negócio da empresa, de forma que o testador irá explorar o sistema buscando por falhas. Para suportar esse trabalho de busca exploratório de erros, podem ser criados checklists, estes garantem que as principais funcionalidades serão testadas e que todas as validações necessárias serão feitas. Após ler essas informações, avalie a situação a seguir: 23 FONTE: Os autores Agora, com base na análise realizada, elabore um checklist que possa ser usado para validação dessa tela e reaproveitado para outras telas que você testar no futuro. 24 25 TÓPICO 3 QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE UNIDADE 1 1 INTRODUÇÃO Não é viável falar de qualidade sem falar de processos. Processos de software são complexos e compostos por um número muito grande de atividades e características. Esses processos têm sido aliados no desenvolvimento de software de qualidade e, além disso, auxiliam na redução de problemas relacionados ao suporte, ao treinamento e às revisões, no aprendizado organizacional e, também, na economia, pois o esforço e o tempo de projetos podem ser reduzidos. Neste tópico, você estudará sobre a qualidade do processo de software, a qualidade do produto de software e vai aprender a definir o processo de garantia da qualidade e processos como revisões e inspeções em softwares. 2 QUALIDADE DE PROCESSO E QUALIDADE DE PRODUTO A qualidade de um processo de desenvolvimento está diretamente ligada à qualidade de um produto. Com o desenvolvimento de software não é diferente, mas esse é um processo mais criativo do que mecânico e ainda é necessário contar com as habilidades individuais e fatores externos, como, por exemplo, as novidades tecnológicas. Assim, processos de software são complexos e englobam um número muito grande de atividades e características (Quadro 1). 26 UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE QUADRO 1 – CARACTERÍSTICAS DOS PROCESSOS FONTE: Adaptado de Sommerville (2011) No entanto, manter processos atualizados e revisados pode ser a garantia de um produto de qualidade e de satisfação do cliente. Segundo Sommerville (2011), para um gerenciamento de qualidade de processo, é necessário envolver: • defi nição de padrões de processo, como “quando” e “como” as revisões devem ser conduzidas. • monitoramento do processo do desenvolvimento para assegurar que os padrões estão sendo seguidos. • relato do processo de software para a gerência de projeto e para o comprador do software. Para um gerenciamento efetivo, os padrões de qualidade são muito importantes e podem ser internacionais, nacionais, organizacionais ou de projeto. Os padrões de produto defi nem as características que os componentes devem ter, por exemplo, um estilo de programação. Já os padrões de processos vão defi nir como o processo de software deve ser instituído. A utilização desses padrões evita a repetição de erros e, também, auxilia na continuidade, caso a produção do produto seja continuada por outros membros da equipe. Veja, na Tabela 1, os padrões de produto e de processo. TÓPICO 3 | QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE 27 TABELA 1 – PADRÕES PARA PRODUTOS E PROCESSOS FONTE: Adaptado de Sommerville(2011) A qualidade do processo de software, além do foco no aumento da qualidade do produto, visa, também, diminuir o retrabalho e aumentar a produtividade. Para implantar um programa de qualidade, é necessário implantar um processo de software que deve ser documentado, compreendido e seguido por todos na organização. 3 GARANTIA DA QUALIDADE DE SOFTWARE A garantia da qualidade de software é um padrão sistemático e planejado de ações que são impostas para garantir essa qualidade. Esse padrão busca produzir softwares com a menor taxa de defeitos, utilizando procedimentos, modelos, padrões e investimento na equipe a garantia tem natureza proativa. A garantia visa, também, o gerenciamento e a melhoria dos processos existentes por meio do aprendizado em cada projeto realizado. O controle da qualidade tem como objetivo evitar que produtos defeituosos sejam entregues aos clientes, tem ação reativa e objetiva o monitoramento do processo, a detecção e a correção dos defeitos. Para garantir a qualidade, algumas ações são necessárias: • aplicar modelos técnicos — esses modelos ajudam o analista a adquirir uma especifi cação de qualidade e ajudam o projetista a desenvolver um projeto de qualidade; • aplicar padrões e procedimentos formais — essa etapa se refere à aplicação de padrões nos processos de engenharia de software; • anotar e manter registros — ações de coleta e disseminação de informações de garantia de qualidade de software. O processo de garantia da qualidade contempla: 28 UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE • a revisão dos produtos intermediários em comparação com os requisitos de qualidade preestabelecidos; • a revisão das atividades comparando com os planos preestabelecidos, que podem ser, entre outros: ○ plano de projeto; ○ plano de documentação; ○ plano de monitoração de riscos. Para avaliar os requisitos de qualidade do produto e se eles estão de acordo com os planos, é necessário aplicar as revisões e os testes. 4 REVISÕES E INSPEÇÕES EM SOFTWARE A inspeção de software é realizada por pessoas que verificam o software com o objetivo de descobrir possíveis defeitos. Essas inspeções podem ser feitas, por exemplo, nos requisitos, no projeto, nos dados de configuração, nos dados de testes e são bastante utilizadas para descobrir erros no programa. Quando o software está em fase de teste, um defeito pode ser encoberto por outro e, para evitar que isso ocorra, vários testes e execuções são necessários. Alguns defeitos são recorrentes em software. Nessa hora, o conhecimento em programação faz diferença para processos de detecção e correção mais rápidas. Durante o processo de validação e verificação, são utilizados as inspeções e os testes, que são técnicas complementares. As inspeções verificam a conformidade com uma especificação do software, mas não verificam a não conformidade com os requisitos reais do cliente e nem características não funcionais, como, por exemplo, desempenho, usabilidade e adaptabilidade. Para inspeções em programas, é necessária uma abordagem mais formalizada, que contenha todas as revisões efetuadas, não só a título de controle, mas também para histórico e comprovação. Essas estão relacionadas à detecção de defeitos que podem ser erros lógicos, erros de sintaxe, erro na lógica de programação e, até mesmo, de não conformidade com os padrões definidos, mas não estão relacionadas com a correção deles. Para realizar a inspeção, as condições para que esse processo ocorra precisam estar disponíveis, bem como os padrões organizacionais que são seguidos e utilizados. Conforme os erros são encontrados e reparados, deverão ser inseridos em um checklist, embora esse não deva ser usado a título de penalidade aos que cometeram o erro e nem para avaliação de competência da equipe. Para a inspeção, Sommerville (2011) indica o processo demonstrado na Figura 2. TÓPICO 3 | QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE 29 FIGURA 2 – PROCESSO DE INSPEÇÃO FONTE: Adaptado de Sommerville (2011) Nesse processo: • o planejamento discute como será feita a inspeção; • a visão geral apresenta o sistema para a equipe que realizará a inspeção; • na preparação, o código e a respectiva documentação são apresentados para a equipe que realizará a inspeção; • a reunião de inspeção ocorre quando os erros descobertos são anotados no checklist; • na etapa retrabalho, as modifi cações são feitas para reparar os erros encontrados; • na etapa acompanhamento, uma nova inspeção é realizada se for necessário. Veja, na Tabela 2, os papéis que os participantes da inspeção apresentam (SOMMERVILLE, 2011). TABELA 2 – PAPEIS NA INSPEÇÃO FONTE: Adaptado de Sommerville (2011) 30 UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE 5 REVISÕES TÉCNICAS FORMAIS As atividades de controle de qualidade de software que são realizadas por engenheiros de software são denominadas revisão técnica formal ou RTF. Segundo Pressman e Maxim (2016), os objetivos de uma RTF são: • descobrir erros na função, na lógica ou na implementação; • verifi car se o projeto que está sendo revisado atende aos requisitos do cliente; • garantir que o software está de acordo com os padrões predefi nidos; • tornar os projetos mais gerenciáveis 6 DIRETRIZES DE REVISÃO As revisões devem ter foco no produto, e não nas pessoas. Apontar erros não deve ser uma prática dentro das revisões formais; caso contrário, as reuniões de revisão podem causar desconforto na equipe, inclusive desmotivando os participantes. Manter uma agenda para as revisões também é uma boa prática. Além de manter o foco da reunião, a agenda também ajuda a manter os prazos estabelecidos. Para as reuniões de revisão, é interessante limitar o número de participantes, que devem preparar-se com antecedência. Veja a Tabela 3. TABELA 3 – ITENS DE REVISÃO VERSUS RESULTADO ESPERADO FONTE: Os autores Nesse sentido, é importante destacar a diferença entre revisão, erro e defeito: a revisão é o fi ltro do processo e é utilizada para detectar erros e defeitos; o erro é um problema de qualidade que ocorre antes da entrega ao cliente; e o defeito é um problema de qualidade constatado depois da entrega ao cliente. TÓPICO 3 | QUALIDADE DO PROCESSO E PRODUTO DE SOFTWARE 31 7 O CHECKLIST Conforme comentado, durante a inspeção, um checklist deve ser alimentado com os erros encontrados. Uma prática utilizada também é um checklist com os erros mais comuns encontrados nos projetos anteriores a fi m de direcionar a inspeção atual. Veja, no Tabela 4, um exemplo de verifi cação de inspeção e, na Tabela 4, um modelo de checklist. TABELA 4 – EXEMPLO DE VERIFICAÇÃO DE INSPEÇÃO FONTE: Adaptado de Sommerville (2011) 32 UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE FIGURA 3 – MODELO DE CHECKLIST DE VALIDAÇÃO DE REQUISITOS FONTE: Oliveira (2014, s.p.) Leitura recomendada: STEFFEN, J. B. O que são essas tais de metodologias ágeis? 2012. Disponível em: https://ibm.co/2D8yddW. Acesso em: 1 nov. 2018. DICAS 33 RESUMO DO TÓPICO 3 Neste tópico, você aprendeu que: • A qualidade do processo de software, além do foco no aumento da qualidade do produto, visa, também, diminuir o retrabalho e aumentar a produtividade. • O processo de garantia da qualidade contempla a revisão dos produtos intermediários em comparação com os requisitos de qualidade preestabelecidos; e a revisão das atividades comparando com os planos preestabelecidos. • A inspeção de software é realizada por pessoas que verificam o software com o objetivo de descobrir possíveis defeitos. Além disso, também aprendeu a definir revisões e inspeções em softwares. • As atividades de controle de qualidade de software que são realizadas por engenheiros de software são denominadas revisão técnica formal ou RTF. 34 1 Analise as alternativas a seguir e assinale a que corresponde a um dos objetivos das revisões técnicas formais de software. a) ( ) Realizar uma únicareunião ao final do projeto para avaliar se o software foi bem construído. b) ( ) Realizar reuniões com os clientes para descobrir o que deve ser feito. Senhas complexas e firewall. c) ( ) Documentar os requisitos solicitados. d) ( ) Garantir que o software não tenha erros. e) ( ) Garantir que o software atenda aos requisitos especificados. 2 Analise as alternativas a seguir e assinale a que corresponde a um objetivo das inspeções de software. a) ( ) Revisões de progresso. b) ( ) Avaliação de metas organizacionais. c) ( ) Detecção de defeitos. d) ( ) Revisões de cronograma. e) ( ) Revisões de custo. 3 No que se refere à qualidade de software, as revisões, as inspeções e os testes realizados ao longo do processo de software para garantir que o produto satisfaça os requisitos estabelecidos são importantes. Sobre os itens mencionados, classifique V para as sentenças verdadeiras e F para as falsas: ( ) Garantia de qualidade. ( ) Custo da qualidade. ( ) Controle de qualidade. ( ) Reengenharia de processos. Assinale a alternativa que apresenta a sequência CORRETA: a) ( ) F – V – F – V. b) ( ) F – F – V – F. c) ( ) F – F – V – V. d) ( ) V – V – F – V. 4 No gerenciamento da qualidade, como é conhecido quando são estabelecidos padrões organizacionais e uma estrutura de procedimentos para condução de um software de qualidade? AUTOATIVIDADE 35 a) ( ) Planejamento da qualidade. b) ( ) Garantia da qualidade. c) ( ) Controle da qualidade. d) ( ) Gerenciamento da configuração. e) ( ) Revisões de qualidade. 5 As técnicas de prototipação e de revisão de requisito são as mais utilizadas para: a) ( ) o gerenciamento de requisitos. b) ( ) a validação de requisitos. c) ( ) o levantamento e a análise de requisitos. d) ( ) o estudo de viabilidade e o desenvolvimento do sistema. e) ( ) a especificação de requisitos. 36 37 TÓPICO 4 CONFIABILIDADE DE SOFTWARE UNIDADE 1 1 INTRODUÇÃO Pode-se dizer que o ciclo completo de vida de um sistema compreende duas fases importantes: o desenvolvimento do sistema e sua operação. A confiabilidade de software se refere ao desenvolvimento de um software confiável, ou seja, seus conceitos são tratados amplamente na fase de desenvolvimento. Neste tópico, você terá a oportunidade de estudar os conceitos que permeiam a confiabilidade de software, principalmente no que se refere às dimensões de confiança de software. 2 CONFIABILIDADE DE SOFTWARE O software deve estar disponível sempre que necessário, bem como operar adequadamente, com segurança e confiabilidade, sem quaisquer efeitos colaterais adversos ou preocupações de segurança. É essencial que o software utilizado em sistemas críticos seja confiável, pois a consequência de uma falha (por exemplo, a falha em uma usina nuclear) pode resultar em um dano massivo, que poderá significar a perda de vidas. De acordo com o ANSI (1991), a confiabilidade de software é definida como a probabilidade de um software operar sem falhas por um período específico em um ambiente específico. Embora a confiabilidade de software seja definida como uma função probabilística e venha a sugerir uma noção de tempo, devemos observar que, diferentemente da confiabilidade de hardware tradicional, a confiabilidade de software não é uma função direta do tempo. Peças eletrônicas e mecânicas podem se tornar “velhas” e desgastadas com o tempo e o uso, mas o software não enferruja ou se desgasta durante seu ciclo de vida. O software não será alterado com o tempo, a menos que seja alterado ou atualizado intencionalmente. Costumava-se acreditar que o software nunca se danificava. Intuitivamente, ao contrário de peças mecânicas, como parafusos, alavancas ou peças eletrônicas, como transistores e capacitores, o software permanecerá no mesmo estado, a menos que haja problemas no hardware que alterem o conteúdo do armazenamento ou o caminho dos dados. 38 UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE O software não envelhece, enferruja, desgasta, deforma ou racha. Além disso, o software não tem forma, cor, material ou massa, mas tem um papel crucial no funcionamento dos sistemas. A confiabilidade do software é um atributo importante para a qualidade do software, com a funcionalidade, a usabilidade, o desempenho, a capacidade de manutenção, a instabilidade e a capacidade de manutenção e documentação. A confiabilidade é difícil de atingir, porque a complexidade do software tende a ser alta. Embora em qualquer sistema com alto grau de complexidade seja difícil alcançar certo nível de confiabilidade, os desenvolvedores de sistemas tendem a empurrar a complexidade para a camada de software. Como exemplos de tendências nesse sentido, temos que: • as aeronaves de última geração terão mais de um milhão de linhas de código- fonte de software a bordo; • os sistemas de controle de tráfego aéreo da próxima geração conterão entre um e dois milhões de linhas; • a próxima estação espacial internacional terá mais de dois milhões de linhas a bordo e mais de dez milhões de linhas de software de suporte terrestre; • vários sistemas de defesa críticos terão mais de cinco milhões de linhas de software. Embora a complexidade do software esteja inversamente relacionada à confiabilidade do software, ela está diretamente relacionada a outros fatores importantes na qualidade do software, especialmente funcionalidade e capacidade. A ênfase nesses recursos tende a adicionar mais complexidade ao software. As falhas de software ocorrem devido a erros, ambiguidades, descuidos ou interpretações errôneas da especificação do software, descuido ou incompetência ao escrever o código, testes inadequados, uso incorreto ou inesperado do software, ou outros problemas não previstos. É comum fazer uma analogia entre confiabilidade de software e confiabilidade de hardware, mas software e hardware têm características básicas que os tornam diferentes quanto aos mecanismos de falha. As falhas de hardware são principalmente falhas físicas, enquanto as falhas de software são falhas de projeto, que são mais difíceis de se detectar, classificar e corrigir. As falhas de projeto estão intimamente relacionadas a fatores humanos diversos e às fases do projeto mais complexas, conforme Lyu (1995). Com o passar do tempo, o hardware exibe as características de falha, conhecidas como a curva da banheira. Nessa curva, é possível identificar o período de vida útil do hardware ao longo do tempo. Já a confiabilidade do software não possui as mesmas características; uma curva de software possível é apresentada no gráfico a seguir, se projetarmos a confiabilidade do software nos mesmos eixos. TÓPICO 4 | CONFIABILIDADE DE SOFTWARE 39 Existem duas grandes diferenças entre as curvas de hardware e software. Uma diferença é que, na última fase, o software não tem uma taxa de falhas crescente, como acontece com o hardware. Nessa fase, o software está se aproximando da obsolescência, e não fazem sentido quaisquer atualizações ou alterações no software. Portanto, a taxa de falha não será alterada. A segunda diferença é que, na fase da vida útil, o software sofrerá um aumento drástico na taxa de falhas cada vez que uma atualização for feita. A taxa de falha é desativada gradualmente, em parte devido aos defeitos encontrados e corrigidos após as atualizações. GRÁFICO 2 – TAXA DE FALHAS DE HARDWARE AO LONGO DO TEMPO FONTE: <https://bit.ly/2VQ6XaJ>. Acesso em: 30 jun. 2020 GRÁFICO 3 – TAXA DE FALHAS DE SOFTWARE AO LONGO DO TEMPO FONTE: Adaptada de Hartz e Walker (1996) Segundo Avizienis, Laprie e Randell (2001), são três os fatores que afetam a confi abilidade de sistemas: 1- Falta. 2- Erro. 3- Falha. 40 UNIDADE 1 | VALOR DA INFORMAÇÃO E CONFIABILIDADE DE SOFTWARE A falta é conhecida como defeito ou bug e é considerada em estado dormente até a sua ocorrência. Um exemplo comum de falta é a declaração de uma variável
Compartilhar