Qual a principal característica da Engenharia de software

trabalho dissertativo

Curso de sistemas de informação

SABRINA LIZETE TEIXEIRA DE SOUZA

TÍTULO: CONCEITOS E FUNDAMENTOS DA ENGENHARIA DE SOFTWARE.

Belém- PA

2021

SABRINA LIZETE TEIXEIRA DE SOUZA

Conceitos e fundamentos da Engenharia de Software: O software como algo abstrato, virtual e intangível; a disciplina e o processo de engenharia de software; engenharia de requisitos; evolução de software.

Estudo bibliográfico de aprofundamento na matéria Tópicos em desenvolvimento de sistemas, apresentado ao Professor Iranildo Ramos da Faci Faculdade Ideal, Compus em Belém.

Belém- PA

2021

RESUMO

Neste trabalho, são apresentados os conceitos relacionados à o ciclo de vida, definições, características, processos de desenvolvimento, manutenção e a testabilidade do software, desta maneira o estudo na área de Engenharia de Software traz uma série de métodos, processos, modelos, e estes estudos embasados na qualidade no setor de software mostrando a maturidade dos processos descrevendo o Projeto MPS-Br, CMMI e uma abordagem diferente do PMBOK, compreendendo a fundamental importância do processo de engenharia de requisitos, existi diferentes maneiras de estruturar um processo com atividades relacionadas, manutenção do software e suas características, são essenciais para a evolução da tecnologia do Software, contudo entendendo a real importância dos testes usados de acordo com necessidades ou restrições tecnológicas, por fim sabendo-se que a testabilidade é um requisito não-funcional importante, pode ser definida como a propriedade que mensura o quão fácil é testar trecho de código ou funcionalidade de um software específico.

Palavras-chave: software, ciclo de vida, definições, testabilidade.

ABSTRACT

In this work, the concepts related to the software life cycle, specifications, characteristics, development processes, maintenance and software testability are called, in this way the study in the area of Software Engineering brings a series of methods, processes, models, and these studies based on quality in the software sector showing a maturity of the processes, describing the MPS-Br Project, CMMI and a different approach than PMBOK. Understanding a fundamental importance of the requirements engineering process, there are different ways to structure a process with related activities, maintenance of the software and its characteristics, they are essential for the evolution of the software technology, however understanding the real importance of the used tests of according to need or technological restrictions, finally knowing that testability is an important non-functional requirement, it can be defined as a property that measures how easy it is to test the code or functionality of a specific software.

Keywords: software, life cycle, definitions, testability.

LISTA DE ILUSTRAÇÕES

Figura 1                                                                       Níveis de maturidade do CMMI.

Figura 2                                           Grupo de Processos de Gerenciamento de Projetos.

Figura 3    Tabela de relacionamento entre áreas de conhecimento e grupos de processo.

LISTA DE ABREVIATURAS E SIGLAS

PMBOK                            Project Management Body of Knowledge

PMI                                   Project Management Institute

IBM                                  International Business Machines

MPS-BR                           Melhoria do Processo de Software Brasileiro

CMMI                                Capability Maturity Model Integration

CMM                                 Capability Maturity Model

MCTI                                  Ministério da Ciência, Tecnologia e Inovações

UML                           Unified Modeling Language

SEI                              Software Engineering Institute

SIMA                                  Sistema Integrado de Monitoramento Ambiental

CAD                                  Computer-aided design

SW                              Software

Sumário

1 INTRODUÇÃO.. 1

1.3 SOFTWARE É ABSTRATO E INTANGIVEL. 2

1.4 DEFINIÇÃO DE SOFTWARE. 2

1.4.1 Características de um software. 3

1.4.2 Conjuntos de processo de desenvolvimento de software. 3

1.4.3 Atividades fundamentais e comuns a todos os processos de desenvolvimento de software. 4

1.4.3.1 Fases comuns nos modelos de desenvolvimento de softwares. 4

1.4.3 Técnicas no desenvolvimento de tipos software. 5

2 ENGENHARIA DE REQUISITOS. 7

2.1 A IMPORTÂNCIA DA QUALIDADE NA EVOLUÇÃO DO SOFTWARE. 7

2.2 O MODELO CMMI 7

2.2.1 Mps-br. 8

2.3 CICLOS DE VIDA DE UM SOFTWARE. 9

3 OTICA DE VISÃO DO PMBOK.. 11

3.1 ÁREAS DE CONHECIMENTO E GRUPOS DE PROCESSO. 12

4 QUALIFICAÇÃO TESTADA.. 14

4.1 TÉCNICAS DE TESTE DE SOFTWARE ATUALMENTE. 14

4.2 PRATICA E ANALISE DE TESTE. 15

4.2.1 Software cleanroom.. 15

4.3 TESTANDO A APTIDÃO DE UM SOFTWARE PARA ATENDER TESTES. 16

CONCIDERAÇÕES FINAIS. 17

LEITURA.. 18

REFERÊNCIAS. 19

GLOSSÁRIO.. 20

1 INTRODUÇÃO

Na prospecção da tecnologia conceitual para a engenharia de software ao longo do tempo teve grandes avanços com o desenvolvimento cada vez maior se tornando mais complexo, então viu-se a necessidade de criar melhores processos que consiste em conjunto de regras que devem ser adotados para serem seguidas quando lidam com projetos, isso em prol é claro da qualidade no processo de criação de um software, sendo assim este conjunto de atividades que são interdependentes, com responsáveis e com entradas e saídas definidas sendo seguido criteriosamente em um projeto possibilita a diminuição do distanciamento da excelência de um produto software, para alcançar a inovação excedendo as expectativas do cliente.

Rocha et al. (2001), no trecho a seguir: “Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo”.

Cada vez mais sistemas controlados por software, fazendo com que a economia de praticamente todos os países seja muito dependente da qualidade dos softwares por eles usados, justificando um investimento significativo nesse setor. Mas logo no início da prospecção do Software, desenvolvia-se de uma maneira completamente artesanal, então de uma simples definição dos requisitos do software já pulava imediatamente para a implementação do mesmo. Hoje em dia, ainda existe muitas empresas que desenvolvem software assim, mas várias outras estão mudando suas formas de trabalho.

O desenvolvimento de software de pequeno porte, no qual não exige muito esforço a forma artesanal de trabalho não traz grandes problemas para a implementação, entretanto os softwares de grande porte, teria sérios problemas na implementação que podem comprometer todo o projeto.

Com o avanço da tecnologia do hardware e consequentemente disponibilidade de máquinas cada vez mais potentes e baratas, o uso de computadores tem-se tornado cada vez mais difundido em diversas áreas. Isso tem feito com que aumente a demanda por software cada vez maior e mais complexo. No entanto, a demanda por software tem-se tornado maior que a capacidade do mercado para atendê-la.

Muitos projetos sem um planejamento adequado são entregues com atrasos e com os custos além do inicial, muitas vezes não tendo um desempenho satisfatório. Projetos sem a qualidade dos testes acabam apresentando erro a pós o lançamento, na tentativa de se concertar os erros, na maior parte das vezes introduzem mais erros. Geralmente, a quantidade de problemas é diretamente proporcional ao aumento da complexidade do software produzido nos dias de hoje. Esses problemas no desenvolvimento de software são conhecidos mundialmente como a “crise de software” e corresponde à incapacidade da indústria de software de atender prontamente à demanda do mercado de software, dentro dos custos e dos níveis de qualidade esperados.

Entrando em um entendimento Histórico mais resumido dês dos anos 1960, quando o termo “crise de software” foi pronunciado pela primeira vez, o mesmo foi tomando proporção e na década de 70 a expressão “crise do software” explodiu, Segundo Wazlawick (2013, p. 1), foi utilizada com impacto pela primeira vez por Dijkstra (1971, p. 859–66), nesta época a Engenharia de Software era uma área sem visibilidade.

1.3 SOFTWARE É ABSTRATO E INTANGIVEL

A engenharia de software é essencial para o funcionamento de sociedade, devido sua total relevância em cada processo em geral.

O software é o termo genérico de programas, é mais fácil chama-lo pelas suas funções ou mesmo pelo nome do programa, também podemos explicar software como um conjunto de instruções responsáveis por permitir a comunicação entre usuário e máquina. Desde os simples sistemas embutidos até os sistemas de informações complexos, são vários tipos de software.

São abstratos, pois, o modelo de processo de software é uma representação abstrata, não são descrições definitivas de processo de software, mas sim abstrações úteis representando uma perspectiva particular.

Software não existe fisicamente então não se vê ou não se toca, sendo assim o software é um ativo intangível que muitas empresas possuem como um bem, de certa forma isso simplifica a engenharia de software, mas com a falta de restrições físicas os sistemas de software podem se tornar extremamente complexos.

Diferentes tipos de software exigem abordagens diferentes, então vendo por este ângulo não encontraremos anotações, métodos ou técnicas universais para a engenharia de software.

1.4 DEFINIÇÃO DE SOFTWARE

A palavra software é bem comum dentro do ramo da tecnologia, (em português: programou programas de computador), entretanto, dentro do ramo da engenharia de software, seu significado e importância vai além do tradicionalmente utilizado.

A Engenharia de Software está preocupada acima de tudo com a qualidade do sistema, cada modelo e metodologia que ela propõe são em prol de uma qualidade satisfatória do software. Os projetos de software costumam ser divididos em conjuntos de atividades, propostos por modelos como o UML, podendo ou não ter algum tipo de dependências entre si, alguns podem ser paralelos e outros com algum nível de independência. Essas atividades costumam reaproveitar sistemas de outro projeto, muitas vezes até melhorando uma versão anterior usada como modelo, agilizando processos e também facilitando o projeto trabalhado.

1.4.1 Características de um software

Pressman (2011) aponta 3 características que descreve o software e consiste em:

(1) instruções (programas de computador) que, quando executadas, fornecem características, funções e desempenho desejados;

(2) estruturas de dados que possibilitam aos programas manipular informações adequadamente;

(3) informação descritiva, tanto na forma impressa como na virtual, descrevendo a operação e o uso dos programas. (PRESSMAN, 2011, p. 32).

O Software não se desgasta com o tempo, mas pode se deteriorar, ficando defasado por exemplo. O mesmo pode ser desenvolvido ou projetado pela engenharia, não manufaturado no sentido clássico. Visando as grandes possibilidades de eficiência e qualidade de um produto software pode ser o principal destaque na melhoria da performance de uma empresa.

1.4.2 Conjuntos de processo de desenvolvimento de software

No desenvolvimento de um projeto de software quanto mais complexo é o software, maior é o empenho que o engenheiro de software deve fazer para desenvolver e tem que ter maior gerenciamento (JALOTE, 2005).

As bases da engenharia de software são conjuntos de atividades para o processo de desenvolvimento de software. Os vários tipos de desenvolvimento de software para resolver problemas são: analise de requisito, design do software, código e teste (JALOTE, 2005).

Analise de requisito: Através da análise de requisito é o momento onde efetua o conhecimento do problema para desenvolve o software (JALOTE, 2005). 

Design do software: Pelo design do software é o momento que o engenheiro de software realiza o planejamento da solução do problema que foi levantado no documento de requisito (JALOTE, 2005). 

Codificação: A codificação é o momento que pega o problema resolvido no design do software e transformará em uma linguagem de programação (JALOTE, 2005). 

Teste: O teste de software é o processo tem a intenção de encontrar defeitos nos artefatos de software (MYERS, 2004). O teste é uma maneira de medir o controle da qualidade do software durante o desenvolvimento de software (JALOTE, 2005)

1.4.3 Atividades fundamentais e comuns a todos os processos de desenvolvimento de software.

Vamos ver de forma resumida sobre os processos comuns e fundamentais no desenvolvimento de software seção 2.2 atividades de processo segundo Sommerville (2011).

Especificação de requisitos: A funcionalidade do software e as restrições em sua operação devem ser definidas, então na especificação de requisitos é incluído quatro fases principais: Estudo de viabilidade; Análise de requisitos; Especificação de requisitos; Validação dos requisitos. Contudo podemos verificar a viabilidade na análise de requisitos, com os requisitos obtidos e traduzidos em um documento, então são catalogados e classificados. Mediante ao realismo, consistência e completude é feito a validação de requisitos.

Projeto e implementação: O software deve ser produzido de modo que atenda a suas especificações, desta forma no desenvolvimento do software é incluído três fases principais: Projeto arquitetural (mais abstrato) define a estrutura modular do software; O Projeto detalhado define para cada modulo do projeto preliminar uma solução; Na Implementação é transcrito as decisões em linguagem de programação.

Verificação e validação: O software tem de ser validado para garantir que ele faça o que o cliente deseja. Então a parti da atividade de validação e feito a depuração do software, em um círculo as atividades percorrem para localizar erro, projetar reparo, reparar erro, re-testar.

Evolução do software: O software deve evoluir para atender às necessidades mutáveis do cliente. (Sommerville 2011)

1.4.3.1 Fases comuns nos modelos de desenvolvimento de softwares.

Não há um modelo rígido e uma sequência obrigatória, pois, em alguns casos pode ocorrer até mesmo de modo paralelo, então não podemos apontar uma sequência obrigatória de fases que deve ser seguido sem considerar a realidade do negócio, da organização e do contexto ao qual está inserido. Veremos as principais fases e atividades comuns nos modelos de desenvolvimento de softwares.

Especificação de requisitos: Envolve uma análise dos requisitos, independentemente do modelo de processos adotado para se desenvolver um software. Será necessário conhecer quais são as necessidades deste software, quais são as restrições e conhecer bem o domínio da aplicação.

Projeto de sistema: Nesta fase envolve o projeto propriamente dito, a partir de análises e tradução dos requisitos para que estes possam ser codificados na próxima fase e permitir uma capacidade de gerência.

Programação (codificação): Desenvolvimento do código-fonte em uma linguagem de programação, que irá representar o controle do sistema, a lógica e as operações de acordo com aquilo que fora descrito e levantado na fase de projetos a partir dos requisitos.

Verificação e integração (validação): Nesta fase são realizados os testes, a verificação do sistema checando se o produto desenvolvido ou seus componentes estão alinhados com as necessidades propostas pelo cliente e a satisfação destes para com o software ou sistema desenvolvido, visando a qualidade do software. Nesta fase também acontece a integração, colocando o sistema em produção para que seus usuários finais possam usá-lo.

Manutenção e evolução: Esta fase prevê as mudanças, ajustes, reparos, melhorias e qualquer alteração que os requisitos venham sofrer após o sistema ser colocado em produção. Esta fase também é conhecida como manutenção e estas atividades podem sofrer tanto mudanças estruturadas como não estruturadas.

1.4.3 Técnicas no desenvolvimento de tipos software

Para determinar quais métodos e técnicas serão utilizadas no desenvolvimento de um software, é necessário primeiramente determinar de que tipo ele será. Segundo Sommerville (2011) alguns dos possíveis tipos de aplicativos são:

Aplicações stand-alone: Aplicações executadas em um computador local, como um PC. Elas contêm toda a funcionalidade necessária e não precisam estar conectadas a uma rede.

Exemplos: programas CAD, software de manipulação de fotos etc.

Aplicações interativas baseadas em transações: Aplicações executadas em um computador remoto, acessadas pelos usuários a partir de seus computadores ou terminais. Aplicações interativas incorporam um grande armazenamento de dados, que é acessado e atualizado em cada transação.

Exemplos de Aplicações incluídas de Web; são aplicações de comércio eletrônico em que você̂ pode interagir com o sistema remoto para comprar produtos ou serviços.

Sistemas de controle embutidos: Controlam e gerenciam dispositivos de hardware. É provável que seja a maioria no mercado atual.

Exemplos de sistemas embutidos incluem softwares em telefone celular, softwares que gerou o Programa Eletrônico de Estabilidade mais conhecido como ABS.

Sistemas de processamento de lotes: São sistemas corporativos projetados para processar dados em grandes lotes. Eles processam grande número de entradas individuais para criar as saídas correspondentes. Exemplos de lotes incluem sistemas periódicos de cobrança e sistemas de pagamentos de salário.

Sistemas de entretenimento: Sistemas que a utilização principal é pessoal e o objetivo é entreter o usuário. A qualidade de interação com o usuário é a característica mais importante.

Exemplo esses são de jogos de diferentes tipos.

Sistemas para modelagem e simulação: São sistemas que incluem vários objetos separados que interagem entre si, desenvolvidos por cientistas e engenheiros para modelar processos ou situações físicas. Requerem sistemas paralelos de alto desempenho para executar, pôs, fazem uso intensivo de recurso computacionais.

Dentre as funcionalidades: orientar o processo de tomada de decisão, proceder análises e avaliações de sistemas e propor soluções para a melhoria de performance.

Sistemas de coleta de dados: São sistemas que coletam dados de seu ambiente com um conjunto de sensores e enviam esses dados para outros sistemas para processamento. O software precisa interagir com sensores e frequentemente é instalado em um ambiente hostil, exemplo; dentro de uma máquina em um lugar remoto.

Por exemplo O SIMA é um conjunto de hardware e software desenhado para a coleta de dados e o monitoramento em tempo real de processos da hidrosfera.

Sistemas de sistemas: São sistemas compostos de uma série de outros sistemas de software. Alguns deles podem ser produtos genéricos de software, como um programa de planilha eletrônica. Outros sistemas do conjunto podem ser escritos

especialmente para esse ambiente. (Sommerville, 2011, p. 7)

2 ENGENHARIA DE REQUISITOS

A Engenharia de Requisitos possui como um dos principais propósitos melhorar a capacidade de entender e definir as características de um sistema antes de sua construção. Um dos seus objetivos é ser a ponte entre os usuários e os desenvolvedores no que devem fazer, existem diferentes maneiras de estruturar um processo com atividades relacionadas à engenharia de requisitos em empresas desenvolvedoras de software.

2.1 A IMPORTÂNCIA DA QUALIDADE NA EVOLUÇÃO DO SOFTWARE

A qualidade de software específica a partir de guias e modelos as melhores práticas de gestão de projetos que auxiliam e buscam obter melhores resultados na integração de escopos, custos, riscos e tempo. Dentre esses modelos temos grandes exemplos como o CMMI e o MPS.BR eles possuem uma divisão de níveis de qualidade que são avaliados a partir de atividades distintas dentro da empresa, podendo assim especificar à empresa um tipo de nível de qualidade baseado em suas próprias atividades e em como elas são geridas.

2.2 O MODELO CMMI

Desenvolvido pelo SEI, o CMMI é uma evolução do CMM, entendendo melhor o modelo CMMI é uma ferramenta no gerenciamento de projetos de Software sendo o mais completo quando o assunto é qualidade de software, tornou-se um modelo de referência que contém práticas (genéricas ou específicas) necessárias à maturidade em disciplinas específicas, é também um modelo de maturidade de melhoria de processos para o desenvolvimento de produtos e serviços. São melhorias práticas que endereçam desde atividades de desenvolvimento até a manutenção do produto, ou seja, é o ciclo de vida inteiro do projeto. Determinam a maturidade da organização conforme os níveis, e cada fase é uma base para o próximo.

A área de processo é um conjunto de práticas relacionadas que, quando são executadas coletivamente, alcançam sensíveis melhoras. As áreas de processos estão organizadas por níveis de maturidade na figura 1.

           figura 1 – níveis de maturidade do CMMI

fonte (autoria própria)

Na figura acima encontrasse os 5 níveis de maturidade CMMI são:

Nível 1: Inicial: os processos normalmente estão envoltos num caos decorrente da não obediência ou ainda, inexistência de padrões;

Nível 2: Gerenciado: os projetos têm seus requisitos gerenciados neste ponto. Além disso, há o planejamento, a medição e o controle dos diferentes processos;

Nível 3: Definido: os processos já estão claramente definidos e são compreendidos dentro da organização. Os procedimentos se encontram padronizados, além de ser preciso prever sua aplicação em diferentes projetos;

Nível 4: Gerenciado Quantitativamente: ocorre o aumento da previsibilidade do desempenho de diferentes processos, uma vez que os mesmos já são controlados quantitativamente;

Nível 5: Otimizado: existe uma melhoria contínua dos processos.

2.2.1 Mps-br

O MPS-BR é uma metodologia voltada à área de desenvolvimento de sistemas e que foi criada por um conjunto de organizações ligadas ao desenvolvimento de software. Muitas instituições envolvidas são de origem acadêmica organizações comumente não-governamentais como a Softex (SP), a RioSoft (RJ), o COPPE/UFRJ (RJ) e o CESAR (PE).

A capacidade de desenvolvimento de software, serviços e as práticas de gestão de RH na indústria de TIC. Para isto, foram elaborados 3 modelos:

MR-MPS-SW: modelo de referência associado à melhoria de processo de Software;

MR-MPS-SV: modelo de referência associado à melhoria de processo de Serviços;

MR-MPS-RH: modelo de referência associado à melhoria de processo de Gestão de Pessoas.

O MPS-BR é compatível inclusive com as práticas do CMMI, a estrutura de maturidade, está de maneira parecida com àquela existente dentro do CMMI.

A baixo mostra os 7 níveis de maturidade previstos pelo MPS-BR:

•                    F: Gerenciado;

•                    E: Parcialmente Definido;

•                    D: Largamente Definido;

•                    C: Definido;

•                    B: Gerenciado Quantitativamente;

•                    A: Em otimização.

De acordo com Wikipédia (2015), cada nível de maturidade do MPS.BR, no MR-MPS, possui suas áreas de processo, onde são analisados:

Processos fundamentais : aquisição; gerência de requisitos; desenvolvimento de requisitos; solução técnica; integração do produto; instalação do produto; liberação do produto.

Processos organizacionais : gerência de projeto; adaptação do processo para gerência de projeto; análise de decisão e resolução; gerência de riscos; avaliação e melhoria do processo organizacional; definição do processo organizacional; desempenho do processo organizacional; gerência quantitativa do projeto; análise e resolução de causas; inovação e implantação na organização.

2.3 CICLOS DE VIDA DE UM SOFTWARE

“Quando os processos possuem um conjunto de regras de maneira mais abstrata e estes são especificados, o consideramos como um modelo de processo” (WAZLAWICK, 2013, p.31).

O modelo de processo adotado em um projeto também é conhecido e chamado de ciclo de vida e atualmente existem vários modelos de processos de software.

Processos de software é o conjunto de atividades que constituem o desenvolvimento de um sistema computacional. Estas atividades são agrupadas em fases, como: definição de requisitos, análise, projeto, desenvolvimento, teste e implantação.

Abrangendo a vida do sistema dês da definição de seus requisitos até o término de seu uso, o ciclo de vida é a estrutura contendo processos, atividades e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto de software. A primeira escolha e o ciclo de vida de um software até a maneira mais adequada de obter as necessidades do cliente e entregar a versão operacional do sistema. Vamos ver as versões resumidamente de 5 ciclos de vida que são:

Modelo em cascata: Formalizado por Royce em 1970, é o modelo mais antigo. O nome do modelo se dá devido ao seu ciclo de vida clássico, que encadeia uma fase com a outra, onde uma fase seguinte não deve começar sem a fase anterior ter terminado. Suas fases ou estágios de suas atividades fundamentais são: Análise e definição de requisitos; Projeto; Implementação; Teste; Integração.

Compreende as atividades fundamentais de especificação, desenvolvimento, validação e evolução e as representa em fases de processo separadas: especificação de requisitos, projeto de software, implementação e teste.

Modelo em V: Neste modelo, do Ministério de Defesa da Alemanha, 1992, o modelo em cascata é colocado em forma de "V". Do lado esquerdo do V ficam da análise de requisitos até o projeto, a codificação fica no vértice e os testes, desenvolvimento, implantação e manutenção, à direita, conforme

Ciclos de vida incremental: Neste modelo, de Mills em 1980, os requisitos do cliente são obtidos, e, de acordo com a funcionalidade, são agrupados em módulos e cada módulo passará por todas as fases "cascata" de projeto. Após este agrupamento, a equipe, junto ao cliente, define a prioridade em que cada módulo será desenvolvido, escolha baseada na importância daquela funcionalidade ao negócio do cliente.

Modelo evolutivo: Neste modelo, os requisitos são adquiridos em paralelo à evolução do sistema, baseia-se em uma implementação de um protótipo inicial que é exposto para comentários do cliente/usuário, podendo sofrer diversos ajustes até que se chegue a um sistema adequado.Devido à grande exigência do cliente sempre está tendo atualização e mudanças bem diferentes comparadas com a anterior

RAD “Rapid Application Development”: Este modelo formalizado por James Martin em 1991, como uma evolução da “prototipagem rápida”, destaca-se pelo desenvolvimento rápido da aplicação. É um ciclo de vida incremental, iterativo, onde é preferível que os requisitos tenham escopo restrito na obtenção dos requisitos, costumam-se optar por metodologias mais dinâmicas e rápidas, como workshops ao invés de entrevistas. Permite-se também um desenvolvimento inicial no nível mais alto de abstração dos requisitos visto o envolvimento maior do usuário e visibilidade mais cedo dos protótipos.

3 OTICA DE VISÃO DO PMBOK

O software para poder ser desenvolvido e realizar a manutenção (mudança) no mesmo é uma tarefa complicada, exige grande esforço da equipe de engenheiro de software. Ao passar do tempo o software fica deteriorado. (PRESSMAN, 2006)

PMBOK não é uma metodologia, pois, não fornece abordagens diferentes de acordo com cada tipo de projeto, isso quer dizer que o PMBOK não contempla peculiaridades de linguagem restritas à cultura de cada organização e também não apresenta modelos únicos de documentos a serem utilizados, ele nada mais é do que uma coletânea de melhores práticas que descreve o universo de conhecimentos para o gerenciamento de projetos, contudo é claro que o PMBOK se torna uma fonte de inspiração pra as metodologias existentes.

A meta do gerenciamento de projetos, segundo o PMBOK é conseguir exceder

as necessidades e expectativas dos stakeholders. Envolve um balanceamento entre as várias demandas concorrentes em relação a:

•                    Escopo, tempo, custo e qualidade (objetivos do projeto);

•                    Stakeholders com necessidades e expectativas diferenciadas;

•                    Requisitos identificados (necessidades) e requisitos não identificados (expectativas).

O PMBOK possui processos para gerenciar os projetos, esses processos fazem parte de todo o ciclo de vida de um projeto, desde a iniciação do projeto, passando pelo planejamento, execução, controle até o encerramento do projeto. Normalmente, os grupos de processos ocorrem paralelamente, isto é, não é necessário que uma atividade termine para que outra comece como podemos ver nos níveis de interação entre processos na figura 2.

Figura 2: Grupo de Processos de Gerenciamento de Projetos

Fonte:PMBOK (5ª edição)

3.1 ÁREAS DE CONHECIMENTO E GRUPOS DE PROCESSO.

Os 47 processos do guia PMBOK são divididos nesses 5 grupos de processo. No Processo de Iniciação tem-se dois processos, no processo de Planejamento temos 24 processos, no processo de execução temos 8 processos, no controle temos 11 processos e no encerramento temos 2 processos.

Grupos de Processos de Iniciação: Neste grupo de processos o escopo inicial é definido e os recursos financeiros iniciais são comprometidos. Além disso, os processos deste grupo também ajudam a decidir se o projeto deve ser continuado, adiado ou interrompido.

Após a autorização para iniciar o projeto ou a fase, possui dois processos para definir um novo projeto ou uma nova fase de um projeto existente. Se o projeto é dividido em fases cada um dos processos do grupo de iniciação é revisitado em cada uma das fases.

Grupos de Processos de Planejamento: Este grupo possui 24 processos realizados para definir o escopo do projeto, refinar os objetivos e desenvolver os cursos de ação necessários para alcançar os objetivos para os quais o projeto foi criado. O Planejamento do projeto é iterativo e continuo progressivamente, não precisa definir todo planejamento do projeto no seu início e sim em ondas sucessivas na medida que o projeto vai evoluindo e mais informações vão sendo coletadas.

Grupos de Processos de Execução: O grupo de execução possui outros 8 processos utilizados para executar o trabalho definido no plano de gerenciamento do projeto para satisfazer as especificações do mesmo.

Nesses processos é que a maior parte do orçamento será consumido. Também durante a execução é que pode ser necessário atualizar o planejamento e mudar alguns planos de gerenciamento.

Grupos de Processos de Controle e Monitoramento: Este Grupo de Processos possui 11 processos necessários para acompanhar, revisar e regular o progresso e o desempenho do projeto, identificar todas as áreas nas quais serão necessárias mudanças no plano e iniciar mudanças correspondentes.

É nos processos deste grupo que o desempenho do projeto é observado e mensurado de forma periódica e uniforme para identificar variações em relação ao plano. O grupo de processo de controle possui processos em todas as áreas menos na de recursos humanos.

Grupos de Processos de Encerramento: Este grupo possui 2 processos executados para finalizar todas as atividades de todos os processos visando encerrar formalmente o projeto ou a fase.Os processos de encerramento incluem a aceitação do cliente e do patrocinador, revisão pós-relevantes.

figura 3 – tabela de relacionamento entre áreas de conhecimento e grupos de processo. Fonte livro: Scrum e PMBOK unidos no gerenciamento de projetos ed.Brasport.

Na figura 3 a baixo podemos ver o número de processos que existem nas áreas de conhecimento e nos grupos de processos. As áreas de conhecimento são outra forma de organizar os 47 processos do guia PMBOK, no entanto, agora divide-se por áreas e não mais por um grande grupo de processos

4 QUALIFICAÇÃO TESTADA

A Verificação envolve a análise de um sistema para certificar se atende aos requisitos funcionais e não funcionais. A Validação, é a certificação de que o sistema atende as necessidades e expectativas do cliente.

Os benefícios são bem mais econômicos e praticamente a prova de erros, pois, os erros são absurdamente diminuídos comparado com um projeto tradicional.

4.1 TÉCNICAS DE TESTE DE SOFTWARE ATUALMENTE

Existem muitas maneiras de se testar um software, diversos autores dão sugestões de como um software deveria ser projetado para se atingir um alto grau de testabilidade. Existem as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje são utilizadas para os sistemas orientados a objeto, apesar do desenvolvimento ser diferente o objetivo principal destas técnicas continua a ser o mesmo, encontra falhas no software.

Técnica Estrutural (ou teste caixa-branca) Técnica de teste que avalia o comportamento interno do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos e teste de caminhos lógicos (PRESSMAN, 2006).

Teste Funcional (ou teste caixa-preta) Técnica de teste em que o componente de software a ser testado é abordado como se fosse uma caixa-preta, ou seja, não se considera o comportamento interno do mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. A técnica de teste funcional é aplicável a todos os níveis de teste (PRESSMAN, 2006)

Particionamento em classes de equivalência: Esse critério divide o domínio de entrada de um programa em classes de equivalência, a partir das quais os casos de teste são derivados. Ele tem por objetivo minimizar o número de casos de teste, selecionando apenas um caso de teste de cada classe. Eventualmente, pode-se também considerar o domínio de saída para a definição das classes de equivalência (ROCHA et al., 2001).

Análise do valor limite: Por razões não completamente identificadas, um grande número de erros tende a ocorrer nos limites do domínio de entrada invés de no “centro”. Esse critério de teste explora os limites dos valores de cada classe de equivalência para preparar os casos de teste (PRESSMAN, 2006).

Outras técnicas de teste podem e devem ser utilizadas de acordo com necessidades de negócio ou restrições tecnológicas. Destacam-se as seguintes técnicas: teste de desempenho, teste de usabilidade, teste de carga, teste de stress, teste de confiabilidade e teste de recuperação.

4.2 PRATICA E ANALISE DE TESTE

A Inspeção de software podendo trabalhar em conjunto com outras técnicas SW, é o ato de analisar as representações do sistema, analisar os documentos de requisitos, diagramas e código-fonte, esta análise estática pode ser completada por analises automática de texto de origem do sistema ou dos documentos associados. Podem ser utilizadas outras técnicas em conjunto como a Inspeção de SW

O teste de software preocupasse com a execução e observação, desta forma é feito a verificação dinâmica do sistema operacional, executando-o com dados de teste e o seu comportamento operacional é observado.

Ligando todo o ciclo de vida do sistema, deve ser aplicado a Técnica V&V, deve estabelecer a confiança de que o Sistema é adequado ao seu propósito, devendo atender as necessidades dos usuários e que seja útil para a tarefa pretendida.

4.2.1 Software cleanroom

Para maior produtividade e organização é usado o Checklist, as classes verificadas na Inspeção são:

1.                 Defeito de Dados,

2.                 Defeito de Controle,

3.                 Defeito de Entrada e Saída,

4.                 Defeito de Interface,

5.                 Defeito do Gerenciamento de Armazenamento e

6.                 Defeito de Gerenciamento de Exceções.

O desenvolvimento de Software Cleanroom tem como principal objetivo o sistema sem defeito pelo processo de Inspeções, o processo de desenvolvimento tem as seguintes etapas:

1.                 Especificar Formalmente o Sistema;

2.                 Desenvolver Perfil Operacional;

3.                 Definir Incremento de SW;

4.                 Projetar Testes Estáticos;

5.                 Construir Programa Estruturado;

6.                 Verificar Código;

7.                 Integrar Incremento;

8.                 Testar Sistemas Integrados.

4.3 TESTANDO A APTIDÃO DE UM SOFTWARE PARA ATENDER TESTES

Os testes devem ter uma série de características que permitam atingir o objetivo de encontrar o maior número de erros (PRESSMAN, 2011, p. 429).

Segundo as definições clássicas:

Testabilidade: A facilidade com que um programa de computador pode ser testado.

Operabilidade: Quanto melhor funcionar, mais eficientemente pode ser o teste sem sobressaltos.

Observabilidade: O código-fonte é acessível as entradas fornecidas como parte do teste produzem saídas distintas. Estados e variáveis do sistema são visíveis ou podem ser consultados durante a execução.

Controlabilidade: O teste pode ser automatizado e otimizado convenientemente especificados, automatizados e reproduzidos. Estados e variáveis de software e hardware podem ser controlados diretamente pelo engenheiro de teste.

Decomponibilidade: Controlando o escopo do teste, podemos isolar problemas

mais rapidamente e executar um releste mais racionalmente. O sistema de software é construído a partir de módulos independentes que podem ser testados de forma independente.

Simplicidade: simplicidade estrutural e simplicidade de código.

Estabilidade: As alterações no software são pouco frequentes, controladas quando elas ocorrem e não invalidam os testes existentes.

Compreensibilidade: Quando por exemplo em um projeto a documentação técnica é instantaneamente acessível, bem organizada, especifica, detalhada e precisa. Alterações no projeto são comunicadas aos testadores. (PRESSMAN, 2011, p. 429).

CONCIDERAÇÕES FINAIS

A Engenharia de Software visa à criação de produtos de software que atendam às necessidades de pessoas e instituições e, portanto, tem valor econômico. Para isso, usa conhecimentos científicos, técnicos e gerenciais, tanto teóricos quanto empíricos. Ela atinge seus objetivos de produzir software com alta qualidade e produtividade quanto é praticada por profissionais treinados e bem informados, utilizando tecnologias adequadas, dentro de processos que tirem proveito tanto da criatividade quando da racionalização do trabalho.

Os ciclos de vida se comportam de maneira sequencial, por tanto fases seguem determinada ordem. Desta forma podemos ver que utilizar um modelo de ciclo de vida do software é uma das melhores formas de garantir um bom alinhamento entre o desenvolvimento do software e a necessidade do usuário que irá utilizá-lo. Vimos também que não existe o modelo ideal, e sim o que é melhor aplicado para cada necessidade.

É substancialmente preterível testar seu projeto para ter uma análise detalhada das normas seguidas, azeitar os erros e corrigi-lo antes do lançamento do software, então a verificação e a validação de um projeto, assegurando que o software seja adequado confirmando que este cumpra suas especificações.

Tomando entendimento sobre o assunto da complexidade do desenvolvimento do software não termina no lançamento do produto final, existe processos complexos de análise de erros antes do produto ser lançado para evitar uma demanda de insatisfação do cliente, além do mais precisa de melhoria constante para o produto não ficar defasado, por estes motivos precisa de atualizações. Desta forma claramente e entendível que a qualidade na criação de um software é extremamente importante por este motivo foi criado técnicas com abordagens criteriosas com base em um conjunto de regras.

LEITURA

Sobre o MPS.BR existem alguns artigos interessantes disponíveis na Internet, bem como o Guia Geral que contém a descrição geral do MPS.BR e detalha o Modelo de Referência (MR -MPS) e as definições comuns necessárias para seu entendimento e aplicação, que pode ser encontrado aqui: https://promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/

Uma abordagem para condução de iniciativas de melhoria de processos de software, disponível em: http://migre.me/oJyDC

MAZIERO, Carlos Alberto. Virtualização. Sistemas Operacionais: Conceitos e Mecanismos. Disponível em: http://wiki.inf.ufpr.br/maziero/lib/exe/fetch.php?media=socm:socm-31.pdf

Li somente alguns trechos para a elaboração deste material, mas foi interessante e envolvente a parte I do livro de Pressman, 2011, “Engenharia de Software, Uma abordagem profissional”.

SPÍNOLA, R.O., ÁVILA, A.L., 2008. Introdução à Engenharia de Requisitos. Engenharia de Software Magazine, Edição 1;

REFERÊNCIAS

ROCHA, A. R. C.; Maldonado, J. C.; Weber K. C. et al. Qualidade de Software: Teoria e Prática. 1. ed.Prentice Hall. São Paulo: 2001.

WAZLAWICK, R. S. Engenharia de Software: Conceitos e Práticas, 1ª .ed. Elsevier, 2013.

DIJKSTRA, E. W. The Humble Programmer. Communications of the ACM 15(10), 1971.

PRESSMAN, Roger S. Engenharia de software : uma abordagem profissional; tradução Ariovaldo Griesi, Mario Moro Fecchio ; revisão técnica Reginaldo Arakaki, Renato Manzan de Andrade. 7. ed. Porto Alegre : AMGH, 2011.

JALOTE, P. An Integrated Approach to Software Engineering. 3. ed. New York: Springer, 2005.

MYERS, G. J. The Art of Software Testing. 2. ed. New York: John Wiley & Sons, 2004.

SOMMERVILLE, I. Engenharia de software. 6.ed. São Paulo: Addison Wesley, 2003.

PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paula: McGraw-Hill, 2006.

SOMMERVILLE, Ian. Engenharia de software: tradução Ivan Bosnic e Kalinka G. de O. Gonçalves. revisão técnica Kechi Hirama. 9. ed. São Paulo : Pearson Prentice Hall, 2011.

PMI. Um Guia do Conhecimento em Gerenciamento de Projetos: Guia PMBOK. 5ª Ed, 2013.

NORMAS NBR ISO 12207.ABNT. Ciclo de vido do software.  Disponível em < http://abnt.org.br/paginampe/biblioteca/files/upload/anexos/pdf/fc0fb7a9f049313e04764fc144d0e0f7.pdf> Acesso em : 27 abr. 2021.

COLETA de dados e monitoramento. SIMA .2021. Disponível em <http://www.dsr.inpe.br/hidrosfera/sima/> Acesso em: 26 abr. 2021.

MODELO cmmi. SEI .2021. Disponível em < http://www.sei.cmu.edu/> acesso em: 27.abr.2021

MELHORIA de Processos do Software Brasileiro.Wikipedia. Disponível em:<

http://pt.wikipedia. org/wiki/Melhoria_de_Processos_do_Software_Brasileiro > . Acesso em: 26 abr. 2021.

GLOSSÁRIO

PMBOK: tradução Conjunto de conhecimentos em gerenciamento de projetos, é de autoria do Project Management Institute (PMI) ou, mais precisamente, do PMI Standards Committee, o comitê de padronização do PMI.

PMI: Instituto de Gerenciamento de Projetos:é uma associação de profissionais de gerenciamento de projetos que existe desde 1969.

STAKEHOLDERS: significa público estratégico e descreve todas as pessoas ou "grupo de interesse" que são impactados pelas ações de um empreendimento, projeto, empresa ou negócio.

CMMI: (Capability Maturity Model ® Integration – Modelo Integrado de Maturidade e de Capacidade) é um modelo de maturidade para melhoria de processo, gerido pelo CMMI Institute®, para o desenvolvimento de produtos e serviços.

CMM: (Capability Maturity Model em português Modelo de Maturidade em Capacitação), também conhecido como Software CMM (SW-CMM) pode ser definido como sendo uma soma de "melhores práticas" para diagnóstico e avaliação de maturidade do desenvolvimento de softwares em uma organização.

MPS-BR: (Melhoria do Processo de Software Brasileiro): é um programa da Softex com apoio do Ministério da Ciência, Tecnologia e Inovações (MCTI). Área de Qualidade da Softex é responsável por apoiar a inserção da cultura da qualidade de software e serviços.

UCSD: p-System era o sistema operacional escrito em Pascal da Universidade da Califórnia (University of California Software Distribution - Pascal System). Consistia em um sistema operacional que executava programas em pseudo-código, chamados de p-code, em uma máquina virtual previamente escritos em Pascal.

SEI: (Software Engineering Institute)é um centro de pesquisa e desenvolvimento patrocinado pelo Departamento de Defesa dos Estados Unidos que provê uma prática avançada de engenharia de software qualificando graus de qualidade de software.

IBM: máquina de negócio internacional: é uma empresa dos Estados Unidos voltada para a área de informática.

A empresa é uma das poucas na área de tecnologia da informação (TI) com uma história contínua que remonta ao século XIX.

CAD: Projeto de Desenho Assistido por Computador é a utilização sistemas computacionais para auxiliar na criação, modificação, análise, ou otimização de um projeto

SOFTEX: Organização Social Civil de Interesse Público (OSCIP) atua há 24 anos em prol do fomento da Transformação Digital Brasileira.

RIOSOFT: é marca registrada da Cia. Brasileira de Software e Serviços Ltda.

COPPE: Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa de Engenharia, da Universidade Federal do Rio de Janeiro.

UML: Unified Modeling Language, em português Linguagem de Modelagem Unificada: é uma linguagem-padrão para a elaboração da estrutura de projetos de software.

Quais são as principais características de um software?

Quais são os três principais elementos da engenharia de software?

Quais os princípios de engenharia de software?

Quais são as principais atividades da engenharia de software?