Engenharia de Software

Prévia do material em texto

2
AULA 1 - FUNDAMENTOS DE SOFTWARE E GERENCIAMENTO DE PROJETOS
Descrição
O processo de desenvolvimento de software e sua aplicação no Gerenciamento de Projeto.
Propósito
Compreender a importância do processo de desenvolvimento de software e do Gerenciamento de Projetos no contexto da Engenharia de Software.
Objetivos
· Módulo 1: Reconhecer os conceitos básicos relacionados com o desenvolvimento de software
· Módulo 2: Descrever as etapas essenciais de um processo de desenvolvimento de software
· Módulo 3: Relacionar as etapas de um processo de desenvolvimento de software com as etapas de Gerenciamento de Projeto
· Módulo 4: Descrever a importância do Gerenciamento de Risco no projeto de software
Introdução
Nos dias atuais, a importância do software é facilmente perceptível em função dos inúmeros serviços digitais disponíveis na nossa Sociedade da Informação. Em outros cenários, o software também está presente em sistemas de controle de veículos, aviões, refinarias entre outros.
Podemos afirmar que o “produto” software tem que ser projetado aplicando-se as melhores práticas da engenharia, pois quais seriam as consequências de um defeito de software em uma aeronave com 500 pessoas ou na falha de um sistema de controle de tráfego aéreo? Realmente, o software necessita das melhores práticas da engenharia no seu projeto.
Neste contexto, destaca-se a disciplina Engenharia de Software, que trata dos aspectos técnicos que permitem a geração do “produto” software. De uma forma geral, a engenharia, qualquer que seja, necessita de processos. Em função dessa premissa, podemos afirmar que não existe engenharia sem processo.
O processo de desenvolvimento de software inclui algumas etapas básicas, cujo momento de aplicação depende do modelo adotado pelo engenheiro de software.
Uma área de conhecimento importante, aplicada em qualquer engenharia, é o Gerenciamento de Projeto. Ele permite elaborar um plano de projeto onde são otimizados os recursos, que incluem pessoas, materiais e equipamentos. A metodologia de gerenciamento de projeto permite, a partir de requisitos identificados nas primeiras etapas do processo de qualquer engenharia, a geração do produto objeto do projeto de acordo com o planejado e de forma controlada.
A Engenharia de Software está alinhada com a área de conhecimento Gerenciamento de Projetos, sendo esta fundamental ao engenheiro de software. Cabe um destaque especial nesse contexto ao Gerenciamento de Riscos, principalmente, na seleção de portfólio de projetos de software.
Módulo 1
Reconhecer os conceitos básicos relacionados com o desenvolvimento de software
Software
Seria possível a sua vida hoje sem o smartphone?
Acredito que a maioria em uma pesquisa iria responder um enfático “não”!
O que você acha que torna o telefone móvel tão atrativo? O software?
É provável, pois, não descartando a importância do hardware, o software permite uma relação de usabilidade interativa e intuitiva, gerando um uso intensivo. Essa competência é resultado de trabalho multidisciplinar árduo de engenheiros de softwares, administradores de banco de dados, web designers, entre outros profissionais. Neste contexto, vamos iniciar nosso estudo sobre a extraordinária área de conhecimento Engenharia de Software, que tem como principal produto o software.
ATENÇÃO: Destacamos que a bibliografia Pressman (2016) é uma referência mundial nessa área.
O conceito de software a seguir define esse importante produto.
SOFTWARE CONSISTE EM:
(1) INSTRUÇÕES (PROGRAMA 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; E (3) INFORMAÇÃO DESCRITIVA, TANTO NA FORMA IMPRESSA QUANTO NA VIRTUAL, DESCREVENDO A OPERAÇÃO E O USO DOS PROGRAMAS.
(PRESSMAN, 2016).
Implicitamente, o software relaciona-se com o hardware. Essa relação gerou a denominada “Crise do Software”, sintetizada pela afirmativa a seguir de Edsger.
A MAIOR CAUSA DA CRISE DO SOFTWARE É QUE AS MÁQUINAS SE TORNARAM VÁRIAS ORDENS DE MAGNITUDE MAIS POTENTES! EM TERMOS DIRETOS, ENQUANTO NÃO HAVIA MÁQUINAS, PROGRAMAR NÃO ERA UM PROBLEMA; QUANDO TIVEMOS COMPUTADORES FRACOS, ISSO SE TORNOU UM PROBLEMA PEQUENO; E AGORA QUE TEMOS COMPUTADORES GIGANTESCOS, PROGRAMAR TORNOU-SE UM PROBLEMA GIGANTESCO.
(DIJKSTRA, 1972).
É importante destacar que o desenvolvimento tecnológico do hardware nos últimos anos permitiu o desenvolvimento de softwares cada vez mais complexos, tendo um forte impacto na indústria de software. Como exemplo, podemos apresentar a substituição do paradigma estruturado pelo paradigma orientado a objetos, baseado na programação orientada a objetos que permite o reuso intensivo de especificação, bem como uma melhor manutenibilidade e, como consequência, o desenvolvimento de softwares mais complexos.
Vamos enfatizar uma das principais finalidades do software: a geração de informação. A figura acima, ilustra de forma implícita os principais componentes tecnológicos de um Sistema de Informação, i.e., hardware, software, sistema gerenciador de banco de dados, redes de comunicação e serviços, sendo os referidos componentes interdependentes. O ambiente empresarial está representado pela respectiva pirâmide funcional, cabendo ao componente software, o importante papel de agregar valor aos dados quando da geração de informações aos diferentes níveis de gestão – operacional, gerencial e estratégico, pois essa pode ser utilizada em um processo de tomada de decisão ou no controle de funções empresariais, tais como financeiro, recursos humanos e outras.
Um segundo exemplo, vamos considerar a complexidade do desenvolvimento de um software embarcado em uma aeronave com 500 pessoas e que realiza o seu controle total, em que um defeito pode ter um impacto altamente negativo.
Vamos imaginar o que seria do piloto sem as informações do voo no painel de controle.
Em ambos exemplos, observamos que o software apresenta dois papéis distintos, o primeiro como um produto a ser utilizado pelos usuários, o segundo como veículo que distribui o produto, pois a comunicação entre os diversos componentes de um sistema de informação ocorre por meio de sistemas operacionais, software de comunicação entre outros. O software distribui o produto mais importante da nossa era – a Informação (PRESSMAN, 2016).
Você consegue imaginar quais os desafios atuais de um engenheiro de software? Destacamos que os desafios incluem sete grandes categorias:
	Software de sistema
	Camadas de software que atendem a outros softwares, tais como, sistemas operacionais, drivers e outros.
	Software de aplicação
	Inclui software com escopo específico, tais como, sistemas de gestão empresarial (ERP).
	Software de engenharia/científico
	Inclui software aplicado às áreas de engenharia e científica, tal como, software para cálculo estrutural na área de engenharia civil ou processamento de imagem.
	Software embarcado
	Instalado em produtos com funções específicas, tal como, o controle de um veículo com informações disponíveis no painel digital.
	Software para linha de produtos
	Projetado com determinado conjunto de funcionalidades e utilizado por diferentes clientes, por exemplo, sistema emissor de nota fiscal.
	Aplicações web/aplicativos móveis
	Software específico para dispositivo móvel.
	Software de inteligência artificial
	Utilizam técnicas de inteligência artificial, tais como, sistema especialistas, redes neurais, aprendizado de máquinas e outros.
Engenharia de software
Vimos nos exemplos do software embarcado em uma aeronave ou controlando o tráfego aéreo uma característica comum: a complexidade. A melhor tratativa para a complexidade é a aplicação de metodologia que permita a decomposição do problema em problemas menores de forma sistemática, cabendo à engenharia essa sistematização.
Uma premissa básica é que a engenharia permite a solução de problemas e, quanto mais complexo um produto a ser gerado, mais a engenharia faz-se necessária.
Vamos ver no caso daconstrução de uma simples casa, talvez um engenheiro resolva o problema; e no caso de um edifício inteligente com vários andares? Neste caso, o problema tornou-se multidisciplinar, ou seja, serão necessários vários profissionais de várias áreas, e.g., arquiteto, engenheiros civis, mecânicos, elétricos, de software etc. A construção do prédio torna-se inviável caso não haja uma tratativa sistemática por meio da aplicação das melhores práticas da engenharia.
A mesma correlação pode ser aplicada quando o produto a ser gerado é o software. No caso do software, aplica-se a Engenharia de Software.
O desenvolvimento de software deve submeter-se aos mesmos princípios aplicados nas engenharias tradicionais, sendo um produto distinto em função da sua intangibilidade que o associa, muitas vezes, somente aos códigos dos programas de computador. Entretanto, diferentemente de outros produtos de outras engenharias em produção, possui alta volatilidade em função de constantes evoluções na tecnologia e nos requisitos, agregando ao software uma complexidade adicional.
A primeira referência ao termo “Engenharia de Software” foi em 1968, em uma conferência sobre o tema, sob responsabilidade do Comitê de Ciência da NATO (North Atlantic Treaty Organization). Nesse contexto, o Guide to the Software Engineering Body of Knowledge Version 3.0 (SWEBOK Guide V3.0) apresenta a seguinte definição para a Engenharia de Software:
A APLICAÇÃO DE UMA ABORDAGEM SISTEMÁTICA, DISCIPLINADA E QUANTIFICÁVEL PARA O DESENVOLVIMENTO, OPERAÇÃO E MANUTENÇÃO DE SOFTWARE, QUE É A APLICAÇÃO DE ENGENHARIA AO SOFTWARE.
Tecnologia em camadas
A Engenharia de Software é uma tecnologia em camadas, como ilustra a figura abaixo. Vejamos as descrições das referidas camadas:
	Camada de qualidade
	Garante que os requisitos que atendem às expectativas do usuário serão cumpridos.
	Camada de processo
	Determina as etapas de desenvolvimento do software.
	Camada de métodos
	Define, por exemplo, quais as técnicas de elicitação de requisitos, os artefatos gerados em função da técnica de modelagem adotada, tal como, modelo de casos de uso ou de classes.
	Camada de ferramentas
	Estimula a utilização de ferramentas “CASE” (Computer-Aided Software Engineering) no desenho dos diversos artefatos ou mesmo na geração automática de código, entre outras aplicações; a tecnologia CASE está disponível para uso em todas as etapas do processo de desenvolvimento de software.
Considerando um produto tangível para todos nós, você poderia imaginar que um dia construirá sua casa própria? Vamos imaginar que sim. O que você precisaria para levar em frente esta construção? Um processo?
Certamente, pois terá que organizar as etapas da construção: fundação, estrutura, cobertura, alvenaria, instalações etc. Agora a construção da casa fica mais fácil.
Da mesma maneira, a construção de um software necessita de processo; esse deverá ocorrer de acordo com as melhores práticas estabelecidas pela Engenharia de Software.
É importante destacar que a base da Engenharia de Software é a camada de processo.
Processo de software
Processo é uma sequência de etapas que permitem a geração de um produto, no nosso caso, o software. O processo permite uma melhor tratativa em relação à complexidade de obtenção de um determinado produto, pois, na maioria das vezes, é um trabalho multidisciplinar realizado por analistas, programadores, gerentes de projeto, gerentes de teste e outros profissionais.
Assim como em todas as engenharias, a Engenharia de Software possui uma diversidade de modelos para processos de desenvolvimento de software que atendem a diferentes problemas.
Um requisito importante na seleção de um processo de software é a complexidade. Basicamente, quanto maior a complexidade de um sistema, mais formal deve ser o processo adotado. Importante: a qualidade é a camada base que sustenta a camada processo.
Uma metodologia de processo genérica compreende cinco atividades:
	Comunicação
	As primeiras atividades de um processo de software requerem uma comunicação intensiva com os usuários, buscando o entendimento do problema, a definição de objetivos para o projeto, bem como a identificação de requisitos.
	Planejamento
	Destaca-se nesta atividade a área de conhecimento Gerenciamento de Projeto, que permitirá a elaboração de um Plano de Gerenciamento do Projeto de forma sistemática, tendo como entrega importante o cronograma que inclui as atividades a serem desenvolvidas no referido projeto, contemplando diferentes áreas de conhecimento.
O processo de desenvolvimento de software disponibiliza as principais atividades que irão compor o Plano de Gerenciamento do Projeto, sendo esse plano executado e monitorado.
	Modelagem
	A engenharia tem como melhor prática a geração de modelos, tal como a planta baixa de uma casa. A maioria desses modelos gráficos, denominados de diagramas na Engenharia de Software, podem ser complementados por descrições textuais. Como exemplo, apresentamos o modelo de casos de uso que inclui diagramas de casos de uso, artefatos gráficos e descrições de cenários dos casos de uso, artefatos textuais.
	Construção
	A partir dos modelos gerados, é realizada a construção ou implementação do software, portanto, os modelos determinam o comportamento do software. Essa atividade inclui a codificação e os testes de software de acordo com o planejado.
	Entrega
	Ao final, ocorre o objetivo de um plano de projeto de software, i.e., a entrega do produto em produção de acordo com o planejado.
As atividades básicas apresentadas são complementadas pelas denominadas “atividades de apoio”, que incluem:
	Controle e acompanhamento de projeto
	Dentro do princípio de que “não se controla o que não se mede”, a etapa do Gerenciamento de Projeto Monitoramento e Controle permite verificar se a execução está de acordo com o planejado, pois, caso seja identificada alguma não conformidade, ações corretivas devem ser implementadas.
	Administração de riscos
	Ênfase à área de Gerenciamento de Risco, de modo que qualquer evento, positivo ou negativo que possa impactar o desenvolvimento do projeto, seja tratado.
	Garantia da qualidade de software
	Ênfase à área de Gerenciamento da Qualidade, a fim de garantir que os requisitos do projeto sejam atendidos.
	Revisões técnicas
	Atividade intrínseca da qualidade, pois todos os artefatos devem ser testados, inclusive, processos, modelos, código do software e outros.
	Medição
	Outra atividade da qualidade que permite a definição de métricas para avaliar as várias atividades durante o desenvolvimento do software.
	Gerenciamento da configuração de software
	Inclui os efeitos das mudanças, por exemplo o gerenciamento de versionamento do software em um processo iterativo e incremental, onde um defeito em produção pode surgir em uma versão anterior à desenvolvida no momento, sendo a manutenção realizada na versão anterior e propagada para a versão atual. Este procedimento, muitas vezes, exige uma ferramenta que automatize a solução deste problema, que pode ser bem complexo.
	Gerenciamento da capacidade de reutilização
	O reuso de software deve ser um objetivo persistido por quem desenvolve o software. No paradigma estruturado, existiam as bibliotecas de funções que permitiam a reutilização de código em várias aplicações com possibilidades bem limitadas e com o advento do paradigma orientado a objetos, o reuso ficou mais sofisticado em função de mecanismos, e.g. herança, que possibilitam uma melhor componentização do software.
	Preparo e produção de artefatos de software
	Um processo de software encadeia uma série de atividades, sendo que estas atividades possuem métodos próprios para a geração de artefatos que necessitam ser documentados, e.g., modelo de casos de uso.
Cabe ao engenheiro de software documentar cada atividade que será aplicada no processo de desenvolvimento de software em função da natureza do problema (complexidade), das características das pessoas que realizarão o trabalho e dos usuários envolvidos.
Resumindo
Nestemódulo, podemos destacar a importância do software atualmente, bem como da complexidade no seu desenvolvimento. A aplicação da Engenharia de Software permite lidar com a referida complexidade, pois melhores práticas podem ser aplicadas de forma a gerar um produto “software” que atenda às necessidades para as quais foi projetado.
Destacamos que a Engenharia de Software é uma tecnologia em camadas, ou seja, com foco na qualidade, processo, métodos e ferramentas. Cabe enfatizar que a base da Engenharia de Software é a camada de processo, por isso foram descritas as principais atividades genéricas que devem compor um processo de software: comunicação, planejamento, modelagem, construção e entrega.
Módulo 2
Descrever as etapas essenciais de um processo de desenvolvimento de software
Você sabe por que se aplica de forma intensa o conceito de abstração no desenvolvimento de software?
Porque o processo de software é iniciado com especificações e modelos com alto nível de abstração e, à medida que o desenvolvimento de software se aproxima da codificação, o nível de abstração diminui, de modo que o código representa o nível mais baixo da abstração ou de maior detalhamento na especificação do software.
Vamos agora diminuir o nível de abstração do Modelo Genérico apresentado no módulo 1 (figura acima), ou seja, aumentar os detalhes das atividades do processo de software.
Processo de desenvolvimento de software
O engenheiro de software deverá definir qual o processo de desenvolvimento a ser aplicado em um determinado projeto de software como especificação de requisito não funcional. Inicialmente, terá que identificar quais as atividades que irão compor o desejado processo e, em seguida, definir o sequenciamento das referidas atividades, ou seja, o fluxo do processo.
As atividades típicas que compõem o processo de desenvolvimento de software estão ilustradas na figura abaixo. O objetivo é ilustrar as atividades mais comuns que compõem os processos de desenvolvimento de software, ou seja, qualquer processo deverá possuir as referidas atividades.
Vamos agora descrever cada uma das atividades comumente previstas em um processo de desenvolvimento de software.
Etapa de levantamento de requisitos
A primeira etapa, também denominada de Elicitação de Requisitos, inclui o primeiro desafio do engenheiro de software, entender o problema!
Imagine você como engenheiro de software, projetando um software para o mercado financeiro! O desafio impressiona? Talvez você concorde comigo – “sim”!
Realmente, o desafio é grande, pois o referido engenheiro, normalmente, não entende do ambiente de negócio que o software será implementado. Portanto, terá que se comunicar com diferentes usuários que, muitas vezes, entendem de somente parte do problema; para tal, deverá utilizar diferentes técnicas de levantamento de requisitos, tais como, entrevistas, questionários, leituras de documentos, etnografia e outros.
Nesta etapa, são identificados os requisitos que serão implementados no software projetado. O grande desafio é que o engenheiro de software tenha o mesmo entendimento do negócio que os usuários.
Neste momento, precisamos apresentar a conceituação de requisito:
OS REQUISITOS DE UM SISTEMA SÃO DESCRIÇÕES DOS SERVIÇOS FORNECIDOS PELO SISTEMA E AS SUAS RESTRIÇÕES OPERACIONAIS. ESSES REQUISITOS REFLETEM AS NECESSIDADES DOS CLIENTES DE UM SISTEMA QUE AJUDA A RESOLVER ALGUM PROBLEMA.
SOMMERVILLE, 2007.
A partir dessa conceituação, identificamos a tipificação de requisitos comumente utilizada: requisitos funcionais, não funcionais e de domínio.
	Requisitos funcionais
	Estão relacionados com os serviços fornecidos pelo sistema, ou seja, as funcionalidades que estarão disponíveis no software, tal como, a geração de um histórico escolar em um sistema de gestão acadêmico ou geração de uma nota fiscal em um sistema de vendas
	Requisitos não funcionais
	Incluem as restrições operacionais impostas ao software, tais como, o sistema gerenciador de banco de dados, a linguagem de programação, legislação pertinente à compliance, entre outros, bem como os requisitos de qualidade, tais como: confiabilidade, manutenibilidade, usabilidade e outros
	Requisitos de domínio
	Também são conhecidos como “regras de negócio”, que, normalmente, apresentam-se como restrições ao requisito funcional. Como exemplo, temos o cálculo da média para aprovação em uma determinada disciplina, a contagem de pontuação de multas para computo da perda de uma carteira de motorista ou o cálculo dos impostos quando da geração de uma nota fiscal. O não cumprimento de um requisito de domínio pode comprometer o uso do sistema
Cabe destacar que Sommerville (2007) apresenta uma classificação relativa aos níveis de abstração aplicados na descrição dos requisitos, utilizando o termo requisitos de usuários, para especificação com alto nível de abstração, e requisitos de sistema, para especificação com descrições detalhadas, ou seja, com baixo nível de abstração. Realizada essa primeira classificação, os requisitos de sistema são tipificados em funcionais, não funcionais e de domínio, como anteriormente apresentados.
Muitos estudos destacam a importância desta etapa, pois o mau entendimento de um requisito é propagado nas próximas etapas no processo, ilustrado na figura acima, refletindo de forma negativa no produto software.
Quando da especificação de requisitos, o engenheiro de software firma um contrato com os usuários, de modo a definir qual produto de software será entregue. A participação dos usuários envolvidos, ou clientes, deve permitir feedbacks sobre defeitos na especificação, evitando a propagação dos referidos defeitos.
Nesta etapa do PDS, normalmente, é realizada uma entrega, ou uma especificação, denominada de Documento de Requisitos, sendo determinado o Escopo do projeto.
A partir desse documento, inicia-se a rastreabilidade dos requisitos, ou seja, a relação com os produtos gerados, e.g. modelos, a partir dos mesmos.
Exemplo: Na etapa de Análise, é gerado o modelo de casos de uso e o modelo de classes; na etapa de Projeto, o modelo de interação; e na etapa de Implementação, a codificação. A rastreabilidade de requisitos garante que as especificações geradas até a codificação estejam de acordo com a documentação de requisitos.
Etapa de análise
Ainda no contexto da construção de uma casa, quais seriam os requisitos iniciais para que essa construção ocorresse?
Poderíamos imaginar uma descrição especificando que você quer uma casa com uma sala, três quartos, uma suíte, cozinha, piscina, churrasqueira e com aproximadamente 120 m2. Textualmente, temos um documento de requisitos.
E agora, o que fazer com esse documento? Podemos contratar um arquiteto para desenhar uma planta baixa que atenda aos requisitos descritos. Essa planta é o que chamamos de modelo, que representa parte da solução do problema “construir a sua casa”.
A engenharia tem como boa prática a construção de modelos que permitem uma melhor tratativa da complexidade em função de abstrações aplicadas, e.g., o diagrama de casos de uso enfatiza a abstração funcional e o diagrama de sequência, os aspectos dinâmicos do sistema, ou seja, a comunicação entre objetos na realização de um caso de uso. O modelo permite, também, a comunicação entre as partes interessadas do projeto, pois podemos considerar que um diagrama de caso de uso permite uma comunicação, por exemplo, entre analistas e usuários ou entre analistas e gerentes de projeto. Os modelos permitem, ainda, uma economicidade no projeto, pois uma correção em um modelo de classes na etapa de análise por um erro no entendimento de um determinado requisito evita a propagação desse defeito no código em produção, manutenção essa que seria bem mais custosa. Uma última colocação: os modelos determinam a forma da solução do problema, ou seja, se o diagrama de componentes estabelece três camadas de software, o software implantado deverá refletir a referida especificação.
Na etapa de Análise, as especificações contidas no Documento de Requisitos sãoconvertidas em modelos de análise que incluem artefatos gráficos e textuais. Como exemplo, os requisitos funcionais evoluem para uma especificação gráfica denominada Modelo de Casos de Uso, sendo este composto por diagramas de caso de uso, artefatos gráficos, e descrições de caso de uso, artefatos textuais. Importante destacar que uma descrição de caso de uso permite identificar os diferentes cenários de utilização do referido caso. A figura abaixo ilustra um diagrama de casos de uso.
Nesta etapa, o engenheiro de software aplica um alto nível de abstração de modo a definir “O QUE” o sistema deverá implementar, ou seja, nenhum tipo de restrição tecnológica é considerado, e.g., como ocorre a comunicação entre os objetos que permitirão implementar o caso de uso “Agendar consulta”.
A entrega da referida etapa inclui os modelos denominados “modelos de análise” com alto nível de abstração.
O entendimento do problema modelado está correto?
Em função desse questionamento, o engenheiro de software necessita VALIDAR seus modelos com os usuários, pois, afinal, são estes que entendem do problema. A validação por parte do usuário garante ao engenheiro que o entendimento da solução do problema está correto e, de acordo com as suas expectativas, i.e., de acordo com os requisitos registrados no documento de requisitos.
Os modelos estão corretos e balanceados?
A verificação é uma atividade técnica do engenheiro de software que permite a verificação da correção de cada modelo e o balanceamento entre esses.
A figura abaixo ilustra um diagrama de classes, sendo este um artefato do Modelo de Classes que permite identificar os objetos do domínio do problema que serão utilizados na implementação dos casos de uso. Cabe ao engenheiro de software, verificar a correção do modelo e a consistência com o Modelo de Casos de Uso.
Etapa de projeto
A fase de Projeto permite os refinamentos dos modelos gerados na análise, bem como a construção de novos modelos gerando especificações com menor nível de abstração e que permitam definir “COMO” implementar a solução especificada, ou seja, ao final desta etapa, o nível de detalhamento da especificação permite a implementação da solução. Dentre as principais atividades, destacamos:
· Refinamento do modelo de classes iniciado na análise.
· Construção do modelo de interação, que permite identificar a comunicação entre objetos que irão permitir a implementação das funcionalidades especificadas pelos casos de uso.
· Mapeamento objeto-relacional, permitindo a geração do modelo lógico do banco de dados, ou seja, identificação das tabelas necessárias ao sistema considerando um requisito não funcional que determine uma tecnologia relacional.
· Desenho dos componentes do sistema e dos nós computacionais necessários para a sua implantação, gerando modelos que determinam a arquitetura do sistema.
Etapa de implementação
Nesta etapa, ocorre a codificação do software de acordo com os requisitos definidos na etapa de Projeto. Os padrões de projeto devem ser considerados por representarem melhores práticas de implementação do software.
Etapa de testes
Nesta etapa, são aplicados os denominados testes de software ou testes de validação que permitem verificar se o produto certo está sendo construído.
Os testes validam os componentes individualmente bem como a integração entre eles. Em geral, esta etapa inicia com os testes unitários, em seguida, os testes de integração e os testes de aceitação ou homologação. Ao final dessa sequência, ocorre a migração do sistema para o ambiente de produção.
Recomendação: Nesta etapa, é fundamental a geração de um Plano de Teste a partir dos casos de testes, que, por sua vez, estão vinculados aos cenários descritos na descrição de cada caso de uso.
Outro aspecto importante é a automação dos testes em função da provável repetição destes em um ciclo iterativo e incremental, onde o software é implementado em versões e, a cada nova versão, os testes anteriores necessitam ser refeitos.
Etapa de implantação
Nesta etapa, o software é migrado para o ambiente de produção, de acordo com o aval da equipe de qualidade.
Esta etapa pode exigir a geração de manuais de utilização, a migração de dados do ambiente de homologação para o de produção, treinamento de usuários, ou até mesmo a implantação de um call center em caso de sistemas complexos assim o exigirem.
Fluxo de processo
A especificação de um processo de desenvolvimento de software, lembrando ser este um requisito não funcional, requer a definição de quais atividades irão compor o respectivo processo e como as referidas atividades serão encadeadas, também denominada de Fluxo de Processo ou Ciclo de Vida.
	Fluxo de processo linear
	A figura abaixo ilustra o denominado Fluxo de Processo Linear, onde as atividades são executadas em sequência, de modo que cada atividade é realizada por completo uma única vez.
	Fluxo de processo iterativo
	A figura abaixo ilustra o denominado Fluxo de Processo Iterativo, onde uma atividade ou um conjunto de atividades podem ser repetidas antes de prosseguir para a seguinte.
	Fluxo de processo evolucionário
	A figura abaixo ilustra o denominado Fluxo de Processo Evolucionário, onde o sequenciamento de cada fluxo inclui todas as atividades, sendo que cada iteração completa gera uma nova versão do software, ou seja, o software agrega valor às suas funcionalidades a cada ciclo completo.
	Fluxo de processo paralelo
	A figura abaixo ilustra o denominado Fluxo de Processo Paralelo, que permite a execução de uma ou mais atividades em paralelo.
	Modelo de Ciclo de Vida Iterativo e Incremental
	A figura abaixo ilustra o Modelo de Ciclo de Vida Iterativo e Incremental, onde cada iteração inclui todas as atividades e ocorre o versionamento do produto software gerado. Este modelo corresponde ao Fluxo de Processo Evolucionário. A cada novo ciclo, um subconjunto de requisitos é considerado.
Resumindo
Neste módulo, podemos avaliar a importância do processo de desenvolvimento de software. Cabe destacar que processo é a principal camada da Engenharia de Software.
Foram descritas as principais atividades que, genericamente, compõem um processo de desenvolvimento de software, que inclui: levantamento de requisitos, análise, projeto, implementação, testes e implantação.
Cabe ao engenheiro de software determinar as atividades que comporão a especificação de um processo de desenvolvimento de software, sendo o sequenciamento determinado pelo Fluxo de Processo, podendo ser Fluxo de Processo Linear, Fluxo de Processo Iterativo, Fluxo de Processo Evolucionário ou Fluxo de Processo Paralelo.
Lembre-se, não existe engenharia sem processo.
Módulo 3
Relacionar as etapas de um processo de desenvolvimento de software com as etapas de Gerenciamento de Projeto
Gerenciamento de projeto
Agora que você tem uma boa compreensão das atividades genéricas que compõem um processo e as possibilidades de fluxos de processos, ou seja, os encadeamentos possíveis das referidas atividades, temos agora que compreender como aplicar de forma sistemática uma metodologia que lhe permita, a partir de uma necessidade de um determinado usuário, gerar o produto software desejado.
A sigla PMI lhe diz algo? O PMI, Project Management Institute, é uma organização que visa disseminar as melhores práticas de Gerenciamento de Projetos em todo o mundo e que tem como premissa o fato de ser esse gerenciamento uma profissão.
DICA: A certificação de Profissional de Gerenciamento de Projetos (PMP)® do PMI é a certificação para gerentes de projeto reconhecida como uma das mais importantes para a indústria, incluindo a de software. No Brasil, podemos afirmar que é a mais importante.
Qual seria a importância de uma certificação para você?
A certificação complementa a formação acadêmica tornando o profissional de TI mais atualizado e com maior empregabilidade, tanto na busca de um novo posto de trabalho como de uma promoção.
Retornando ao nosso tema PMI, este publica um conjunto de melhores práticas denominado de Guia deConhecimento em Gerenciamento de Projetos – PMBOK, ou Project Management Body of Knowledge, em inglês. O Guia PMBOK é uma base sobre a qual podemos criar uma metodologia para obtenção do nosso produto, i.e., o software. Nesse contexto, temos que apresentar um primeiro conceito:
UM PROJETO É UM ESFORÇO TEMPORÁRIO EMPREENDIDO PARA CRIAR UM PRODUTO, SERVIÇO OU RESULTADO ÚNICO.
(PMI, 2017)
Podemos inferir do conceito que todo projeto tem início, meio e fim, por isso é temporário, sendo o mesmo fator impulsionador de mudança nas organizações. Agora, podemos apresentar um segundo conceito que cabe destaque:
Lembra que a Engenharia de Software está baseada em processos?
A atividade de gerenciamento de projetos tem a mesma base.
Vamos entender a seguir como funciona.
Ciclo de vida do projeto x Grupos de processos
O ciclo de vida do projeto inclui as fases genéricas ilustradas na figura abaixo e que fazem parte de todo projeto.
Qual a relação do ciclo de vida do projeto com o fluxo de processo do software?
Os fluxos de processos ou ciclos de vida que apresentamos anteriormente incluem os tipos: linear, iterativo, evolucionário e paralelo. A seleção de um determinado Fluxo de Processo determina as fases pelas quais um projeto irá passar, do início ao término.
Exemplificando: o engenheiro de software seleciona o Fluxo de Processo Evolucionário, ou Iterativo e Incremental, representado na figura seguinte. A partir dessa especificação, o ciclo de vida do projeto está estabelecido e as entregas do projeto ocorrerão por meio de uma série de iterações.
Como esse ciclo de vida do projeto estabelecido é gerenciado?
Por meio da execução de uma série de atividades de gerenciamento de projeto, conhecidas como processos de gerenciamento de projetos.
Cada processo de gerenciamento de projetos transforma entradas em saídas através da aplicação de técnicas e ferramentas de gerenciamento de projetos apropriadas (figura 13). As saídas podem ser uma entrega ou um resultado.
A figura seguinte ilustra as cinco etapas que permitem a “GESTÃO” de um projeto: Iniciação; Planejamento; Execução; Monitoramento e Controle; e Encerramento.
Temos que considerar que cada etapa possui um conjunto de processos, conjunto este denominado de Grupo de Processos de Gerenciamento de Projetos.
De uma forma simplificada, o gerente de projetos tem que considerar as etapas de gestão, por exemplo, para a etapa INICIAÇÃO:
1. Seleciona os processos que serão utilizados, considerando a complexidade do projeto.
2. Aloca responsáveis por cada processo de acordo com a área de conhecimento.
3. Os responsáveis realizam os processos de acordo com o que preconiza o PMBOK.
4. Os responsáveis geram seus respectivos resultados para cada processo.
Em seguida, aplica os passos de 1 a 4 anteriores para cada etapa do ciclo de vida do projeto: Planejamento, Execução, Monitoramento e Controle e Encerramento. Em projetos complexos, as etapas podem ocorrer de forma iterativa. Os cinco grupos de processos ilustrados abaixo, serão descritos a seguir:
	Grupo de processos de iniciação
	Grupo que inclui os processos realizados no início de um projeto, cabendo destaque ao Termo de Abertura do Projeto, termo que autoriza a alocação de recursos ao projeto.
	Grupo de processos de planejamento
	Grupo que inclui os processos realizados para planejar a execução de um novo projeto. A primeira atividade de planejamento é o gerenciamento do escopo do projeto.
A principal entrega do planejamento é o cronograma. O cronograma físico inclui as datas de início e término de todas as atividades do projeto.
	Grupo de processos de execução
	Aqui está um dos grandes desafios do gerente de projeto, que é executar o projeto de acordo com o planejado. Lembre-se de que o gerente de projetos não está sozinho, sendo um integrador de pessoas e distintos conhecimentos.
	Grupo de processos de monitoramento e controle
	Nesse grupo, podemos aplicar a máxima de que “não se controla o que não se mede”.
Grupo que inclui os processos que permitem monitorar e controlar o progresso e desempenho do projeto. Caso alguma atividade não ocorra de acordo com o planejado, terá que ser avaliada uma ação corretiva a fim de que essa não conformidade seja tratada por meio de um gerenciamento de mudanças.
	Grupo de processos de encerramento
	Lembre-se, todo projeto é temporário, portanto, em algum momento, terá que ser, formalmente, encerrado.
Grupo que inclui os processos que permitirão a conclusão ou encerramento do projeto, tais como, a entrega e aceitação do produto, a dispensa da equipe de projeto ou avaliação geral dos resultados.
Áreas de conhecimento em gerenciamento de projetos
Assim como a complexidade é um fator determinante na definição de um processo de software, também é inerente ao Gerenciamento de Projeto, de modo que, quanto maior o problema, mais multidisciplinar este se torna. Em função dessa complexidade, qual seria a sua equipe técnica para desenvolver um projeto de software?
Provavelmente, você pensaria em engenheiro de software, analistas, administrador de banco de dados, programadores, arquitetos de software, entre outros. Perfeito, essa seria uma boa equipe!
Mas essa equipe seria capaz de realizar a “GESTÃO” de um projeto de software? Podemos considerar que uma equipe de Gerenciamento de Projeto deve ser composta por especialistas em custos que realizem orçamentos realistas; especialistas em aquisições que tenham capacitações na realização de contratações ou licitações; especialistas em recursos humanos, a fim de gerenciar os direitos trabalhistas da equipe de projeto; e outros.
É possível que essa equipe técnica resolva parte do problema em função da complexidade na área de gestão que um projeto de software possa requerer.
Considerando que o gerenciamento de projetos é uma atividade multidisciplinar, o PMBOK realiza a fatoração dessa complexidade em 10 (dez) áreas de conhecimento, onde cada área é composta por um conjunto de processos, como ilustra a figura 15.
Você poderia perguntar como gerente de projeto: qual a minha equipe então?
Respondendo ao questionamento, o perfil de sua equipe deverá estar alinhado às áreas de conhecimento que serão descritas a seguir.
Gerenciamento da integração do projeto
Área que inclui os processos que permitem a integração das diferentes áreas de conhecimento, estando essa área sob controle direto do gerente de projetos.
Podemos dizer que o gerente de projeto atua como um maestro, pois não precisa ter conhecimento específico de cada área de conhecimento. Este combina os resultados em todas as outras áreas de conhecimento e tem a visão geral do projeto, pois é o único responsável pelo projeto como um todo.
Observe na figura acima que a única área com processos em todos os grupos de processos é a Integração. Isso significa que o gerente de projetos está presente em todas as etapas de gestão.
Cabe destacar, mais uma vez, que o Termo de Abertura do Projeto é o documento que autoriza a alocação de recursos ao projeto.
Gerenciamento do escopo do projeto
Área que inclui os processos necessários para assegurar que o projeto contemple todo e somente o trabalho necessário para que este termine com sucesso. Nesta área, são especificados e detalhados os requisitos de software.
A principal técnica para a definição do escopo é a confecção da Estrutura Analítica do Projeto (EAP) ou Work Breakdown Structure (WBS).
A figura abaixo ilustra um exemplo de EAP, onde cada elemento constitui uma entrega e as entregas que não são decompostas são chamadas de pacotes de trabalho ou workpackages. Os pacotes de trabalho são conjuntos de tarefas ou ações que, efetivamente, serão executadas no projeto.
Gerenciamento do cronograma do projeto
Área que inclui os processos necessários para gerenciar o término pontual do projeto, tendo como principal entrega no planejamento o cronograma (físico) do projeto.
O cronograma do projeto é gerado na etapa de planejamento do projeto. Inicialmente, são identificadas as atividades, a partir dos pacotes de trabalhoda EAP e, para cada atividade, devemos especificar a duração e os respectivos insumos. Em seguida, é elaborado o diagrama de rede do cronograma do projeto, que determina as interdependências entre as atividades, tal como ilustrado na figura abaixo.
Finalmente, podemos gerar o cronograma do projeto, exemplificado na figura 18.
	Gerenciamento dos custos do projeto
	Inclui os processos envolvidos na gestão dos orçamentos do projeto, a fim de permitir que o projeto possa ser encerrado dentro do orçamento aprovado.
	Gerenciamento da qualidade do projeto
	Área que inclui os processos que garantem o atendimento aos requisitos do projeto e, como consequência, as expectativas dos financiadores do projeto
	Gerenciamento dos recursos do projeto
	Área que inclui os processos para identificar, adquirir e gerenciar os recursos necessários para a conclusão bem-sucedida do projeto.
	Gerenciamento das comunicações do projeto
	Área que inclui os processos necessários para assegurar que as informações do projeto tenham uma gestão oportuna e apropriada.
	Gerenciamento dos riscos do projeto
	Área que inclui os processos de gestão dos riscos em um projeto.
	Gerenciamento das aquisições do projeto
	Área que inclui os processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do projeto.
	Gerenciamento das partes interessadas do projeto
	Área que inclui os processos exigidos para identificar partes interessadas que possam gerar impacto no projeto, bem como desenvolver estratégias para o seu engajamento eficaz nas decisões e execução do projeto.
Resumindo
Neste módulo, podemos avaliar a importância do relacionamento entre o fluxo de processo de software com o ciclo de vida de Gerenciamento do Projeto.
Ambos os ciclos têm como base o conceito processo, pois, como vimos, processo é a principal camada da Engenharia de Software e o gerenciamento de projeto é orientado a projeto em função dos grupos de processos. Importante destacar que um processo no Gerenciamento de Projetos tem duas dimensões: a primeira, como parte de um grupo de processos; e a segunda, como parte de uma das 10 (dez) áreas de conhecimento.
As áreas de conhecimento permitem a tratativa da complexidade de projetos multidisciplinares, pois a equipe de gerenciamento de projetos deverá ser composta por especialistas nas diversas áreas de conhecimento.
Módulo 4
Descrever a importância do Gerenciamento de Risco no projeto de software
Risco
As melhores práticas desenvolvidas neste módulo têm por fundamento o PMBOK, cujos processos estão definidos na figura abaixo.
Imagine você realizando um planejamento de uma viagem ao exterior nas próximas férias. Considerando que o roteiro está definido, bem como as reservas dos hotéis realizadas, as passagens reservadas e uma quantidade de dólares adquiridos, podemos, intuitivamente, aplicar uma abstração denominada risco, ou seja, o que pode ocorrer de errado na minha viagem? Vamos, então, gerar uma pequena lista de possíveis eventos negativos para entendermos os conceitos:
· Ocorrência de um problema de saúde, por causa de um acidente ou ter contraído alguma doença.
· Cancelamento da passagem pela companhia aérea.
· A quantidade de dólar adquirida não ser suficiente.
Observe que a avaliação de risco gera uma preocupação que o conduz ao futuro, inserindo um grau de incerteza – ele pode ou não ocorrer. Ao mesmo tempo, espera-se que fique clara a importância de sua avaliação, pois, caso ocorra algum dos eventos listados durante a sua viagem, essa pode estar seriamente comprometida.
UM RISCO É UM EVENTO OU CONDIÇÃO INCERTA QUE, SE OCORRER, PROVOCARÁ UM EFEITO POSITIVO OU NEGATIVO EM UM OU MAIS OBJETIVOS DO PROJETO.
(PMI, 2017)
Você pode agora questionar: efeito positivo?
O risco não trata de efeitos negativos ou coisas que podem dar errado? Realmente, o mais comum é associar risco a algo negativo, mas, conceitualmente, pode ser algo positivo. Vamos exemplificar.
Imagine uma empresa exportadora de minério que elabora o seu plano de investimento para o próximo ano e que identificou o seguinte risco: variação cambial do dólar, sendo essa a moeda padrão da comercialização de commodities. O planejamento inclui aplicar os recursos de investimentos em novos projetos de prospecção de minas.
Neste momento, faz-se necessário realizar uma projeção do valor do câmbio para o próximo ano, pois, como apresentado, o faturamento da empresa está atrelado à referida moeda – vamos imaginar que o valor projetado para o dólar foi de R$ 5,50 (reais). Temos então dois cenários possíveis:
	CENÁRIO NEGATIVO
	CENÁRIO POSITIVO
	O dólar chega a valer R$ 4,00, ou seja, a empresa terá que reduzir o seu portfólio de projetos em função da redução do capital de investimento, pois a empresa irá faturar menos com a mesma quantidade de produtos exportados. Esse cenário é um obstáculo para a consecução dos resultados esperados.
	O dólar chega a valer R$ 7,00, ou seja, a empresa poderá incrementar o seu portfólio de projetos em função do aumento de capital de investimento, pois a empresa irá faturar mais com mesma quantidade de produtos exportados. Esse cenário é uma oportunidade para a consecução dos resultados esperados.
ATENÇÃO: Lembrando que nosso contexto é a Engenharia de Software, a melhor prática é focar nos cenários negativos.
Como citado anteriormente, o risco permite planejar o futuro e evitar que empresas tenham “sustos” nos seus projetos em função de eventos inesperados e, a partir destes, iniciar as devidas tratativas. Em síntese, a área de Gerenciamento de Risco permite a sistematização dessas tratativas em forma de plano.
Veja, na figura abaixo, os processos que fazem parte da área de conhecimento Gerenciamento de Riscos. Os referidos processos permitem a sistematização da identificação, da análise e das respostas aos riscos de um projeto.
Identificação de riscos
Alinhado às descrições apresentadas, podemos determinar que um risco possui três componentes: um evento; a probabilidade de ocorrência do evento, associada ao grau de incerteza; e o impacto decorrente do evento, caso aconteça, associado ao grau de perda.
Como parte do Plano de Gerenciamento de Riscos, a elaboração de uma Estrutura Analítica do Risco (EAR) auxilia na definição de potenciais fontes de riscos para o projeto, permitindo a identificação de riscos de forma categorizada, exemplificada na figura 19.
O processo de Identificação de Riscos requer uma clara compreensão da missão, escopo e objetivos do projeto.
Segundo Pressman (2016), uma proposta para identificação de categorias genéricas de risco relacionadas com o software inclui:
	Tamanho do produto
	Riscos associados ao tamanho do software.
	Impacto no negócio
	Riscos oriundos de restrições impostas pelo cliente ou pelo mercado.
	Características do envolvido
	Riscos relacionados com a comunicação oportuna, por exemplo, entre engenheiro de software e um determinado cliente.
	Definição do processo
	Riscos relacionados com a auditoria de processos por parte da equipe de qualidade.
	Ambiente de desenvolvimento
	Riscos associados às ferramentas disponíveis para criar o software, tais como, ferramentas CASE disponíveis.
	Tecnologia a ser criada
	Risco relacionado com as inovações tecnológicas aplicadas no desenvolvimento do software, tal como, um novo framework de persistência de dados.
	Quantidade de pessoas e experiência
	Riscos que associados aos perfis dos engenheiros de software, administradores de banco de dados, web designers, enfim, da equipe que realizará o trabalho.
O processo de identificação de riscos é iterativo, pois novos riscos podem aparecer durante o projeto. Uma técnica muito comum a ser utilizada na identificação de riscos é a técnica denominada de Brainstorming. Esta inclui uma reunião com um conjunto multidisciplinar de especialistas com a finalidade de obter uma lista abrangente de cada risco de projeto e as fontes do risco geral do projeto, sendo as ideias geradas sob a orientação de um facilitador.
Uma segunda técnica é conhecidacomo Lista de Verificação ou Check List, ou seja, uma lista de riscos baseada em informações históricas e conhecimentos acumulados de projetos semelhantes e outras fontes de informações. Essas listas ajudam a identificar pontos fracos no projeto atual a partir de experiências passadas.
Uma terceira técnica proposta pelo PMBOK é a entrevista.
A seguir, vamos explorar um exemplo da aplicação dessa técnica com experientes gerentes de projeto de software, que levantaram as seguintes questões e foram apresentadas por Pressman (2016).
Exemplo da Técnica de Entrevista
1. A alta gerência e o cliente estão formalmente comprometidos em apoiar o projeto?
2. Os usuários estão bastante comprometidos com o projeto e o sistema/produto a ser criado?
3. Os requisitos são amplamente entendidos pela equipe de engenharia de software e clientes?
4. Os clientes foram totalmente envolvidos na definição dos requisitos?
5. Os usuários têm expectativas realistas?
6. O escopo do projeto é estável?
7. A equipe de Engenharia de Software tem a combinação de aptidões adequadas?
8. Os requisitos de projetos são estáveis?
9. A equipe de projeto tem experiência com a tecnologia a ser implementada?
10. O número de pessoas na equipe de projeto é adequado para o trabalho?
11. Todos os clientes e usuários concordam com a importância do projeto e com os requisitos do sistema/produto a ser criado?
Caso alguma questão seja respondida negativamente, insira o risco, ou riscos, na sua lista de riscos.
Análise qualitativa dos riscos
Até o momento, temos uma lista com os prováveis riscos do projeto.
Vamos imaginar que tenhamos uma longa lista. Isso, intuitivamente, nos leva a considerar a necessidade de determinarmos a importância relativa entre os referidos riscos, a fim de que possamos saber quais os riscos prioritários.
É interessante destacar que a tratativa de riscos poderá gerar alocação de recursos financeiros, impactando o orçamento do projeto, ou seja, não é possível tratar os riscos listados com a mesma prioridade, devido às limitações de tempo e recursos.
O objetivo da Análise Qualitativa dos Riscos é priorizar os riscos, combinando a probabilidade de ocorrência e, caso o risco ocorra, o seu impacto. Essa combinação permite determinar o potencial de cada risco em influenciar os resultados do projeto. A probabilidade determina a dimensão da incerteza e o impacto, o efeito sobre os objetivos do projeto.
No início deste módulo, definimos três eventos, a título de exemplo, no projeto de uma viagem ao exterior. Vamos agora aplicar a Análise Qualitativa de Riscos nesses eventos.
	Probabilidades
	Temos que definir as probabilidades que serão adotadas:
	Grande chance de ocorrer
	0,95
	Provavelmente ocorrerá
	0,75
	Igual chance de ocorrer ou não
	0,50
	Baixa chance de ocorrer
	0,25
	Pouca chance de ocorrer
	0,10
	Graus de Impacto
	Definir os graus de impacto:
	Muito grande
	5
	Grande
	4
	Moderado
	3
	Pequeno
	2
	Muito pequeno
	1
	Aplicação
	Podemos, então, aplicar os valores a cada evento:
	Evento
	Probabilidade
	Impacto
	Probabilidade x Impacto
	1) Ocorrência de um problema de saúde, por causa de um acidente ou ter contraído alguma doença
	0,75
	5
	3,75
	2) Cancelamento da passagem pela companhia aérea
	0,50
	3
	1,5
	3) A quantidade de dólar adquirida não ser suficiente
	0,50
	4
	2,0
Atenção! Para visualização completa da tabela utilize a rolagem horizontal
Temos agora prioridades! De acordo com a tabela, o evento mais crítico está relacionado com a saúde, em seguida, com a quantidade de dólar e, finalmente, com a passagem.
Saiba mais: A Força Aérea Americana determina em seus projetos de software os seguintes componentes de risco: desempenho, custo, suporte e cronograma. As categorias de impacto incluem: catastrófico, crítico, marginal e negligenciável.
Você pode questionar: como determino a probabilidade e o impacto, valores que agregam incertezas? Lembre-se de que a área de conhecimento Gerenciamento de Risco do Projeto requer, como as demais áreas, especialistas na respectiva área. Os profissionais que trabalham com risco têm a expertise necessária no trato desses números que representam incertezas, principalmente, por experiências em projetos passados semelhantes.
O gerente de projetos é um integrador de conhecimentos e não precisa ter expertise em todas as áreas de conhecimento, mas tem que entender bem dos processos aplicados nas diferentes áreas.
Análise quantitativa dos riscos
A Análise Quantitativa dos Riscos é um processo de analisar numericamente os efeitos dos riscos priorizados pela Análise Qualitativa de Riscos, pois estes podem gerar impacto potencial e substancial nos resultados do projeto.
As técnicas aplicadas incluem simulações, árvore de decisão entre outras. No contexto da Engenharia de Software, podemos aplicar a árvore de decisão, a fim de avaliar (1) a contratação de uma fábrica de software para desenvolvimento de um determinado software ou (2) realizar o desenvolvimento na empresa.
Vamos agora dar continuidade ao nosso pequeno exemplo. A tabela a seguir, considerando a simplicidade do cenário adotado, ilustra o resultado da análise quantitativa:
	Prioridade
	Evento
	Custo (R$)
	1
	Ocorrência de um problema de saúde, por causa de um acidente ou ter contraído alguma doença
	10.000,00
	2
	A quantidade de dólar adquirida não ser suficiente
	1.000,00
	3
	Cancelamento da passagem pela companhia aérea
	3.000,00
Planejamento de respostas aos riscos
O processo Planejar Respostas aos Riscos inclui o planejamento de ações para o aumento das oportunidades e redução das ameaças aos objetivos do projeto, gerenciando os riscos de acordo com sua prioridade. As referidas ações são representadas pelas respostas adequadas a cada risco, podendo ser incluído o tratamento a ser aplicado, por exemplo, mitigação, quando se busca reduzir o impacto no resultado do projeto, ou eliminação, uma resposta que elimine o referido impacto.
Retornando ao nosso pequeno exemplo, temos uma proposta de respostas aos riscos identificados na tabela a seguir:
	Prioridade
	Evento
	Tratamento
	Resposta
	1
	Ocorrência de um problema de saúde, por causa de um acidente ou ter contraído alguma doença
	Eliminação
	Contratar o seguro-viagem
	2
	A quantidade de dólar adquirida não ser suficiente
	Eliminação
	Atualizar o cartão de crédito para uso internacional
	3
	Cancelamento da passagem pela companhia aérea
	Mitigação
	Confirmar a reserva em companhia aérea com boas alternativas de voos
Resumindo
Neste módulo, podemos destacar a importância da área de conhecimento Gerenciamento dos Riscos do Projeto. Um risco é um evento ou condição incerta que, se ocorrer, provocará um efeito positivo ou negativo em um ou mais objetivos do projeto.
A identificação dos riscos pode ser facilitada pela definição de uma Estrutura Analítica de Riscos (EAR), pois essa permite a categorização dos riscos.
Definidos os riscos, surge a necessidade de priorização destes, pois a tratativa dos riscos poderá impactar o orçamento final do projeto. O processo de análise qualitativa permite a referida priorização definindo para cada risco a sua probabilidade de ocorrência e o grau de impacto, caso ocorra, nos resultados do projeto. Obtidos os dois valores numéricos, pode-se então priorizar os riscos.
Priorizados os riscos, o próximo processo inclui a realização da análise quantitativa dos riscos, permitindo, de acordo com a priorização realizada anteriormente, quantificar os impactos sobre os custos do projeto em função dos riscos.
O planejamento tem como último processo a elaboração do Planejamento de Respostas aos Riscos, incluindo as ações que irão realizar as tratativas que permitirão eliminar ou mitigar os impactos nos resultados do projeto. O referido plano é colocado em execução por meio do processo Implementar Respostas aos Riscos e devidamente monitorado pelo processo Monitorar os Riscos (veja figura abaixo).
O projeto de software possui características que necessitam das melhores práticas de gerenciamento de riscos contidas noPMBOK, com destaque para as atualizações constantes das tecnologias e a alta volatilidade dos requisitos durante o projeto.
Lembre-se, analise os riscos do seu projeto.
Conclusão
Considerações finais
Apresentamos os principais conceitos da Engenharia de Software relacionados com processo de desenvolvimento de software e Gerenciamento de Projetos.
O processo de desenvolvimento de software permite identificar as atividades que permitem a geração do produto software. Embora existam diferentes modelos de processos, destacamos as atividades típicas ou genéricas que compõem os referidos processos, cujo entendimento permite ao engenheiro de software compreender os possíveis modelos a serem adotados em um determinado projeto de software.
O Gerenciamento de Projetos tem foco na gestão durante o desenvolvimento de software, diferentemente do processo de software, que determina as atividades técnicas. Ele define as atividades de gestão relacionadas à iniciação, ao planejamento, à execução, ao monitoramento e controle e ao encerramento do projeto. Nesse contexto, destacamos o gerenciamento de risco.
AULA 2 – FASES DO DESENVOLVIMENTO
Descrição
O processo de desenvolvimento de software e suas atividades genéricas.
Propósito
 
Compreender as etapas do processo de desenvolvimento de software, que abrange atividades de levantamento de requisitos, análise, projeto, implementação, teste, implantação e manutenção.
Objetivos
· Módulo 1: Descrever as atividades da Engenharia de Requisitos do processo de desenvolvimento de software
· Módulo 2: Reconhecer as atividades do projeto de software do processo de desenvolvimento de software
· Módulo 3: Reconhecer as etapas de implementação e testes do processo de desenvolvimento de software
· Módulo 4: Descrever as etapas de implantação e manutenção do processo de desenvolvimento de software
Introdução
Nos dias atuais, o software tem destaque cada vez maior. Uma tendência que ratifica essa importância está no uso intensivo dos smartphones.
O sucesso dessa tecnologia, não descartando a importância do hardware, tem um forte respaldo na competência do software, ou seja, interfaces com designs atraentes, responsivas, usabilidade intuitiva, entre outras características.
Por trás dessa competência, temos vários especialistas, tais como engenheiros de software, web designers, administradores de banco de dados, arquitetos de software e outros que trabalham arduamente para manutenção desse sucesso exponencial.
A referida equipe tem uma composição multidisciplinar, refletindo uma característica do software: a complexidade. O trato dessa complexidade requer a aplicação da Engenharia de Software, que, por sua vez, tem como base a camada de processos. Podemos afirmar que não existe engenharia sem processo.
Nesse contexto, é importante compreender as principais atividades desenvolvidas nas etapas genéricas de um Processo de Desenvolvimento de Software, também conhecido pela sigla PDS.
Módulo 1
Descrever as atividades da Engenharia de Requisitos do processo de desenvolvimento de software
Engenharia de software
Vamos iniciar nosso estudo sobre o processo de desenvolvimento de software, no contexto da Engenharia de Software, que tem como principal produto o software. Aproveito para destacar que a bibliografia Pressman (2016) é uma referência mundial nesta área.
Imaginando um software embarcado em uma aeronave com centenas de pessoas ou controlando o tráfego aéreo de uma grande cidade, podemos destacar uma característica comum: a complexidade. A melhor tratativa para a complexidade é a aplicação de metodologia que permita a decomposição do problema em problemas menores de forma sistemática, cabendo à Engenharia de Software essa sistematização.
Entretanto, diferentemente de produtos de outras engenharias em produção, o software possui alta volatilidade, em função de constantes evoluções na tecnologia e nos requisitos, agregando a ele uma complexidade adicional.
A Engenharia de Software é uma tecnologia em camadas. Vejamos as descrições das referidas camadas na tabela a seguir:
	Camada
	Descrição
	Camada qualidade
	Garante que os requisitos atendam às expectativas dos usuários
	Camada de processo
	Define as etapas de desenvolvimento do software
	Camada de métodos
	Determina as técnicas e os artefatos de software
	Camada ferramentas
	Estimula a utilização de ferramentas CASE
Importante destacar que a base da Engenharia de Software é a camada de processo que trata das etapas de desenvolvimento.
Processo de desenvolvimento de software
Você sabe por que se aplica de forma intensa o conceito de abstração no desenvolvimento de software?
Porque esse processo é iniciado com especificações e modelos com alto nível de abstração e, à medida que o desenvolvimento de software se aproxima da codificação, o nível de abstração diminui, de modo que o código representa o nível mais baixo da abstração ou de maior detalhamento na especificação do software.
Os diferentes modelos de processos de desenvolvimento de software possuem as seguintes atividades típicas:
	1
	2
	3
	4
	5
	6
	Levantamento de requisitos
	Análise
	Projeto
	Implementação
	Testes
	Implantação
Vamos, agora, descrever cada uma das atividades comumente previstas em um processo de desenvolvimento de software.
Engenharia de requisitos
As etapas de levantamento de requisitos e análise, no processo de desenvolvimento de software, compõem a Engenharia de Requisitos, de modo que essa engenharia está no contexto da Engenharia de Software.
Neste momento, precisamos apresentar a conceituação de requisito:
“OS REQUISITOS DE UM SISTEMA SÃO DESCRIÇÕES DOS SERVIÇOS FORNECIDOS PELO SISTEMA E AS SUAS RESTRIÇÕES OPERACIONAIS. ESSES REQUISITOS REFLETEM AS NECESSIDADES DOS CLIENTES DE UM SISTEMA QUE AJUDA A RESOLVER ALGUM PROBLEMA”.
SOMMERVILLE, 2007
A Engenharia de Requisitos inclui as atividades de descobrir, analisar, documentar e verificar os serviços fornecidos pelo sistema e suas restrições operacionais, possuindo um processo próprio, tal qual ilustrado na Figura 1. Destacamos a existência de outras propostas de processos.
Você poderia perguntar: “Outro processo?”. Sim! Lembre-se de que a engenharia tem como base a camada de processos. Vamos entender cada etapa desse processo ilustrado acima.
	Concepção
	Essa etapa exige do engenheiro de software o estabelecimento do entendimento inicial do problema, a identificação das partes interessadas que serão atendidas pelo software, a natureza da solução desejada e a eficácia da comunicação e colaboração preliminares entre clientes e usuários com a equipe de projeto.
Cabe destacar que um software costuma ter vários tipos de usuários, como, por exemplo, as partes interessadas em diferentes níveis gerenciais de uma empresa.
	Levantamento
	Atividade que permite definir o escopo do projeto, ou “tamanho do problema”, além de possibilitar que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido. Isso é um desafio! Concorda?
Nesta etapa, é gerada uma especificação de requisitos que serve como um contrato entre clientes e equipe de projeto, esclarecendo aos clientes o que será entregue como produto do trabalho da equipe de desenvolvimento.
Ainda sobre a etapa de levantamento, esses clientes devem ser capazes de compreender os requisitos e fornecer feedback sobre eventuais falhas na especificação, para que estas sejam corrigidas de imediato, antes que o trabalho errado se propague pelo projeto.
A referida especificação comumente tipifica os requisitos em três categorias: requisitos funcionais, não funcionais e de domínio.
	Os requisitos funcionais estão relacionados aos serviços fornecidos pelo sistema, ou seja, as funcionalidades que estarão disponíveis no software, tal como a geração de um histórico escolar em um sistema de gestão acadêmica.
	Os requisitos não funcionais incluem as restrições operacionais impostas ao software, tais como o sistema gerenciador de banco de dados, a linguagem de programação, legislação pertinente a compliance, entre outros, bemcomo os requisitos de qualidade, e.g., confiabilidade, manutenibilidade, usabilidade etc.
	Os requisitos de domínio também são conhecidos como “regras de negócio”, que normalmente apresentam-se como restrições ao requisito funcional. Como exemplo, temos o cálculo da média para aprovação em determinada disciplina, a contagem de pontuação de multas para cômputo da perda de uma carteira de motorista ou o cálculo dos impostos quando da geração de uma nota fiscal. O não cumprimento de um requisito de domínio pode comprometer o uso do sistema.
Agora, vejamos as técnicas mais utilizadas para levantar requisitos.
	A observação, ou etnografia, permite ao engenheiro de software imergir no ambiente de trabalho onde a solução será usada, observando o trabalho rotineiro e tomando notas das tarefas em execução nas quais as partes interessadas estão envolvidas.
	A entrevista é uma forma de diálogo, formal ou informal, onde o entrevistador busca respostas para um conjunto de questões previamente definidas e os entrevistados se apresentam como fontes de informação.
	A pesquisa consiste na aplicação de um questionário às partes interessadas e posterior análise das respostas. Essa técnica permite a rápida obtenção de informações quantitativas e qualitativas de um público-alvo numeroso, particularmente quando não estão em um único local físico.
	O JAD, Joint Application Design, é um método de projeto interativo que substitui as entrevistas individuais por reuniões de grupo, onde participam representantes dos usuários e dos desenvolvedores.
	A técnica brainstorming inclui reuniões na qual participam todos os envolvidos na idealização do produto, como os engenheiros de software, clientes e usuários finais. Todos os envolvidos devem expor suas ideias e necessidades em relação ao produto.
Você poderia imaginar uma entrega nesta etapa?
Temos uma entrega denominada “documento de requisitos”, cujo objetivo é documentar de forma fiel e completa todas as necessidades dos clientes e obter um aceite sobre o que se está propondo entregar em termos de produto.
A partir desse documento, inicia-se a rastreabilidade dos requisitos, garantindo que as especificações geradas até a codificação estejam de acordo com a documentação de requisitos.
Elaboração
Nesta etapa, os engenheiros de software realizam um estudo detalhado dos requisitos levantados e, a partir desse estudo, são construídos modelos para representar o sistema a ser construído.
Na etapa de elaboração, a modelagem é guiada pela criação e pelo refinamento de cenários, identificados a partir dos requisitos funcionais, que descrevem como os usuários interagem com o sistema. A modelagem de casos de uso da UML (Unified Modeling Language) representa os referidos cenários, incluindo diagramas de casos de uso, artefatos gráficos, e descrições de casos de uso, artefatos textuais. Abaixo, uma ilustração de um diagrama de caso de uso.
A partir dos casos de uso, podemos identificar as classes de análise que representam os objetos do negócio ou do domínio do problema. A imagem abaixo, ilustra um diagrama de classes da UML.
Na modelagem de análise, podemos considerar a construção do modelo de atividades e do modelo de estados. O modelo de atividades, ilustrado abaixo, possui diagramas que podem ser utilizados no mapeamento de processos de negócios, na descrição gráfica de um caso de uso ou na definição do algoritmo de um método. O modelo de estados permite representar mudanças de estados significativas e respectivos eventos que causam a referida mudança.
	
	Negociação
	Nesta etapa, ocorre a priorização e a resolução de conflitos entre os requisitos definidos nas etapas anteriores. Todos os envolvidos, equipe de projeto e usuários, participam da avaliação de custos, riscos e conflitos, a fim de eliminar, combinar e/ou modificar os referidos requisitos e, logicamente, priorizá-los.
	Especificação
	O engenheiro de software deverá gerar um documento de especificação incluindo todos os requisitos e modelos gerados nas etapas anteriores.
	Validação
	A validação permite ao engenheiro de software evidenciar que os modelos refletem as necessidades dos usuários com relação ao sistema a ser desenvolvido. Um defeito não considerado gera a construção de um sistema que não corresponderá às expectativas do usuário.
	Gestão
	Finalizando o processo da engenharia de requisitos, a etapa de gestão permite controlar as mudanças dos requisitos à medida que o projeto evolui.
Podemos destacar que o engenheiro de software deverá considerar que o gerenciamento do escopo do projeto inclui um documento denominado matriz de rastreabilidade dos requisitos, sendo essa uma tabela que liga os requisitos dos produtos desde as suas origens até as entregas que lhes satisfazem. A manutenção desse documento permite monitorar a estabilidade dos requisitos.
Resumindo: Neste módulo, podemos destacar a relevância da Engenharia de Requisitos no contexto do processo de desenvolvimento de software. Importante lembrar que a Engenharia de Requisitos inclui as etapas de levantamento de requisitos e análise do referido processo.
Os requisitos são comumente categorizados em requisitos funcionais, não funcionais e de domínio. Os requisitos funcionais estão associados aos serviços ou às funcionalidades disponibilizadas pelo sistema. Os requisitos não funcionais estão relacionados com as restrições operacionais, tais como linguagem de programação, padrão de arquitetura etc., além de requisitos de qualidade, e.g., manutenibilidade, usabilidade e outros. Os requisitos de domínio detalham as regras de negócio identificadas no domínio do problema.
A Engenharia de Requisitos inclui um processo com tarefas que, de forma simplificada, permitem a identificação dos requisitos, a geração de modelos de análise, a validação dos requisitos por parte dos usuários e a gestão dos requisitos, possibilitando a rastreabilidade durante as etapas seguintes do projeto de software.
Módulo 2
Reconhecer as atividades do projeto de Software do processo de desenvolvimento de software
Projeto de software
Podemos observar que os principais modelos da etapa de análise do processo de desenvolvimento de software são: o modelo de casos de uso, o modelo de classes de análise, o modelo de atividades e o modelo de estados.
ATENÇÃO: Muitos autores e profissionais de Engenharia de Software preferem usar o termo original do inglês design no lugar de projeto, para não confundir com o homógrafo projeto, no sentido de project, cujo significado é diferente de design. Neste texto, o termo projeto é usado indistintamente no sentido de project ou de design, dependendo do contexto.
Você acha possível implementar um software com os referidos modelos? Provavelmente, faltam mais detalhes. Vamos, agora, tratar desses detalhes.
O conceito de abstração é fundamental no processo de desenvolvimento de software, pois ele é iniciado com especificações e modelos com alto nível de abstração.
A etapa projeto de software diminui o nível de abstração dos diagramas de análise por meio de refinamentos sucessivos, como também exige a criação de novos modelos.
As principais atividades realizadas na fase de projeto serão descritas a seguir.
Refinamento dos aspectos estáticos e estruturais do sistema
O modelo de classes representa os aspectos estáticos e estruturais do sistema. A partir do modelo de classes gerado na análise, vamos inserir novos elementos que permitirão a implementação das classes, ou seja, aplicaremos refinamentos que possibilitam reduzir o grau de abstração. A imagem seguinte exemplifica as abstrações possíveis de uma classe durante o processo de desenvolvimento de software. Ao final, temos uma especificação de classe em condições de ser codificada. Exemplo:
Vamos analisar os refinamentos: a primeira estrutura indica uma classe e o respectivo nome; a segunda inclui os atributos; a terceira adiciona os métodos ou funções das classes, e a quarta detalha os atributos e métodos. Na análise, não é importante definirmos os tipos de dados, sendofundamental no projeto, pois a especificação de projeto tem de garantir a implementação, ou seja, a codificação da classe.
Além desse refinamento, novos elementos são inseridos em função das associações entre as classes, das heranças existentes, ou mesmo em virtude da criação de novas classes.
Um aspecto importante é a possibilidade de aplicação de padrões de projeto, ou design patterns, no modelo de classes de projeto. Esses padrões representam templates de melhores práticas para a solução de determinados problemas comuns, que serão resolvidos mais facilmente quando implementados pelo programador. A imagem abaixo exemplifica o padrão Factory Method.
Detalhamento dos aspectos dinâmicos do sistema
O que seriam aspectos dinâmicos? Lembre-se: o paradigma dominante na indústria de software é a orientação a objetos, que, de forma simplificada, é a representação do mundo real por meio de objetos que se comunicam por meio de mensagens.
A referida comunicação representa a dinâmica existente entre os objetos e, para a sua representação, temos o modelo de interação, que inclui dois diagramas: diagrama de comunicação e diagrama de sequência. Ambos os diagramas têm a mesma abstração dinâmica com representações distintas e recíprocas.
Qual a relação existente entre o modelo de classes e o modelo de interação?
O modelo de interação é desenvolvido usualmente em paralelo com o modelo de classes de projetos, de modo que os métodos implementados nas classes são identificados a partir das mensagens definidas no modelo de interação. A figura acima exemplifica, à esquerda, parte de um diagrama de sequência, onde a mensagem “validar” estabelece uma comunicação entre os objetos “controlador acesso” e “usuário”, sendo a mensagem implementada no objeto receptor “usuário”, ou seja, a classe “usuário” inclui o método “validar” com os respectivos parâmetros.
Detalhamento da arquitetura do sistema
Uma atividade que aplicamos de forma intensa na Engenharia de Software é a fatoração, ou seja, a decomposição da solução do problema em partes menores, facilitando principalmente o trato da complexidade.
Imaginemos um sistema de software complexo; intuitivamente, temos de realizar a decomposição em subsistemas. O processo do projeto que permite identificar os referidos subsistemas, estabelecendo um framework para controle e comunicação entre eles, é denominado projeto de arquitetura.
A arquitetura é definida por meio de duas abstrações: lógica e física.
Abaixo, uma ilustração uma divisão lógica comumente aplicada no projeto de arquitetura, sendo composta das seguintes camadas: apresentação, aplicação, domínio e serviços técnicos.
Importante destacar que as camadas mais altas devem depender das camadas mais baixas – essa fatoração permite melhor trato da complexidade, ou seja, decomposição do sistema em partes menores. Outra vantagem é o reuso, pois, as camadas inferiores são independentes das camadas superiores. A arquitetura em camadas permite baixo acoplamento, ou seja, mínimo de dependências entre os subsistemas, e alta coesão, isto é, deve haver mais associações entre as classes internamente do que externamente.
A camada de apresentação da figura acima inclui as denominadas classes de fronteira, que permitem a instanciação dos objetos de fronteira que interagem com os usuários.
A camada de aplicação inclui as classes de controle, que permitem a instanciação dos objetos de controle que atuam como intermediários entre os objetos da camada de apresentação e os objetos do domínio do problema.
A camada de domínio é composta pelas classes de domínio oriundas do diagrama de classes, que permitem a instanciação dos objetos do domínio do problema – esses objetos podem conter métodos que alteram o próprio estado.
Finalmente, a camada de serviços técnicos pode incluir serviços genéricos, cabendo destaque à camada de persistência de dados.
Assim como existem padrões de projeto aplicados ao projeto de classes (acima), temos também padrões aplicados à arquitetura. Como exemplo, podemos destacar o padrão de arquitetura em camadas denominado MVC (Model-View-Controller), formulado na década de 1970 e focado no reúso de código e na separação de conceitos em três camadas interconectadas, tal como ilustra a figura seguinte.
	
· O controlador (controller) tem funcionalidade para atualizar o estado do modelo, como, por exemplo, uma nota fiscal, ou alterar a apresentação da visão do modelo.
· Um modelo (model) mantém os dados, notificando visões e controladores quando da ocorrência de mudança em seu estado.
· A visão (view) permite a exibição dos dados.
Após a definição lógica da arquitetura, o engenheiro de software precisará definir a arquitetura física por meio do modelo de implantação, que projeta a infraestrutura de hardware necessária para o software projetado.
Você poderia questionar: “O engenheiro de software especifica hardware?”.
Nesse caso, não, mas o projeto tem de definir os nós computacionais necessários para a implantação do software, devendo a especificação do hardware ficar por conta da equipe de infraestrutura. A imagem seguinte exemplifica um diagrama de implantação com quatro nós computacionais e as respectivas conexões.
Você lembra qual a composição das camadas apresentadas?
Cada camada é composta por um conjunto de classes, formando componentes diversos. Os componentes podem ser compostos por uma ou mais classes que encapsulam funcionalidades de forma independente – um conjunto de componentes pode compor um sistema complexo. A forma de representar essa “componentização” do software é definida no modelo de implementação. A imagem abaixo ilustra o diagrama de componentes embutido no diagrama de implantação da figura anterior, de modo que podemos verificar a alocação por nó computacional dos referidos componentes.
Mapeamento objeto-relacional
O padrão da indústria de software atualmente é o paradigma orientado a objetos, que podem assumir estruturas de dados com elevado grau de complexidade, sendo que a maioria deles, em algum momento, necessita de persistência.
Por outro lado, o padrão das tecnologias de banco de dados ainda é o modelo relacional, ou seja, temos uma estrutura de armazenamento bidimensional denominada tabela.
O que fazer para integrar os dois padrões?
Vamos utilizar o diagrama de classes como modelo conceitual do banco de dados e, a partir de então, gerar o modelo lógico de banco de dados, criando as tabelas necessárias às persistências exigidas pelos objetos. Esse processo é denominado mapeamento objeto-relacional. A imagem abaixo ilustra um exemplo de associação muitos-para-muitos em um diagrama de classes, cujo mapeamento gera as três tabelas descritas.
Realização do projeto da interface gráfica com o usuário
O diagrama de casos de uso define as funcionalidades do sistema, sendo que cada caso de uso representa uma interação completa entre o sistema e um agente externo denominado ator. Nessa interação, precisamos definir uma interface como meio de comunicação homem-máquina. Nesse ponto, o requisito-chave não funcional é usabilidade, portanto é fundamental a participação do usuário no processo de definição das interfaces, ou seja, “deixe o usuário no comando”.
Vamos apresentar possíveis questões relativas à interface que podem surgir: tempo de resposta – em um sistema de venda online com alto tempo de resposta, talvez ocorra uma desistência e uma ida para o concorrente; recursos de ajuda, disponíveis sem que haja necessidade de abandonar a interface; tratamento de erros, por meio de uma linguagem inteligível para o usuário; acessibilidade da aplicação, com foco no atendimento aos usuários com necessidades especiais.
Resumindo: Neste módulo, pudemos avaliar a importância da etapa de projeto no processo de desenvolvimento de software.
Cabe ao engenheiro de software implementar as seguintes atividades que genericamente compõem a etapa de projeto:
1. Refinamento dos aspectos estáticos e estruturais do sistema.
2. Detalhamento dos aspectos dinâmicos do sistema.
3. Detalhamento da arquiteturado sistema.
4. Mapeamento objeto-relacional.
5. Realização do projeto da interface gráfica com o usuário.
Ao final desta etapa, podemos iniciar a implementação do software de acordo com as especificações contidas nos modelos de projeto gerados.
Módulo 3
Reconhecer as etapas de implementação e testes do processo de desenvolvimento de software
Implementação
Quais são as entregas da etapa “projeto” do processo de desenvolvimento de software? Modelos, ou seja, diagramas e especificações textuais que permitem a implementação, ou codificação do software. Realizando um paralelo com a Engenharia Civil, temos plantas baixas, projeto estrutural, hidráulico-sanitário, elétrico etc.; agora, podemos ir para o terreno construir a casa.
A etapa “implementação” do processo de desenvolvimento de software permite realizar a tradução dos modelos de projeto em código executável por meio do uso de uma ou mais linguagens de programação.
Temos aqui um desafio! Ainda não conhecemos todos os detalhes dos algoritmos que efetivamente resolvem o problema; para solucioná-lo, entram em cena os programadores.
Podemos destacar o impacto de muitos requisitos não funcionais nesta etapa, tais como linguagens de programação, frameworks de persistência, e.g., framework para o mapeamento objeto-relacional escrito na linguagem Java denominado hibernate, sistema de gerenciamento de banco de dados, requisitos de qualidade, e.g., confiabilidade, usabilidade etc., reutilização de componentes, entre outros.
Nesse contexto, podemos descrever a denominada “Crise do software” sintetizada pela afirmativa de Edsger Dijkstra, em 1972:
A MAIOR CAUSA DA CRISE DO SOFTWARE É QUE AS MÁQUINAS TORNARAM-SE VÁRIAS ORDENS DE MAGNITUDE MAIS POTENTES! EM TERMOS DIRETOS, ENQUANTO NÃO HAVIA MÁQUINAS, PROGRAMAR NÃO ERA UM PROBLEMA; QUANDO TIVEMOS COMPUTADORES FRACOS, ISSO SE TORNOU UM PROBLEMA PEQUENO, E, AGORA QUE TEMOS COMPUTADORES GIGANTESCOS, PROGRAMAR TORNOU-SE UM PROBLEMA GIGANTESCO.
PRESSMAN, 2016.
Importante destacar que o desenvolvimento tecnológico do hardware nos últimos anos permitiu o desenvolvimento de softwares cada vez mais complexos, tendo forte impacto na indústria de software. Como exemplo, podemos apresentar a substituição do paradigma estruturado pelo paradigma orientado a objetos, baseado na programação orientada a objetos, que permite o reuso intensivo de especificação, bem como melhor manutenibilidade e, como consequência, o desenvolvimento de softwares mais complexos.
Qualidade de software
Um dos fatores que exerce influência negativa sobre um projeto é a complexidade, estando associada a uma característica bastante simples: o tamanho das especificações. Em programas de computador, o problema de complexidade é ainda mais grave, em razão das interações entre os diversos componentes do sistema.
A discussão sobre problemas de software versus complexidade não estará completa sem abordar o assunto qualidade. De forma simplificada, a qualidade está em conformidade com os requisitos, tendo como objetivo satisfazer o cliente por meio da aplicação da Engenharia de Software, nosso contexto.
A norma ISO 9126 identifica seis atributos fundamentais de qualidade para o software:
	Funcionalidade
	Satisfação dos requisitos funcionais.
	Confiabilidade
	Tempo de disponibilidade do software.
	Usabilidade
	Facilidade de uso.
	Eficiência
	Otimização dos recursos do sistema.
	Facilidade de manutenção
	Realização de correção no software.
	Portabilidade
	Adequação a diferentes ambientes.
A qualidade possui duas dimensões fundamentais aplicáveis ao software: as dimensões da qualidade do processo e da qualidade do produto.
Considerando que estamos descrevendo a etapa de implementação do processo de software, vamos apresentar considerações relativas à qualidade do produto software, ou seja, aos testes que garantem a qualidade do produto software.
Teste de software
A qualidade do produto software pode ser garantida através de sistemáticas aplicações de testes nos vários estágios do desenvolvimento da aplicação. Esses testes permitem a validação da estrutura interna do software e sua aderência aos respectivos requisitos. A integração dos subsistemas também é avaliada, com destaque para as interfaces de comunicação existentes entre os referidos componentes de software.
Podemos, então, definir teste como um processo sistemático e planejado que tem por finalidade única a identificação de erros. No caso de softwares complexos, sabe-se que o teste será capaz de descobrir a presença de erros, mas não a sua ausência!
Softwares mal testados podem gerar prejuízos às empresas. Um defeito de projeto poderá encadear requisições de compras inadequadas, gerar resultados financeiros incorretos, entre outros. Até mesmo as tomadas de decisões gerenciais da empresa podem ser negativamente impactadas, pois muitos profissionais se apoiam nas informações com o objetivo de tornar a empresa mais eficiente. A qualidade das decisões está intimamente ligada à qualidade das informações disponibilizadas aos diversos níveis gerenciais.
Os procedimentos de testes aplicados diretamente em softwares são também conhecidos como testes de software ou testes dinâmicos, podendo, em sua maioria, sofrer alto nível de automação, o que possibilita a criação de complexos ambientes de testes que simulam diversos cenários de utilização.
ATENÇÃO: Lembre-se de que quanto mais cenários simulados, maior o nível de validação que obtemos do produto, caracterizando maior nível de qualidade do software desenvolvido.
Os testes de software têm por objetivo avaliar a qualidade desse produto nas mais variadas dimensões possíveis, ou seja, em relação à sua estrutura interna, na aderência às regras de negócios estabelecidas, nos parâmetros de performance esperados pelo produto etc.
Durante a codificação do software, podemos adotar a estratégia representada abaixo. Essa espiral é percorrida a partir do interior, aumentando o nível de abstração a cada volta. Vamos descrever como cada etapa dessa estratégia funciona.
	Teste de unidade
	A validação da unidade de software é a primeira etapa da estratégia, tendo por objetivo testar componentes individuais de uma aplicação.
Nesta estratégia de testes, o objetivo é executar o software a fim de exercitar adequadamente toda a estrutura interna de um componente, como os desvios condicionais, os laços de processamento etc.
	Teste de integração
	Objetiva a manutenção de compatibilidade das novas unidades construídas, ou modificadas, com os componentes previamente existentes.
A compatibilidade de um componente é quebrada sempre que existe alteração ou exclusão de uma rotina ou propriedade pública de um componente. Quando isso ocorre, todos os outros componentes que empregam essas rotinas ou propriedades estão automaticamente incompatíveis com o componente modificado, gerando erros durante a execução do software. São exatamente esses erros que devem ser identificados nesse estágio dos testes de software.
	Teste de validação
	Quando atingimos esse estágio dos testes, a maior parte das falhas de funcionalidade deve ter sido detectada nos testes unitários e nos testes de integração, sendo o objetivo desta etapa realizar a validação da solução como um todo. Os testes de validação contam com uma infraestrutura mais complexa de hardware, visando estar o mais próximo do ambiente real de produção.
Nesta etapa, são realizados os testes funcionais, que visam verificar se a versão corrente do sistema permite executar processos ou casos de uso completos do ponto de vista do usuário, de modo a obter os resultados esperados; e os testes não funcionais, que visam testar o software em relação às características não funcionais, como desempenho, segurança, confidencialidade, recuperação a falhas etc.
Devemos planejar os testes de software a partir dos cenários contidos nas descrições de casos de uso e identificados na etapa de análise do processo de software; normalmente, o engenheiro de software define os cenários com alto nível de abstração lógica, denominados tambémde casos de teste. Neste caso, o analista de teste da equipe de qualidade deverá diminuir o nível de abstração dos referidos cenários, detalhando os mesmos por meio dos casos de testes. Como exemplo, um caso de uso “Realizar saque de conta”, onde podemos imaginar um cenário em que o saldo supera o valor do saque e a transação ocorre sem problema, ou cenários alternativos ou de exceção, tais como bloqueio do saque por saldo insuficiente; liberação do saque utilizando o limite disponível pelo banco com cobrança de juros; liberação do saque com retirada de fundo de aplicação, entre outros.
Nesta etapa, ocorrem os procedimentos de aceite, que deverão ser realizados a cada ciclo de implementação da solução, permitindo correções antecipadas de determinados pontos que não foram adequadamente atendidos pelo software.
Como essa é a última oportunidade efetiva de detectar falhas no software, poderemos empregar o aceite como uma estratégia para reduzir riscos de uma implantação onde um erro vital não detectado pode comprometer a imagem da solução como um todo. Dessa forma, podemos dividir o aceite em três momentos distintos: o Teste Alpha, o Teste Beta e o Aceite Formal.
	Aceite Teste Alpha
	Os usuários finais são convidados a operar o software dentro de um ambiente controlado, sendo realizado na instalação do desenvolvedor.
	Aceite Teste Beta
	Os usuários finais são convidados a operar o produto utilizando suas próprias instalações físicas, ou seja, o software é testado em um ambiente não controlado pelo desenvolvedor.
	Aceite Formal
	Trata-se de uma variação do Teste Beta, cabendo aos próprios clientes e usuários determinarem o que deverá ser testado e validar se os requisitos foram adequadamente implementados.
A validação tem sucesso quando o software atende os requisitos, ou seja, funciona da forma esperada pelo usuário.
Teste de sistema
A última etapa na espiral, é o teste de sistema, que extrapola os limites da engenharia de software, ou seja, considera o contexto mais amplo da engenharia de sistemas de computadores. Após ser validado, o software deve ser combinado com outros elementos do sistema, tais como hardware, base de dados etc. Vejamos alguns testes sugeridos nesta etapa.
	Teste de recuperação
	Este teste tem por objetivo avaliar o comportamento do software após a ocorrência de um erro ou de determinadas condições anormais.
Os testes de recuperação devem também contemplar os procedimentos de recuperação do estado inicial da transação interrompida, impedindo que determinados processamentos sejam realizados pela metade e sejam futuramente interpretados como completos. Como exemplo, simular saque com defeito no caixa eletrônico ou simular saque com queda de energia.
	Teste de segurança
	Teste cujo objetivo é detectar as falhas de segurança que podem comprometer o sigilo e a fidelidade das informações, bem como provocar perdas de dados ou interrupções de processamento. Esses ataques à segurança do software podem ter origens internas ou externas.
A ideia é avaliar o nível de segurança que toda a infraestrutura oferece, simulando situações que provocam a quebra de protocolos de segurança. Como exemplo, avaliar se a senha do cartão está sendo requisitada antes e depois da transação ou avaliar se a senha adicional e randômica está sendo requisitada no início da operação.
	Teste por esforço
	Teste com o objetivo de simular condições atípicas de utilização do software, provocando aumentos e reduções sucessivas de transações que superem os volumes máximos previstos para o software, gerando contínuas situações de pico e avaliando como o software e toda a infraestrutura estão se comportando. Como exemplo, simular 10.000 saques simultâneos.
	Teste de desempenho
	Teste cujo objetivo é determinar se o desempenho, nas situações previstas de pico máximo de acesso e concorrência, está consistente com os requisitos definidos.
Devemos especificar os tempos de resposta considerados factíveis à realização de cada cenário. Como exemplo, garantir que manipulação com dispositivos físicos no saque não ultrapassem 10 segundos da operação.
	Teste de disponibilização
	Também chamado de teste de configuração, tem por objetivo executar o software sobre diversas configurações de softwares e hardwares. A ideia é garantir que a solução tecnológica seja executada adequadamente sobre os mais variados ambientes de produção previstos nas fases de levantamento dos requisitos.
O referido teste também examina todos os procedimentos de instalação e instaladores a serem utilizados pelos clientes, bem como a documentação que será usada pelos usuários finais. Como exemplo, simular saque com impressora dos fornecedores X, Y e Z. 
Resumindo: Neste módulo, pudemos avaliar a importância das etapas de implementação e testes do processo de desenvolvimento de software.
À medida que o programador codifica a solução a partir dos modelos gerados na etapa de projeto, os testes são aplicados por meio de uma estratégia de testes em forma de espiral, incluindo quatro categorias de testes.
Inicialmente, o teste unitário permite validar a estrutura interna de cada componente de software.
O teste de integração possibilita validar a integração de novos componentes, ou componentes que passaram por manutenção, com os componentes previamente validados.
O teste de validação inclui a realização de testes de alto nível realizados pelos usuários finais do sistema, inicialmente em ambientes controlados pelo desenvolvedor e, posteriormente, em ambientes de produção não controlados pelo desenvolvedor, a fim de que ocorra a verificação do atendimento aos requisitos. Ao final, podemos ter a aceitação do sistema pelo usuário.
Finalizando, o teste de sistema, que extrapola os limites da Engenharia de Software, permite combinar o software com outros elementos do sistema, tais como hardware, base de dados etc.
Módulo 4
Descrever as etapas de implantação e manutenção do processo de desenvolvimento de software
Implantação
Considerando as etapas do processo de desenvolvimento de software apresentadas, o que temos até o momento?
O produto software testado em condições de migrar para o ambiente denominado “produção”, ou seja, mundo real, onde os usuários irão utilizá-lo nas suas rotinas diárias, seja na realização de um controle administrativo, seja no contexto de um processo de tomada de decisão.
A implantação é a etapa do processo de desenvolvimento de software relacionada à transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários, ou seja, o sistema entra em produção no ambiente real.
O objetivo da implantação é produzir com sucesso a entrega do software para seus usuários finais, podendo cobrir vasta gama de atividades, como descritas a seguir:
	A produção de releases externos do software
	Inclui o lançamento de uma nova versão do software, ou resultado de uma manutenção no mesmo, sendo exigidas decisões, por parte de desenvolvedores e usuários, sobre como realizar a distribuição do produto.
	A embalagem do software
	Quando o software será comercializado por meio de determinada mídia, como, por exemplo, DVD. 
	Distribuição do software
	É o processo de entrega de software para o usuário final, podendo ocorrer de forma manual, sem auxílio de ferramentas, ou automática, com auxílio de ferramentas.
	Instalação do software
	É um processo que inclui a instalação de todos os arquivos necessários à execução do software projetado.
	Prestação de ajuda e assistência aos usuários
	Quando a complexidade do software exige um serviço de atendimento aos clientes que procuram esclarecimentos sobre dúvidas relacionadas às funcionalidades ou sobre problemas técnicos relacionados ao software, e.g., serviço de help desk.
GESTÃO DE CONFIGURAÇÕES VERSUS IMPLANTAÇÃO
Vamos imaginar que estamos desenvolvendo um software utilizando o fluxo de processo iterativo e incremental, ou evolucionário, sendo esse fluxo comumente adotado atualmente. Após os testes, geramos a primeira versão e a disponibilizamos no ambiente de produção. Nesteponto, realizamos a implantação dessa versão.
O que faz a equipe desenvolvedora? Inicia o desenvolvimento da segunda versão, ou seja, mais um conjunto de requisitos é analisado em um novo ciclo iterativo. Em algum momento, soa um alerta dos usuários informando que “temos um defeito” no software em produção.
O que você faria como engenheiro de software?
· CENÁRIO 1: Terminar a versão 2 com o defeito corrigido e liberá-la para produção.
· CENÁRIO 2: Realizar a manutenção, eliminando o defeito na versão 1, liberá-la para produção e realizar a devida alteração na versão 2 em desenvolvimento.
Tecnicamente, o cenário 2 é a melhor solução, pois o usuário teria de aguardar a liberação da versão 2, convivendo por um período com o impacto negativo do defeito do software no ambiente de produção.
Neste pequeno estudo de caso, podemos destacar dois problemas para o engenheiro de software: o controle de alterações e o controle de versões. Nesta etapa, temos de considerar alguns aspectos que relacionam a gestão de configurações com a implantação de um sistema.
Gestão de configuração, de forma simplificada, é um conjunto de tarefas que visam gerenciar as alterações durante o desenvolvimento do software, sendo essa gestão aplicada em todas as etapas do processo de desenvolvimento de software. Uma das tarefas do processo de gestão de configuração é denominada “controle de alterações”, permitindo solucionar o primeiro problema apresentado anteriormente.
A imagem abaixo, ilustra um processo de controle de alterações, que, a partir de uma solicitação de alteração, requer a avaliação do mérito técnico, dos efeitos colaterais em potencial, do impacto global em termos de configuração e da funcionalidade e do custo da alteração. Na referida figura, o acrônimo ECO (Engineering Change Order) representa um pedido de alteração de engenharia.
Qual a importância deste processo para a etapa de implantação?
O processo tem de estar bem definido e ajustado à complexidade do software quando implantado, pois os defeitos serão identificados em produção, e os procedimentos de alteração estarão definidos. Lembre-se de que, em projetos complexos, a falta de um controle de alterações pode gerar o caos. Afinal, sabe-se que a fase de testes não é capaz de zerar a existência de erros.
Vamos, agora, ao segundo problema do nosso pequeno exemplo apresentado, ou seja, “controle de versões”. Neste caso, ainda no contexto do gerenciamento de configuração, podemos destacar o gerenciamento de releases.
Um release de sistema é uma versão do mesmo distribuída aos clientes. A gestão de releases determina quando um release será liberado para o cliente, gerencia o processo de criação e de meios de distribuição, bem como documenta o release.
Um release pode incluir:
· Arquivos de configuração
· Arquivos de dados
· Um programa de instalação
· Documentação eletrônica ou em papel
· Empacotamento e publicidade associada
Manutenção
Realizada a implantação do software com sucesso, iniciamos imediatamente a próxima etapa: a manutenção.
A etapa mais longa do ciclo de vida do software, a manutenção inclui a correção de defeitos não identificados nas etapas anteriores do processo de desenvolvimento de software, no aprimoramento da implementação dos subsistemas e na disponibilização de novas funcionalidades a partir da identificação de novos requisitos.
Pouco tempo depois de iniciada a etapa de manutenção, começam a chegar aos engenheiros de software os relatos de erros, bem como solicitações de adaptações e melhorias. Estas devem ser planejadas, programadas e executadas. Reiteramos aqui a importância do processo de gestão de alterações descrito e ilustrado anteriormente.
Outro problema associado à manutenção é a mobilidade dos engenheiros de software, pois, com o passar do tempo, a equipe que trabalhou no desenvolvimento do software pode ter sido substituída ou mesmo dissolvida, ou seja, pode ocorrer a inexistência de um engenheiro de software que conheça o sistema.
Neste ponto, podemos destacar a importância do correto cumprimento de todas as etapas do processo de desenvolvimento de software, de modo a gerar uma solução bem estruturada para o projeto, incluindo os diversos modelos que representam decisões tomadas ao longo do projeto, o que permite o entendimento da solução por parte de um engenheiro de software que não trabalhou no desenvolvimento do produto.
Na verdade, toda solução que aplica as melhores práticas da engenharia de software busca o cumprimento do requisito não funcional denominado manutenibilidade, sendo esse um indicativo qualitativo da facilidade de corrigir, adaptar ou melhorar o software.
Importante! Um dos grandes objetivos da engenharia de software é criar sistemas que apresentem alta manutenibilidade.
Manutenção versus Reengenharia de Software
Vamos considerar determinado produto de software implantado. Ao longo do tempo, a equipe de engenheiros de software realiza as manutenções necessárias em função de erros detectados ou de alterações geradas a partir da volatilidade dos requisitos. Paralelamente, a tecnologia vai se tornando obsoleta, e a manutenção, cada vez mais difícil.
O que você faria? Que tal reconstruirmos o produto com mais funcionalidades, melhor desempenho, confiabilidade e manutenibilidade? Esse processo é denominado reengenharia.
A reengenharia possui dois níveis: reengenharia de processos de negócio e reengenharia de software.
No primeiro nível, também denominado estratégico, a reengenharia de processos de negócio visa – por meio de alterações em regras de negócio, ou seja, das tarefas que permitem a obtenção de um resultado de negócio – o aumento da eficiência e competitividade de uma empresa.
Destacamos que um software tem como importante objetivo agregar valor a uma organização por meio da automação de processos; portanto, a referida alteração no negócio deve ser absorvida pela engenharia de software, gerando dois cenários:
· CENÁRIO 1: Que exige a construção de um novo software.
· CENÁRIO 2: Que permite a modificação de um software existente.
No segundo cenário, aplicamos a reengenharia de software, o que extrapola os objetivos da etapa manutenção.
Resumindo: Neste módulo, destacamos a importância das etapas de implantação e manutenção do processo de desenvolvimento de software.
A implantação inclui a migração do software de um ambiente de desenvolvimento para um ambiente de produção, permitindo a utilização do software pelos diversos usuários envolvidos.
Após a etapa de implantação, temos a manutenção. A existência de erros descobertos em produção é um fato; para tal, a equipe de engenheiros de software terá de aplicar as tarefas definidas no processo de gerenciamento de alterações. Outro motivo comum de solicitação de manutenção ocorre em função da volatilidade dos requisitos.
Com o tempo, as solicitações vão sendo intensificadas em função de alterações de regras de negócios ou pela obsolescência da tecnologia, podendo-se, neste caso, aplicar a reengenharia de software, o que extrapola a etapa de manutenção.
Conclusão
Considerações finais
Apresentamos as etapas genéricas, ou típicas, de um processo de desenvolvimento de software, que são: levantamento de requisitos, análise, projeto, implementação, testes, implantação e manutenção. Lembramos que a Engenharia de Requisitos inclui as etapas de levantamento de requisitos e análise desse processo.
O levantamento de requisitos tem como principal entrega o documento de requisitos, comumente categorizados em requisitos funcionais, não funcionais e de domínio, ou regras de negócio. Essa etapa define o contexto do projeto.
Na análise, o engenheiro de software cria os modelos a partir dos requisitos. Como exemplos, destacamos os modelos de casos de uso, de classes e atividades.
No projeto, ocorrem os refinamentos dos modelos de análise e a criação de novos modelos, que permitirão a implementação da solução. Como exemplo, podemos destacar os modelos de interação, implementação e implantação.
Na etapa de implementação, ocorre a codificação da solução a partirdos modelos gerados na etapa de projeto. Na sequência, temos a etapa de testes, que permite a validação inicial de unidades de código, terminando na validação do sistema como um todo em ambiente próximo ao de produção.
A etapa de implantação permite a migração para o ambiente de produção, onde estão os usuários finais do sistema. Em seguida, temos a etapa de manutenção, que visa o atendimento às solicitações de alterações no software em virtude de defeitos encontrados ou alterações decorrentes da volatilidade de alguns requisitos.
AULA 3 – MODELOS DE PROCESSOS DE DESENVOLVIMENTOS DE SOFTWARES
Descrição
Os modelos de Processos de Desenvolvimento de Software e seus fluxos de atividades.
Propósito
Compreender os principais modelos de processos de desenvolvimento de software (processo unificado, Extreme Programming, SCRUM e processo unificado ágil), suas aplicações, etapas e atividades, conhecimentos indispensáveis ao engenheiro de software.
Objetivos
· Módulo 1: Descrever os modelos prescritivos de processo de desenvolvimento de software
· Módulo 2: Explicar o Processo Unificado para o desenvolvimento de software
· Módulo 3: Explicar o processo de desenvolvimento ágil Extreme Programming (XP)
· Módulo 4: Explicar o processo de desenvolvimento ágil SCRUM e o Processo Unificado Ágil (AUP)
Introdução
O software apresenta um destaque cada vez maior na vida moderna. Uma tendência que ratifica essa importância está no uso intensivo dos smartphones. O sucesso dessa tecnologia, não descartando a relevância do hardware, tem um forte respaldo na competência do software, isto é, interfaces com designs atraentes, responsivas, usabilidade intuitiva, entre outras características.
Por trás desta competência, temos vários especialistas, tais como: engenheiros de software, web designers, administradores de banco de dados, arquitetos de software e outros que trabalham arduamente para manutenção desse sucesso exponencial. Esta equipe tem uma composição multidisciplinar, refletindo uma característica do software: a complexidade. O trato dessa complexidade requer a aplicação da Engenharia de Software que, por sua vez, tem como base a camada de processos. Dito isso, podemos afirmar que não existe engenharia sem processo.
Nesse contexto, é essencial conhecermos os principais modelos de processos de desenvolvimento de software, cuja escolha depende de forma significativa da sua complexidade, pois quanto mais complexo, mais formalismo deve estar embutido no modelo adotado.
Módulo 1
Descrever os modelos prescritivos de processo de desenvolvimento de software
Engenharia de software
Os modelos de Processo de Desenvolvimento de Software têm este como principal produto no contexto da Engenharia de Software.
Diferentemente de produtos de outras engenharias, o software possui alta volatilidade em função dos requisitos, visto que é constantemente impactado pelas evoluções na tecnologia, fatores estes que agregam a ele uma complexidade adicional.
A melhor tratativa para a complexidade é a aplicação de metodologia que permita a decomposição do problema em outros menores e de forma sistemática, cabendo à Engenharia de Software tal sistematização.
A Engenharia de Software é uma tecnologia em camadas, então vejamos as descrições de tais camadas:
	Camada qualidade
	Garante o cumprimento dos requisitos que atendem às expectativas dos usuários.
	Camada de processo
	Determina as etapas de desenvolvimento do software.
	Camada de métodos
	Define, por exemplo, as técnicas de levantamento de requisitos, os artefatos gerados em função da técnica de modelagem adotada, tais como modelos de casos de uso ou de classes.
	Camada ferramentas
	Estimula a utilização de ferramentas “CASE” (Computer-Aided Software Engineering) no desenho dos diversos artefatos ou mesmo na geração automática de código, entre outras aplicações.
Processo de desenvolvimento de software
O processo de desenvolvimento de software é iniciado com especificações e modelos com alto nível de abstração e, à medida que o desenvolvimento de software se aproxima da codificação, o nível de abstração diminui, de modo que o código representa o nível mais baixo da abstração ou de maior detalhamento na especificação do software.
As atividades típicas que compõem o processo de desenvolvimento de software, descritas por Pressman (2016), estão representadas na imagem abaixo. O objetivo é ilustrar as atividades mais comuns que compõem os processos de desenvolvimento de software, ou seja, as atividades genéricas incorporadas por qualquer processo, sendo uma notória diferença entre os modelos, a ênfase dada a cada atividade.
Vamos agora descrever cada uma das atividades comumente previstas em um processo de desenvolvimento de software:
	Comunicação
	As primeiras atividades de um processo de software requerem uma comunicação intensiva com os usuários, buscando o entendimento do problema, a definição de objetivos para o projeto, bem como a identificação de requisitos.
	Planejamento
	Destaca-se, nesta atividade, a área de conhecimento e gerenciamento de projeto, que permitirá a elaboração de um Plano de Gerenciamento do Projeto de forma sistemática, tendo como entrega importante, o cronograma que inclui as atividades a serem desenvolvidas nesse projeto.
	Modelagem
	A engenharia tem como melhor prática a geração de modelos, tal como a planta baixa de uma casa, e a maioria desses modelos gráficos, denominados de diagramas na Engenharia de Software, podendo ser complementados por descrições textuais, assim como o modelo de casos de uso.
	Construção
	A partir dos modelos gerados, é realizada a construção ou implementação do software, portanto, os modelos determinam o comportamento deste. Essa atividade inclui a codificação e os testes de software de acordo com o planejado.
	Entrega
	Ao final, ocorre o objetivo de um plano de projeto de software, i.e., a entrega do produto em produção de acordo com o planejado.
Modelos de processos prescritivos
A Engenharia de Software permite sistematizar o desenvolvimento de software por meio de processos. Nesse sentido, um modelo de processo identifica as atividades que serão desenvolvidas, sendo comumente utilizadas as atividades ilustradas na figura anterior.
Podemos, então, afirmar que um modelo de processo sistematiza o trabalho de engenharia de software, incluindo as atividades, fluxos de processos, artefatos gerados e outros, propiciando, também, estabilidade, controle e organização ao referido trabalho.
O que diferencia os modelos de processos? Embora todas as atividades típicas sejam utilizadas em todos os modelos, cada representação enfatiza de forma diferente cada atividade, e o encadeamento dessas ações — talvez o mais importante — é denominado de fluxo de processo.
O primeiro conjunto de modelos que abordaremos são os denominados modelos de processos prescritivos, por prescreverem metodologias, tarefas, artefatos, garantia da qualidade e mecanismos de controle de mudanças, ou seja, um conjunto de elementos de processo.
Modelo em cascata
O modelo em cascata sugere uma abordagem sequencial, isto é, a execução das atividades ilustradas acima, de forma encadeada. Este é o modelo de processo mais antigo da engenharia de software e utilizado de forma intensa à época em que o paradigma de desenvolvimento estruturado era dominante na indústria de software.
Podemos descrever algumas características negativas relativas a esse modelo, tais como:
· Projetos reais raramente seguem um fluxo sequencial, em função da volatilidade dos requisitos.
· Assume que é possível ao cliente explicitar detalhadamente todas as suas necessidades em forma de requisitos, antes do início das demais fases do desenvolvimento, aumentando a possibilidade de propagação de erros pelas fases do processo.
· Inflexibilidade na divisão do projeto em fases distintas, visto que uma versão do software somente estará disponível ao final do projeto.
Dica: Podemos aplicar o modelo em cascata em projetos com requisitos fixos e de forma que o fluxo de trabalho possaser realizado sequencialmente até o seu encerramento.
Modelo de Processo Incremental e Modelos de Processo Evolucionário
Ambos os modelos dividem o desenvolvimento de um produto de software em ciclos, e cada ciclo de desenvolvimento inclui todas as atividades contidas na figura anterior.
Podemos observar abaixo na ilustração, a repetição, a cada incremento e de forma iterativa, das atividades típicas de um processo de software. Cada iteração considera um subconjunto de requisitos, ocorrendo uma entrega a cada final de ciclo, isto é, a cada novo incremento um novo conjunto de funcionalidades é disponibilizado ao usuário final.
O desenvolvimento atual do software comumente tem restrições de prazos e uma alta volatilidade dos requisitos, limitando a geração de um produto abrangente. Esse modelo permite a geração de uma versão limitada que imediatamente agrega valor ao usuário.
Qual é a diferença entre o modelo incremental e evolucionário?
	Modelo incremental
	Modelo evolucionário
	No modelo incremental, ocorre a entrega de um produto essencial, estando as demais iterações bem definidas
	No modelo evolucionário, uma parte dos requisitos está bem entendida, ocorrendo o versionamento em função desse entendimento. A cada nova iteração ocorre um melhor entendimento do problema por meio da definição de novos requisitos e novas versões são geradas
O modelo incremental de processo de desenvolvimento de software
Veja, a seguir, as atividades típicas de desenvolvimento incremental que ocorrem em cada iteração do modelo:
Prototipação
Imagine a construção de uma grande barragem onde, em uma fase inicial, é construído um protótipo em escala reduzida para numericamente avaliar os esforços existentes. Depois dos testes, a maquete serve como peça de museu ou vai para um laboratório de uma universidade para estudos de caso.
Você poderia questionar: como faço isso no software? A abstração é a mesma, porém o produto software tem suas peculiaridades.
Vamos imaginar que um requisito não funcional determina que a replicação de dados ocorrerá por meio de uma tecnologia desconhecida da equipe de desenvolvimento. Seria razoável aguardar o momento do desenvolvimento para realizar a tratativa desse requisito?
Resposta: Com certeza não, pois existiria um risco enorme do projeto atrasar em função do atendimento desse requisito tardiamente. Nesse caso, podemos aplicar a prototipação.
Na prototipação, o desenvolvedor interage diretamente com o usuário, escutando seus pedidos e desenvolvendo, imediatamente, um protótipo do produto desejado, isso de forma iterativa e evolucionária, como um “projeto rápido” apresentado a seguir.
Saiba mais: Podemos descartar esse software gerado? Depende, normalmente essa primeira versão do protótipo serve apenas para validar um requisito e necessita ser reconstruída, mas, considerando as peculiaridades do software, essa mesma versão pode ser refinada e integrada ao sistema em desenvolvimento.
Atenção, a prototipação pode ser utilizada como modelo de processo na solução de problemas de baixa complexidade.
Modelo espiral
O Modelo Espiral foi originalmente proposto por Barry Boehm em 1988. De acordo com a ilustração abaixo, cada quadrante da espiral corresponde a uma etapa do desenvolvimento e cada loop na espiral representa uma fase do processo de software. O loop mais interno pode estar relacionado com a viabilidade do sistema, o próximo, ao levantamento de requisitos e assim sucessivamente.
Barry W. Boehm é um engenheiro de software americano, professor de ciência da computação, engenharia industrial e de sistemas, além de diretor fundador do Center for Systems and Software Engineering the University of Southern California. Ele é conhecido por suas muitas contribuições para a área de engenharia de software, como o Modelo Espiral.
	Primeira etapa
	A primeira etapa (Analysis) inclui a determinação de objetivos, alternativas, riscos e restrições, em que ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos.
	Segunda etapa
	Na segunda etapa (Evaluation), avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco, sendo a prototipação uma boa ferramenta para tratar de ameaças.
	Terceira etapa
	Na terceira etapa (Development) ocorre o desenvolvimento do produto.
	Quarta etapa
	Na quarta etapa (Planning) o produto é avaliado, sendo realizado o planejamento para início de um novo ciclo.
Podemos fazer uso da abstração de forma a visualizarmos o modelo espiral como um metamodelo, tendo como exemplo o proposto por Pressman (2016), apresentado abaixo, na qual a espiral do modelo é dividida nas atividades genéricas ilustradas na Figura 1.
Resumindo: Neste módulo, pudemos destacar a importância dos modelos dos processos prescritivos para a Engenharia de Software. Vale lembrar que a camada base dessa engenharia é a referente a processos. Os modelos de processos permitem definir as atividades que serão executadas durante o projeto de software, bem como o fluxo de processos que define o encadeamento relativo a essas mesmas atividades.
Os modelos de processos prescritivos incluem a definição de metodologias, tarefas, artefatos, garantia da qualidade e mecanismos de controle de mudanças, isto é, um conjunto de elementos de processo.
O modelo em cascata determina a realização das tarefas de forma sequencial. Já os modelos de processo incremental e os modelos de processo evolucionário permitem um versionamento do software de forma iterativa e incremental.
O paradigma da prototipação é aplicado primariamente na validação de requisitos. O modelo espiral permite um desenvolvimento evolucionário do software.
Módulo 2
Explicar o Processo Unificado para o desenvolvimento de software
Unified Modeling Language - UML
A compreensão do Processo Unificado exige que tenhamos o entendimento da Unified Modeling Language, comumente denominada de UML, que é uma linguagem de modelagem padrão para a elaboração de artefatos no contexto do paradigma de desenvolvimento orientado a objetos.
Saiba mais: Até meados da década de 1990, o paradigma de desenvolvimento estruturado era o padrão mais utilizado na indústria de software, ou seja, os métodos vigentes aplicavam os conceitos estruturados nos artefatos gerados, tal como o diagrama de fluxo de dados na etapa de análise. Importante destacar que a unidade básica do software era a função.
Considerando a evolução da complexidade do software, alguns metodologistas perceberam que os conceitos da orientação a objetos permitiam um melhor trato da complexidade, particularmente nos requisitos reuso e manutenibilidade. Esses metodologistas começaram a propor métodos com artefatos direcionados ao referido paradigma. A unidade básica do software passou a ser o objeto, que inclui dados ou atributos, e funções ou métodos, encapsulados.
Em algum momento, percebeu-se a necessidade de um padrão para a modelagem de sistemas que fosse aceito e utilizado amplamente, surgindo a UML em 1996 como a linguagem “unificadora” das diversas propostas de métodos orientados a objetos. Em 1997, a UML foi aprovada pelo Object Management Group (OMG), tornando-se um padrão de modelagem orientada a objeto na indústria do software.
A UML é uma linguagem visual, independente de linguagem de programação e de processo de desenvolvimento. Um processo de desenvolvimento que utilize a UML como linguagem de modelagem envolve a criação de artefatos de software gráficos, denominados de diagramas, que podem ser complementados por descrições textuais.
Por que é definida como linguagem?
Uma linguagem serve para a comunicação, possuindo uma sintaxe e uma semântica associada. A sintaxe determina o padrão de escrita, tal como, a estrutura de uma frase formada por “sujeito + verbo + predicado” e a semântica está associada ao significado da frase, tal como, “Carlos foi ao clube”. Fazendo uma analogia com a UML, a Figura 6 ilustra a estrutura de uma classe, cujo padrão inclui o nome da classe, atributos e métodos, ouseja, esse padrão de desenho, ou sintaxe do modelo, é definido pela UML.
E a semântica?
A partir do momento que construímos um diagrama com um conjunto de classes, assim como ilustrado na Figura 7, temos então a formação de uma rede semântica, na qual os objetos e associações representam uma abstração da estrutura estática de certo domínio do problema.
E a comunicação?
Como já afirmado, uma linguagem serve para comunicação. No caso do desenvolvimento de software, um modelo permite a comunicação entre engenheiros de software, entre estes e os usuários para validação dos referidos modelos, entre estes e os gerentes de projeto ou programadores; enfim, caso você, como engenheiro de software, desenhe um diagrama de classes, a semântica será compreendida por qualquer outro engenheiro de software que faça uso do paradigma orientado a objetos.
A ilustração acima, mostra os diagramas especificados na UML, com destaque para as duas categorias: diagramas comportamentais e diagramas estruturais. Os diagramas comportamentais têm ênfase na abstração funcional do projeto de software e os diagramas estruturais, nas abstrações das estruturas de dados e de componentes.
Processo unificado - RUP
O Processo Unificado, também denominado de Rational Unified Process (RUP), é um processo de desenvolvimento de software criado pela Rational Software Corporation, empresa fundada pelos criadores da UML, posteriormente adquirida pela IBM.
O RUP é considerado um processo formal que permite ser utilizado na solução de problemas com alta complexidade, entretanto, pode ser customizado para projetos de qualquer escala.
O RUP possui três princípios:
	Guiado por casos de uso
	O planejamento do desenvolvimento é feito em função dos casos de uso, de modo que o processo é iniciado pela abstração funcional, ou seja, pelos serviços desejados pelos usuários.
	Centrado em arquitetura
	O RUP enfatiza o papel da arquitetura permitindo ao arquiteto de software manter o foco nas metas corretas, tais como, compreensibilidade, confiança em mudanças futuras e reutilização.
A arquitetura deve permitir a realização dos requisitos, abrangendo um conjunto de decisões estruturais e comportamentais, alinhado às duas categorias de diagramas ilustradas na Figura 8, com destaque para a modularização da solução.
	Iterativo e incremental
	O RUP aplica o modelo de processo de software iterativo e incremental. De forma evolucionária, novos requisitos são incorporados ocorrendo o versionamento das entregas de software ao usuário final, fundamental ao desenvolvimento de software moderno. Não necessariamente deve ocorrer uma entrega ao final de uma iteração.
A figura seguinte, ilustra o aspecto bidimensional do RUP. Na horizontal, temos as fases que permitem capturar o aspecto temporal do projeto, que podem ser utilizadas como marcos durante esse projeto, e na vertical, as atividades iterativas. Vejamos as descrições dessas fases.
Veja mais detalhes sobre as etapas do modelo unificado a seguir:
	Iniciação
	A fase de iniciação, também denominada de concepção, exige do engenheiro de software uma visão inicial e geral do sistema a ser desenvolvido, cabendo destacar a possibilidade da utilização dos modelos de estado ou de atividades no desenho dos processos de negócio, isto é, a aplicação da primeira atividade do fluxo de trabalho que é a modelagem de negócio. Tal modelagem permite aos engenheiros de software compreender o negócio e garantir que todas as partes interessadas tenham um entendimento comum do domínio do problema.
A partir dessa compreensão do negócio, pode-se obter os requisitos fundamentais do projeto, isto é, requisitos funcionais e não funcionais. Em seguida, realizar a modelagem dos casos de uso mais críticos, incluídos os principais serviços disponibilizados aos usuários, e a modelagem de classes, para entendimento da estrutura de dados a ser gerenciada pelo sistema.
A identificação dos principais requisitos, junto aos modelos de casos de uso e classes iniciais, permite o estabelecimento do escopo do projeto. Nessa fase, a arquitetura do sistema limita-se a um esquema provisório com os principais subsistemas e as funções e recursos que o compõem.
Temos agora dois grandes desafios aplicáveis a muitos projetos de software: verificar a viabilidade técnica e financeira do projeto, bem como garantir o seu financiamento, visto que ambos os desafios incluem também a análise de riscos.
Podemos avançar com o projeto? Caso positivo, vamos realizar o planejamento detalhado da fase de Elaboração e geral das demais fases. Caso negativo, encerramos nossas atividades.
	Elaboração
	Com o projeto de software aprovado, iniciamos a fase de elaboração, que é realizada de forma iterativa e incremental, de acordo com a imagem acima. Vamos reduzir o nível de abstração dos modelos de casos de uso e de classes iniciais, finalizando a atividade de análise do processo de software.
Na sequência, temos a atividade de projeto na qual ocorre o refinamento de alguns modelos da análise e a criação de novos, assim como o modelo de interação, que representa os aspectos dinâmicos do sistema, além de construir um protótipo da interface com o usuário. A representação arquitetural é expandida em cinco visões do software: modelo de casos de uso, modelo de análise, modelo de projeto, modelo de implementação e modelo de implantação. Cada visão inclui um conjunto de modelos com seus respectivos diagramas. Nessa fase, devemos, também, minimizar os riscos e realizar o planejamento da fase de construção.
	Construção
	A fase de construção segue o modelo de arquitetura gerando os componentes, ou aplica-se o reuso, que tornam os casos de uso operacionais para os usuários.
Os modelos gerados na fase de elaboração são concluídos para refletir a versão final do incremento de software. Com o avanço da codificação, são realizados os testes unitários, os testes de integração entre os componentes e os testes de validação, até o teste beta, em que os usuários realizam a validação em ambiente de desenvolvimento controlado.
	Transição
	A fase de transição tem como objetivo realizar a implantação do software no ambiente de produção. Inicialmente, o software é disponibilizado aos usuários para realização do teste beta em ambiente não controlado pelo desenvolvimento, tendo como foco a correção de defeitos e mudanças necessárias em função dos feedbacks dos usuários.
Nessa fase, podem ocorrer a elaboração dos manuais do usuário, treinamento dos usuários, procedimentos de instalação, montagem de estrutura de suporte ou definição do processo de manufatura. Na conclusão dessa fase, o incremento torna-se uma versão de produção utilizável pela comunidade de usuários.
Fluxo de trabalho
Após o detalhamento das fases do RUP ilustradas anteriormente, vamos entender as atividades transversais. Essas atividades, que correspondem às atividades genéricas de um processo de desenvolvimento de software, apresentadas anteriormente, compõem o denominado fluxo de trabalho, sendo as atividades distribuídas em todas as fases.
Como ocorre o relacionamento entre as dimensões fases do projeto x fluxos de projeto9?
Cada atividade do fluxo de trabalho se desenvolve de forma mais intensa em determinada fase. Por exemplo, os fluxos de trabalho da modelagem de negócio e requisitos são intensos na fase de concepção, justamente quando são definidos os requisitos de alto nível do negócio; a análise e design, i.e., projeto, tem uma intensidade na concepção em função dos modelos de análise e projeto, entretanto podemos observar alguma atividade na fase de construção, pois alguns modelos são refinados nesta fase do software.
· Por que ocorre a atividade de implementação na fase de elaboração?
· Essa fase não é intensa em análise e projeto?
Lembra-se da prototipação? Podemos nessa fase validar algum requisito do software aplicando a prototipação que inclui atividade de codificação, i.e., implementação.
O RUP define três grupos de atividades de apoio ao desenvolvimento do software:
	Ambiente
	Inclui as atividadesnecessárias para configurar os processos e as ferramentas que darão suporte à equipe de desenvolvimento.
	Gerenciamento de configuração e mudança
	Permite a estruturação sistemática dos artefatos, tais como documentos e modelos, que precisam estar sob controle de versão, devendo essas alterações serem visíveis.
	Gerência de projeto
	Enfatiza a importância do gerenciamento de projetos; nessa atividade, sugerimos a utilização das melhores práticas contidas no PMBOK.
O guia Project Management Body of Knowledge (PMBOK) é um conjunto de práticas na gestão de projetos organizado pelo instituto PMI, sendo considerado a base do conhecimento sobre gestão de projetos por profissionais da área.
Resumindo: Neste módulo, pudemos avaliar a importância do Processo Unificado no contexto do desenvolvimento de software. Inicialmente, apresentamos a UML, linguagem de modelagem unificada, a qual define o padrão dos artefatos de software de acordo com o paradigma de desenvolvimento orientado a objetos a serem utilizados em dado modelo de processo de desenvolvimento de software.
Prioritariamente, o RUP é um modelo de processo de software para o desenvolvimento de acordo com o paradigma orientado a objetos. Esse processo tem um alto grau de formalismo, possuindo os seguintes princípios: baseado em casos de uso, centrado em arquitetura e iterativo e incremental. Enfim, se o problema for complexo, o RUP é um forte candidato a ser escolhido por algum engenheiro de software como requisito não funcional “modelo de processo de software”.
ATENÇÃO: Vale destacar que o RUP pode ser ajustado a qualquer escala de complexidade e a seleção do requisito não será tão simplista.
Módulo 3
Explicar o processo de desenvolvimento ágil Extreme Programming (XP)
Desenvolvimento ágil de software
Até meados dos anos 1990, os processos de desenvolvimento de software prescritivos exigiam um detalhado planejamento de projeto, um sistema de garantia da qualidade estabelecido, a aplicação de métodos de análise e projeto, tal como a modelagem de caso de uso, apoiados por ferramentas CASE e controlados por um disciplinado e formal modelo de processo de desenvolvimento de software.
Essa visão era influenciada por equipes de engenheiros de software engajados em sistemas de software complexos que exigiam um esforço significativo de planejamento, projeto e documentação de sistema.
Mas esse esforço justifica-se em sistemas de menor grau de complexidade?
Em 2001, um grupo de 17 metodologistas e outros profissionais da indústria de software se reuniram no estado norte-americano de Utah para discutir e propor uma alternativa aos processos prescritivos dominantes à época. Ao final da reunião, esse grupo lançou as bases para um novo conceito de processo de software, as quais foram registradas em um documento que chamaram de Manifesto para o Desenvolvimento Ágil de Software, que inclui quatro valores:
1. Indivíduos e interações, mais do que processos e ferramentas.
2. Software em funcionamento, mais do que documentação abrangente.
3. Colaboração com o cliente, mais do que negociação de contratos.
4. Resposta a mudanças, mais do que seguir um plano.
A maioria dos métodos ágeis de desenvolvimento de software têm foco no próprio software, em vez de em seu projeto e documentação, assumem um fluxo de processo iterativo e incremental para entrega de software e apoiam aplicações de negócios nas quais os requisitos possuem alta volatilidade durante o desenvolvimento.
Um projeto de software ágil busca a capacidade de implantar uma nova versão a cada incremento, enfatizando o software funcional como uma medida primária de progresso.
A entrega de software rápida permite que os clientes validem de forma imediata o incremento, indicando possíveis erros ou alterações de requisitos, bem como descrevendo novos requisitos para as próximas iterações.
ATENÇÃO: Métodos ágeis também enfatizam comunicações em tempo real entre equipe de desenvolvimento e clientes.
Extreme Programming - XP
A Extreme Programming, ou simplesmente XP, é considerada um processo de desenvolvimento de software ágil, tendo sido proposta por Kent Beck em 1999. A XP adota valores que servem como critérios que norteiam as partes interessadas de um projeto, incluindo: comunicação, simplicidade, feedback, coragem e respeito.
Kent Beck é um engenheiro de software americano criador do Extreme Programming e Test Driven Development. Beck foi um dos 17 signatários originais do Agile Manifesto (Manifesto ágil) em 2001, que trata-se de uma declaração de princípios que fundamentam o desenvolvimento ágil de software.
Vejamos uma breve descrição de cada valor:
	Comunicação
	A comunicação objetiva construir um entendimento dos requisitos com o mínimo de documentação formal e o máximo de interação entre equipe de desenvolvimento e clientes.
	Simplicidade
	A simplicidade sugere que a equipe adote soluções mais simples, criando um ambiente onde o custo de mudanças no futuro seja baixo.
	Feedback
	O feedback permite que os programadores também tenham feedback quando da execução dos testes e quando da validação funcional por parte dos clientes, permitindo a correção de erros e alterações nos requisitos.
	Coragem
	A coragem é necessária para lidar com o risco de erro, que deve ser considerado natural e se traduz em confiança nos seus mecanismos de prevenção e proteção.
	Respeito
	O respeito é o valor mais básico e que dá sustentação a todos os demais, e sem o qual não haverá nada que possa salvar um projeto de software do insucesso.
Saiba mais: Assim como um segundo nível de abstração, a XP possui cinco princípios que servem para ajudar a equipe de software na escolha de alternativas de solução de problemas durante o projeto. Os princípios incluem: feedback rápido, assumir simplicidade, mudança incremental, abraçando mudanças e trabalho de qualidade.
A XP possui doze práticas que se enquadram nos valores e princípios descritos na tabela a seguir:
	TABELA 1 – Doze práticas enquadradas nos valores e princípios da XP
	Prática
	Descrição
	Jogo de Planejamento
	Os requisitos são registrados em cartões, ou fichas, denominados “história de usuários”, sendo a descrição e a priorização realizadas pelos clientes. A equipe de desenvolvimento estima a duração de cada release
	Pequenas releases
	Cada release deve ser a menor possível, incluindo os requisitos mais importantes para o negócio. As releases frequentes permitem um maior feedback para clientes e equipe de desenvolvimento, facilitando o aprendizado e a correção dos defeitos do software
	Metáfora
	Facilita a comunicação com o cliente, entendendo a sua realidade, isto é, procura traduzir as palavras do usuário para o significado que ele espera dentro do projeto. Como exemplo, a metáfora “Estoque 4.0” para um subsistema de gestão virtual dos estoques no contexto de um sistema de logística
	Projeto simples
	Projeto simples inclui projetar somente as histórias de usuários, ou funcionalidades, previamente definidas, bem como se concentrar em soluções de projeto simples e bem estruturadas, tal como o menor número possível de classes e métodos
	Cliente no local de Trabalho
	Incluir um cliente na equipe de desenvolvimento para responder perguntas, ou alguém da parte do cliente com conhecimento do negócio. O cliente é protagonista em um projeto XP
	Semana de 40 horas
	Estimula a busca de um ritmo sustentado de trabalho, tal como 40 horas semanais. Horas extras são permitidas quando trouxerem produtividade para a execução do projeto, devendo estar restringidas a duas semanas seguidas
	Programação pareada
	Todo código deve ser gerado por dois programadores trabalhando em um único computador. O programador codifica e o parceiro revisa e sugere. Dessa forma, o programa sempre é revisto por duas pessoas, evitando e diminuindo, assim, a possibilidade de defeitos. Com isso, busca-se sempre a evolução da equipe, melhorando a qualidade do código fonte gerado
	Propriedade coletiva
	O código fonte pode ser alterado por qualquer membro da equipe de desenvolvimento,de modo que esta detém a propriedade do código. O objetivo com isso é fazer a equipe conhecer todas as partes do sistema. Os testes de unidade e integração garantem a estabilidade dessa prática
	Padronização do Código
	A prática da propriedade coletiva de código exige o estabelecimento de regras para programar a serem seguidas por todos. O objetivo é facilitar o entendimento do código
	Desenvolvimento Orientado a Testes
	Um framework automatizado é sugerido para a escrita dos testes unitários, antes que determinada funcionalidade seja implementada, técnica denominada “test first”.
Os testes de integração também são realizados sistematicamente.
Os testes de validação são especificados pelos clientes a partir das histórias de usuários.
	Refatoração
	A refatoração é um processo de modificar a estrutura interna do software sem alterar o seu comportamento externo, permitindo a melhoria contínua da programação com o mínimo de introdução de erros e mantendo a compatibilidade com o código já existente
	Integração contínua
	O sistema deverá ser integrado sempre que produzir uma nova funcionalidade. Essa continuidade permite a detecção imediata de erros de integração, evitando problemas de compatibilidade e interface
Processo XP
A XP adota o paradigma orientado a objetos, aplicando seus valores, princípios e práticas em um processo com quatro atividades metodológicas: planejamento, projeto, codificação e testes. A figura abaixo, ilustra essas atividades metodológicas propostas por Pressman (2016).
O processo ágil Extreme Programming (XP)
Veja mais detalhes sobre o processo XP e suas etapas:
	Planejamento
	A primeira atividade é ouvir o cliente, realizando um levantamento de requisitos que possibilite o entendimento do escopo do problema. Essa atividade gera um conjunto de histórias de usuários, escritas pelos clientes, juntamente à equipe de desenvolvimento que, de forma simplificada, compõem as necessidades destes. Cada história é colocada em uma ficha ou cartão, sendo priorizadas pelos clientes em função da agregação de valor ao negócio.
Após a elaboração dos cartões, a equipe de desenvolvimento avalia as histórias e as divide em tarefas, estimando o esforço e os recursos necessários à implementação. Caso o esforço exija mais do que três semanas de desenvolvimento, é preciso que o cliente fatore a história analisada em histórias menores.
As histórias que farão parte de cada incremento são selecionadas de forma conjunta por equipe de desenvolvimento e clientes, considerando os seguintes critérios: as histórias de maior risco serão priorizadas, em seguida, as que agregam maior valor ao negócio.
Após a implantação da primeira versão do software, é calculada a velocidade do projeto que é o número de histórias de usuários implementadas na primeira release. Essa velocidade serve para avaliar se o compromisso firmado está compatível e auxiliar na estimativa de prazos das versões seguintes.
	Projeto
	Aqui temos a máxima: “Não complique!”
A XP estimula a modelagem com cartões CRC (Classe-Responsabilidade-Colaborador), que permitem identificar as classes orientadas a objetos relevantes para a iteração corrente do software. Os cartões CRC são os únicos artefatos de projeto gerados durante o processo XP.
Caso algum requisito necessite ser validado em função de sua complexidade, é recomendada a prototipação, como solução pontual, a fim de reduzir o risco dessa especificação no projeto.
A refatoração também é estimulada, tendo em vista uma melhor organização do código interno do software sem impactar a sua funcionalidade, o que minimiza as possibilidades de erros.
	Codificação
	A XP sugere que dois programadores trabalhem juntos em um mesmo computador a fim de criarem código para uma história, fornecendo um mecanismo de solução de problemas em tempo real, cabendo a máxima de que duas cabeças pensam melhor que uma, além de garantir a qualidade do código, pois a sua revisão é imediata. Ambos desenvolvedores têm papéis distintos, tal como, uma pessoa implementa o código, outro verifica os padrões de codificação.
Quando da conclusão da codificação, esse código é integrado aos demais. A estratégia de integração contínua possibilita a identificação precoce de erros.
	Teste
	Como afirmado anteriormente, a equipe de desenvolvimento avalia cada história e a divide em tarefas, que representa uma característica discreta do sistema. Antes da codificação, a equipe de desenvolvimento elabora os testes de unidades a serem aplicados nas tarefas. A automação desses testes é fortemente recomendada, o que estimula a realização dos testes de regressão toda vez que o código for alterado.
A estratégia de integração contínua está vinculada aos testes de integração, realizados de forma sistemática a cada novo código gerado a ser integrado, o que permite lançar alertas logo no início, evitando propagações indesejadas.
Os testes de aceitação são elaborados pelos clientes com base nas histórias de usuários especificadas anteriormente e que serão implementadas na próxima release. O foco está nas funcionalidades externas visíveis aos clientes. Em outras palavras, os testes verificam se o sistema atende às reais necessidades dos usuários.
Teste de Regressão é a reexecução de algum subconjunto de testes que já foram conduzidos para garantir que as modificações não propagaram efeitos colaterais indesejáveis.
Resumindo:
Neste módulo, compreendemos as principais características das metodologias ágeis e, em particular, da Extreme Programming – XP. A partir do questionamento do excesso de formalismo dos processos prescritivos dominantes em meados da década de 1990, foi redigido o Manifesto para o Desenvolvimento Ágil de Software, com quatro valores: Indivíduos e interações, mais do que processos e ferramentas; software em funcionamento, mais do que documentação abrangente; colaboração com o cliente, mais do que negociação de contratos; e resposta a mudanças, mais do que seguir um plano.
A maioria dos métodos ágeis de desenvolvimento de software tem como foco o software, em vez de formalismos de projeto e documentação, assumem um fluxo de processo iterativo e incremental e apoiam aplicações com requisitos altamente voláteis durante o desenvolvimento.
A XP possui um conjunto de valores, princípios e práticas como base aos que assumem a metodologia XP.
O processo XP possui quatro atividades metodológicas:
· O planejamento está fundamentado nas histórias de usuários.
· O projeto tem um mínimo de formalismo em função de gerar um único tipo de artefato, os cartões CRC, sendo sugeridas a prototipação e refatoração nessa etapa.
· A codificação sugere o trabalho em par de programadores alocados em um único computador, permitindo uma revisão de código em tempo real.
· Os testes têm uma característica peculiar, são escritos antes da codificação e aplicados de forma sistemática em ambiente automatizado; na sequência, temos os testes unitários, de integração e aceitação.
Módulo 4
Explicar o processo de desenvolvimento ágil SCRUM e o Processo Unificado Ágil (AUP)
Metodologia ágil SCRUM
O termo SCRUM, cujo significado se reporta a um método de reinício de jogada no esporte rugby, foi concebido fora da indústria de software como um estilo de gerenciamento de produtos. A partir de conceitos relacionados com este termo, Jeffrey Sutherland e Ken Schwaber, no início da década de 1990, desenvolveram o denominado Processo de Desenvolvimento SCRUM, publicado em 1995. Desde então, esse processo passou a ser aplicado no desenvolvimento de software em todo o mundo.
A metodologia SCRUM sofreu, posteriormente, desenvolvimentos adicionais abrangendo o gerenciamento de projetos, não necessariamente relacionados a projetos de software. Entretanto, o SCRUM é empregado de forma sistemática no gerenciamento de projetos de desenvolvimento de software, utilizando-se dos valores e princípios do manifesto ágil junto aos conceitos definidos em seu framework. Tal metodologia tem sua aplicação recomendada principalmente quando, em função da complexidade do projeto,não é possível estabelecer todos os requisitos nas fases iniciais do planejamento.
Importante destacar que alguns autores adotam uma abstração de aplicar ao SCRUM uma denominação de processo ágil de desenvolvimento de software.
O SCRUM possui três pilares fundamentais:
	Transparência
	A equipe de desenvolvedores deve dispor de um mesmo entendimento dos aspectos significativos do processo com base num padrão, tal como uma linguagem comum referente ao processo.
	Inspeção
	A máxima é “inspeção constante de todos os artefatos”, ou seja, a equipe de desenvolvedores deve sistematicamente inspecionar os artefatos SCRUM e o progresso desses, de modo a detectar não conformidades; entretanto, a inspeção não deve ser um entrave à própria execução das tarefas.
	Adaptação
	Inclui a adaptação do produto software, que pode sofrer mudanças em função da volatilidade dos requisitos e/ou mudanças da tecnologia, bem como a adaptação do processo em função de alguma falha; os ajustes devem ser realizados o mais rápido possível de forma a evitar a propagação de desvios.
Papéis no SCRUM
Uma equipe SCRUM é composta pelo Product Owner (Dono de Produto), SCRUM Master e SCRUM Team.
O Dono do Produto, ou Product Owner, faz o papel do cliente, determinando os requisitos e funcionalidades que deverão ser entregues, incluindo as suas mudanças, além de manter e comunicar às partes interessadas uma visão clara do projeto e estar disponível para esclarecer eventuais questionamentos.
O SCRUM Master é o responsável por garantir que as regras do método SCRUM estejam sendo seguidas, desempenhando, também, funções de um facilitador na resolução de problemas ou nas interferências externas. O SCRUM Master é o mantenedor das regras e dos procedimentos do SCRUM durante a execução do projeto, auxiliando a todos da equipe a entenderem seus papéis no processo.
A SCRUM Team, ou equipe SCRUM, é multidisciplinar, incluindo os especialistas necessários para desenvolver o produto de forma a não depender de membros externos, tais como programadores, administradores de banco de dados, web designers etc.
Artefatos SCRUM
Os Artefatos SCRUM são concebidos com a finalidade de garantir que as equipes SCRUM sejam bem-sucedidas na geração de um incremento. Vejamos os principais artefatos:
	Product Backlog
	Lista incluindo todos os requisitos ou funcionalidades levantados para o produto, estando sob responsabilidade do product owner; no início do desenvolvimento, são estabelecidos os requisitos inicialmente conhecidos e mais bem compreendidos, evoluindo à medida que o produto e o ambiente em que ele será utilizado também evoluem, ou seja, o product backlog é dinâmico.
	Sprint Backlog
	Subconjunto de requisitos do product backlog selecionados para determinada iteração, denominada de Sprint; inclui, também, o plano para entregar um incremento do produto e atingir a meta da Sprint, isto é, estabelece quais funcionalidades estarão na próxima versão e o trabalho necessário para a referida entrega, também denominada de “Done”. A equipe de desenvolvimento é a responsável, quando necessário, pelas modificações no Sprint backlog.
Eventos SCRUM
Os eventos permitem otimizar a organização das inspeções e iterações, sendo por meio deles que os conceitos descritos são postos em prática de uma forma ágil e produtiva. Os eventos permitem, também, a minimização da necessidade de reuniões não contempladas no SCRUM. Os eventos possuem um tempo pré-definido com uma duração máxima estipulada denominada de timebox, o que garante uma quantidade apropriada de tempo no planejamento.
Vejamos os eventos SCRUM.
	Sprint
	O Sprint corresponde a uma unidade de iteração em SCRUM, tendo uma duração (timebox) em torno de um mês, ao final do qual é gerado um incremento de produto em condições de uso pelos usuários finais. Ele possui duração consistente durante todo o desenvolvimento. Cada Sprint inclui as atividades típicas de um processo de desenvolvimento de software, tais como, levantamento de requisitos, análise, projeto etc.
	Reunião de planejamento do Sprint
	A Reunião de planejamento do Sprint permite planejar o trabalho a ser realizado em dado Sprint, sendo esse plano resultado de trabalho colaborativo da equipe SCRUM. A reunião é limitada a 8h para um Sprint de um mês, dividida em duas partes que, respectivamente, buscam respostas às seguintes perguntas: O que será entregue no incremento resultante do Sprint planejado? Como será alcançado o trabalho necessário para entregar o incremento?
	Reunião diária do Sprint (Daily SCRUM)
	A Reunião diária do Sprint (Daily SCRUM), como diz o próprio nome, é um evento diário limitado a 15 minutos, no qual a equipe SCRUM ajusta as atividades e cria um plano para as próximas 24 horas. Isso é feito inspecionando o trabalho desde a última daily SCRUM e pela previsão do trabalho a ser feito antes da próxima reunião diária.
	Revisão do Sprint
	A Revisão do Sprint é realizada no final do Sprint para inspecionar o incremento e adaptar, se necessário, o product backlog. Essa é uma reunião informal, e a apresentação do incremento destina-se a obter feedback e a fomentar a colaboração na equipe, não devendo ultrapassar quatro horas para Sprints de um mês.
	Retrospectiva do Sprint
	A Retrospectiva do Sprint é uma oportunidade formal para a equipe SCRUM inspecionar e criar um plano de melhorias a ser seguido durante o próximo Sprint, sendo uma reunião limitada a 3h para Sprints de um mês. Os objetivos dessa retrospectiva incluem verificar como correu o último Sprint no que diz respeito às pessoas, relações, processos e ferramentas; identificar e ordenar os itens que correram de forma satisfatória e potenciais ajustes; e criar um plano para implementar melhorias no modo como a equipe SCRUM faz o seu trabalho.
Fluxo de processo do SCRUM
O processo de desenvolvimento ágil SCRUM
O fluxo de processo SCRUM está ilustrado acima. Os requisitos que definem as funcionalidades a serem entregues são agrupadas pelo product owner no product backlog. Veja mais detalhes sobre este fluxo, a seguir:
	Reunião de planejamento de Sprint
	No início de cada Sprint, é realizada a reunião de planejamento de Sprint, com a participação do product owner, SCRUM master e SCRUM Teams, a fim de que sejam priorizados e selecionados os requisitos do product backlog que serão implementados no Sprint em planejamento. Esses requisitos são decompostos em tarefas, para cada tarefa é alocado um responsável que realiza a sua estimativa. Ao final da reunião, essas tarefas passam a compor o Sprint backlog.
	Desenvolvimento do Sprint
	Na sequência, a SCRUM Team inicia o desenvolvimento do Sprint de acordo com o planejado. No início de cada dia do Sprint, a daily SCRUM permite o compartilhamento, entre os membros da equipe, do que foi concluído no dia anterior e quais as prioridades do dia atual. O SCRUM master conduz essa reunião.
	Reunião de revisão de Sprint
	Ao final do Sprint, ocorre a reunião de revisão de Sprint que permite a geração de um product backlog revisto, sendo definidas as prováveis exigências para o próximo Sprint; os requisitos podem ser ajustados em função de sua volatilidade ou de novas tecnologias. Participam dessa reunião o project owner, o SCRUM master e a SCRUM Team.
	Reunião de retrospectiva do Sprint
	A última atividade da iteração Sprint é a reunião de retrospectiva do Sprint com a finalidade de levantar as lições aprendidas nessa iteração, incluindo os pontos positivos e o que precisa ser aprimorado nas próximas reuniões.
Processo unificado ágil – AUP
O Processo Unificado Ágil, ou Agile Unified Process (AUP), é uma versão simplificada do Rational Unified Process (RUP). O AUP baseia-se nos seguintes princípios:
· A equipe sabe o que está fazendo. O AUP disponibiliza links de acesso à documentação com muitos detalhes, isso para os que estiverem interessados.
· Simplicidade. Tudo é descrito de forma concisa maximizando a simplicidade.
· Agilidade. O AUP está em conformidade com os valores e princípios da metodologia ágil de desenvolvimentode software.
· Concentre-se em atividades de alto valor. O foco está nas atividades que realmente agregam valor ao cliente.
· Independência de ferramenta. A recomendação é utilizar as ferramentas mais adequadas, que muitas vezes são ferramentas simples.
· Customização. O produto AUP é facilmente customizável às necessidades dos seus usuários.
O AUP adota uma natureza serial para o que é amplo, e iterativo para o que é particular. Vejamos a natureza serial do AUP que inclui as mesmas quatro fases adotadas pelo RUP:
	Concepção
	Tem como objetivos a identificação do escopo do projeto, de uma arquitetura em potencial para o sistema e a viabilidade do projeto.
	Elaboração
	Tem foco na comprovação da arquitetura do sistema.
	Construção
	Visa a construir um software funcional de forma iterativa e incremental que atenda às necessidades das partes interessadas do projeto.
	Transição
	Tem como objetivo validar e implantar o sistema em ambiente de produção.
Vejamos a natureza iterativa do AUP. As atividades que são realizadas de forma iterativa pelos membros da equipe de desenvolvimento para construir, validar e entregar software operacional são as seguintes:
	Modelagem
	Inclui o entendimento do negócio em questão e do problema a ser resolvido pelo software, identificando uma solução; representações UML para os modelos são utilizadas, entretanto, devem ser suficientemente boas e adequadas, ou seja, o mínimo de formalismo.
	Implementação
	Transformação dos modelos em código executável, realizando os respectivos testes básicos, tais como testes unitários.
	Testes
	Realização de uma avaliação objetiva a fim de garantir a qualidade, incluindo a detecção de defeitos, a validação funcional e a verificação de que os requisitos são cumpridos.
	Implantação
	Planejar e executar a entrega do software operacional aos usuários finais e na obtenção de feedback dos usuários.
	Gerenciamento de configuração
	Garantir o acesso aos artefatos do projeto, incluindo o rastreamento das diversas versões, bem como o controle e gerenciamento de suas alterações.
	Gestão de projetos
	Planejar, monitorar e controlar as atividades do projeto a fim de que ele seja entregue no prazo, dentro do orçamento e atendendo as expectativas dos usuários.
	Ambiente
	Atua em apoio às demais atividades, garantindo a infraestrutura do processo que inclui padrões, ferramentas e outras tecnologias de suporte disponíveis à equipe.
Importante destacar que a adoção do AUP requer a aceitação prévia dos conceitos, valores e princípios relacionados com o desenvolvimento ágil.
Resumindo: Neste módulo, destacamos os processos de desenvolvimento ágil SCRUM e Processo Unificado Ágil (AUP). O SCRUM é uma metodologia que possui uma destacada aplicação em projetos de software. Existe a possibilidade de aplicarmos a metodologia SCRUM no gerenciamento de projeto ágil de software ou como processo ágil de desenvolvimento de software. Como todo processo ágil, aplica o fluxo de processo iterativo, sendo cada iteração denominada de Sprint e, ao final de cada um destes, é gerada uma entrega, isto é, um software operacional.
O método AUP tem suas origens no Processo Unificado (RUP), podendo ser considerado uma versão simplificada em função de sua adesão aos valores e princípios das metodologias ágeis. As fases do projeto permanecem as mesmas do RUP, tais como, concepção, elaboração, construção e transição. As mudanças significativas estão nas atividades iterativas compostas de modelagem, implementação, testes, implantação, gerenciamento de configurações, gestão de projetos e ambiente.
Conclusão
Considerações finais
Apresentamos os principais modelos de processo de desenvolvimento de software prescritivos, bem como detalhamos o Processo Unificado (RUP) e os métodos ágeis, com seus valores, princípios e práticas, sendo detalhados o processo Extreme Programming (XP), o processo SCRUM e o Processo Unificado Ágil (APU).
Os modelos de processos prescritivos incluem um conjunto de elementos metodológicos de processo. A partir do questionamento do excesso de formalismo desses processos prescritivos, dominantes em meados da década de 90, foi redigido o Manifesto para o Desenvolvimento Ágil de Software, com um conjunto de valores, princípios e práticas que foram assimilados pelos processos ágeis, tais como, XP, SCRUM e AUP.
Entre os métodos ágeis, o XP está fundamentado nas histórias de usuários, tendo um único tipo de artefato de modelagem, que são os cartões CRC. O SCRUM tem como evento base o Sprint, que corresponde a uma iteração com as tarefas que permitem a criação de incrementos de software operacional. Já o AUP, adota as etapas clássicas do RUP, aplicando uma significativa simplificação nas atividades iterativas, particularmente, na modelagem.
AULA 4 – QUALIDADE DE SOFTWARE
Definição
O planejamento, a garantia e o controle da qualidade como parte do processo de desenvolvimento de software.
Propósito
Compreender a importância do planejamento, garantia e controle da qualidade, através de técnicas adequadas de medições, seleção de métricas e realização de diferentes tipos de testes.
Preparação
Não existem pré-requisitos operacionais para o tema.
Objetivos
· Módulo 1: Descrever a qualidade de processo e de produto de software
· Módulo 2: Explicar o processo da garantia de qualidade de software
· Módulo 3: Explicar o planejamento da qualidade e o controle da qualidade de software
· Módulo 4: Descrever as medições e métricas do software
Introdução
O software tem um destaque cada vez maior na vida moderna. Podemos imaginar a complexidade de um software embarcado em uma aeronave com 500 passageiros ou um software que gerencia o tráfego aéreo de uma grande cidade.
A construção de um software desta magnitude exige o envolvimento de vários especialistas, tais como engenheiros de software, web designers, administradores de banco de dados, arquitetos de software e outros que trabalham arduamente para o sucesso do produto software.
A referida equipe tem uma composição multidisciplinar, refletindo uma característica do software: A complexidade. O trato desta complexidade requer a aplicação da Engenharia de Software, que por sua vez tem como foco a camada qualidade. A referida camada garante que os requisitos que atendem às expectativas do usuário serão cumpridos.
Nesse contexto, o presente tema descreve o planejamento, a garantia e o controle da qualidade de software.
Módulo 1
Descrever a qualidade de processo e de produto de software
Engenharia de Software X Qualidade
Vamos iniciar nosso estudo sobre qualidade no contexto da área de conhecimento Engenharia de Software, que tem como principal produto o software.
A cada dia, o produto software está mais presente nas nossas vidas, quer por meio das redes sociais, em nossos veículos ou nas nossas residências.
No contexto da qualidade de software, podemos destacar a denominada “Crise do software” sintetizada pela afirmativa a seguir:
A MAIOR CAUSA DA CRISE DO SOFTWARE É QUE AS MÁQUINAS SE TORNARAM VÁRIAS ORDENS DE MAGNITUDE MAIS POTENTES! EM TERMOS DIRETOS, ENQUANTO NÃO HAVIA MÁQUINAS, PROGRAMAR NÃO ERA UM PROBLEMA; QUANDO TIVEMOS COMPUTADORES FRACOS, ISSO SE TORNOU UM PROBLEMA PEQUENO, E AGORA QUE TEMOS COMPUTADORES GIGANTESCOS, PROGRAMAR TORNOU-SE UM PROBLEMA GIGANTESCO.
DIJKSTRA, 1972
Importante destacar que o aprimoramento tecnológico do hardware nos últimos anos permitiu o desenvolvimento de softwares cada vez mais complexos, tendo um forte impacto na indústria de software. Exemplos:
1. Podemos apresentar a substituição do paradigma estruturado pelo paradigma orientado a objetos, que permite o reuso intensivo de especificação, bem como uma melhor manutenibilidade e, como consequência, o desenvolvimento de softwares mais complexos.
2. Podemos imaginar as sérias consequências na falha de um software embarcado em uma aeronave com 500 passageiros ou em um sistema de controle de tráfego aéreo de uma grande cidade. Uma falha seria algo bem trágico!
Ambos os exemplos possuem uma característica comum: A complexidade.A melhor tratativa para a complexidade é a aplicação de metodologia que permita a decomposição do problema em problemas menores de forma sistemática, cabendo à engenharia de software essa sistematização. A engenharia de software é uma tecnologia em camadas . Veja:
	Qualidade
	A camada qualidade garante que os requisitos que atendem às expectativas do usuário serão cumpridos.
	Processo
	A camada de processo determina as etapas de desenvolvimento do software.
	Métodos
	A camada de métodos define os artefatos gerados em função da técnica de modelagem adotada.
	Ferramentas
	A camada ferramentas estimula a utilização de ferramentas CASE.
CASE: É uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de software, desde análise de requisitos e modelagem até programação e testes.
Retornando aos nossos exemplos, qual camada evitaria uma falha?
Vejamos os seguintes argumentos e depois tire a sua conclusão.
ATENÇÃO: A camada base é a camada de processo, sendo a camada qualidade dependente da existência dessa, ou seja, a definição de um processo de desenvolvimento de software é condição para a implantação de um sistema de qualidade em um projeto de software.
Os métodos e ferramentas da engenharia de software servem, entre outras coisas, ao propósito de garantir, ou pelo menos facilitar, a obtenção do objetivo de garantir a qualidade no software.
Qualidade de software
De acordo com Pressman (2016), a qualidade de software é definida como uma gestão de qualidade efetiva, aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam.
Vamos a uma análise da citada definição:
	Gestão de qualidade
	Permite estabelecer uma infraestrutura de suporte ao desenvolvimento de software com qualidade.
	Produto útil
	Inclui o atendimento às necessidades dos usuários, ou seja, atendimento aos requisitos, sendo esse produto isento de defeitos.
	Valor mensurável
	Permite a agregação de valor aos usuários e ao fabricante, sendo que nesse último caso, os engenheiros de software terão menos trabalho de manutenção e mais tempo disponível na construção de novas aplicações.
O gerenciamento de qualidade de software usualmente é estruturado em três atividades principais:
· Garantia de qualidade: Estabelece um conjunto de procedimentos e padrões organizacionais que permitem a geração de software com qualidade.
· Planejamento de qualidade: Permite o ajuste dos procedimentos e padrões a um determinado projeto de software.
· Controle de qualidade: Inclui a definição e aprovação de processos que assegurem que a equipe de desenvolvimento de software tenha seguido os procedimentos e os padrões de qualidade de projeto.
A imagem abaixo ilustra o relacionamento entre o processo de gerenciamento da qualidade e o processo de desenvolvimento de software proposta por Sommerville (2019). O primeiro permite uma verificação independente no segundo, verificando as entregas de artefatos do projeto. Uma melhor prática é que a equipe de garantia de qualidade seja independente da equipe de desenvolvimento, pois no caso de surgirem problemas, tal como atraso no projeto, poderia ocorrer um comprometimento da qualidade de modo a cumprir o cronograma.
Podemos visualizar a qualidade de software sob duas dimensões:
	Processo
	Podemos destacar que o processo de desenvolvimento do software exige que diversas decisões sejam tomadas ao longo do mesmo. Portanto, se desejamos produzir software com qualidade, é necessário garantir a qualidade em todas as etapas do processo.
	Produto
	Destacamos que softwares mal testados provocam prejuízos enormes às empresas, pois um simples erro poderá, por exemplo, gerar requisições de compras desnecessárias, produzir indicadores falsos de produtividade, entre outros; podem, também, afetar o processo de tomada de decisão de gerentes e executivos que apoiam-se nas informações para minimizar riscos, direcionar esforços, promover investimentos, sempre na busca da excelência operacional, pois a qualidade das decisões está intimamente ligada à qualidade das informações disponibilizadas pelos softwares organizacionais.
1. Erro é um lapso humano que resulta em um software incorreto.
2. Defeito é uma anomalia no produto.
3. Falha ocorre quando uma unidade funcional de um sistema relacionado a um software não mais consegue desempenhar as funções necessárias ou deixa de operar dentro dos limites especificados.
Qualidade do processo
Processo é uma sequência de etapas que permitem a geração de um produto, no nosso caso, o software.
Atenção: O processo permite uma melhor tratativa em relação à complexidade de obtenção de um determinado produto, pois na maioria das vezes é um trabalho multidisciplinar realizado por analistas, programadores, gerentes de projeto, gerentes de teste e outros.
A Engenharia de Software possui uma diversidade de modelos para processos de desenvolvimento de software que atendem a diferentes problemas, sendo um requisito importante na seleção de um processo a complexidade.
Basicamente, quanto maior a complexidade de um sistema, mais formal deverá ser o processo adotado.
Uma metodologia de processo genérica, segundo Pressman (2016), compreende cinco atividades:
	Comunicação
	A comunicação permite o entendimento do problema, a definição de objetivos para o projeto, bem como a identificação de requisitos.
	Planejamento
	Inclui o gerenciamento de projeto.
	Modelagem
	Abrange a geração de modelos, tal como o modelo de casos de uso.
	Construção
	Inclui, a partir dos modelos gerados, a codificação e os testes de software de acordo com o planejado.
	Entrega
	Disponibiliza o produto em produção de acordo com o planejado.
A garantia da qualidade de um software inclui o estabelecimento de uma cultura de não tolerância a erros.
Os processos devem estar estruturados com mecanismos de detecção de defeitos nos diversos artefatos gerados durante o processo, com o objetivo de evitar a propagação de defeitos nas fases seguintes, refletindo na inserção de defeitos durante a codificação. Os artefatos incluem qualquer entrega gerada durante o processo de software, incluindo, entre outros, os documentos de requisitos, os modelos, bem como o produto software.
COMENTÁRIO: Usualmente, os testes estão relacionados ao produto software, mas podemos aplicar testes em todas as tarefas do processo de desenvolvimento de software, sendo esses denominados de testes de verificação, conhecidos também como testes estáticos. Os objetivos desses testes são os artefatos gerados durante todo o processo de desenvolvimento do software, tal como o diagrama de classes ou o diagrama de casos de uso.
ATENÇÃO: A produção de software com qualidade exige o estabelecimento de um processo de desenvolvimento de software, pois não poderemos garantir a qualidade de algo que não existe.
Qualidade do produto
Pressman (2016) descreve os fatores de qualidade do produto software de McCall, sendo uma proposta de categorização dos fatores que afetam a qualidade de software. Esses fatores de qualidade de software, apresentados na figura abaixo, focam em três etapas de um produto de software: revisão do produto, transição e operação
Vejamos uma descrição dos referidos fatores, cabendo destacar que a avaliação da qualidade de uma aplicação usando esses fatores possibilitará uma sólida indicação da qualidade de um software:
	Correção
	O quanto um programa satisfaz a sua especificação e atende às necessidades do cliente
	Confiabilidade
	O quanto se pode esperar que um programa realize a função pretendida com a precisão exigida
	Eficiência
	A quantidade de recursos computacionais e código exigidos por um programa para desempenhar sua função
	Integridade
	O quanto o acesso ao software ou dados por pessoas não autorizadas pode ser controlado
	Usabilidade
	Esforço necessário para aprender, operar, preparar a entrada de dados e interpretar a saída de um programa
	Facilidade de manutenção
	Esforço necessáriopara localizar e corrigir um erro em um programa
	Flexibilidade
	Esforço necessário para modificar um programa em operação
	Testabilidade
	Esforço necessário para testar um programa de modo a garantir que ele desempenhe a função destinada
	Portabilidade
	Esforço necessário para transferir o programa de um ambiente de hardware e/ou software para outro
	Reusabilidade
	O quanto um programa, ou partes do mesmo, pode ser reutilizado em outras aplicações
	Interoperabilidade
	Esforço necessário para integrar um sistema a outro
A qualidade do produto pode ser garantida por meio de um sistemático plano de testes executado durante a etapa de codificação do processo de software, sendo esses testes denominados de testes de validação.
1. Inicialmente, ocorre a validação da estrutura interna da unidade de software, bem como sua aderência aos requisitos estabelecidos.
2. Em seguida, a validação da sua integração com as unidades de software desenvolvidas anteriormente, com destaque para as validações das interfaces dos componentes de software.
3. Finalmente, ocorre a validação funcional e não funcional do software como um todo, sendo os usuários envolvidos nessa etapa.
Os procedimentos de testes aplicados diretamente em softwares são também denominados de testes de software ou testes dinâmicos.
Os testes de software podem sofrer um alto nível de automação, o que possibilita a criação de complexos ambientes de testes que simulam diversos cenários de utilização. Quanto mais cenários simulados, maior o nível de validação que obtemos do produto, caracterizando maior nível de qualidade do software desenvolvido.
Custos da qualidade
O custo da qualidade é composto pelo custo da conformidade e custo da não conformidade.
Custo da conformidade
Agrega o custo da prevenção de defeitos e o custo da detecção de defeitos ou falhas. O custo de prevenção inclui os esforços do sistema de qualidade em evitar a ocorrência de defeitos, tais como detalhamento de metodologias, treinamentos, utilização de ferramentas, estabelecimento de procedimentos, entre outros. O custo de detecção de defeitos, também denominado de custo de avaliação, é composto pelos custos relacionados à atividade de avaliação, detecção ou inspeção da qualidade do processo ou do produto, tais como revisões de artefatos (requisitos, modelos, planos de testes etc.), inspeções de código, testes de software, auditorias, entre outros.
Custo da não conformidade
O custo proveniente da falta de qualidade, que desapareceria caso não surgisse nenhum erro antes ou depois da entrega do produto ao cliente, soma-se aos custos relacionados às correções de defeitos originados no processo de desenvolvimento de software, tais como retrabalhos, ações corretivas, atrasos nos cronogramas, perdas financeiras e operacionais, entre outros. Tais custos podem ser denominados de custos de falhas internas, ou seja, erros identificados antes da entrega do software ao cliente, e custos de falhas externas, associados aos erros identificados após a referida entrega.
Quanto mais cedo ocorrer a identificação de um defeito, menor o custo.
Resumindo: Neste módulo, destacamos a importância da qualidade no contexto da engenharia de software. Vimos que a qualidade de software possui duas dimensões: processo e produto.
A qualidade do processo exige a definição prévia de um processo de desenvolvimento de software que viabilize a sua aplicação.
Nessa dimensão, são aplicados os testes de verificação nos artefatos gerados nas diversas etapas do processo de software, com o objetivo de impedir a propagação de defeitos nas etapas posteriores do referido processo.
A qualidade do produto é aplicada ao software na etapa de codificação do processo de software. A partir de um plano de testes, são aplicados os testes de validação ou testes de software, que validam desde a estrutura interna de uma unidade de software até as funcionalidades por parte dos usuários.
Atenção: Lembre-se de que um sistema de qualidade tem um custo associado à conformidade, ou seja, à obtenção da garantia da qualidade do software, tendo, também, um custo associado à não conformidade, ou seja, à falta de qualidade do software.
Módulo 2
Explicar o processo da garantia de qualidade de software
Processo de garantia da qualidade
Um sistema de garantia da qualidade de software, também denominado SQA (Software Quality Assurance), pode ser definido como a estrutura organizacional com responsabilidades, procedimentos, processos e recursos para implementação da gestão da qualidade, garantindo que os produtos e serviços de uma determinada organização satisfaçam às expectativas do cliente por meio do atendimento às suas especificações.
O processo de garantia de qualidade de software, parte do referido sistema, inclui a definição e seleção de padrões que devem ser aplicados ao processo de desenvolvimento de software ou ao produto de software, podendo ocorrer a seleção de ferramentas e métodos, como apoio a esses padrões.
Atenção: A equipe de qualidade deve examinar o software sob o ponto de vista do cliente, assertiva alinhada com a máxima de que “A qualidade é conformidade aos requisitos”, ou seja, o software deve atender às necessidades do cliente.
A garantia da qualidade de software é composta pelas atividades que se concentram na gestão da qualidade de software. Vejamos algumas:
	Padrões
	Os padrões, tal como os estabelecidos pela ISO, podem ser adotados pela equipe de Engenharia de Software ou determinados pelo cliente, cabendo à equipe de qualidade garantir que esses padrões sejam aplicados e que todas as entregas estejam em conformidade aos mesmos.
	Revisões e auditorias
	As revisões técnicas permitem a identificação de erros nos diversos artefatos gerados, sendo as auditorias usualmente aplicadas na verificação da conformidade de processos com os respectivos procedimentos, tal como a verificação do processo de revisão, a fim de garantir que as revisões estejam sendo eficazes na descoberta de erros.
	Testes
	Os testes de software têm como finalidade a descoberta de erros, cabendo à equipe de qualidade garantir que os planos de testes sejam implementados e executados na consecução do citado objetivo básico.
	Coleta e análise de erros/defeitos
	Considerando a máxima de que “Não se controla o que não se mede”, a equipe de qualidade deverá realizar a análise de erros e defeitos, propondo melhorias de procedimentos.
	Gerenciamento de mudanças
	Considerando a alta volatilidade de requisitos e as evoluções tecnológicas constantes, cabe à equipe de qualidade o estabelecimento de procedimentos relacionados com a gestão de mudanças.
	Educação
	A equipe de qualidade deverá realizar a gestão de programas educacionais a fim de permitir o aperfeiçoamento da equipe de desenvolvimento.
	Gerência dos fornecedores
	Cabe à equipe de qualidade, no caso de aquisição de software, incorporar exigências de qualidade como parte de qualquer contrato com um fornecedor externo.
	Administração da segurança
	Inclui, entre outros, a proteção de dados em todos os níveis, a implantação de firewalls e a garantia de que o software não tenha sido alterado internamente, sem autorização, cabendo à equipe de qualidade o emprego de processos e tecnologias apropriadas.
	Proteção
	O impacto de defeitos ocultos pode ser catastrófico, tal como no nosso exemplo da aeronave com 500 pessoas, cabendo à equipe de qualidade avaliar o impacto de falhas de software e as respectivas tratativas em relação à redução de riscos.
	Administração de riscos
	A gestão de riscos é responsabilidade da equipe de desenvolvimento, cabendo à equipe de qualidade garantir que essa gestão seja conduzida de forma apropriada e que planos de contingência estejam estabelecidos.
Padrões de software
Vamos entender os tipos de padrões de software que podem ser estabelecidos pela equipe de qualidade:
	Padrões de produto
	Inclui padrões de documentação, tal como um cabeçalho de comentário padronizado para uma definição de uma classe que permitirá instanciar objetos, e padrões decodificação, que definem como uma linguagem de programação deve ser usada
	Padrões de processo
	Definem os processos que devem ser seguidos durante o desenvolvimento de software, tal como o processo da engenharia de requisitos, e uma descrição dos documentos que devem ser escritos ao longo desses processos
Reveja esta figura, apresentada no módulo 1:
Ela ilustra o relacionamento entre os padrões de produto e de processo. Os padrões de produto aplicam-se à saída do processo de software e, em muitos casos, os padrões de processo incluem atividades de processo específicas que asseguram que os padrões de produto sejam seguidos. Podemos destacar alguns aspectos relacionados aos padrões de software:
· Incluem melhores práticas, evitando a repetição de erros
· Provêm um framework para a implementação do processo de garantia de qualidade, assegurando que essas melhores práticas sejam cumpridas
· Permitem a continuidade quando da ocorrência de substituições na equipe
A equipe de qualidade deve gerar, podendo ter como base modelos de padrões nacionais e internacionais, os padrões necessários para sua organização. Recomenda-se que esse trabalho inclua o envolvimento da equipe de desenvolvimento, uma sistemática revisão dos padrões e a disponibilização de ferramentas CASE de apoio aos padrões.
A aplicação de um determinado processo de desenvolvimento de software depende fortemente da complexidade do escopo do problema, de modo que poderão ser utilizados diferentes tipos de processos de software em uma organização, impactando o processo de garantia da qualidade. Do exposto, a equipe de desenvolvimento deve ter a autoridade de modificar os padrões de processo de acordo com as circunstâncias de cada projeto em comum acordo com a equipe de qualidade; importante ressaltar a possibilidade de alterações nos padrões existentes, ou até mesmo a inclusão de novos padrões.
Padrões ISO 9000
Vejamos agora um exemplo de padrão de processo internacional e vamos entender de forma simplificada como pode ocorrer a sua adoção por parte de uma empresa.
ISO 9000 é um conjunto internacional de padrões aplicados a um sistema de gerenciamento de qualidade genérico, podendo ser aplicado na indústria de manufatura, na indústria de serviço e outros.
O padrão ISO 9001 não é especificamente voltado para desenvolvimento de software, mas possui uma interpretação denominada ISO 9000-3 que estabelece princípios gerais que podem ser aplicados ao software. As necessidades delineadas pelos tópicos da ISO 9001 são:
· Responsabilidade administrativa.
· Um sistema de qualidade.
· Revisão contratada.
· Controle de projeto.
· Controle de dados e documentos.
· Identificação e rastreabilidade de produtos.
· Controle de processos.
· Inspeções e testes.
· Ações preventivas e corretivas.
· Registros de controle de qualidade.
· Auditorias de qualidade internas.
· Treinamento.
· Manutenção.
· Técnicas estatísticas.
Atenção: Uma organização de software que busque uma certificação ISO 9001 tem de estabelecer políticas e procedimentos para atender a cada uma das necessidades citadas, bem como ser capaz de demonstrar que tais políticas e procedimentos estão sendo seguidos. A certificação é um indicador da seriedade de como uma organização trata a qualidade.
Os relacionamentos entre o padrão ISO 9000, o manual de qualidade e os planos de qualidade de projeto individual, de acordo com Sommerville (2019), são mostrados na Figura 6. O manual de qualidade, ou Plano SQA, aplica os elementos básicos do padrão ISO 9000. Cada projeto instancia um plano de qualidade a partir do referido manual e de acordo com o processo de desenvolvimento de software adotado. O manual determina o processo de qualidade da organização, que devidamente adaptado a cada novo projeto, permite a implantação do gerenciamento de qualidade de cada projeto instanciado.
Padrão ISO 9126
Vejamos agora um exemplo de padrão de produto disponível para adoção em um projeto de software. O padrão ISO 9126 foi desenvolvido como uma tentativa de identificar os atributos fundamentais de qualidade para software. O padrão identifica seis atributos fundamentais de qualidade:
	Funcionalidade
	O grau com que o software satisfaz às necessidades declaradas conforme indicado pelos subatributos adequabilidade, exatidão, interoperabilidade, conformidade e segurança.
	Confiabilidade
	Quantidade de tempo que o software fica disponível para uso conforme indicado pelos subatributos maturidade, tolerância a falhas, facilidade de recuperação.
	Usabilidade
	Grau de facilidade de utilização do software conforme indicado pelos subatributos facilidade de compreensão, facilidade de aprendizagem, operabilidade.
	Eficiência
	O grau de otimização do uso, pelo software, dos recursos do sistema conforme indicado pelos subatributos comportamento em relação ao tempo, comportamento em relação aos recursos.
	Facilidade de manutenção
	A facilidade com a qual uma correção pode ser realizada no software conforme indicado pelos subatributos facilidade de análise, facilidade de realização de mudanças, estabilidade, testabilidade.
	Portabilidade
	A facilidade com a qual um software pode ser transposto de um ambiente a outro conforme indicado pelos subatributos adaptabilidade, facilidade de instalação, conformidade, facilidade de substituição.
Gerenciamento da qualidade de acordo com o PMBOK
Vamos agora entender o gerenciamento da qualidade segundo o PMBOK (2017).
Uma das dez áreas de conhecimento do PMBOK é o Gerenciamento da Qualidade do Projeto que inclui os processos para incorporação da política de qualidade da organização com relação ao planejamento, gerenciamento e controle dos requisitos de qualidade do projeto e do produto para atender às expectativas dos clientes. A referida área possui três processos que serão descritos a seguir:
Tabela 1 – Processos do Gerenciamento da Qualidade do Projeto
	Planejamento
	Execução
	Monitoramento e Controle
	Gerenciar a Qualidade
	Controlar a Qualidade
	Planejar o Gerenciamento da Qualidade
	Processo do grupo de processo planejamento que permite identificar os requisitos e/ou padrões da qualidade do projeto e suas entregas, e documentar como o projeto demonstrará a conformidade com os requisitos e/ou padrões de qualidade, tendo como principal entrega o plano de gerenciamento da qualidade
	Processo do grupo de processo execução que transforma o plano de gerenciamento da qualidade em atividades da qualidade executáveis que incorporam no projeto as políticas de qualidade da organização
	Processo do grupo de processo planejamento que monitora e registra resultados da execução de atividades de gerenciamento da qualidade para avaliar o desempenho e garantir que as saídas do projeto sejam completas, corretas e atendam às expectativas do cliente
PMBOK: O guia Project Management Body of Knowledge (PMBOK) é um conjunto de práticas na gestão de projetos organizado pelo instituto PMI e é considerado a base do conhecimento sobre gestão de projetos por profissionais da área.
Atenção: O Gerenciamento da Qualidade do Projeto trata do gerenciamento do projeto e das entregas do projeto, adotando, entre outras, a premissa de que a prevenção é preferível à inspeção, pois é melhor obter a qualidade nas entregas, em vez de identificar não conformidades em uma determinada inspeção. Nesse caso, o custo de prevenção é geralmente muito menor do que o custo de corrigir os erros identificados.
Existem cinco níveis de gerenciamento da qualidade cada vez mais eficaz, conforme a seguir:
1. Deixar que o cliente encontre os defeitos é uma abordagem que pode gerar problemas de garantia, recalls, retrabalho e outros, sendo em geral uma abordagem mais cara.
2. Detectar e corrigir os defeitos antes que as entregas sejam enviadas para o cliente como parte do processo de controlar a qualidade, pois esse processo tem custos relacionados, que são principalmente os custos de avaliação e os custos internos de falhas.
3. Usar a garantia da qualidade para examinar e corrigir o processo em si e não apenas defeitosespeciais.
4. Incorporar a qualidade no planejamento e design do projeto e do produto.
5. Criar uma cultura na organização que esteja ciente e comprometida com a qualidade em processos e produtos.
Resumindo: Neste módulo, avaliamos a importância da garantia da qualidade no desenvolvimento de software.
Incialmente, destacamos que um sistema de garantia da qualidade define a estrutura organizacional responsável pela gestão da qualidade, garantindo o atendimento às expectativas do cliente.
Vimos que o processo de garantia de qualidade de software, parte do referido sistema, enfatiza a adoção de padrões que devem ser aplicados ao processo de desenvolvimento de software, bem como garantir que esses sejam cumpridos; os padrões devem ser aplicados nos processos e produtos.
A adoção de um padrão, tal como os especificados pela ISO, permite a geração de manuais de qualidade da organização, que por sua vez define o processo de qualidade da organização, sendo o mesmo customizado para cada projeto em função de sua complexidade e processo de desenvolvimento de software adotado.
Vimos, também, que o PMBOK possui três processos na área de conhecimento e gerenciamento da qualidade de projetos em diferentes grupos de processos.
Módulo 3
Explicar o planejamento da qualidade e o controle da qualidade de software
Planejamento da qualidade
A equipe de SQA, ou equipe de garantia da qualidade, tem como atribuição auxiliar a equipe de software a obter um produto final de alta qualidade.
O SEI recomenda um conjunto de ações de garantia da qualidade que tratam do planejamento, da supervisão, da manutenção de registros, da análise e de relatórios relativos à referida garantia.
SEI: O Software Engineering Institute (SEI) é 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.
Comentário: Essas ações deverão ser realizadas pela equipe de qualidade, sempre que possível independente, que, entre outras atividades, prepara um plano de qualidade de software para um projeto. O plano é desenvolvido como parte do planejamento de projeto, sendo revisado por todos os interessados.
As ações de garantia da qualidade realizadas pela equipe de Engenharia de Software e equipe de qualidade são orientadas pelo plano, que identifica as avaliações, auditorias e revisões a serem realizadas, padrões que serão aplicados no projeto, procedimentos para relatório e acompanhamento de erros, produtos resultantes produzidos pelo grupo de SQA e o feedback que será fornecido à equipe de software.
O plano de qualidade de software fornece um roteiro para instituir a garantia da qualidade de software, devendo ser desenvolvido pela equipe SQA ou pela equipe de desenvolvimento, no caso da inexistência da equipe SQA. O plano serve como um gabarito para atividades de garantia da qualidade de software que serão instituídas para cada projeto de software.
Imagino um questionamento: Cada projeto de software tem um plano?
Resposta: Respondemos ao questionamento nos reportando à imagem ilustrada abaixo, na qual podemos identificar que a organização elabora um manual de qualidade, ou uma política com procedimentos padrões, sendo instanciado para cada projeto, a partir desse manual, um plano de qualidade de software primariamente em função da complexidade e do processo de desenvolvimento do software em questão.
Foi publicado pelo IEEE um padrão para planos de qualidade de software. O padrão recomenda uma estrutura que identifique:
· O propósito e o escopo do plano.
· Uma descrição de todos os artefatos resultantes de engenharia de software (por exemplo, modelos, documentos, código-fonte).
· Todos os padrões e práticas que são aplicados durante a gestão de qualidade.
· As ações e tarefas da garantia da qualidade (incluindo revisões e auditorias) e sua aplicação na gestão de qualidade.
· As ferramentas e os métodos que dão suporte às ações e tarefas da garantia da qualidade.
· Procedimentos para administração de configurações de software.
· Métodos para montagem, salvaguarda e manutenção de todos os registros relativos à garantia da qualidade.
· Papéis e responsabilidades dentro da organização relacionados com a qualidade do software.
IEEE: O Instituto de Engenheiros Eletricistas e Eletrônicos é a maior organização profissional do mundo dedicada ao avanço da tecnologia em benefício da humanidade. O IEEE tem filiais em muitas partes do mundo, sendo seus sócios engenheiros eletricistas, engenheiros da computação, cientistas da computação, profissionais de telecomunicações etc. Sua meta é promover conhecimento no campo da Engenharia Elétrica, Eletrônica e Computação, entre outros.
Planejamento da qualidade segundo o PMBOK
O PMBOK demonstra a importância da qualidade em todos os projetos por meio da definição de uma área de conhecimento denominada de Gerenciamento da Qualidade do Projeto, sendo essa área composta de três processos em diferentes grupos de processos (Tabela 1), ou etapas do ciclo de vida, sendo o processo Planejar o Gerenciamento da Qualidade do grupo de processo planejamento; esse processo permite gerar o Plano de Gestão de Qualidade do Projeto como um todo.
O processo Planejar o Gerenciamento da Qualidade, ilustrado na Tabela 2, é o processo de identificação dos requisitos e/ou padrões de qualidade do projeto e suas entregas, e de documentação de como o projeto demonstrará conformidade com os requisitos e/ou padrões de qualidade.
O principal benefício desse processo é o fornecimento de orientação e direcionamento sobre como a qualidade será gerenciada e verificada ao longo de todo o projeto.
De acordo com a Tabela 2, as entradas são convertidas em saídas pela aplicação das técnicas e ferramentas listadas, cabendo destaque à geração do Plano de Gerenciamento da Qualidade.
Tabela 2 – Planejar o Gerenciamento da Qualidade
	Entradas
	Técnicas e Ferramentas
	Saídas
	Termo de abertura do projeto
	Opinião especializada
	Plano de gerenciamento da qualidade
	Plano de gerenciamento do projeto
	Coleta de dados
	Métricas da qualidade
	Documentos do projeto
	Análise de dados
	Atualizações do plano de gerenciamento do projeto
	Fatores ambientais da empresa
	Tomada de decisões
	Atualizações de documentos do projeto
	Ativos de processos organizacionais
	Representação de dados
	
	
	Planejamento de testes e inspeções
	
	
	Reuniões
	
Planejamento de testes e revisões
Relembrando: Lembramos que teste é um processo sistemático e planejado que tem por finalidade única a identificação de erros.
Vamos apresentar uma visão prática do planejamento de testes e revisões, item 6 do módulo “Técnicas e Ferramentas” da Tabela 2, que permite o planejamento da garantia da qualidade do processo e do produto, segundo Bartié (2002). Podemos observar na figura abaixo que o Processo de Qualidade de Software proposto está decomposto em fases que se organizam em um formato de "U".
As etapas à esquerda estão relacionadas com a qualidade do processo de desenvolvimento de software, sendo aplicados os denominados testes de verificação. As etapas à direita estão relacionadas com a qualidade do produto software, sendo aplicados os denominados testes de validação.
O objetivo de ambos os grupos de testes é garantir que durante o ciclo de desenvolvimento do software se produza efetivamente todos os produtos previstos na metodologia empregada e que o software em construção atenda aos requisitos.
Os testes de verificação visam a garantir o processo de engenharia do software, enquanto os testes de validação estão focados na garantia da qualidade do produto de software, cabendo destacar que ambos os testes se complementam.
Testes de verificação
Avaliam a qualidade de todo o processo de desenvolvimento de software, validando se todas as documentações e atividades geradas estão de acordo com os padrões estabelecidos, reduzindo os riscos de propagação de falhas ao longo do processo.
Os testes de verificação devem concentrar-se em doisaspectos bem distintos, de acordo com a ilustração abaixo: As atividades de verificação com foco nas documentações são denominadas de revisões; e as que avaliam as atividades, são chamadas de auditorias.
As duas situações são consideradas métodos estruturados, pois possuem planejamento, regras de condução e necessitam de profissionais qualificados para desempenhar essas funções e acompanhar seu progresso. A revisão é um processo de análise de determinado documento. O principal objetivo das auditorias de qualidade é avaliar se em determinado projeto a equipe de desenvolvimento segue o processo de desenvolvimento de software, ou seja, registrando os defeitos encontrados, produzindo os documentos de análise e projeto etc.
TESTES DE VALIDAÇÃO
Observando a imagem novamente, iniciamos os testes de validação que focam na garantia do produto software. Os procedimentos de testes aplicados diretamente em softwares são também conhecidos como testes de software ou testes dinâmicos, podendo, em sua maioria, sofrer um alto nível de automação, o que possibilita a criação de complexos ambientes de testes que simulam diversos cenários de utilização.
A validação da unidade de software tem como objetivo executar o software de forma a exercitar adequadamente toda a estrutura interna de um componente, como os desvios condicionais, os laços de processamento etc.
A validação da integração objetiva a manutenção de compatibilidade das novas unidades construídas, ou modificadas, com os componentes previamente existentes.
A validação do sistema conta com uma infraestrutura mais complexa de hardware, visando a estar o mais próximo do ambiente real de produção, sendo realizados os testes funcionais, que visam a verificar se a versão corrente do sistema permite executar processos ou casos de uso completos do ponto de vista do usuário, de modo a obter os resultados esperados, e os testes não funcionais, que visam a testar o software em relação às características não funcionais, como desempenho, segurança, confidencialidade, recuperação de falhas etc.
Como essa é a última oportunidade efetiva de detectar falhas no software, poderemos empregar o aceite como uma estratégia para reduzir riscos de uma implantação na qual um erro vital não detectado pode comprometer a imagem da solução como um todo.
Podemos dividir o aceite em três momentos distintos:
	Teste Alpha
	Os usuários finais são convidados a operar o software dentro de um ambiente controlado, sendo realizado na instalação do desenvolvedor
	Teste Beta
	Os usuários finais são convidados a operar o produto utilizando suas próprias instalações físicas, ou seja, o software é testado em um ambiente não controlado pelo desenvolvedor
	Aceite Formal
	É uma variação do Teste Beta, cabendo aos próprios clientes e usuários determinarem o que deverá ser testado e validar se os requisitos foram adequadamente implementados
Teste de sistema
Você sabia: De acordo com Pressman (2016), os testes de sistema, não inclusos na figura acima, extrapolam os limites da engenharia de software, ou seja, consideram o contexto mais amplo da engenharia de sistemas de computadores.
Após ser validado, o software deve ser combinado com outros elementos do sistema, tais como hardware, base de dados etc. Vejamos alguns testes sugeridos nesta etapa:
	Teste de recuperação
	Tem por objetivo avaliar o comportamento do software após a ocorrência de um erro ou de determinadas condições anormais, tal como simular um saque com defeito no caixa eletrônico ou simular saque com queda de energia.
	Teste de segurança
	Busca detectar as falhas de segurança que podem comprometer o sigilo e a fidelidade das informações, bem como provocar perdas de dados ou interrupções de processamento, tal como avaliar se a senha do cartão está sendo requisitada antes e depois da transação ou avaliar se a senha adicional e randômica está sendo requisitada no início da operação.
	Teste por esforço
	Visa a simular condições atípicas de utilização do software, provocando aumentos e reduções sucessivas de transações que superem os volumes máximos previstos para o software, gerando contínuas situações de pico e avaliando como o software e toda a infraestrutura estão se comportando, tal como simular 10.000 saques simultâneos.
	Teste de desempenho
	Objetiva determinar se o desempenho, nas situações previstas de pico máximo de acesso e concorrência, está consistente com os requisitos definidos, tal como garantir que a manipulação com dispositivos físicos no saque não ultrapasse 10 segundos da operação.
	Teste de disponibilização
	Também chamado de teste de configuração, tem por objetivo executar o software sobre diversas configurações de softwares e hardwares; a ideia é garantir que a solução tecnológica seja executada adequadamente sobre os mais variados ambientes de produção previstos nas fases de levantamento dos requisitos, tal como simular um saque com impressoras dos fornecedores X, Y e Z.
Controle de qualidade
Controlar a qualidade é o processo de monitorar e registrar resultados da execução das atividades de gerenciamento da qualidade verificando se as entregas e o trabalho do projeto cumprem os requisitos especificados. O processo Controlar a Qualidade é realizado para medir a integridade, conformidade e adequação para uso de um produto ou serviço antes da aceitação do usuário e entrega final. Isso é feito medindo todos os passos, atributos e variáveis usados para verificar a conformidade com ou o cumprimento das especificações definidas no planejamento.
	Entradas
	Técnicas e Ferramentas
	Saídas
	Plano de gerenciamento do projeto
· Plano de gerenciamento da qualidade
	Coleta de dados
· Listas de verificação
· Folhas de verificação
· Amostragem estatística
· Questionário e pesquisas
	Medições de controle da qualidade
	Documentos do projeto
· Registro das lições apreendidas
· Métricas da qualidade
· Documentos de teste e avaliação
	Análises de dados
· Análises de desempenho
· Análise de causa-raiz
	Entregas verificadas
	Solicitações de mudança aprovadas
	Inspeção
	Informações sobre o desempenho do trabalho
	Entregas
	Testes/avaliação de produtos
	Solicitações de mudança
	Dados de desempenho do trabalho
	Representação de dados
· Diagramas de causa e efeito
· Gráficos de controle
· Histograma
· Diagramas de dispersão
	Atualizações do plano de gerenciamento do projeto
· Plano de gerenciamento da qualidade
	Fatores ambientais da empresa
	Reuniões
	Atualizações de documentos do projeto
· Registro das questões
· Registro das lições apreendidas
· Registro dos riscos
· Documentos de teste e Avaliação
	Ativos de processos organizacionais
	
	
Atenção:
· Devemos destacar que a entrada do processo “Documentos de testes e avaliação”, na coluna Entradas, incluem os testes aplicados na garantia do processo e do produto descritos anteriormente.
· Um segundo destaque, na coluna Saídas, são as “Solicitações de mudança”, pois uma não conformidade observada poderá gerar uma atualização no registro de mudanças do projeto, sendo que as solicitações de mudança aprovadas podem incluir modificações, como reparos de defeitos, revisão dos métodos de trabalho e revisão dos cronogramas.
Resumindo
Neste módulo, compreendemos o Planejamento da Qualidade com destaque ao trabalho realizado pela equipe de garantia da qualidade, que tem como atribuição auxiliar a equipe de software a obter um produto final de alta qualidade.
O plano de qualidade de software, elaborado pela referida equipe, fornece um roteiro para instituir a garantia da qualidade de software, servindo como um gabarito para as atividades de garantia da qualidade de software que serão instituídas para cada projeto de software.
Existem padrões para os referidos planos propostos pelo IEEE, PMBOK, entre outros.
Vimos também os testes de verificação que estão relacionados com a qualidade do processo de desenvolvimento de software e os testes de validação, relacionados com a qualidade do produto software.
O processo Controlar a qualidade permite atender à máxima“Não se controla o que não se mede”, permitindo monitorar e registrar resultados da execução das atividades de gerenciamento da qualidade, verificando se as entregas e o trabalho do projeto cumprem os requisitos especificados.
Módulo 4
Descrever as medições e métricas do software
Medição
Um elemento-chave de qualquer processo de engenharia é a medição, pois podemos aplicar a máxima “Não se controla o que não se mede”.
Vamos entender o conceito de medição por meio dos termos medida, medição e métricas. No contexto de engenharia de software, uma medida proporciona uma indicação quantitativa da extensão, quantidade, capacidade ou tamanho de algum atributo de um produto ou processo, sendo a medição ato de determinar uma medida.
A métrica é uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo.
Exemplo: Exemplificando, uma medida é estabelecida quando ocorre a coleta do número de erros descobertos em um componente de software. A medição ocorre como resultado de um conjunto de revisões de componentes e testes de unidade investigados na coleta de medidas do número de erros para cada um. A métrica de software relaciona as medidas individuais, ou seja, o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade.
A medição de software está preocupada com a quantificação de algum atributo de um sistema de software, como a sua complexidade ou a sua confiabilidade. Comparando os valores medidos uns com os outros e com os padrões que se aplicam a uma organização, deve ser possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia de processos de software, de ferramentas e de métodos, ou seja, o gerenciamento da qualidade pode contar com medições de atributos que afetam a qualidade do software.
Processo de medição
O fluxo abaixo ilustra um processo de medição proposto por Sommerville (2019), que pode ser parte de um processo de avaliação da qualidade de software, no qual cada componente do sistema pode ser analisado separadamente usando uma variedade de métricas. Os valores dessas métricas podem, então, ser comparados com diferentes componentes e, talvez, com dados de medição históricos, coletados em projetos anteriores. Medições anômalas, que se desviam significativamente da norma, em geral indicam problemas com a qualidade desses componentes.
	Escolher as medições a serem feitas
	Inclui a formulação das questões às quais a medida se destina a responder, bem como a definição das medições necessárias para respondê-las.
	Selecionar os componentes a serem avaliados
	Selecionar um conjunto representativo de componentes para medição, a fim de permitir uma avaliação geral da qualidade do sistema.
	Mediar as características dos componentes
	Os componentes selecionados são medidos, e os valores de métricas associados são calculados, sendo sugerido o uso de uma ferramenta de coleta automática de dados.
	Identificar medições anômalas
	Depois que as medições do componente foram feitas, é possível compará-las umas com as outras e com as medições anteriores registradas em um banco de dados de medição, devendo-se procurar valores atipicamente altos ou baixos para cada métrica, pois eles sugerem que pode haver problemas com o componente que está exibindo esses valores.
	Analisar componentes anômalos
	Ao identificar componentes que têm valores anômalos, é preciso examiná-los para decidir se esses valores de métricas anormais significam que a qualidade do componente está comprometida ou não, pois um valor de métrica anormal, e.g., para a complexidade, não significa necessariamente um componente de má qualidade, pois pode haver algum outro motivo para o alto valor, ou seja, pode não haver problema de qualidade com o componente.
Uma boa prática inclui a manutenção dos dados coletados como um recurso organizacional e guardar registros históricos de todos os projetos, pois o estabelecimento de um banco de dados de medição robusto permitirá realizar comparações de qualidade de software em projetos e validar as relações entre atributos de componentes internos e características de qualidade.
Método GQM
O método GQM (Goal – Question – Metric) é uma técnica aplicada no planejamento do trabalho de medição, ou seja, permite a identificação de métricas significativas para qualquer parte do processo de software. O GQM organiza o planejamento de uma medição de software em etapas de acordo com as descrições a seguir:
GQM: Goal Question Metric - GQM é uma abordagem de métrica de software em engenharia de software, desenvolvida por Victor Basili, da Universidade de Maryland, e pelo Laboratório de Engenharia de Software do Goddard Space Flight Center da NASA, após orientar uma tese de doutorado do Dr. David M. Weiss. (Wikipedia)
	Objetivo
	Um objetivo de medição deve ser específico para uma determinada atividade do processo ou característica de produto a ser avaliada e de acordo com os requisitos do software, tal como “Garantir que todos os requisitos funcionais deverão ser testados”.
	Questões
	Definição de um conjunto de questões que devem ser respondidas para atingir o objetivo, tal como “Qual a cobertura dos testes?”; as questões estabelecem uma ponte entre os objetivos planejados e as métricas.
	Métricas
	Deverão ser formuladas em função das respostas às questões elaboradas, tal como “Número de requisitos testados”.
Conheça as métricas utilizadas no processo de garantia da qualidade de software:
Métricas
Relembrando: Como afirmado anteriormente, uma métrica é uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo, tal como o número médio de erros encontrados por revisão ou o número médio de erros encontrados por teste de unidade.
A Engenharia de Software é uma área de conhecimento quantitativa, portanto, uma métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software por meio de atributos específicos e mensuráveis permitindo aos mesmos criar um software de alta qualidade. Vamos entender como são utilizadas as métricas.
No contexto do processo de definição e após a definição das métricas, coletam-se os dados necessários para derivar as métricas formuladas, sendo as mesmas analisadas com base em diretrizes preestabelecidas e dados do passado; os resultados das análises são interpretados para obter informações sobre a qualidade do software e os dados da interpretação podem gerar alterações nos requisitos, modelos de projeto, código-fonte ou processo de software.
Saiba mais: Uma melhor prática é descrever um conjunto de atributos a serem aplicados às métricas, tais como: Fácil aprendizado em relação à sua derivação e com uma computação sem demanda de esforço; deverá satisfazer as ideias do engenheiro sobre o atributo do produto considerado (por exemplo, uma métrica que mede coesão de módulo deverá crescer em valor na medida em que aumenta o nível de coesão); sempre produzir resultados que não sejam ambíguos; a computação matemática da métrica deverá usar medidas que não resultem em combinações incomuns de unidades, e.g., multiplicar o número de pessoas nas equipes de projeto pelas variáveis da linguagem de programação no programa resulta em uma mistura duvidosa de unidades que não é claramente convincente; baseadas no modelo de requisitos, modelo de projeto ou na própria estrutura do programa; fornecer informações que podem levar a um produto final de melhor qualidade.
Podemos afirmar que uma métrica de software é uma característica de um sistema de software, da documentação do sistema ou do processo de desenvolvimento, que pode ser medida objetivamente. De acordo com Sommerville (2019), as métricas de software podem ser:
	Métricas de controle ou de processo
	Apoiam o gerenciamento de processos, ou seja, geralmente estão associadas aos processos de software, tais como o esforço médio ou o tempo necessário para reparar defeitos relatados. Podem ser usados três tipos de métricas de processo:
1. O tempo queum determinado processo leva para ser concluído.
2. Os recursos necessários para um determinado processo, tais como o esforço total, em pessoas-dia, custos de viagens ou recursos de computadores.
3. O número de ocorrências de um determinado evento, tais como o número de defeitos detectados durante a inspeção de código, o número de alterações de requisitos solicitadas, o número de relatórios de defeitos em um sistema entregue e o número médio de linhas de código modificadas em resposta a uma mudança de requisitos.
	Métricas de previsão ou de produto
	Também denominadas de métricas de produto, estão associadas ao produto software e permitem quantificar atributos internos de um sistema de software, tais como o tamanho do sistema, medido em linhas de código, ou o número de métodos associados a cada classe. As métricas de produtos enquadram-se em duas classes:
1. Métricas dinâmicas, cujas medições são realizadas no software em execução durante um teste de sistema ou em operação.
2. Métricas estáticas, cujas medições são feitas a partir de representações do sistema, como o projeto, o programa ou a documentação.
As métricas estáticas ajudam a avaliar a complexidade, a compreensibilidade e a manutenibilidade de um sistema ou de seus componentes. A tabela a seguir exemplifica algumas métricas estáticas de produto software.
	Métrica
	Descrição
	Fan-in / fan-out
	· Fan-in: Número de funções ou métodos que chamam outra função ou método (por exemplo, x).
· Fan-out: Número de funções que são chamadas pela função x.
· Um valor elevado para o fan-in significa que x está fortemente acoplado ao resto do projeto e as mudanças em x terão um amplo efeito dominó.
· Um valor elevado para fan-out sugere que a complexidade geral de x pode ser alta por causa da complexidade da lógica de controle necessária para coordenar os componentes chamados.
	Comprimento do código
	· Medida do tamanho de um programa.
· Geralmente, quanto maior o tamanho do código de um componente, mais complexo e propenso a erros ele tende a ser.
	Complexidade ciclomática
	· Visa a analisar a estrutura do código-fonte.
As métricas dinâmicas ajudam a avaliar a eficiência e a confiabilidade de um sistema.
Exemplo: A confiabilidade é uma característica de qualidade de software a ser avaliada, pois, de forma simplificada, um software é confiável quando não falha (ver imagem abaixo. Fatores de qualidade de software de McCall). Nesse caso, podemos aplicar algumas métricas dinâmicas: Total de falhas relatadas durante o teste, número de falhas corrigidas, tempo médio entre as falhas, porcentagem de falhas corrigidas, entre outras.
As métricas de controle e de previsão podem influenciar a tomada de decisões de gerenciamento, como mostrado na abaixo. Os gerentes usam as medições de processo para decidir se as alterações desse processo devem ser feitas e as métricas de previsão para decidir se as alterações de software são necessárias e se o software está pronto para entrar em produção.
Resumindo
Neste módulo, destacamos a importância das medições e métricas para a qualidade do software.
A medição de software tem como objetivo a quantificação de algum atributo de um sistema de software, como a sua complexidade ou a sua confiabilidade. Comparando os valores medidos uns com os outros e com os padrões que se aplicam a uma organização, deve ser possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia de processos de software, de ferramentas e de métodos. Um processo de medição pode ser parte de um processo de avaliação da qualidade de software, onde cada componente do sistema pode ser analisado separadamente usando uma variedade de métricas.
A Engenharia de Software é uma área de conhecimento quantitativa, portanto, uma métrica de produto ajuda os engenheiros de software a visualizar o projeto e a construção do software por meio de atributos específicos e mensuráveis permitindo aos mesmos criar um software de alta qualidade.
As métricas de controle geralmente estão associadas aos processos de software e as métricas de previsão associadas ao produto software, permitindo quantificar atributos de um sistema de software.
Conclusão
Considerações finais
A qualidade no contexto da Engenharia de Software possui duas dimensões: Processo e produto. A produção de software com qualidade exige a garantia da qualidade em todas as etapas do processo de desenvolvimento do software, bem como do produto software.
Destacamos que um sistema de garantia da qualidade define a estrutura organizacional responsável pela gestão da qualidade, garantindo o atendimento às expectativas do cliente. O processo de garantia de qualidade de software, parte do referido sistema, enfatiza a adoção de padrões que devem ser aplicados ao processo de desenvolvimento de software.
O plano de qualidade de software, elaborado pela equipe de garantia da qualidade, fornece um roteiro para instituir a garantia da qualidade de software, servindo como um gabarito para atividades de garantia da qualidade de software que são instituídas para cada projeto de software.
A medição de software tem como objetivo a quantificação de algum atributo de um sistema de software, como a sua complexidade ou a sua confiabilidade. Comparando os valores medidos uns com os outros e com os padrões que se aplicam a uma organização, deve ser possível tirar conclusões sobre a qualidade do software ou avaliar a eficácia de processos de software, de ferramentas e de métodos. Um processo de medição pode ser parte de um processo de avaliação da qualidade de software.
No contexto da medição de software, as métricas ajudam os engenheiros de software a visualizar o projeto e a construção do software por meio de atributos específicos e mensuráveis, permitindo aos mesmos criar um software de alta qualidade.
AULA 5 – GERENCIAMENTO DE CONFIGURAÇÕES
Descrição
Gerenciamento de configurações no processo de desenvolvimento de software.
Propósito
Compreender o gerenciamento de configurações como parte do processo de desenvolvimento de software, incluindo o controle de alterações, a construção de sistemas e o papel das ferramentas CASE, é importante para a formação do engenheiro de software.
Objetivos
· Módulo 1: Descrever o planejamento de gerenciamento de configurações
· Módulo 2: Descrever o gerenciamento de mudanças, versões e releases
· Módulo 3: Descrever a construção de sistemas
· Módulo 4: Descrever as ferramentas CASE para gerenciamento de configurações
Introdução
Este tema trata do processo de gerenciamento de configurações de software que inclui o gerenciamento de mudanças, de versões e de releases de um sistema de software.
O gerenciamento de mudanças permite que as alterações sejam aplicadas ao sistema de uma maneira controlada, ou seja, garante que a evolução do sistema seja controlada e que as alterações mais urgentes e com bom custo-benefício sejam priorizadas, cabendo ao gerenciamento de versões controlar as diferentes versões de componentes de software e dos sistemas, envolvendo também a garantia de que as alterações feitas por diferentes desenvolvedores não interfiram umas com as outras.
O processo de construção de sistema executável, que ocorre por meio da compilação e da ligação dos componentes do sistema, das bibliotecas externas, dos arquivos de configuração e de outras informações necessárias ao referido processo é fundamental no contexto do gerenciamento de configurações.
Trataremos também das ferramentas CASE (Computer Aided Software Engineering), pois estas permitem que as atividades principais de gerenciamento de configuração resultem em ganhos de produtividade no gerenciamento e controle de itens de configuração gerados ao longo do processo de desenvolvimento de software.
Módulo 1
Descrever o planejamento de gerenciamento de configurações
Conceito de gerenciamento de configurações
Consideremos que uma equipe de engenheiros de software desenvolve uma aplicação para gestão de vendas cujo fluxo de processo é iterativo e incremental, aplicando-se a cada subconjunto de requisitosas tarefas típicas de um processo de desenvolvimento de software, isto é, levantamento de requisitos, análise, projeto, implementação, testes e implantação.
Ao final, após o aval da equipe de qualidade, é disponibilizada aos usuários uma versão em produção. Imediatamente, essa equipe aplica as referidas tarefas em um segundo subconjunto de requisitos, sendo que, durante a implementação da versão 2, soa o alarme do ambiente de produção informando que foi detectada uma falha na versão 1. Temos dois cenários possíveis:
	Cenário 1
	Cenário 2
	Finalizar a versão 2 com as alterações necessárias à eliminação do defeito.
	Aplicar as alterações na versão 1, colocá-la em produção e refletir as alterações na versão 2.
O que você faria? Seria tecnicamente viável um software com defeito em produção até que seja substituído por uma nova versão?
Resposta: Este cenário, sem dúvida, seria um risco. Neste caso, a melhor solução técnica é o cenário 2. Temos basicamente duas tarefas a executar: Primeira, obter a versão 1 e realizar as alterações devidas e, segunda, replicar as alterações realizadas na versão 1 na versão em desenvolvimento.
A solução para o nosso pequeno estudo de caso exige a implantação de um processo de gerenciamento de configurações de software (GCS).
Atenção: Importante, o software está em constante processo de mudança, principalmente pela volatilidade dos requisitos, pela evolução tecnológica ou pelos defeitos detectados, ou seja, surgem necessidades de alterações em função de atualização de plataforma, de novos recursos de hardwares, de adaptações a novos requisitos do negócio, de restrições orçamentárias ou de cronograma que causam a redefinição do sistema ou produto e outros.
O GCS inclui um conjunto de atividades destinadas a gerenciar as alterações identificando os artefatos que precisam ser alterados, estabelecendo relações entre eles, definindo mecanismos para gerenciar diferentes versões desses artefatos, controlando as alterações impostas e auditando e relatando as alterações feitas. O GCS gerencia alterações através de todo o ciclo de vida de um software, podendo ser visto como uma atividade de garantia de qualidade do software aplicada através de todo o processo de desenvolvimento do software.
Comumente, tais atividades cabem à equipe de qualidade, podendo ser designada uma equipe específica para controlar o processo GCS. Cabe destacar que alterações não controladas podem impactar negativamente a qualidade do software, sendo a gestão de alterações parte essencial da gestão da qualidade.
Pressman (2016), identifica quatro importantes elementos que devem compor um sistema de GCS:
	Elementos de componente
	Conjunto de ferramentas acopladas em um sistema de gestão de arquivos que possibilita acesso à gestão de cada item de configuração de software.
	Elementos de processo
	Coleção de ações e tarefas que definem uma abordagem eficaz da gestão de alterações para todas as partes envolvidas na gestão, engenharia e uso do software.
	Elementos de construção
	Conjunto de ferramentas que automatizam a construção do software, assegurando que tenha sido montado o conjunto apropriado de componentes validados.
	Elementos humanos
	Conjunto de ferramentas e características de processo usados pela equipe de software para implementar um GCS eficaz.
Planejamento de gerenciamento de configurações
O plano de gerenciamento de configurações descreve os padrões e procedimentos que devem ser adaptados para atender aos requisitos e às restrições de cada projeto específico. O plano de GCS deve incluir:
A inclusão de outros tópicos no plano GCS é possível, tal como o gerenciamento de software oriundo de fornecedores externos e procedimentos de auditoria dos processos de GCS. A definição de responsabilidades inclui quem é o responsável pela entrega de cada documento ou de componente de software para a garantia da qualidade e para o gerenciamento de configuração, bem como os revisores de cada documento.
Gestão de item de configuração de software (ICS)
Um fato comum no desenvolvimento de software é a alteração, pois clientes querem modificar requisitos, engenheiros de software e gerentes querem modificar seus métodos.
Comentário: Por que tanta necessidade de mudanças? O entendimento do problema evolui durante o processo de desenvolvimento de software, gerando a necessidade de alterações.
Vamos ao entendimento do conceito item de configuração de software (ICS), cuja identificação está prevista no plano de GCS. Um ICS é uma informação criada como parte do processo de engenharia de software, tal como única seção de uma grande especificação ou um caso de teste em um grande conjunto de testes, ou seja:
Caso de teste: Em Engenharia de Software, caso de teste é um conjunto de condições usadas para teste de software.
Exemplo: Um ICS é todo ou parte de um artefato, por exemplo, um documento, um conjunto inteiro de casos de teste ou um programa ou componente com nome.
Um ICS pode incluir ferramentas de software sob o controle de configuração, tais como versões específicas de editores, compiladores, browsers e outras ferramentas automáticas.
Como essas ferramentas foram usadas para produzir documentação, código-fonte e dados, elas devem estar disponíveis quando alterações forem feitas na configuração do software, pois uma nova versão de uma ferramenta (por exemplo, uma IDE) pode produzir resultados diferentes daqueles da versão original.
IDE: Do inglês Integrated Development Environment ou Ambiente de Desenvolvimento Integrado, é um programa de computador que reúne características e ferramentas de apoio ao desenvolvimento de software com o objetivo de agilizar este processo.
Os ICS são organizados como objetos de configuração que podem ser persistidos em um banco de dados, sendo que cada objeto de configuração tem um nome, atributos e pode estar associado a outros objetos. De acordo com a imagem acima, os objetos de configuração EspecificaçãoProjeto, ModeloDados, ComponenteN, CódigoFonte e EspecificaçãoTeste são definidos individualmente, estando relacionados entre si, como mostram as setas. As setas curvas são indicativas de relacionamento de composição, de modo que ModeloDados e ComponenteN são parte do objeto EspecificaçãoProjeto.
Você sabia: Um conceito importante na gestão de configuração de software é a referência, que é uma especificação ou produto que tenha sido formalmente revisado e acordado, que depois serve de base para mais desenvolvimento, e pode ser alterado somente por meio de procedimentos formais de controle de alteração.
Uma vez estabelecido um ICS como uma referência, podem ser feitas alterações, mas deve ser aplicado um processo específico e formal para avaliar e verificar cada alteração. No contexto de Engenharia de Software, uma referência é um marco no desenvolvimento de software. Uma referência é marcada pelo fornecimento de um ou mais ICS que foram aprovados em consequência de uma revisão técnica.
Vamos exemplificar:
Considerando que os elementos de um modelo de projeto foram documentados e que todas as partes do modelo foram revisadas, corrigidas e então aprovadas, o modelo do projeto torna-se uma referência. Outras alterações na arquitetura do programa, documentadas no modelo de projeto, podem ser feitas apenas depois que cada uma tenha sido avaliada e aprovada. Embora as referências possam ser definidas em qualquer nível de detalhe, as referências de software mais comuns estão na imagem abaixo.
A imagem acima, ilustra a sequência de eventos que levam a uma referência, pois a partir de tarefas de engenharia de software são gerados os ICSs, sendo posteriormente revisados, aprovados e registrados em um banco de dados de projeto ou repositório de software.
Quando um engenheiro de software quer fazer uma alteração em um ICS que se tornou referencial, o mesmo é copiado do banco de dados de projeto para o ambiente de desenvolvimento do engenheiro. Porém, esse ICS somente poderá ser modificado se os controles de GCS, tal como o controle de versão, forem seguidos.
ResumindoVimos neste módulo que o gerenciamento de configurações de software (GCS) inclui um conjunto de atividades destinadas a gerenciar alterações, identificando os artefatos que precisam ser alterados, estabelecendo relações entre eles, definindo mecanismos para gerenciar diferentes versões desses artefatos, controlando as alterações impostas e auditando e relatando as alterações feitas.
O plano de gerenciamento de configurações descreve os padrões e procedimentos que devem ser adaptados para atender aos requisitos e às restrições de cada projeto específico, cabendo destaque à identificação dos itens de configuração de software (ICS) e da base de dados onde serão armazenados os ICSs.
Um ICS é uma informação criada como parte do processo de engenharia de software, tal como um caso de teste em um grande conjunto de testes, podendo o mesmo tornar-se um referencial registrado no banco de dados. A partir deste registro, qualquer alteração será aplicada de acordo com controles de GCS.
Módulo 2
Descrever o gerenciamento das mudanças, versões e releases
Processo de gerenciamento de configurações de software
O processo de gerenciamento de configurações de software (GCS), proposto por Pressman (2016), inclui tarefas que têm quatro objetivos primários:
· Identificar todos os itens que coletivamente definem a configuração do software
· Gerenciar alterações de um ou mais desses itens
· Facilitar a construção de diferentes versões de uma aplicação
· Assegurar que a qualidade do software seja mantida à medida que a configuração evolui com o tempo
O referido processo define cinco tarefas de GCS: Identificação, controle de versão, controle de alteração, auditoria de configuração e relatos, tal como a ilustração seguinte.
Atenção: As camadas são concêntricas, de modo que os itens de configuração de software (ICS) transitam da camada mais interna para as camadas externas, tornando-se parte da configuração do software de uma ou mais versões da aplicação ou sistema.
À medida que um ICS se move através de uma camada, as ações deduzidas por cada tarefa GCS podem ser ou não aplicáveis, pois caso não sejam solicitadas alterações para o ICS, a camada de controle de alteração não se aplica. Um ICS possui uma versão específica do software, sendo mantido um registro do ICS, tal como seu nome, data de criação, designação da versão etc, para fins de auditoria da configuração e relato para aqueles que precisam ter conhecimento.
Gerenciamento de mudanças
A camada controle de alterações, definida na Figura 3, é denominada de gerenciamento de mudanças por Sommerville (2019). As mudanças podem ser necessárias a partir de alterações nas necessidades organizacionais e nos requisitos, ou em função de defeitos que necessitam ser corrigidos.
O gerenciamento de mudanças permite que as alterações sejam aplicadas ao sistema de uma maneira controlada, ou seja, garante que a evolução do sistema seja controlada e que as alterações mais urgentes e com bom custo-benefício sejam priorizadas.
A figura abaixo ilustra um processo de gerenciamento de mudanças que deve entrar em vigor quando o software for entregue para lançamento aos clientes ou para implantação dentro de uma organização, cabendo destacar que o formalismo depende da complexidade do software.
Atenção: Importante, também, são as ferramentas utilizadas no gerenciamento de mudanças, tais como um sistema de rastreamento de defeitos ou um software integrado a um pacote de gerenciamento de configuração de sistemas de larga escala, como o Rational Clear Case.
RATIONAL CLEAR CASE: É uma família de ferramentas de software de computador que suporta gerenciamento de configuração de software (GCS) de código-fonte e outros ativos de desenvolvimento de software, sendo desenvolvido pela IBM.
	1
	O referido processo começa quando uma parte interessada, clientes, usuários, testadores, desenvolvedores e outros, envia um formulário de solicitação de mudança (FSM), descrevendo a mudança necessária no sistema, podendo essa solicitação ser um relatório de defeitos, no qual os sintomas dos defeitos são descritos, ou um pedido para acrescentar funcionalidade ao sistema.
	2
	À medida que a solicitação de mudança é processada, informações são adicionadas ao FSM em cada estágio do processo representando uma fotografia do estado da solicitação de mudança, podendo ser registradas as recomendações pertinentes à alteração, os seus custos estimados, as datas em que a mudança foi solicitada, aprovada, implementada e validada, ou uma descrição como a alteração pode ser implementada.
	3
	Em seguida, a solicitação de mudança é conferida para garantir que seja válida, podendo ser rejeitada, mas caso seja válida, será registrada como uma solicitação pendente para a próxima etapa do processo, que é a avaliação da mudança e o cálculo dos custos. Esta função verifica o impacto da alteração, sendo preciso identificar todos os componentes afetados pela mudança, e, na sequência, estima-se o custo de proceder com essas mudanças.
	4
	Um grupo, designado de comitê de controle de mudança (CCM) ou grupo de desenvolvimento do produto, analisa e aprova todas as solicitações de mudança, a menos que as alterações envolvam simples correções de erros menores em telas, páginas da web ou documentos. Estes pequenos pedidos devem ser passados para implementação imediata pelo time de desenvolvimento.
	5
	O CCM, ou o grupo de desenvolvimento do produto, decide se a mudança em questão é economicamente justificável e prioriza as mudanças aceitas para serem implementadas, sendo as mudanças aceitas devolvidas ao grupo de desenvolvimento.
Você sabia: Os fatores que influenciam a decisão sobre a implementação ou não de uma mudança incluem as consequências de não fazer a mudança em caso de uma falha de software muito grave que compromete o uso operacional do sistema; usuários beneficiados pela mudança; os custos envolvidos na mudança; caso uma nova versão do software tenha sido disponibilizada recentemente aos clientes, pode fazer sentido postergar a mudança para a próxima mudança.
Nos produtos de software, tal como o CAD, as solicitações de mudança vêm da equipe de suporte ao cliente, da equipe de marketing da empresa ou dos próprios desenvolvedores, sendo que esses pedidos podem refletir sugestões e feedbacks de clientes ou análises do que é oferecido pelos produtos concorrentes. Neste caso, o processo de solicitação de mudança, mostrado na imagem acima, é iniciado depois da liberação do sistema aos clientes.
CAD: Desenho assistido por computador (DAC; em inglês: computer aided design - CAD) é o nome genérico de sistemas computacionais (software) utilizados pela Engenharia, Geologia, Geografia, Arquitetura e Design para facilitar o projeto e desenho técnicos.
Durante o desenvolvimento, quando novas versões do sistema são criadas por meio de construções sistemáticas, não há necessidade de um processo formal de gerenciamento de mudanças, pois as mudanças que afetam os componentes individuais são passadas diretamente para o desenvolvedor do sistema, que pode aceitá-las ou indicar por que não são necessárias. No entanto, uma autoridade independente, como um arquiteto do sistema, deve avaliar e priorizar as mudanças que afetam os módulos do sistema produzidos por diferentes times de desenvolvimento.
Em alguns métodos ágeis, os clientes propõem mudanças nos requisitos do sistema e trabalham com a equipe de desenvolvimento na avaliação dos impactos das mudanças e nas decisões relativas à implementação das mesmas.
Gerenciamento de versões
O gerenciamento de versões tem como objetivo controlar as diferentes versões de componentes de software e dos sistemas, envolvendo também a garantia de que as alterações feitas por diferentes desenvolvedores não interfiram umas com as outras. De acordo com Sommerville (2019), o gerenciamento de versões é o processo de gerenciamento de codelines e baselines.
CODELINES: Uma codeline é uma sequência de versões do código-fonte, sendo aplicadas a componentes de sistemas para que haja versões diferentesde cada componente.
BASELINES: Uma baseline é uma definição de um determinado sistema, especificando as versões dos componentes incluídas no sistema e a identificação das bibliotecas utilizadas, dos arquivos de configuração e de outras informações do sistema.
A imagem abaixo ilustra que diferentes baselines usam versões diferentes dos componentes de cada codeline, onde podemos destacar a mainline que incorpora uma sequência de baselines representando diferentes versões do sistema.
As baselines são importantes porque, muitas vezes, é preciso recriar uma versão individual de um sistema, tal como a instanciação de um software em versões específicas para cada cliente, ou mesmo recriar a versão entregue a um cliente, caso relate defeitos em seu sistema que necessitem ser alterados.
Existem dois tipos de sistemas de controle de versão modernos:
1. Sistemas centralizados compostos por um único repositório mestre que mantém todas as versões dos componentes de software.
2. Sistemas distribuídos compostos por várias versões do repositório de componentes ao mesmo tempo.
Ambos os sistemas possuem funcionalidades semelhantes, mas as implementam de maneiras diferentes. As principais características destes sistemas são:
	Identificação de versão e lançamento
	As versões gerenciadas de um componente recebem identificadores únicos quando são submetidas a um sistema, permitindo que diferentes versões do mesmo componente sejam gerenciadas, sem alterar o nome dele.
	Registro do histórico de mudanças
	Manutenção dos registros das mudanças feitas para criar uma versão nova de um componente, com base em uma versão anterior.
	Desenvolvimento independente
	Permite que diferentes desenvolvedores possam estar trabalhando simultaneamente no mesmo componente, controlando os componentes em que se fez check-out para edição, e assegura que as mudanças feitas em um componente por desenvolvedores diferentes não interfiram umas nas outras.
	Apoio de projeto
	Apoia o desenvolvimento de vários projetos que compartilham componentes.
	Gerenciamento de armazenamento
	Pode utilizar mecanismos eficientes que garantam que não sejam mantidas cópias duplicadas de arquivos idênticos, tal como casos em que há apenas pequenas diferenças entre os arquivos. O sistema de controle de versão pode armazenar estas diferenças em vez de manter várias cópias dos arquivos.
A maior parte do desenvolvimento de software é uma atividade para ser realizada por um time, então, frequentemente, diversos membros trabalham no mesmo componente de modo simultâneo. Vamos exemplificar um cenário baseado na figura seguinte, a fim de que possamos entender como funcionam os sistemas com repositório centralizado, tal como o SVN (Subversion).
Um engenheiro de software utiliza uma área de trabalho “ALFA”, um segundo engenheiro, a área de trabalho “BETA”, ambos requerem mudanças em componentes comuns. Para apoiar o desenvolvimento independente sem interferências, todos os sistemas de controle de versão usam o conceito de um repositório de projeto, mantendo uma versão 'mestre' de todos os componentes, que é utilizada para criar as baselines para a construção do sistema.
Ao modificar componentes, os desenvolvedores copiam estes componentes do repositório para sua área de trabalho, ou seja, realizam a operação de check-out, e executam implementações nestas cópias. Após implementadas as alterações, realizam a operação de check-in, ou seja, os componentes modificados são devolvidos para o repositório, criando uma versão nova do componente, que pode ser compartilhada.
Em um sistema de controle de versão distribuído, tal como o Git, existe um repositório 'mestre' no servidor que mantém o código produzido pelo time de desenvolvimento. Em vez de simplesmente fazer o check-out dos arquivos de que precisa, um desenvolvedor cria um clone do repositório do projeto, que é baixado e instalado em seu computador.
Os desenvolvedores trabalham nos arquivos necessários e mantêm as novas versões em seu repositório particular, em seu próprio computador. Quando terminam de fazer as alterações, realizam um commit nas mesmas, atualizando seu repositório. A disponibilização dessas alterações para o repositório do projeto ocorre por meio de uma operação push, cabendo ao gerente de configuração ‘puxar' (pull) esses arquivos para o repositório do projeto, ou seja, um repositório pode se comunicar com qualquer outro através das operações básicas pull e push.
Git: Git é um sistema de controle de versões distribuído, usado principalmente no desenvolvimento de software, mas pode ser usado para registrar o histórico de edições de qualquer tipo de arquivo (Exemplo: alguns livros digitais são disponibilizados no GitHub e escrito aos poucos publicamente). O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos. (Wikipedia).
Commit: Agrupamento de um conjunto de alterações candidatas a serem atualizadas.
Pull: Atualiza o repositório local com todas as alterações feitas em outro repositório.
Push: Envia as alterações do repositório local para outro repositório.
Gerenciamento de releases
Uma release, ou lançamento de sistema, é uma versão do software distribuída para os clientes, podendo esses lançamentos serem categorizados, para software de mercado, em lançamentos principais (major releases), por oferecerem uma nova funcionalidade significativa, e lançamentos secundários (minor releases), que consertam defeitos e solucionam problemas relatados por clientes, tal como IDE 4.2.
Comentário: Isto significa um lançamento secundário 2 do lançamento principal 4 da IDE, sendo esses lançamentos secundários comumente gratuitos. Entretanto, provavelmente o cliente terá que pagar pela versão 5.0.
Um lançamento de produto de software não é apenas o código executável do sistema, podendo incluir:
A complexidade do processo de gerenciamento de lançamentos do sistema depende do número de clientes, pois pode ser preciso criar lançamentos do sistema para cada cliente, em função, por exemplo, de diferentes hardwares. Neste caso, os sistemas e processos de gerenciamento de configurações têm de ser projetados para fornecer informações sobre quais clientes têm quais versões do sistema e a relação entre os lançamentos e as versões do sistema. No caso de um problema com um sistema entregue, o GCS deve ser capaz de recuperar todas as versões dos componentes utilizadas nesse sistema específico.
Resumindo
Vimos neste módulo que um processo de gestão de configuração de software (GCS) define cinco tarefas: Identificação dos itens de configuração de software (ICS), controle de versão, controle de alteração, auditoria de configuração e relatos.
O gerenciamento de mudanças permite que as alterações sejam aplicadas ao sistema de uma maneira controlada, ou seja, garante que a evolução do sistema seja controlada e que as alterações mais urgentes e com bom custo-benefício sejam priorizadas.
O gerenciamento de versões tem como objetivo controlar as diferentes versões de componentes de software e dos sistemas, envolvendo também a garantia de que as alterações feitas por diferentes desenvolvedores não interfiram umas com as outras.
O gerenciamento de releases, cuja complexidade depende do número de clientes, requer que os processos de gerenciamento de configuração sejam projetados para fornecer informações sobre quais clientes têm quais versões do sistema e a relação entre os lançamentos e as versões do sistema.
Módulo 3
Descrever a construção de sistemas
Construção de sistemas
O processo de criar um sistema executável, também conhecido como build, compilando e ligando os componentes do sistema, as bibliotecas externas, os arquivos de configuração e outras informações, é denominado de construção de sistema.
Dica: As ferramentas de construção de sistema e de controle de versões devem ser integradas, pois o processo de construção usa versões dos componentes do repositório gerenciado pelo sistema de controle de versões. Considerandoque a construção de um sistema envolve diferentes informações sobre o software e seu ambiente operacional, sugere-se o uso de uma ferramenta de construção automatizada para criar um build do sistema.
Podemos observar na abaixo que o referido build poderá incluir, além dos arquivos de código-fonte envolvidos na construção do sistema, as bibliotecas vinculadas externamente, os arquivos de dados, os arquivos de configuração, ou mesmo as especificações das versões do compilador e ferramentas de software utilizadas na construção. Idealmente, deve ser possível construir um sistema completo com um único comando ou clique do mouse.
Vejamos algumas funcionalidades usualmente disponíveis em ferramentas para integração e construção de sistemas:
	Geração do script de construção
	Permite a análise do programa em construção, identificando componentes dependentes e gerando automaticamente um script de construção ou arquivo de configuração.
	Integração com o sistema de controle de versão
	Realiza o check-out das versões necessárias dos componentes que estão no sistema de controle de versão, de forma a garantir a integridade do build.
	Recompilação mínima
	Analisa qual código-fonte precisa ser recompilado e realizar as compilações essenciais.
	Criação do sistema executável
	Vincula os arquivos objetos compilados uns aos outros e a outros arquivos necessários, como bibliotecas e arquivos de configuração, para criar um sistema executável.
	Automação dos testes
	Executa automaticamente testes usando ferramentas de automação de teste, a fim de verificar a correta integração dos componentes do build em função das possíveis mudanças.
	Emissão de relatórios
	Fornece relatórios sobre o sucesso ou a falha da construção, bem como dos testes executados.
	Geração da documentação
	Gera notas de lançamento sobre o build e páginas de ajuda do sistema.
O script de construção é uma definição do sistema a ser construído, incluindo informações sobre os componentes e suas dependências e versões das ferramentas usadas para compilar e ligar o sistema, sendo, então, necessário à linguagem de configuração adotada descrever os componentes do sistema a serem incluídos na construção e suas dependências.
Podemos observar abaixo as plataformas de sistema envolvidas, o que confere um grau de complexidade no processo de construção.
Vejamos as plataformas:
	Sistema de desenvolvimento
	· Inclui ferramentas de desenvolvimento, como compiladores e editores de código-fonte.
· Os desenvolvedores fazem check-out do código do sistema de controle de versão, ou seja, transferem do repositório para uma área de trabalho particular antes de fazer alterações no sistema, sendo possível a criação de uma versão do sistema para teste em seu ambiente de desenvolvimento antes de efetivar as alterações feitas no sistema de controle de versão.
· Ao final das alterações e/ou testes é realizado o check-in, ou seja, os componentes modificados são devolvidos ao repositório.
· O processo que envolve o check-in e check-out requer o uso de ferramentas de construção locais que usam versões de componentes na área de trabalho particular.
	Servidor de construção
	· Utilizado na construção de versões definitivas e executáveis do sistema, mantendo as versões definitivas de um sistema.
· Todos os desenvolvedores de sistema fazem check-in de código para o sistema de controle de versão no servidor de construção para construir o sistema.
· O servidor de construção realiza o check-out de todos os componentes que irão compor a versão do sistema.
	Ambiente de destino
	· Esse ambiente inclui a plataforma na qual o sistema é executado, podendo ser o hardware de destino semelhante ao do ambiente de desenvolvimento, ou, tal como em sistemas em tempo real e embarcados, o ambiente de destino pode ser mais simples.
· Em determinados sistemas, o ambiente de destino inclui bancos de dados e outros sistemas de aplicações que não podem ser instalados em máquinas de desenvolvimento.
Integração contínua
Os métodos ágeis recomendam que a construção do sistema seja realizada com bastante frequência, com testes automatizados utilizados para descobrir problemas de software. As construções frequentes fazem parte de um processo de integração contínua, como mostrado abaixo.
Atenção: As metodologias ágeis adotam, entre outras melhores práticas, a possibilidade de atendimento rápido às mudanças e a integração de forma sistemática, o que requer a reconstrução frequente da mainline que representa uma sequência de baselines representando diferentes versões do sistema. As etapas da integração contínua ilustradas acima são:
	1
	Extrair o sistema mainline do sistema de gerenciamento de versões para a área de trabalho particular do desenvolvedor.
	2
	Construir o sistema e executar testes automatizados para garantir que o sistema construído passe em todos os testes; no caso de falha, a construção é considerada “quebrada”, sendo necessário informar quem fez o check-in no último sistema baseline, pois essa pessoa será responsável por reparar o problema.
	3
	Fazer as mudanças nos componentes do sistema.
	4
	Construir o sistema em uma área de trabalho particular e executar novamente os testes de sistema; caso ocorram falhas, a edição deve prosseguir.
	5
	Uma vez que o sistema tenha passado nos testes, é preciso devolvê-lo para o servidor do sistema de construção, mas não efetivá-lo como um novo sistema baseline no sistema de gerenciamento de versões.
	6
	Construir o sistema no servidor de construção e rodar os testes; caso ainda ocorra alguma falha, é preciso fazer o check-out dos componentes que falharam e editá-los em uma área de trabalho particular para que passem no teste.
	7
	Após a aprovação nos testes no sistema de construção, então devem-se confirmar as alterações feitas como um novo baseline no mainline do sistema.
A vantagem da integração contínua é que ela permite a descoberta e a alteração imediata dos problemas causados pelas interações entre diferentes desenvolvedores, sendo o sistema mais recente no mainline o sistema funcional definitivo. Entretanto, podem ocorrer restrições na aplicação da integração contínua, vejamos:
Se o sistema for muito grande, pode levar muito tempo para construí-lo e testá-lo, especialmente se a integração com outros sistemas de aplicações estiver envolvida, podendo ser inviável a construção do sistema várias vezes ao dia.
Caso a plataforma de desenvolvimento seja diferente da plataforma de destino, pode não ser possível executar os testes do sistema na área de trabalho particular do desenvolvedor, em função de possíveis diferenças no hardware, no sistema operacional ou no software instalado, gerando a necessidade de um tempo maior para os testes.
Nos sistemas grandes ou naqueles cuja plataforma de execução não é a mesma da plataforma de desenvolvimento, a integração contínua costuma ser impossível.
Vejamos uma alternativa considerando um sistema de construção diária:
1. A equipe de desenvolvimento estabelece um horário de entrega, tal como 14h, dos componentes de sistema, cabendo aos desenvolvedores que tiverem novas versões dos componentes realizar e entrega no prazo estipulado.
2. A construção do sistema ocorre por meio da compilação e ligação dos componentes, sendo gerado um sistema completo.
3. O novo sistema gerado passa por um conjunto de testes pela equipe de testes.
4. Os defeitos que foram descobertos durante o teste do sistema são documentados e devolvidos para os desenvolvedores do sistema que realizam a manutenção devida.
A vantagem de usar construções frequentes do software é a maior chance de encontrar falhas nas interações de componentes de forma precoce. Desta forma, a construção frequente incentiva testes unitários completos dos componentes com o objetivo de evitar que o check-in de uma determinada versão gere uma falha no sistema inteiro.
Ligação do código-fonte ao código objeto
Como a compilação é um processo computacionalmente intensivo realizado por um determinado compilador, ferramentas de apoio à construção dosistema podem ser projetadas para minimizar a quantidade de compilação necessária, verificando se está disponível uma versão compilada de um componente, pois, em caso positivo, não há necessidade de recompilar esse componente.
Compilador: É um programa de computador que, a partir de um código-fonte escrito em uma linguagem compilada, cria um programa semanticamente equivalente, porém escrito em outra linguagem, código objeto. Classicamente, um compilador traduz um programa de uma linguagem textual facilmente entendida por um ser humano para uma linguagem de máquina, específica para um processador e sistema operacional.
Entendamos como ocorre a ligação do código-fonte de um componente ao seu código objeto equivalente.
Esta ligação é realizada por meio da designação de uma assinatura exclusiva a cada arquivo de componente de código-fonte armazenado, tendo o código objeto correspondente, que foi compilado a partir do código-fonte, uma assinatura relacionada; caso o código-fonte seja editado, esta assinatura é alterada.
Pela comparação das assinaturas nos arquivos de código-fonte e de código objeto, é possível decidir se o componente de código-fonte foi usado para gerar o componente de código objeto.
Vejamos os dois tipos de assinaturas apresentados por Sommerville (2019), conforme exibido acima.
Timestamps de modificação
A assinatura no arquivo de código-fonte é a data e a hora (timestamps) em que esse arquivo foi modificado. Sempre que ocorrer a modificação do arquivo de código-fonte de um componente, o sistema realiza a recompilação para criar um novo arquivo de código objeto correspondente.
Observemos a figura acim, na qual os componentes Comp.java e Comp.class têm assinaturas de modificação de 17:03:05:15:02:2018 e 16:58:43:15:02:2018, respectivamente. Isto significa que o código Java foi modificado às 17 horas, 3 minutos e 5 segundos do dia 15 de fevereiro de 2018 e a versão compilada foi modificada às 16 horas, 58 minutos e 43 segundos do dia 15 de fevereiro de 2018. Neste caso, o sistema recompilaria automaticamente Comp.java, porque a versão compilada tem uma data de modificação anterior à versão mais recente do componente.
Somas de verificação (checksum) de código-fonte
A assinatura no arquivo de código-fonte é uma soma de verificação (checksum) calculada a partir dos dados no arquivo, gerando um número exclusivo a partir do texto de origem como entrada, de forma que qualquer alteração no texto, até mesmo um único caractere, gera uma soma de verificação diferente, sendo essa soma de verificação atribuída ao código-fonte somente antes da compilação e identifica exclusivamente o arquivo de origem.
O sistema de construção, em seguida, marca o arquivo de código objeto gerado com a assinatura da soma de verificação, portanto, se não houver nenhum arquivo de código objeto com a mesma assinatura que o arquivo de código-fonte a ser incluído em um sistema, a recompilação do código-fonte é necessária.
Como os arquivos de código objeto normalmente não são versionados, a abordagem timestamps significa que apenas o arquivo de código objeto compilado mais recentemente é mantido no sistema. A abordagem de soma de verificação tem a vantagem de permitir que sejam mantidas simultaneamente muitas versões diferentes do código objeto de um componente. A assinatura em vez do nome do arquivo é o vínculo entre código-fonte e objeto, pois o código-fonte e os arquivos de código objeto têm a mesma assinatura.
Resumindo
Neste módulo, pudemos compreender o processo de construção de um sistema executável por meio da compilação e da ligação dos componentes do sistema, das bibliotecas externas, dos arquivos de configuração e de outras informações necessárias ao referido processo.
As ferramentas de construção de sistema e de controle de versões devem ser integradas, pois o processo de construção usa versões dos componentes do repositório gerenciado pelo sistema de controle de versões.
Entendemos que a integração contínua permite a descoberta e a alteração imediata dos problemas causados pelas interações entre diferentes desenvolvedores, sendo o sistema mais recente no mainline o sistema funcional definitivo.
A compilação é um processo computacionalmente intensivo exigindo o gerenciamento da ligação do código-fonte de um componente ao seu código objeto equivalente, sendo esta ligação realizada por meio da designação de uma assinatura exclusiva a cada arquivo de componente de código-fonte armazenado, tendo o código objeto correspondente, que foi compilado a partir do código-fonte, uma assinatura relacionada.
Módulo 4
Descrever as ferramentas CASE para gerenciamento de configurações
Ambientes de gerenciamento de configurações
Usualmente, os processos de gerenciamento de configurações são padronizados, ou seja, incluem aplicações de procedimentos predefinidos que requerem o gerenciamento de grande quantidade de dados.
Imaginemos um sistema que esteja sendo construído com base em versões de componentes e um determinado engenheiro de software realiza a publicação de uma versão com uma conexão de banco de dados X, sendo que ocorreu uma alteração de requisito não funcional para o banco de dados Y, ou seja, a versão do componente da camada de persistência não estava corretamente gerenciada.
Atenção: Com base nesse pequeno incidente, podemos concluir que o apoio de uma ferramenta CASE é essencial para o gerenciamento de configuração, podendo a mesma ser combinada para criar uma área de trabalho para apoiar todas as atividades de gerenciamento de configuração.
CASE: Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de Engenharia de Software, desde análise de requisitos e modelagem até programação e testes.
Entendamos dois tipos de ambientes:
	Ambientes abertos
	Incluem ferramentas de código aberto para cada estágio do processo que são integradas por meio de procedimentos organizacionais padronizados para uso dessas ferramentas, ou seja, o gerenciamento de mudança, o gerenciamento de versões e a construção de sistemas possuem ferramentas específicas que devem ser integradas.
	Ambientes integrados
	Fornecem recursos integrados para controlar versões, a construção de sistemas e o rastreamento de mudanças.
Destacamos que sistemas complexos com equipes de desenvolvimento geograficamente distantes necessitam de ferramentas de gerenciamento de configuração que apoiem o trabalho em diferentes localidades com múltiplos repositórios de dados para itens de configuração.
Apoio para gerenciamento de mudanças
Uma melhor prática sugere que um modelo de processo de mudanças deva ser projetado e integrado com um sistema de gerenciamento de versões, de modo que os documentos gerados nas atividades relacionadas com as mudanças sejam enviados para pessoas certas no tempo certo. As ferramentas de gerenciamento de mudanças geralmente fornecem os seguintes recursos para dar suporte ao processo:
	Editor de formulários
	Permite às pessoas criar ou completar formulários com propostas de mudanças.
	Sistema de workflow
	Permite à equipe de gerenciamento de configuração definir quem deve processar o formulário de solicitação de mudança e a ordem de processamento, sendo os formulários encaminhados automaticamente para as pessoas corretas no tempo certo, informando aos membros relevantes da equipe sobre o progresso da mudança.
	Banco de dados de mudança
	Usado para gerenciar todas as propostas de mudança e que pode estar ligado a um sistema de gerenciamento de versões, no qual recursos de consulta permitem à equipe de gerenciamento de configuração encontrar uma proposta específica de mudança.
	Sistema de relato de mudanças
	Gera relatórios gerenciais sobre o status das solicitações de mudança enviadas.
Apoio para gerenciamento de versões
As ferramentas de gerenciamento de versões controlam um repositório de itens de configuração no qual os conteúdos dos repositórios não podem ser alterados.
Comentário: Para trabalharnum item de configuração, o engenheiro de software deve retirá-lo por meio de uma operação check-out do repositório e guardá-lo num diretório de trabalho, sendo devolvido ao repositório, após a realização das mudanças no componente, por meio de uma operação check-in, sendo uma nova versão automaticamente criada.
Os sistemas de gerenciamento de versões fornecem um conjunto básico de capacidades semelhantes, embora alguns recursos sejam mais sofisticados que outros. Vejamos:
	Identificação de versões e releases
	Versões gerenciadas recebem identificadores quando são enviadas ao sistema.
	Gerenciamento de armazenamento
	Um sistema de gerenciamento de versões fornece recursos de gerenciamento de armazenamento de maneira que as versões sejam descritas pela sua diferença em relação a uma versão mestre, sendo as diferenças entre versões representadas por um delta, que engloba as instruções necessárias para recriar a versão do sistema associado, tal como exemplifica a Figura 11, pois considerando que a última versão é a versão 1.3, a criação da versão 1.2 exige a aplicação do delta de mudança correspondente D3.
	Registro do histórico de mudanças
	Inclui o registro de todas as mudanças executadas no código de um sistema ou componente. Desenvolvimento independente ‒ Múltiplas versões de um sistema podem ser desenvolvidas em paralelo, podendo cada versão ser modificada de forma independente, tal como um release 1 pode ser modificado depois de iniciado o desenvolvimento do release 2, pois o sistema de gerenciamento de versões mantém a rastreabilidade dos componentes retirados por meio do check-out para a edição.
	Suporte a projetos
	Inclui o suporte a múltiplos projetos.
Suporte para construção de sistemas
A construção de sistemas é um processo computacional intensivo, podendo incluir centenas de arquivos.
Atenção: As ferramentas de construção de sistemas automatizam o processo de construção para reduzir a possibilidade de ocorrência de erro humano e, quando possível, minimizar o tempo necessário para a construção de sistemas.
Vejamos alguns recursos que podem estar presentes em ferramentas CASE de construção de sistemas:
Vamos entender esta dependência entre objetos derivados a partir da figura seguinte, bem como a minimização da recompilação.
Considere uma situação em que um programa de compilador chamado comp é criado por quatro módulos objetos chamados scan.o, syn.o, sem.o e cgen.o, sendo cada módulo objeto criado dos respectivos códigos-fontes, ou seja, scan.c, syn.c, sem.c e cgen.c. Um arquivo de declarações de variáveis e de constantes chamado defs.h é compartilhado por scan.c, syn.c e sem.c . Na Figura abaixo, as setas significam 'depende de', ou seja, a entidade na base da seta depende da entidade que está no topo, de modo que comp depende de scan.o, syn.o, sem.o e cgen.o; scan.o depende de scan.c, e assim, sucessivamente.
O que você acha que ocorreria se scan.c fosse alterado?
Inicialmente, a ferramenta de construção de sistemas detecta que o objeto derivado scan.o deva ser recriado pela comparação dos momentos da modificação do scan.o e do scan.c, pois scan.c foi modificado depois de scan.o. Em seguida, a referida ferramenta chama o compilador C para compilar o scan.c a fim de criar um novo objeto derivado, ou seja, o scan.o. A ferramenta de construção então usa a ligação de dependência entre comp e scan.o para detectar que comp deve ser recriado pela ligação de scan.o, syn.o, sem.o e cgen.o.
Comentário: A partir deste pequeno exemplo, podemos imaginar a complexidade de gerenciamento de diversos arquivos e respectivas dependências, ou seja, a automação do gerenciamento de versões é fortemente recomendada.
Muitas ferramentas de construção de sistemas usam a data de modificação de arquivo como um atributo-chave para decidir se a recompilação é necessária, de modo que, se um arquivo de código-fonte é modificado depois do seu correspondente arquivo de código objeto, o arquivo de código objeto é recriado.
Algumas ferramentas mantêm o registro da última versão do código objeto que corresponde ao mais recente componente de código-fonte modificado, outras ferramentas, entretanto, usam abordagens mais sofisticadas para o gerenciamento de objetos derivados, colocando uma marca nos objetos derivados com a identificação dos códigos-fontes usados para gerar os objetos, o que permite manter todos os objetos derivados.
Ferramentas CASE para gerenciamento de configuração
As ferramentas CASE permitem que as atividades fundamentais de gerenciamento de configuração resultem em ganhos de produtividade no gerenciamento e controle de itens de configuração gerados ao longo do processo de desenvolvimento de software. De acordo com Andrade (2014), as ferramentas CASE podem ser divididas em três grupos principais ilustrados na imagem abaixo:
	Ferramentas de suporte individual
	Tratam o controle de versões, o controle de mudança e a integração contínua de itens.
	Ferramentas de suporte ao projeto
	Suportam o projeto e apoiam a integração das atividades da gerência de configuração.
	Ferramentas de suporte completo à organização
	Apoiam o processo da empresa e a gerência de configuração atrelada ao processo.
Vejamos as ferramentas de suporte individual:
· Controle de versões permite a identificação, armazenamento e gerenciamento dos itens de configuração.
· Controle de mudança tem como foco os procedimentos pelos quais as mudanças de um ou mais itens de configuração são propostas, avaliadas, aprovadas e implantadas.
· Integração contínua permite a identificação, empacotamento e preparação de uma baseline, garantindo que as mudanças sejam construídas, testadas e relatadas.
A tabela a seguir apresenta algumas ferramentas, divididas pelos grupos:
	Tipo de ferramenta
	Ferramentas open source
	Ferramentas comerciais
	Controle de versão
	CVS
Subversion
Aegis
Arch
JEDI
	PVC
ClearCase
StarTeam
Perforce
BitKeeper
Synergy
Serena
Microsoft Visual Source Safe
	Controle de mudança
	Bugzilla
Trac
Mantis
Scarab
	PVCS
Jira
FogBugz
CaliberRM
ClearQuest
Perforce
Synergy
Serena
	Integração contínua
	Ant
SCons
Bitten
Maven
CruiseControl
Gump
TinderBox
	Build Forge
Anthill Pro
FinalBuilder
Resumindo
Neste módulo, destacamos a importância dos processos de gerenciamento de configurações, que incluem aplicações de procedimentos predefinidos que requerem o gerenciamento de grande quantidade de dados.
Um modelo de processo de mudanças deve ser projetado e integrado com um sistema de gerenciamento de versões, de modo que os documentos gerados nas atividades relacionadas com as mudanças sejam enviados para pessoas certas no tempo certo.
As ferramentas de gerenciamento de versões controlam um repositório de itens de configuração no qual os conteúdos dos repositórios não podem ser alterados, de modo que um item de configuração é retirado do repositório por meio de uma operação check-out, sendo devolvido ao repositório, após a realização das mudanças no referido item, por meio de uma operação check-in, sendo uma nova versão automaticamente criada.
As ferramentas de construção de sistemas automatizam o processo de construção para reduzir a possibilidade de ocorrência de erro humano e, quando possível, minimizar o tempo necessário para a construção de sistemas.
As ferramentas CASE permitem que as atividades fundamentais de gerenciamento de configurações resultem em ganhos de produtividade no gerenciamento e controle de itens de configuração gerados ao longo do processo de desenvolvimento de software.
Conclusão
Considerações finais
Apresentamos neste tema o processo de gerenciamento de configurações de software, que inclui um conjunto de atividades destinadas a gerenciar alterações, identificando os artefatos que precisam ser alterados, estabelecendo relações entre eles, definindo mecanismos para gerenciar diferentes versões destes artefatos, controlando as alterações impostas e auditando e relatando as alterações feitas.
Ressaltamos que o gerenciamento de mudanças permite que as alterações sejam aplicadas ao sistemade uma maneira controlada, ou seja, garante que a evolução do sistema seja controlada e que as alterações mais urgentes e com bom custo-benefício sejam priorizadas, cabendo ao gerenciamento de versões controlar as diferentes versões de componentes de software e dos sistemas, envolvendo também a garantia de que as alterações feitas por diferentes desenvolvedores não interfiram umas com as outras.
O processo de construção de sistema executável ocorre por meio da compilação e da ligação dos componentes do sistema, das bibliotecas externas, dos arquivos de configuração e de outras informações necessárias ao referido processo.
Demos destaque às ferramentas CASE no contexto do gerenciamento de configurações, pois elas permitem que as atividades fundamentais desse gerenciamento resultem em ganhos de produtividade no gerenciamento e controle de itens de configuração gerados ao longo do processo de desenvolvimento de software.