Você está na página 1de 72

Direitos: Esta obra foi disponibilizada sob uma Licença Creative Commons Atribuição Uso não-comercial 3.0 Brasil. Direitos de distribuição e publicação: CAPES/MEC, conforme Parágrafo Único, do Artigo 5º, da Resolução CD/FNDE nº 24 de 04 de Junho de 2008.

5º, da Resolução CD/FNDE nº 24 de 04 de Junho de 2008. Universidade Federal de Juiz

Universidade Federal de Juiz de Fora Reitor: Henrique Duque de Miranda Chaves Filho

Instituto de Ciências Exatas Diretor: Rubens de Oliveira

Departamento de Ciência da Computação Chefe: Custódio Gouvea Lopes da Motta

Curso de Licenciatura em Computação Coordenação: Fernanda Claudia Alves Campos

Organização José Maria Nazar David

Comissão Editorial Eduardo Barrére Fernanda Claudia Alves Campos

Revisão Gramatical Hortência Cezar Pinto

Editoração Eletrônica Eduardo Barrére

José Maria Nazar David.

Fundamentos de Engenharia de Sofware / José Maria Nazar David – 2013.

72 f. : il.

Material Didático — Curso de Licenciatura em Computação da Universidade Federal de Juiz de Fora, Juiz de Fora, 2012.

1. Educação à Distância. 2. Engenharia de Software. 3. Teste de Software. 4. Qualidade de Software. I. Título.

Apresentação

Este material foi desenvolvido para apoiar a disciplina de Fundamentos de Engenharia de Software (carga horária: 30 horas) do curso de Licenciatura em Computação da Universidade

Federal de Juiz de Fora. Para a condução desta disciplina parte-

se do pressuposto de que o aluno já cursou a disciplina de

Modelagem de Sistemas, pois alguns conceitos abordados necessitam do entendimento da importância da atividade de

modelagem no processo de desenvolvimento de software.

O objetivo desta disciplina é fornecer uma visão geral do

processo de desenvolvimento de software, bem como discutir a importância das organizações adotarem a abordagem mais adequada ao seu contexto. Não se busca com isso, esgotar a discussão sobre as diferentes etapas do processo de desenvolvimento e os artefatos gerados nas atividades. Em cada capítulo, as atividades realizadas para o desenvolvimento dos artefatos são discutidas, bem como exemplos práticos são oferecidos para ilustrar a criação e a sua importância para o software.

Sobre o autor:

José Maria N. David, professor da disciplina de Engenharia de Software com mais de vinte anos de experiência na área de desenvolvimento de software, inicialmente como Analista de Sistemas e, posteriormente como professor. Recentemente tem

se dedicado à pesquisa dos diferentes aspectos envolvidos no

Desenvolvimento Distribuído de Software. É mestre e doutor em Engenharia de Sistemas e Computação pela Universidade

Federal do Rio de Janeiro (COPPE/UFRJ) e professor do Departamento de Ciência da Computação da Universidade Federal de Juiz de Fora (UFJF).

Iconografia

Conheça os diversos ícones utilizados nos materiais didáticos desenvolvidos pelos professores e tutores do curso de Licenciatura em Computação – DCC/UFJF:

Pesquise.
Pesquise.
Exercícios.
Exercícios.
Material complementar (texto, vídeo, etc.) disponível na Internet.
Material complementar
(texto, vídeo, etc.)
disponível na Internet.
Comentário do Autor.
Comentário do Autor.
Conclusão ou síntese de conteúdo.
Conclusão ou síntese
de conteúdo.
Leitura Complementar.
Leitura Complementar.
Tome nota.
Tome nota.
Fique atento.
Fique atento.

1.

Introdução

2. Processos de Software

2.1 Introdução

2.2 Modelo em Cascata

Sumário

2.3 O Processo Unificado (RUP)

2.4 O Modelo

Evolucionário

3. Engenharia de Requisitos de Software

3.1 Introdução

3.2 O Processo de Engenharia de Requisitos

3.3 Gerenciamento de requisitos

4. Projeto de Sistemas

4.1 Introdução

4.2 Alguns conceitos de projeto de software

5. Implementação

5.1 Introdução

5.2 Reutilização de software

5.3 Gerenciamento de Configuração

6. Teste de Software

6.1 Introdução

6.2 e Validação

Verificação

6.3 Testes Unitários

6.4 Testes de Sistema

7. Manutenção e Evolução de Software

7.1 Introdução

7.2 Transformação de Arquitetura

7

10

10

11

11

14

17

17

19

24

27

27

30

35

35

36

38

44

44

45

46

47

49

49

51

8.

Gerência da Qualidade

53

 

8.1 Introdução

53

8.2 Garantia e Padrões de Qualidade

56

8.3 Planejamento de Qualidade

57

8.4 Controle de Qualidade

58

8.5 Melhoria de Processos

58

9.

Planejamento e Gerenciamento de Software

64

9.1 Introdução

64

9.2 Estimativa de preço do software

65

9.3 Plano de projeto

67

9.4 Programação de projeto

70

Referências Bibliográficas

72

EADDCC032 – Fundamentos de Engenharia de Software

1. Introdução

Antes de iniciarmos a apresentação dos temas associados à Engenharia de Software cabe definirmos o que podemos considerar como “software”, bem como o seu significado. Muitas vezes considera-se que esse termo se refere apenas aos programas de computadores e às suas instruções. Entretanto, ele se relaciona a qualquer artefato gerado no processo de desenvolvimento de programas de computadores que, ao serem executados, apresentarão as funcionalidades desejadas pelos usuários.

Por que devemos ter cuidado ao desenvolvermos software? A evolução da Internet e a crescente complexidade das formas de interação têm demandado sistemas com funcionalidades também complexas. Tais sistemas têm sido constantes nas nossas vidas gerando uma dependência em diferentes momentos. Por exemplo, nos negócios, nas ciências, e no dia a dia de nossas vidas. Hoje podemos encontrar software nos carros, nos eletrodomésticos, nos telefones, e outros. Mais ainda: a quantidade de software que foi desenvolvido no passado e que necessitam de modificações para evoluírem e se adequarem a um novo contexto tecnológico e de negócios.

Além disso, muitos sistemas legados continuam em funcionamento demandando pesquisas em relação às formas de evolução, adaptação às novas tecnologias e aperfeiçoamento em termos de artefatos existentes. Essas pesquisas têm investigado soluções para facilitar a manutenção buscando-se melhorias em termos de qualidade, produtividade e custo.

Mas, por que ainda encontramos projetos que consomem um tempo elevado para realizar entregas de produtos? Por que os custos ainda são altos em relação aos produtos que são entregues? Por que ainda encontramos erros no produto final e o custo de manutenção é tão alto? Um dos motivos associados a essas perguntas está relacionado à ausência de um processo de desenvolvimento e da adoção de boas práticas de projeto de software. As outras respostas a essas perguntas serão apresentadas ao longo dos próximos capítulos, outras serão deixadas como exercícios para discussão ou pesquisa.

7

EADDCC032 – Fundamentos de Engenharia de Software

(1) Pesquise, pelo menos, dois motivos pelos quais ainda se produz software com defeito. (2)

(1) Pesquise, pelo menos, dois motivos pelos quais ainda se produz software com defeito.

(2) Pesquise pelo menos dois motivos que podem elevar o custo de evolução de um software.

Esta apostila está organizada da seguinte forma: o próximo capítulo apresenta

alguns processos da Engenharia de Software. Eles são responsáveis pela organização

das sequências de atividades que apoiarão a construção dos sistemas; no Capítulo 3,

os aspectos relacionados às necessidades das pessoas envolvidas neste projeto são

abordados, desde o levantamento e análise até a especificação e construção de

documentos que descrevem essas necessidades. O Capítulo 4 discute os diferentes

conceitos envolvidos no projeto (design) de software, bem como os artefatos que

podem ser construídos para representar as diferentes características que um projeto

desta natureza requer. Já o próximo capítulo parte dos conceitos e artefatos

previamente apresentados, e trata dos aspectos para construção de um código

executável – a implementação do software. O Capítulo 6 apresenta os conceitos

envolvidos no teste de software com o intuito de oferecer artefatos que funcionem

corretamente, mas também que atendam às necessidades das diferentes pessoas

interessadas no perfeito funcionamento do software (stakeholders). O Capítulo 7

apresenta os conceitos envolvidos na manutenção e evolução do software. Discute

também a necessidade de termos um processo para gerenciar mudanças nos artefatos

produzidos em cada etapa do desenvolvimento de software. O Capítulo 8 apresenta os

conceitos básicos sobre qualidade de software. Apresenta também os principais

atributos de qualidade e a influência desses atributos no processo de desenvolvimento

e manutenção de software. Por fim, o Capítulo 9 trata de questões do planejamento de

do gerenciamento de projetos de software.

8

EADDCC032 – Fundamentos de Engenharia de Software

Exercícios

Exercícios

(1) O que é software?

(2) Em relação ao processo de desenvolvimento de software, podemos afirmar que, ao terminarmos de escrever um programa o trabalho de desenvolvimento terminou?

 

(3) Em relação aos artefatos entregues ao cliente, podemos afirmar que o único artefato entregue em um projeto bem sucedido é o código executável?

(4) Por que devemos construir software sem defeitos?

(5) Apesar dos avanços da Engenharia de Software em relação às metodologias e práticas de desenvolvimento de sistemas, por que não conseguimos garantir um sistema livre de erros antes de entregá-lo ao cliente?

(6) De uma forma geral, por que os custos de manutenção de sistemas ainda são altos?

9

EADDCC032 – Fundamentos de Engenharia de Software

2. Processos de Software

Este capítulo tem como objetivo discutir o conceito de processos de software, bem como apresentar

Este capítulo tem como objetivo discutir o conceito de processos de software, bem como apresentar alguns modelos de processo que são frequentemente utilizados no desenvolvimento de software. Ao término deste capítulo o leitor será capaz de identificar as vantagens e desvantagens da utilização de diferentes processos com o intuito de aplicá-los no desenvolvimento de produtos

2.1

Introdução

Processos podem ser caracterizados como um procedimento ou uma política para a construção de software. Artefatos são construídos ao longo do processo de desenvolvimento de software de diferentes formas, considerando-se as atividades, os recursos e os diferentes papeis envolvidos. Diferentes processos têm sido propostos na literatura de Engenharia de Software com diferentes objetivos considerando-se os contextos nos quais a organização está envolvida. Mas, o que caracteriza um processo como o mais adequado? Ao mencionarmos o contexto, como o fator que determina a escolha de um processo específico de desenvolvimento, nos referimos aos seguintes elementos, por exemplo: à maturidade da organização para desenvolver software, à natureza do produto que será desenvolvido, bem como ao domínio no qual a aplicação será utilizada.

Um processo de desenvolvimento de software engloba algumas práticas que possuem como objetivos gerar artefatos com o foco na qualidade e oferecer mecanismos para que as atividades possam ser continuamente melhoradas. A escolha de um processo irá definir a qualidade dos artefatos gerados nas diferentes etapas do desenvolvimento

Um processo de desenvolvimento, portanto, especifica os artefatos que serão gerados, os papeis e os recursos para o desenvolvimento das atividades. Além disso, oferece uma sequência de atividades cujo objetivo maior é orientar as pessoas envolvidas em relação aos produtos e responsabilidades. Através do conhecimento associado ao processo de desenvolvimento de software os artefatos, bem como as atividades, poderão ser acompanhados, medidos e avaliados. Como resultado, busca-

10

EADDCC032 – Fundamentos de Engenharia de Software

se uma previsibilidade dos eventos ocorridos, e uma melhoria contínua das atividades ali desempenhadas.

2.2 Modelo em Cascata

O ciclo de vida em cascata parte do princípio de que as etapas de especificação de requisitos, projeto, implementação, teste e verificação são realizadas uma após a outra. Ou seja, para realizar a etapa de projeto é necessário que os artefatos relevantes que foram gerados na etapa anterior estejam disponíveis. Desta forma, os artefatos de projeto são gerados a partir da finalização dos requisitos. Entretanto, muitas vezes essas etapas se sobrepõem e as informações geradas nas etapas são trocadas, pois nem todos os artefatos são gerados sem defeitos.

Uma das consequências da utilização deste modelo no desenvolvimento de software é o retrabalho decorrente da ausência de informação ou de equívocos na compreensão dos requisitos. Portanto, este modelo frequentemente se mostra adequado no desenvolvimento de sistemas em que os requisitos são conhecidos na sua totalidade, são estáveis e o domínio é bem conhecido. Como consequência deste fato, todos os artefatos podem ser verificados e revisões podem ser realizadas em cada etapa. Mais ainda, é possível ter uma visão geral e mais abrangente dos requisitos que serão efetivamente implementados.

Mas, nem sempre os requisitos são efetivamente conhecidos e são estáveis exigindo um retrabalho ao retornar às etapas anteriores e modificando cada artefato previamente construído. Consequentemente, sistemas mal estruturados podem ser construídos. Mais ainda, muitas vezes o tempo para entregar a versão final pode ser extenso.

2.3 O Processo Unificado (RUP)

O objetivo deste modelo de processo foi unificar as abordagens previamente existentes evidenciando as seguintes dimensões: as fases e os fluxos de trabalho. As

11

EADDCC032 – Fundamentos de Engenharia de Software

fases correspondem ao tempo. É o aspecto que se relaciona à dinâmica do processo. Neste sentido, cada fase comporta as iterações que irão produzir os artefatos programados para cada ocasião. Já os fluxos de trabalho correspondem às disciplinas do desenvolvimento de software. São elas: modelagem de negócios, requisitos, análise e projeto (design), implementação, teste, implantação, gerência de configuração e mudança, gerenciamento de projeto e ambiente. Considerando-se as duas dimensões, muitas vezes o processo unificado é mencionado na literatura como um modelo de processo híbrido. Percebemos uma sequência de atividades próxima do modelo em cascata previamente discutido.

O RUP é um processo iterativo no qual as disciplinas são apresentadas em cada etapa ao longo da dimensão do tempo. Portanto, podemos supor que ele oferece as vantagens dos modelos que surgiram anteriormente, e propõem as mesmas disciplinas do RUP. Nessa dimensão, o modelo iterativo sugere as seguintes fases do ciclo de vida do software: iniciação, elaboração, construção e transição.

Organização ao longo do tempo

construção e transição. Organização ao longo do tempo Organização ao longo do conteúdo (Fonte:
Organização ao longo do conteúdo
Organização ao longo do conteúdo

(Fonte: http://www.wthreex.com/rup/process/ovu_proc.htm)

Figura 2.1: Fases e disciplinas do RUP

Na fase de Iniciação o objetivo é realizar uma análise econômica do sistema partindo-se do conhecimento do negócio no qual o projeto está inserido. Como resultado, busca-se uma análise da viabilidade do projeto. Para tanto, estimativas iniciais são realizadas, bem como riscos são analisados e escopos são definidos.

12

EADDCC032 – Fundamentos de Engenharia de Software

Na fase de Elaboração, alguns objetivos são bem definidos, tais como: os requisitos para o sistema são especificados, bem como uma arquitetura preliminar é definida. Nada impede que nesta etapa um protótipo seja desenvolvido e apresentado com o intuito de verificar a viabilidade do projeto, por exemplo. Mais ainda, riscos são continuamente aprimorados buscando-se aqueles mais significativos para o atual estágio em que o projeto se encontra.

Na fase de Construção o foco está nos aspectos de implementação. Espera-se nesta fase que os modelos estejam finalizados e revistos, bem como a arquitetura esteja adequada aos incrementos que foram realizados nos artefatos. Mais ainda, os riscos são monitorados e medidas são tomadas para mitigá-los.

Na fase de Transição a maior parte dos artefatos já foi desenvolvida e parcialmente verificada. O sistema como um todo se encontra pronto para ser entregue, bastando uma avaliação da versão final por um grupo de usuários. Portanto, testes ainda são necessários e defeitos ainda poderão ser retirados do produto. Mais ainda, nada impede que sugestões e pedidos de melhorias possam ser realizados. Modificações são realizadas e o produto final é entregue.

Através do desenvolvimento iterativo elementos são integrados de forma incremental, pois os requisitos são passíveis de mudanças. Com isso, as mudanças nos requisitos são consideradas durante todo o processo. Essas mudanças podem acarretar revisões nos artefatos já planejados e projetados, bem como testes que poderão identificar erros mais cedo. Como resultado, entregas são realizadas mais cedo, e é fundamental que os riscos no projeto sejam tratados continuamente.

Entretanto, ao considerarmos a possibilidade de modificações em requisitos exige um gerenciamento no processo de mudanças no sentido de garantir que os artefatos se relacionam. Mais ainda, novos requisitos podem exigir mudanças arquiteturais que reduzam a qualidade do produto, bem como podem gerar sistemas mal estruturados.

RUP trata das seguintes práticas: (i) o software é desenvolvido interativamente. Artefatos são construídos através de várias iterações das quais participam os diferentes interessados; (ii) durante as diferentes etapas e iterações requistos são gerenciados considerando-se que eles podem evoluir conforme os interessados começam a visualizar as funcionalidades e as entregas dos artefatos; (iii) arquiteturas devem ser construídas tomando como base os componentes de software. Estes

13

EADDCC032 – Fundamentos de Engenharia de Software

componentes são responsáveis, em parte, pela facilidade de evolução, pela qualidade

e pelo custo reduzido dos artefatos que são produzidos em cada etapa; (iv) artefatos

são modelados visualmente. Casos de uso, por exemplo, apoiam significativamente o

desenvolvimento a partir da abordagem do RUP. Fornecem um suporte a partir dos

diagramas e das descrições do comportamento das funcionalidades. Esta modelagem

pode ser realizada, por exemplo, com o suporte de uma ferramenta; (v) a qualidade do

software é continuamente verificada considerando-se os padrões de produto e de

processo estabelecidos; e, por fim (vi) mudanças são controladas no sentido de

verificar, por exemplo, a sua viabilidade em termos dos recursos e da tecnologia

necessários, e dos custos envolvidos.

Krutchen, P., 2003, “The Rational Unifies Process – An

Krutchen,

P.,

2003,

“The

Rational

Unifies

Process

An

Introduction”, Addison-Wesley.

 

É um livro que oferece uma visão geral do RUP, e apresenta os conceitos principais para uma leitura introdutória.

2.4 O Modelo Evolucionário

Neste modelo os artefatos são produzidos gradativamente, conforme o

conhecimento sobre o domínio de aplicação do sistema é adquirido. Para tanto duas

abordagens são utilizadas para este modelo. São elas:

(I) Desenvolvimento exploratório: neste tipo o sistema evolui de acordo com o

conhecimento de novas funcionalidades, artefatos são produzidos em constante

interação com o cliente.

(II) Protótipos descartáveis: esta técnica apoia a identificação das necessidades dos

usuários a partir da construção de protótipos que serão apresentados aos

stakeholders com o objetivo de verificar a real necessidade dos requisitos, bem como

a sua consistência.

14

EADDCC032 – Fundamentos de Engenharia de Software

Entretanto, alguns problemas surgem ao utilizarmos este modelo de

desenvolvimento. O primeiro deles diz respeito à visibilidade do processo. Sem um

processo perfeitamente visível, as atividades e as suas dependências não são

apresentadas aos desenvolvedores no sentido de gerenciá-las. Outro problema está

relacionado às mudanças frequentes que este sistema está sujeito. Tais mudanças

estão associadas aos artefatos gerados nas etapas de desenvolvimento. Como

resultado, sistemas mal estruturados podem ser construídos, bem como a associação

entre os diferentes artefatos pode ser mais facilmente perdida. Para apoiar essas

atividades, um gerenciamento das mudanças mais rigoroso pode ser necessário

exigindo o suporte de ferramentas específicas para o controle das modificações. Este

assunto será mais explorado nos próximos capítulos.

A utilização deste modelo pode ser interessante, portanto, para sistemas de

pequeno porte, com um número menor de funcionalidades. Pois, gerenciar as

mudanças de um número significativo de requisitos pode significar o fracasso e a

descontinuidade do projeto. Em algumas situações, nas quais um número maior de

funcionalidades é exigido, um modelo de processo que associe o modelo em cascata e

o modelo evolucionário pode ser utilizado. Ou seja, em situações nas quais os

requisitos são conhecidos e estáveis pode ser utilizado o modelo em cascata. Em

outros momentos, nos quais os requisitos não são perfeitamente conhecidos, bem

como não são estáveis, pod ser empregado o modelo evolucionário. Este processo

frequentemente é denominado de misto.

Exercícios

Exercícios

(1) O que é um processo de desenvolvimento de software?

(2) Justifique a necessidade de um processo de desenvolvimento de software.

 

(3) Considere um determinado sistema cujos requisitos não foram, previamente, bem definidos e não eram estáveis. Ou seja, modificações frequentes nos mesmos ocorriam ao longo das atividades de desenvolvimento. Para tanto, foi utilizado apenas o modelo em cascata. Quais as implicações da utilização desse modelo para o desenvolvimento do sistema?

15

EADDCC032 – Fundamentos de Engenharia de Software

(4) Considere os seguintes conceitos do RUP: fases, disciplinas, artefatos, e papeis. De que forma eles se relacionam em um processo de desenvolvimento de software?

(5) Em algumas situações a abordagem evolucionária para o

desenvolvimento de software apresenta algumas vantagens em relação

à

abordagem em cascata. Em outras situações, a utilização do modelo

em cascata pode ser mais eficaz no sentido de construir sistemas que atendam às necessidades dos usuários. Comente esta afirmação e apresente pelo menos uma vantagem e uma desvantagem da utilização da abordagem evolucionária em relação à abordagem em cascata. Utilize um exemplo para ilustrar a sua resposta.

(6) Considere que é preciso desenvolver um sistema cujos objetivos gerais são inicialmente conhecidos; porém, não foram adequadamente identificados todos os requisitos (entrada, processamento e saída). Qual

o

modelo de processo para o desenvolvimento seria mais adequado?

Quais os problemas frequentemente encontrados quando este modelo é aplicado? Justifique a sua resposta utilizando exemplos

16

EADDCC032 – Fundamentos de Engenharia de Software

3. Engenharia de Requisitos de Software

Este capítulo tem como objetivo apresentar o processo de Engenharia de Requisitos e a sua

Este capítulo tem como objetivo apresentar o processo de Engenharia de Requisitos e a sua relação com as diferentes etapas do processo de desenvolvimento de software. Adicionalmente, cada etapa do processo e os produtos de software gerados em cada uma delas serão discutidos. Ao final do capítulo, o leitor deve ser capaz não apenas de compreender a importância da Engenharia de Requisitos no processo de desenvolvimento de software, mas de especificar um sistema.

3.1

Introdução

Sistemas são desenvolvidos de acordo com as necessidades dos usuários e das organizações. Essas necessidades podem estar relacionadas tanto às funcionalidades quanto às restrições impostas ao funcionamento do sistema. Por exemplo: (i) o sistema deve permitir que o usuário imprima um relatório dos alunos matriculados até um determinado dia; e (ii) o tempo mínimo para gerar este relatório deve ser de 2 minutos.

Entretanto, para que essas necessidades sejam devidamente descritas cabe ao desenvolvedor compreender o processo de negócio que será automatizado, bem como o contexto no qual ele está inserido. Por exemplo, o local em que o sistema será frequentemente executado, os recursos (hardware e software) disponíveis, entre outros.

Percebam que essas necessidades não dizem respeito à descrição da forma pela qual as funcionalidades serão executadas. Esta descrição deverá ser realizada posteriormente, a partir do momento em que o desenvolvedor compreendeu o conjunto de tarefas que serão realizadas, o seu impacto nos negócios da organização, bem como o relacionamento dos diferentes processos de negócio da organização. Em relação a este último, podemos mencionar que não basta, por exemplo, entender a forma pela qual a matrícula de um aluno será automatizada pelo sistema, mas também os diferentes relacionamentos deste processo com aqueles que serão executados pela

17

EADDCC032 – Fundamentos de Engenharia de Software

área financeira da escola. Mais ainda: é necessário identificar os usuários, bem como

compreender a(s) forma(s) pela(s) qual(is) eles irão interagir com o sistema.

As necessidades são descritas através dos requisitos funcionais e não funcionais

do sistema. Os requisitos funcionais estão relacionados às funcionalidades executadas

pelo sistema, o seu comportamento diante das entradas e saídas dos dados. Já os

requisitos não funcionais dizem respeito às restrições para que essas funcionalidades

sejam executadas dentro dos padrões de qualidade esperados. Por exemplo:

segurança, confiabilidade, portabilidade, tempo de entrega do produto, privacidade,

entre outros. Considere o sistema escolar que apresenta como requisito funcional

“permitir que o aluno realize o pagamento da matrícula logo após a escolha das

disciplinas”. Entretanto, para que esta funcionalidade seja executada nos padrões de

qualidade definidos pela escola, este pagamento deve oferecer uma segurança e

confiabilidade satisfatórias para a efetivação da matrícula.

Percebemos, portanto, que existe um relacionamento entre os requisitos

funcionais e não funcionais. Eles interagem de tal forma que um tipo pode modificar o

outro. Por exemplo, se a organização não for capaz de fornecer um nível de segurança

e confiabilidade satisfatório para o aluno, o requisito funcional que trata do pagamento

da matrícula não poderá ser especificado.

Requisitos

Funcionais

Modifica

poderá ser especificado. Requisitos Funcionais Modifica Requisitos não Funcionais Figura 3.1: Relacionamento

Requisitos não

Funcionais

Figura 3.1: Relacionamento entre requisitos

Mas, se os requisitos não funcionais estão relacionados aos atributos de

qualidade do sistema, não é possível colocarmos todos os atributos no mesmo patamar

para que eles sejam atendidos? Por exemplo, o usuário necessita de portabilidade,

escalabilidade, confiabilidade, segurança, facilidade de uso e desempenho, todos no

mesmo patamar. Não, nem sempre eles podem ser atendidos no mesmo nível e

necessitam, portanto que se estabeleça uma prioridade para que eles sejam atendidos.

18

EADDCC032 – Fundamentos de Engenharia de Software

No processo de Engenharia de Requisitos diferentes artefatos são gerados. São exemplos destes artefatos: (i) descrição de casos de uso; (ii) diagramas de casos de uso; (iii) modelos; e (iv) documento de especificação dos requisitos, entre outros.

Mesmo que o processo seja conduzido satisfatoriamente, é necessário certificarmos de que esses produtos estão corretos. Considerando-se o processo de desenvolvimento de software, quanto mais cedo um erro for identificado em um artefato específico, mais facilmente ele poderá ser corrigido e, consequentemente, menor o custo para a sua correção. Além dos erros relacionados a uma compreensão equivocada de uma necessidade, outros erros podem estar relacionados a requisitos inconsistentes e/ou conflitantes. Uma das formas de identificarmos erros nos artefatos é através da realização de revisões. Elas podem envolver diferentes stakeholders e ser realizadas através de reuniões.

3.2 O Processo de Engenharia de Requisitos

Diferentes autores propõem um processo para a Engenharia de Requisitos. No contexto desta disciplina, adotaremos o modelo proposto por Sommerville (2009). Neste processo, o autor propõe as seguintes etapas: (i) estudo de viabilidade, (ii) levantamento e análise de requisitos, (iii) especificação de requisitos e (iv) validação de requisitos. Para cada etapa alguns artefatos são gerados. A seguir discutiremos cada uma das etapas, bem como os artefatos e a importância de cada um deles para o processo de desenvolvimento de software.

Estudo de

viabilidade

Levantamento e análise de requisitos Especificação de requisitos
Levantamento e
análise de requisitos
Especificação
de requisitos

Validação de

requisitos

Figura 3.2: Etapas da Engenharia de Requisitos

(i) Estudo de Viabilidade

Este estudo tem como objetivo principal avaliar a viabilidade de se desenvolver o sistema considerando-se as necessidades dos usuários. Através desta etapa, procuramos antecipar os riscos de iniciarmos o desenvolvimento de um sistema que

19

EADDCC032 – Fundamentos de Engenharia de Software

não trará os benefícios esperados. Para tanto, busca-se identificar, brevemente, os requisitos do negócio que será modelado durante o processo de desenvolvimento. Além disso, cabe descrever o sistema e a forma pela qual ele poderá apoiar a organização nos seus diferentes processos.

Entretanto, quando mencionamos que esta etapa de Engenharia de Requisitos gera como resultado um relatório de viabilidade, muitos questionam o conteúdo deste documento. Cabe enfatizar que ele não deve refletir um estudo longo, pois a descrição detalhada dos requisitos não faz parte desta etapa. É um documento que descreve, sucintamente, as vantagens que o sistema poderá trazer para a organização apresentando as diferentes formas de utilização no contexto dos processos de negócio. Mais ainda: busca responder, brevemente algumas questões relacionadas à utilização do sistema considerando-se as tecnologias e sistemas já existentes na organização. Neste momento, custo e prazo são elementos essenciais para justificar, o não, a continuidade do processo de desenvolvimento.

Por fim, será produzido um relatório que irá, ou não, recomendar a continuidade do processo de desenvolvimento. Além disso, cabe justificar a recomendação de continuidade do processo, ou então sugerir que o escopo do sistema seja modificado em decorrência dos seguintes aspectos: tecnologia, pessoal, prazo, custo, entre outros.

(ii) Levantamento e Análise de Requisitos

Depois de identificada a viabilidade para prosseguir com o desenvolvimento do software, cabe aos analistas procurarem entender com mais detalhes as reais necessidades do cliente. Para tanto, é necessário lançar mão de algumas técnicas que poderão apoiar esses analistas na compreensão do contexto no qual os processos de negócio estão inseridos. Além disso, eles necessitarão ter um conjunto de informações que os ajudarão na compreensão das relações desses processos. Mas cuidado, parece simples, não é? Se perguntarmos aos usuários o que eles necessitam parece ser suficiente, mas não é tão simples assim. Isso acontece por vários motivos. Vejamos então alguns deles a seguir.

20

EADDCC032 – Fundamentos de Engenharia de Software

Muitas vezes achamos que a atividade de levantamento e análise de requisitos é

simples. Isto se deve ao fato de que ela se refere ao entendimento dos processos de

negócio e suas relações, à tecnologia e pessoal envolvidos, aos sistemas existentes,

aos desejos dos usuários, às necessidades e objetivos da organização, entre outros.

Pois então não é tão simples quanto parece, não é?

Algumas técnicas são frequentemente propostas na literatura para apoiar as

atividades de levantamento e análise de requisitos. São exemplos dessas técnicas:

(I) Entrevistas: questões são formuladas para diferentes stakeholders para que

algumas características sejam identificadas seja em relação a um sistema que está

em produção, ou então para um sistema que será desenvolvido;

(II) Prototipagem: um protótipo pode ser caracterizado por uma sequência de interfaces

relacionadas, cujo objetivo é ilustrar o funcionamento de algum requisito. Através

delas alternativas de interface podem ser avaliadas e, ao mesmo tempo, os usuários

passam a ter uma ideia do funcionamento do sistema. Como resultado, riscos de

projeto podem ser minimizados. Uma característica de um protótipo que deve ser

levada em consideração ao adotarmos esta técnica é que ele não deve exigir um

tempo considerável do analista. A figura abaixo ilustra um protótipo de uma interface.

A figura abaixo ilustra um protótipo de uma interface. Figura 3.3: Exemplo de um protótipo de

Figura 3.3: Exemplo de um protótipo de um fórum de discussões associado a um quadro de avisos

21

EADDCC032 – Fundamentos de Engenharia de Software

Como resultado, artefatos podem ser produzidos para serem utilizados nas próximas etapas da Engenharia de Requisitos. São eles:

Declaração da(s) necessidade(s);

Escopo do problema;

Clientes, usuários e outros stakeholders;

Lista de requisitos;

Conjunto de cenários de uso;

Protótipos Dentre os artefatos produzidos nesta etapa, cabe citar também os diferentes modelos capazes de representar diferentes aspectos obtidos durante o entendimento das necessidades dos usuários e dos processos que se deseja automatizar. Mas, por que modelos? Modelos estão relacionados a linguagens gráficas que muitas vezes são mais fáceis de serem utilizadas e compreendidas do que a linguagem escrita. Mais ainda, cada modelo pode documentar um diferente aspecto do sistema. Por exemplo, os diagramas de sequência podem enfatizar a sequência dos eventos e os diagramas de casos de uso podem retratar as interações com o mundo exterior.

Nesta etapa, os requisitos devem ser priorizados, bem como ordenados conforme as necessidades e urgência do cliente. Por exemplo, em um sistema acadêmico é possível entregar, inicialmente, o módulo de cadastro de disciplinas. Esta priorização também está relacionada ao modelo de processo de desenvolvimento adotado. No RUP, por exemplo, entregas relacionadas aos módulos iniciais são negociadas e decisões são tomadas. Como resultado, clientes têm suas necessidades prontamente satisfeitas, e os desenvolvedores podem ter certeza dos prazos e orçamentos a serem cumpridos. Adicionalmente, estimativas são realizadas considerando-se o esforço e o impacto do requisito que será entregue.

(iii) Especificação de Requisitos

Identificadas as necessidades e gerados os artefatos das etapas anteriores, a especificação de requisitos tem como objetivo produzir um documento contendo, dentre outras informações, as funções, as restrições e os atributos de qualidade que serão imprescindíveis para o sistema. O documento resultante pode ser escrito contento modelos gerados na etapa de análise com o intuito de auxiliar na clareza e na precisão das informações ali contidas.

22

EADDCC032 – Fundamentos de Engenharia de Software

Diferentes padrões de documentos são propostos na literatura de Engenharia de Software. O IEEE propõe um formato que contém as informações necessárias para as etapas posteriores. Já Sommerville (2011) sugere um formato diferente separando os requisitos funcionais e não funcionais em duas categorias. São elas: de usuários e de sistema. O que diferencia cada uma das categorias é o nível de abstração em que cada requisito é descrito. Nos requisitos de usuários, encontramos uma declaração em alto nível, que interessa fundamentalmente aos stakeholders que não necessitam de um detalhamento. Já nos requisitos de sistema são fornecidos detalhes que interessam basicamente aos projetistas, implementadores e testadores.

basicamente aos projetistas, implementadores e testadores. Figura 3.4: Diferentes tipos de requisitos (iv) Validação

Figura 3.4: Diferentes tipos de requisitos

(iv) Validação de Requisitos

Considerando-se o modelo adotado para o desenvolvimento de software, quanto mais cedo ambiguidades e forem identificados, custos podem ser reduzidos, produtividade e qualidade dos artefatos podem ser melhoradas. Para tanto, são necessárias validações dos artefatos buscando-se identificar a consistência dos requisitos em relação aos objetivos inicialmente definidos. Mais ainda, são verificados os aspectos relacionados à clareza e a precisão das descrições dos requisitos bem como o nível de detalhamento adotado e a ausência de alguma funcionalidade.

Muitas vezes, requisitos difíceis de serem testados podem ser especificados, ou então o custo de testá-lo pode ser muito alto exigindo simulações inviáveis considerando-se os recursos existentes. Por exemplo, para um sistema de automação industrial a avaliação de valores associados à temperatura e à pressão podem exigir ambientes de simulações que tornariam o custo de desenvolvimento alto.

23

EADDCC032 – Fundamentos de Engenharia de Software

3.3 Gerenciamento de requisitos

Uma vez finalizados os artefatos relacionados ao levantamento e análise de requisitos, bem como realizadas as entregas e homologações do documento de requisitos, as próximas etapas do processo de desenvolvimento podem ser iniciadas. Em cada etapa, posterior à Engenharia de Requisitos, mudanças podem ser necessárias e, portanto, devem ser analisadas em relação à sua viabilidade. Requisitos podem estar equivocados, erros podem ser identificados exigindo modificações nos artefatos produzidos. O gerenciamento de requisitos diz respeito à identificação, controle e rastreamento do impacto das mudanças em relação aos artefatos já entregues. Para tanto se torna necessário o rastreamento em relação, por exemplo, às fontes dos requisitos, as suas dependências e o impacto da mudança em relação aos processos envolvidos e aos diferentes interessados naquele requisito que será impactado pela mudança.

Requisitos funcionais podem ser rastreados em relação a diferentes aspectos, tais como: (i) solicitações de stakeholders, (ii) regras de negócio associadas, e (iii) outros requisitos funcionais que podem ser afetados. Por exemplo, considere um sistema de matrículas de uma escola, ao modificar o requisito funcional RF1: cadastrar disciplinas que são pré-requisitos da disciplina Engenharia de Software pode ser necessário consultar os coordenadores dos cursos que adotam esta disciplina na sua grade curricular. Esses coordenadores foram identificados através de solicitações registradas. Para tanto, essas solicitações devem estar registradas em um documento que forneça esta informação. Um exemplo deste documento é a matriz de rastreabilidade.

Matrizes de rastreabilidade são estruturas de relacionamentos entre os Requisitos Funcionais (RFi, i=1,

dados

que

informam

n)

e diferentes aspectos.

A1 A2 A3 An RF1  RF2     RFn  
A1
A2
A3
An
RF1
RF2
RFn
Exemplos de aspectos: Fontes de requisitos Solicitações de stakeholders Regras de negócio
Exemplos de aspectos:
Fontes de requisitos
Solicitações de stakeholders
Regras de negócio

os

Figura 3.5: Exemplo de uma matriz de rastreabilidade

24

EADDCC032 – Fundamentos de Engenharia de Software

Exercícios Resolvidos:

(1) Pesquise outros motivos que podem dificultar o levantamento e a análise dos requisitos do sistema que será desenvolvido.

Resposta: Problemas de escopo (limite do sistema mal definido, detalhes técnicos desnecessários são especificados); Problemas de entendimento; Problemas de volatilidade.

(2) Por que em algumas situações entrevistas não são tão úteis para apoiar o levantamento de requisitos?

Resposta: (i) Especialistas usam terminologias e jargões específicos. (ii) Alguns conhecimentos de domínio são tão familiares que são difíceis de explicar.

Exercícios

Exercícios

(1) Qual a diferença entre requisitos funcionais e não funcionais?

(2) Considere um sistema para gerenciar o atendimento de pacientes em uma clínica médica e idealize algumas funções e restrições existentes.

 

(3) Algumas técnicas foram apresentadas no corpo do texto para apoiar o levantamento de requisitos. Pesquise na literatura outra técnica que poderia ser utilizadas para esta finalidade.

(4) Além dos requisitos não funcionais apresentados no corpo do texto, pesquise outros requisitos não funcionais que podem ser especificados para um sistema.

(5) Os requisitos funcionais são mais difíceis de serem quantificados? Podemos então afirmar que, em etapas posteriores, caso eles não sejam quantificados, podemos ter custos elevados para analisá-los e verificar se eles estão de acordo com a especificação?

(6) Uma falha na especificação de um requisto funcional (RF) não tem o mesmo efeito em relação à falha na especificação de um requisto não funcional (RNF). Ao cometermos um erro em um RF, podemos afirmar que apenas aquela funcionalidade não terá serventia, enquanto que uma falha em um RNF pode significar a inutilidade do sistema. Comente esta afirmação e apresente umexemplo para ilustrar a sua resposta.

(7) Pesquise outras técnicas que poderiam ser utilizadas para apoiar as revisões de requisitos.

25

EADDCC032 – Fundamentos de Engenharia de Software

(8) Alguns formatos de documento de requisitos são propostos na literatura de Engenharia de Software. Pesquise sobre esses formatos e proponha um formato identificando o conteúdo de cada seção. Defina um sistema bem simples e gere um documento de requisitos para este sistema.

(9) O gerenciamento de requisitos é necessário por diversos motivos. Além daqueles apresentados no corpo do texto pesquise outros motivos que justificam as atividades de gerenciamento de requisitos.

(10)

Por que utilizamos matrizes de rastreabilidade?

(11)

Além dos relacionamentos ilustrados no corpo do texto, pesquise

outros que podem ser documentados em uma matriz de rastreabilidade.

(12)

Como justificar a importância da engenharia de requisitos e dos

produtos

gerados ao longo de cada etapa deste processo?

26

EADDCC032 – Fundamentos de Engenharia de Software

4. Projeto de Sistemas

Este capítulo tem como objetivo apresentar a etapa de projeto (design) no contexto do processo

Este capítulo tem como objetivo apresentar a etapa de projeto (design) no contexto do processo de desenvolvimento de software. Adicionalmente, busca relacionar os artefatos produzidos nesta etapa com aqueles que foram descritos nos capítulos anteriores. Ao término deste capítulo, o leitor deve ser capaz de compreender a importância desta etapa, e dos artefatos gerados, para o desenvolvimento de software.

4.1

Introdução

A etapa de projeto (design) de software está relacionada às atividades cujo objetivo é gerar artefatos que representam modelos do software. Tais modelos podem ter como foco os seguintes aspectos: arquitetura, interface humano-computador, banco de dados, ou classes que compõem o sistema, entre outros. São construídos tendo como objetivo atender aos requisitos funcionais, bem como aos requisitos não funcionais. Ao utilizarmos representações através de modelos atributos de qualidade podem ser avaliados e melhorados tendo como foco os requisitos não funcionais especificados previamente. Por exemplo, ao definirmos uma estrutura de dados no momento de projeto estamos interessados não apenas nas funcionalidades que esta estrutura poderá fornecer, mas também em nos aspectos como desempenho, custo, entre outros.

Modelos e representações geradas na etapa de projeto têm como objetivo detalhar e definir tecnologias a serem utilizadas na criação do software. Por exemplo: o projeto de dados e classes gera, como artefatos, as classes de projeto (com um nível de detalhamento maior) e as estruturas de dados mais adequadas às necessidades do sistema que está sendo desenvolvido. Já o projeto arquitetural tem como foco os estilos arquiteturais que serão utilizados e o projeto de interface humano-computador busca definir as formas de interação com os usuários, bem como o desenho das telas (interfaces) que serão utilizadas.

Mas, qual objetivo de gerar esses modelos e representações? Além de produzir uma documentação do sistema, que servirá de base para futuras modificações e evoluções, esses artefatos permitem a realização de revisões com o foco na qualidade.

27

EADDCC032 – Fundamentos de Engenharia de Software

Através desses artefatos é possível modificar e testar determinadas funcionalidades antes de implementá-las. Como resultado, podemos antecipar a identificação de possíveis defeitos no software e reduzir os custos de implementação e garantir que determinados requisitos (funcionais e não funcionais) sejam atendidos.

De uma forma geral, o objetivo é produzir modelos e descrições que satisfaçam aos requisitos (funcionais e não funcionais) considerando a diversidade de situações que foram percebidas na Engenharia de Requisitos, bem como buscando uma convergência para os negócios e objetivos da organização. Os artefatos gerados devem servir não apenas como uma referência para as etapas posteriores (implementação teste e implantação), mas como recursos para comunicar as decisões tomadas com o foco nos requisitos. Mais ainda servem para apoiar as revisões e, como resultado, informar sobre a corretude dessas decisões. É através dessas atividades que as ambiguidades, erros e omissões podem ser identificados.

Para exemplificar alguns tipos de projetos e os diagramas gerados, podemos

citar:

(i) o projeto de classes, apresenta cada classe, desenhada na etapa de análise, em elementos com um nível de detalhamento maior. A figura abaixo ilustra um diagrama de projeto a partir do diagrama de classes:

ilustra um diagrama de projeto a partir do diagrama de classes: Figura 4.1: Exemplo de um

Figura 4.1: Exemplo de um modelo com classes de projeto

28

EADDCC032 – Fundamentos de Engenharia de Software

(ii) o projeto arquitetural define o relacionamento entre os diferentes elementos que compõem o sistema. A figura abaixo ilustra a arquitetura de alto nível (visão geral) de um sistema de administração escolar. As representações dos sistemas e relacionamentos não mostram propriedades entre eles.

e relacionamentos não mostram propriedades entre eles. Figura 4.2: Exemplo de um modelo abstrato de uma

Figura 4.2: Exemplo de um modelo abstrato de uma arquitetura para um sistema

(iii) o projeto de banco de dados apresenta as diferentes estruturas e seus relacionamentos considerando-se os requisitos funcionais e não funcionais, bem como as consultas frequentes que são realizadas. A figura abaixo ilustra um projeto de banco de dados apresentado na disciplina de Banco de Dados.

(1,1) (1,1) Autor Autor EscreveEscreve cod_autor cod_autor nome nome (1,N) (1,N) nascimento nascimento titulo
(1,1)
(1,1)
Autor
Autor
EscreveEscreve
cod_autor
cod_autor
nome
nome
(1,N)
(1,N)
nascimento
nascimento
titulo
titulo
cod_autor
cod_autor
Livro
Livro
cod_editora
cod_editora
valor
valor
(0,N)
(0,N)
publicacao
publicacao
volume
volume
Editora
Editora
PublicadoPublicado
(0,1)
(0,1)
cod_editora
cod_editora
razao
razao
endereco
endereco
cidade
cidade

Figura 4.3: Exemplo de um modelo de dados para o projeto de um BD

29

EADDCC032 – Fundamentos de Engenharia de Software

Mas, existem algumas diretrizes para a construção dos diagramas de projeto? Quais os princípios que norteiam as suas construções? Inicialmente, vamos partir do princípio de que todo projeto de software deve ser modular. A modularidade permite que a evolução do projeto aconteça de uma forma mais simples, sem que a alteração de uma parte exija a modificação de outras partes. Além disso, incrementos podem ser liberados mais facilmente. Por exemplo, considere que um módulo trate da matrícula dos alunos em um sistema de administração escolar, e outro módulo considera a

matrícula das disciplinas, e as suas dependências. A modularidade permite que apenas

a relação de dependências entre as disciplinas seja modificada sem que o módulo de

matrícula seja alterado. Adicionalmente, um módulo de avaliação de disciplinas pode ser liberado posteriormente.

Além da modularidade, um projeto de tratar das representações dos dados, da arquitetura, das interfaces entre os módulos e dos seus componentes. Mais ainda, cada componente deve tratar das estruturas de dados adequadamente, considerando- se as vantagens e desvantagens da utilização de cada uma delas. Esses componentes

devem utilizar uma notação que comunique para os interessados os seus significados,

e tratar as funcionalidades de forma independente.

4.2 Alguns conceitos de projeto de software

Além da modularização, um conceito que deve ser considerado no projeto de software é a abstração. Ele se refere à simplificação das características que interessam em um contexto específico. Ao abstrair, apresentamos apenas as características que interessam para uma determinada realidade. Por exemplo, no contexto de um sistema de administração escolar os diagramas apresentam apenas as características que interessam em relação aos alunos. Ao tratarmos a matrícula de um determinado curso, não cabe apresentarmos o endereço de cada aluno. Esta característica pode ser abstraída para este contexto. Entretanto, ao considerarmos o módulo de cadastro de cada aluno o endereço é um atributo que deve ser considerado.

Não basta criarmos módulos sem nenhum critério. Dois conceitos são fundamentais quando consideramos a definição de um módulo. São eles: a coesão e o acoplamento. Ao falarmos da coesão de um módulo estamos interessados na sua robustez funcional. Ele está relacionado a uma única atividade. Já o acoplamento está

30

EADDCC032 – Fundamentos de Engenharia de Software

relacionado à dependência do módulo com outros para realizar uma determinada atividade. Para realizar uma atividade será necessária a execução de um módulo que por sua vez chama outros módulos. Desta forma, a modificação de um módulo pode acarretar na modificação dos módulos a eles associados. Por exemplo, um módulo de cadastro de alunos deve realizar apenas o cadastro (alta coesão). Se ao realizar o cadastro ele necessita executar funções de um módulo financeiro (alto acoplamento), as modificações no módulo de cadastro poderiam não ficar limitadas apenas a este módulo. Portanto, para um projeto satisfatório devemos buscar sempre uma alta coesão e um baixo acoplamento entre os módulos.

Outro conceito diz respeito aos padrões que podem ser utilizados no projeto. Mas, muitas vezes os projetistas questionam a necessidade de utilizarmos padrões. Por que eles são importantes? Padrões estão relacionados à documentação das melhores práticas, eles descrevem uma estrutura que foi anteriormente utilizada e que foi bem sucedida. Normalmente eles estão relacionados às melhores práticas considerando-se o contexto e as forças que atuam na utilização do padrão. Por exemplo, alguns padrões de projeto mencionam a estrutura de classes mais adequadas para serem utilizadas em um contexto.

Muitas vezes os módulos devem ser projetados de uma forma que o acesso às informações desnecessárias seja controlado. Nem todos os usuários necessitam acessar e visualizar determinadas informações. Por exemplo, um aluno não necessita ter acesso às informações financeiras da escola. Se ele necessita apenas acessar os dados da disciplina, os custos associados à mesma não necessita ser apresentado ao aluno. Este conceito está relacionado à ocultação de informação. Mas, apenas a visualização e o acesso são as vantagens da ocultação de informação? Quais as consequências da ocultação de informação? Ao abstrairmos uma informação e, ao mesmo tempo, ocultarmos esta informação alguns erros não são propagados para outros módulos. Somente as informações necessárias são enviadas para outros módulos associados. Portanto, a associação entre ocultação de informação e abstração é sempre vantajosa para o projeto de sistemas.

A modularização adequada, associada aos conceitos de abstração e ocultação de informação nos leva ao conceito de independência funcional. Desta forma, não basta considerarmos apenas uma alta coesão e um baixo acoplamento, se as características desnecessárias não forem desconsideradas, bem como os aspectos de acesso à

31

EADDCC032 – Fundamentos de Engenharia de Software

informação também não forem tratados. A independência funcional resulta em um módulo que possui poucas interações com outros módulos. Mais ainda, apresenta interfaces desses módulos simplificadas, pois mostram apenas os parâmetros necessários para as interações. Consequentemente, as manutenções serão mais fáceis, pois as alterações no módulo não acarretam alterações nos módulos a eles associados. Mais ainda, este módulo poderá ser substituído por outro que trará mais funcionalidades, ou poderá ser reutilizado em outro projeto.

O conceito de refinamento está relacionado ao conceito de abstração. Ao refinarmos um módulo estamos tratando do detalhamento das funcionalidades ali encontradas. Saímos de um conceito mais abstrato, em alto nível, e refinamos o módulo com o intuito de apresentar os detalhes, por exemplo, da sua implementação. Sucessivos refinamentos podem ser aplicados ao módulo até o momento em que os detalhes necessários são apresentados. Por exemplo: considere um módulo para tratar a matrícula de um aluno. Como submódulos podemos exemplificar: (i) o módulo de inclusão; (ii) o módulo de exclusão de um aluno; e (iii) o módulo de alteração de um registro de aluno. Cada um desses submódulos possui um submódulo de busca pelo nome do aluno ou pelo número de matrícula, além dos algoritmos de busca utilizados.

Muitas vezes os módulos são construídos de uma forma inadequada, ou então ele

evolui para um projeto que não corresponde às melhores práticas da Engenharia de Software. Consequentemente, ele pode ser refatorado no sentido de melhorar as suas características, funções e comportamentos. Mas, o que pode ser refatorado para melhorar as suas características. Por exemplo, um determinado trecho de código foi

construído utilizando-se uma estrutura em Java <switch

se que este trecho poderia ser tratado utilizando-se o conceito de polimorfismo (Orientação a Objetos). Neste caso, uma refatoração poderia ser aplicada a este código no sentido de aproveitar as vantagens que o conceito de polimorfismo pode trazer para o projeto. A refatoração pode retirar do código elementos que são desnecessários, ou então que podem facilitar as manutenções do módulo. Neste contexto, redundâncias de códigos podem ser eliminadas e algoritmos ineficientes podem ser substituídos.

case>, entretanto, percebeu-

32

EADDCC032 – Fundamentos de Engenharia de Software

Exercício Resolvido:

(1) Um sistema com um único módulo (monolítico) apresenta uma série de problemas principalmente no que diz respeito à evolução do sistema. Entretanto, se dividirmos em uma quantidade significativa de módulos, o custo de integração dos módulos pode se tornar muito alto, enquanto o custo para manter cada módulo pode ser reduzido. Por que não devemos projetar os sistemas como monolíticos? Quais as desvantagens desta decisão de projeto?

Resposta: Ao tomar uma decisão de projeto de um sistema monolítico algumas dificuldades, principalmente no que diz respeito à evolução do sistema. Módulos que estão relacionados a uma funcionalidade específica e que são independentes funcionalmente permitem uma integração mais fácil com um custo mais baixo. Entretanto, o custo para manter o módulo pode aumentar. Encontrar o tamanho adequado de cada módulo é um desafio que deverá ser resolvido pelo projetista.

(1) Além dos exemplos apresentados no coropo do texto, pesquise, pelo menos, dois tipos de
(1) Além dos exemplos apresentados no coropo do texto, pesquise, pelo menos, dois tipos de

(1) Além dos exemplos apresentados no coropo do texto, pesquise, pelo menos, dois tipos de refatoração que poderiam ser aplicados a um código para melhorar a sua qualidade.

(2) Pesquise o conceito de “framework” para apoiar o projeto de software e verifique a(s) forma(s) pela(s) qual (is) ele pode apoiar o projeto de software.

pela(s) qual (is) ele pode apoiar o projeto de software. Exercícios (1) Relacione os seguintes conceitos

Exercícios

(1) Relacione os seguintes conceitos de projeto: (i) modularização e reutilização; e (ii) abstração e modularização.

(2) Por que a abstração, a modularização e a ocultação da informação são conceitos fundamentais para o projeto de software? Utilize um para ilustrar a sua resposta.

(3) Relacione os princípios de projeto com as diferentes etapas do modelo RUP.

(4) De que forma a modularização pode facilitar o planejamento da construção de um sistema e o processo de teste de cada módulo?

(5) Em algumas situações devemos implementar sistemas monolíticos pois, somente assim podemos conseguir o desempenho desejado. Comente esta afirmação apresentando exemplos para ilustrar a sua resposta.

33

EADDCC032 – Fundamentos de Engenharia de Software

(6) Pesquise, pelo menos, dois padrões que podem ser utilizados no projeto de um sistema de administração escolar. Descreva as vantagens e as forças associadas aos padrões especificados.

(7) A reutilização de um módulo está relacionada ao uso do módulo em outros contextos. Portanto, basta tratarmos a independência funcional que garantiremos a reutilização do módulo. Pesquise os elementos que afetam diretamente a reutilização de um módulo e relacione esses elemntos ao conceito de independência funcional.

(8) Considere o conceito de refatoração e apresente as formas pelas quais ele interage com os conceitos previamente discutidos (modularização, acoplamento, abstração e ocultação de informação).

34

EADDCC032 – Fundamentos de Engenharia de Software

5. Implementação

Este capítulo tem como objetivo apresentar alguns aspectos da etapa de implementação de um sistema.

Este capítulo tem como objetivo apresentar alguns aspectos da etapa de implementação de um sistema. Ao término deste capítulo o leitor será capaz de identificar duas abordagens para apoiar a implementação de software. São elas:

reutilização de componentes e gerência de configuração. Associadas a essas abordagens algumas práticas de implementação duas discutidas.

5.1

Introdução

Segundo Sommerville (2011), esta etapa pode ser considerada como a mais crítica do processo de desenvolvimento. Neste momento do processo, o código executável será gerado conforme as especificações das etapas anteriores.

O desenvolvimento de um código executável frequentemente é apoiado por uma plataforma de desenvolvimento de software. Esta plataforma oferece um conjunto de ferramentas para apoiar as diferentes atividades de desenvolvimento, tais como: (i) um editor gráfico de modelos, por exemplo, UML, que serão transformados em código executável. Este código necessita ser editado e, portanto necessita de um suporte de um editor de código para uma linguagem específica, apoiado por um compilador integrado; (ii) um sistema que permita realizar a depuração do código que está em desenvolvimento; e (iii) ferramentas integradas de testes de integração dos módulos. Ferramentas de apoio ao desenvolvimento normalmente são integradas em um ambiente, denominado IDE (Integrated Development Environment).

Editor LP Depurador
Editor LP
Depurador
Testes IDE Editores Modelos
Testes
IDE
Editores
Modelos

Figura 5.1: Elementos de uma IDE

35

EADDCC032 – Fundamentos de Engenharia de Software

Além dos aspectos envolvidos na programação, tais como as boas práticas de programação, esta etapa trata da aderência aos padrões de processo e de produto determinados pela equipe de qualidade. Mais ainda: é importante considerar os artefatos gerados nas etapas anteriores, bem como os processos definidos em cada etapa.

Alguns exemplos de IDE: o NetBeans ( www.netbeans.org ); e o Eclipse ( www.eclipse.org ),

Alguns exemplos de IDE: o NetBeans (www.netbeans.org); e o Eclipse (www.eclipse.org), baseado em plug-ins.

No contexto desta disciplina (Fundamentos da Engenharia de Software) cabe ressaltar duas abordagens normalmente consideradas quando tratamos dos aspectos de implementação de software. São elas: reutilização de software e gerência de configuração.

5.2 Reutilização de software

Reutilização de artefatos no processo de implementação não é recente. Desenvolvedores frequentemente lançam mão desta técnica ao utilizarem as bibliotecas de linguagens de programação. Entretanto, com o surgimento de novas demandas para o desenvolvimento de software, tais como qualidade dos artefatos, alta produtividade e baixo custo, as abordagens para reutilização também evoluíram.

Desenvolvimento de software a partir da reutilização está associado ao processo de construção de sistemas a partir de um conjunto de artefatos, incluindo códigos, já existentes. Portanto, podemos pensar que se vamos “unir” trechos de código (bibliotecas) para construir um sistema, então o processo de desenvolvimento será simplificado. Porém, isto nem sempre é verdade. Em sistemas relativamente pequenos que exigem um conhecimento limitado do domínio no qual ele será aplicado, provavelmente a implementação será simplificada. Entretanto, os processos frequentemente encontrados na prática são aqueles que podemos denominar de “ad- hoc”. Não existe uma sistematização do reuso.

Ao sistematizarmos a reutilização através de padrões de procedimentos podemos obter uma série de benefícios, tais como: os custos de implementação podem ser

36

EADDCC032 – Fundamentos de Engenharia de Software

reduzidos, a produtividade e a qualidade podem ser aumentadas. Além disso, aspectos

relacionados à portabilidade de artefatos podem ser adequadamente tratados, bem

como a confiabilidade e a segurança desses artefatos (Sametinger, 1997).

A reutilização pode apoiar não apenas a etapa de implementação, mas qualquer etapa do processo

A reutilização pode apoiar não apenas a etapa de implementação, mas qualquer

etapa do processo de desenvolvimento, pois esta abordagem não está restrita apenas ao código produzido. Podemos afirmar que a reutilização está associada

a qualquer artefato que foi especificado, projetado, implementado e avaliado para reuso.

Podemos então generalizar a utilização desta abordagem para os processos de

implementação. Certamente, não podemos afirmar que a reutilização sempre oferecerá

benefícios. Se os artefatos foram desenvolvidos para reutilização, a probabilidade de a

implementação ser bem sucedida é maior.

Por outro lado, desenvolver software sem um suporte adequado da reutilização

pode significar que muitas partes são redundantes. Uma modificação em uma

funcionalidade que se repete em uma quantidade significativa de artefatos pode

significar um aumento no custo de implementação e teste, e, ao mesmo tempo, uma

redução na confiabilidade desses artefatos. Mais ainda, como resultado, o tempo para

a liberação de um módulo pode ser maior.

Considere, por exemplo, um módulo que verifica os pré-requisitos das disciplinas

de um determinado curso. Este módulo é reutilizado em dois módulos diferentes. São

eles: o módulo de matrícula e o de exclusão de disciplina do curso. Uma alteração no

sistema de pré-requisitos requer apenas que o módulo correspondente seja modificado.

Esta alteração irá refletir em ambos os módulos que o reutilizam. Caso contrário, a

mesma modificação deveria ser replicada para os dois módulos.

Módulo de pré-requisitos Módulo de exclusão de disciplinas Módulo de matrícula
Módulo de pré-requisitos
Módulo de exclusão
de disciplinas
Módulo de
matrícula

Figura 5.2: Relação entre alguns módulos de um sistema de administração escolar

37

EADDCC032 – Fundamentos de Engenharia de Software

Em relação à tecnologia utilizada para apoiar a reutilização, podemos afirmar que a programação orientada a objetos contribui significativamente para a adoção desta abordagem na etapa de implementação. Entretanto, o reuso não depende desta tecnologia. A adoção de reuso poderá ser mais difícil, mas ela não está associada a uma tecnologia específica.

Se a modificação de um determinado artefato é necessária para decidirmos pela adoção de reuso para a implementação, cabe avaliarmos os efeitos que esta atividade trará para o projeto como um todo. Nem sempre a adoção de reúso pode ser vantajosa. Necessitamos, portanto de formas para julgarmos se as funcionalidades disponíveis em um determinado módulo são adequadas para a implementação de um novo artefato. Reuso está associado às ideias e conceitos utilizados para a implementação de um artefato e, portanto, necessitamos de mecanismos para documentar este artefato para que ele possa, posteriormente, ser reutilizado.

5.3 Gerenciamento de Configuração

Finalizadas as atividades de implementação, mudanças poderão ocorrer a qualquer momento. Elas decorrem não apenas do surgimento de novos requisitos, mas também de alterações naqueles já existentes.

Pesquise : por que mudanças ocorrem nos sistemas que já estão em produção?

Pesquise: por que mudanças ocorrem nos sistemas que já estão em produção?

A partir do momento em que as alterações foram aprovadas e o processo de modificação inicia, problemas podem ocorrer. Por exemplo, um módulo foi alterado, testado e disponibilizado (Módulo matrícula (1) – Figura xx). Posteriormente, a alteração pode ser desfeita por falta de informações, tais como: por que foi feita? (Módulo matrícula (2) – Figura xx). Mais ainda, ela não foi desfeita, porém a versão incorreta foi utilizada para ser integrada ao sistema.

38

EADDCC032 – Fundamentos de Engenharia de Software

EADDCC032 – Fundamentos de Engenharia de Software Figura 5.3: Módulo com alteração desfeita pelo Desenvolvedor 2

Figura 5.3: Módulo com alteração desfeita pelo Desenvolvedor 2

Gerenciamento de Configuração é um processo cujo objetivo é adotar medidas e

práticas para garantir que as mudanças durante o processo de desenvolvimento serão

bem sucedidas. Isto significa que as versões corretas serão utilizadas, bem como

informações relacionadas ao processo de mudança estarão disponíveis, tais como: (i)

quem alterou?; (ii) por que alterou?; (iii) quem solicitou? (iv) por que solicitou? , dentre

outras. Associadas a essas mudanças podemos mencionar as atividades que delas

decorrem, tais como: integração dos componentes, e compilação dos módulos de

acordo com a configuração desejada. Por exemplo: considere um sistema de

administração escolar com os seguintes módulos: matrícula, pagamento, e inclusão de

disciplinas. Suponha que dois desenvolvedores estejam alterando dois módulos

distintos: matrícula e pagamento (Figura xx – (1)), mas não têm o suporte de um

sistema de gerência de configuração. Ao término das modificações, versões erradas

podem ser integradas (Figura xx – (2) e (3)), alterações realizadas no módulo de

matrícula também podem deixar de funcionar.

no módulo de matrícula também podem deixar de funcionar. Figura 5.4: Alterações em módulos distintos: problemas

Figura 5.4: Alterações em módulos distintos: problemas de integração de módulos

Duas atividades são frequentemente mencionadas na literatura ao abordar o

gerenciamento de configuração: gerenciamento de versões e integração de módulos

39

EADDCC032 – Fundamentos de Engenharia de Software

que compõem o sistema. Sommerville (2011) acrescenta o rastreamento de problemas

como outra atividade básica para o gerenciamento de configuração. Esta última trata

das sinalizações de desenvolvedores que estão trabalhando em um determinado

módulo para identificar um problema específico. No exemplo anterior do sistema de

administração escolar o desenvolvedor do módulo de matrícula poderia ser informado

sobre a alteração que está em andamento tanto no mesmo módulo, quanto em outro

módulo que se relaciona a este. Como resultado, um sistema de gerenciamento de

configuração poderia adotar diferentes políticas para tratar esta situação. Por exemplo:

não permitir que dois desenvolvedores modifiquem o mesmo módulo ao mesmo tempo,

permitir que eles alterem o mesmo módulo ao mesmo tempo, porém ao gravar o

módulo o desenvolvedor seria informação que o módulo está sendo alterado por outro

e permitiria que eles interagissem para resolver um possível impasse.

Pesquise outras políticas de gerência de configuração diferentes daquelas que foram apresentadas no corpo do

Pesquise outras políticas de gerência de configuração diferentes daquelas que foram apresentadas no corpo do texto.

Portanto, podemos considerar que a gerência de configuração está relacionada

ao controle de versões de módulos que foram geradas em decorrência de solicitações

de mudanças, de correções identificadas posteriormente à entrega do sistema, de

defeitos identificados a qualquer momento, ou então de alterações no hardware que

podem exigir também mudanças na implementação. Sem um sistema de gerência de

configuração esforços podem sem desperdiçados a partir do momento em que um

desenvolvedor altera uma versão equivocada. Mais ainda, podem gerar retrabalho e,

como consequência, aumentar os custos, gerar atrasos e reduzir a qualidade do

sistema.

As atividades de gerência de configuração (GC) não estão associadas apenas à etapa de implementação

As atividades de gerência de configuração (GC) não estão associadas apenas à etapa de implementação e aos artefatos produzidos nesta etapa. GC deve ser utilizada em todas as etapas do processo de desenvolvimento de software. Desde a Engenharia de Requisitos até a Implantação do sistema, passando pela Gerência de Qualidade.

40

EADDCC032 – Fundamentos de Engenharia de Software

Além de apoiar o processo de mudança oferecendo informações relativas às diferentes versões produzidas, podemos encontrar também dentre as atividades de GC procedimentos para registrar e processar as mudanças. São esses procedimentos que nos apoiarão, por exemplo, nas análises das viabilidades de mudanças. Através desses registros poderemos encontrar informações tais como: por que a mudança foi realizada, quais os requisitos que estão associados a ela, quantas vezes ela foi solicitada, dentre outras informações.

Se um mecanismo eficiente para gerenciar a configuração durante a implementação de um módulo, problemas relacionados à qualidade podem surgir em decorrência, por exemplo, da não utilização de um padrão estabelecido, ou então pela liberação de um artefato equivocado para a equipe de qualidade. Podemos afirmar, portanto, que as atividades de Gerência de Configuração estão fortemente relacionadas à Gerência de Qualidade.

A gerência de configuração não está associada apenas ao controle de versões resultantes de modificações durante o processo de implementação. Ela está associada também ao gerenciamento de diferentes versões em decorrência da liberação do produto para diferentes plataformas de hardware e software. Por exemplo, sistemas operacionais diferentes que são utilizados por clientes distintos que necessitam adquirir o produto, ou então em função de requisitos específicos de determinados clientes que necessitam ser gerenciados.

de determinados clientes que necessitam ser gerenciados. Figura 5.5: Exemplo de gerência de configuração entre

Figura 5.5: Exemplo de gerência de configuração entre plataformas distintas

Os gerentes de configuração necessitam manter o controle das diferenças entre as versões produzidas e liberá-las corretamente para clientes específicos. Esses clientes podem utilizar sistemas operacionais diversificados e, portanto, necessitam de

41

EADDCC032 – Fundamentos de Engenharia de Software

configurações também específicas para as suas necessidades. Por exemplo, para as

versões que utilizam o sistema operacional Windows foi disponibilizado o módulo que

permite realizar matrículas através de dispositivos móveis. Portanto, há necessidade de

liberar este módulo apenas para os clientes que utilizam a plataforma Windows.

Exercícios Resolvidos:

(1) Considerando a produtividade e a confiabilidade, por que podemos afirmar que a abordagem de reutilização oferece benefícios para as atividades de implementação?

Resposta: Em relação à produtividade podemos afirmar que uma quantidade reduzida de código será construída, ao mesmo tempo em que podemos utilizar códigos já amplamente avaliados (confiabilidade).

(2) Suponha que versões incorretas de módulos foram utilizadas e, mesmo assim, o sistema continua executando sem indicar erros. Por que isso é possível? Quais as consequências de se utilizar versões incorretas de um módulo para compor um sistema?

Resposta: Módulos com versões que não pertencem a uma mesma versão do sistema podem executar sem apresentar erro, entretanto, as funcionalidades não estão de acordo com os requisitos especificados. Frequentemente, não é uma atividade fácil a identificação desse tipo de erro. Como resultado, inconsistências poderão ser geradas afetando o banco de dados do sistema.

poderão ser geradas afetando o banco de dados do sistema. Exercícios (1) Por que é vantajosa

Exercícios

(1) Por que é vantajosa a utilização de IDE para apoiar a implementação de um artefato?

(2) Quais os fatores não técnicos que podem significar obstáculaos para adoção de reúso para as atividades de implementação?

(3) Além das IDE exemplificadas no corpo do texto, pesquise outras que estão disponíveis para utilização.

(4) Compare as funcionalidades de duas IDE disponíveis para utilização.

42

EADDCC032 – Fundamentos de Engenharia de Software

(5) Considerando a qualidade e o custo, por que podemos afirmar que a abordagem de reutilização oferece benefícios para as atividades de implementação?

(6) Identifique, pelo menos, dois riscos para as atividades de implementação que podem surgir com a adoção de reúso.

(7) Além da possibilidade de controlar as versões que estão sendo geradas, por que gerenciar a configuração de um sistema durante a implementação?

(8) A rastreabilidade está associada à associação de diferentes artefatos no processo de desenvolvimento de software. Por que um suporte à rastreabilidade é importante durante o processo de implementação? De que forma um sistema de gerência de configuração pode apoiar a rastreabilidade?

(9) De que forma a gerência de configuração dos artefatos produzidos nas etapas de Engenharia de Requisitos e Projeto podem afetar os módulos produzidos na etapa de Implementação?

(10) Uma função da gerência de configuração é controlar sistematicamente

as

mudanças do software. Para tal, torna-se necessário uma ferramenta

para apoiar o controle de versões. Cite pelo menos três funcionalidades dessa ferramenta.

43

EADDCC032 – Fundamentos de Engenharia de Software

6. Teste de Software

Este capítulo tem como objetivo discutir sobre a importância dos processos de teste de software, bem como sobre os artefatos produzidos nesta etapa. Adicionalmente, apresenta os conceitos relacionados a teste de software, de uma forma geral, evidenciando as atividades de verificação e validação.Fundamentos de Engenharia de Software 6. Teste de Software 6.1 Introdução Muitas vezes nos depararmos com

6.1

Introdução

Muitas vezes nos depararmos com a seguinte pergunta: “se o software é construído considerando as metodologias, os processos e as ferramentas, por que ainda encontramos tantos erros nos produtos?” Erros e defeitos em software podem acarretar falhas na execução do código, acarretar uma insatisfação do usuário e gerar custos altíssimos para a reparação. Nosso dia a dia está cada vez mais dependente dos softwares. Eles podem ser encontrados em toda a parte. Portanto, a cada dia percebemos que não mais espaço para sistemas com baixa qualidade.

A qualidade está relacionada a diversos fatores, tais como: o produto desenvolvido não realiza as funções de acordo com o que foi especificado, ou realiza as funcionalidades que não foram especificadas. Mais ainda, muitas vezes não encontramos uma funcionalidade na especificação do sistema, mas que deveria ser definida. Outros problemas se relacionam indiretamente com os erros e defeitos. São eles: não existe um cuidado na construção dos artefatos e eles acabam sendo de difícil compreensão.

Mas, por que um erro ou defeito de software ocorre? Diferentes razões podem acarretar em um erro ou defeito, mas frequentemente elas estão relacionadas a especificações erradas ou imprecisas. Portanto, podemos deduzir que um erro na especificação pode “se arrastar” durante todo o processo de desenvolvimento, e, como resultado, o custo para identificarmos e corrigir certamente será maior. Por quê?

Quanto mais cedo identificarmos e corrigirmos um erro, maior será a probabilidade de construirmos software

Quanto mais cedo identificarmos e corrigirmos um erro, maior será a probabilidade de construirmos software com qualidade.

44

EADDCC032 – Fundamentos de Engenharia de Software

Um erro ou defeito também pode estar relacionado ao processo de desenvolvimento, ou até mesmo à qualificação da mão de obra envolvida neste processo que pode gerar artefatos equivocados. Por exemplo, um erro em um modelo pode gerar sérios problemas que são difíceis de serem identificados.

Mesmo que todos os possíveis caminhos em um programa sejam testados, não podemos garantir que ele estará correto e que nenhuma falha ocorrerá a partir deste momento. Isto se relaciona ao fato de que não podemos garantir que todos os possíveis dados (entradas e saídas) foram avaliados. Mesmo que tivéssemos todas as entradas e saídas conhecidas elas podem ser inúmeras tornando inviável o processo de teste, por exemplo, como poderíamos testar todas as entradas e saídas de uma calculadora? Outro motivo está relacionado à forma pela qual as especificações são construídas, gerando muita imprecisão e ambiguidade. Portanto, não podemos garantir que em um software nunca encontraremos uma falha ou defeito. Uma forma de reduzir esta probabilidade é utilizar diferentes formas de verificação e validação nas etapas do processo de desenvolvimento.

6.2 Verificação e Validação

sua

especificação, se os diferentes artefatos estão de acordo com a sua especificação. Já,

através das formas de validação buscamos ter a certeza de que todas as funcionalidades esperadas foram implementadas. Se o produto corresponde às expectativas do usuário, não apenas realizando todas as funcionalidades, mas resolvendo o problema que foi definido no momento da especificação.

As

formas

de

verificação

buscam

garantir

que

o

programa atende

a

Frequentemente alguns autores relacionam as formas de verificação a uma busca constante à seguinte pergunta: estamos desenvolvendo o software corretamente? Já as formas de validação se associam às respostas à seguinte pergunta: estamos desenvolvendo o software correto? Os processos de verificação e validação (V&V) ocorrem, portanto, nas diferentes etapas do desenvolvimento do software. Por exemplo, podemos desenvolver um sistema de administração escolar para o qual o documento de requisitos foi desenvolvido, supostamente, de acordo com as necessidades dos usuários. Desta forma, as outras etapas ocorreram conforme previstas pelo modelo de processo adotado. São elas: projeto (design), implementação

45

EADDCC032 – Fundamentos de Engenharia de Software

e testes. Além disso, todas as revisões foram feitas nos artefatos, conforme previsto. Entretanto, o sistema não foi aprovado pelos usuários, ou seja, as funcionalidades esperadas não foram adequadamente implementadas. O sistema, portanto, não foi validado e necessita de correções.

Em relação ao processo de desenvolvimento, quanto mais cedo os erros e defeitos forem identificados, menor o esforço para resolvê-los. Requisitos devem ser validados no sentido de identificar erros, omissões, ambiguidades e inconsistências. No momento da validação dos requisitos eles serão revistos e através dos casos de testes verifica-se se eles são capazes de serem testáveis.

Percebemos, então que a Verificação e a Validação são abordagens que se complementam. Ao utilizarmos as técnicas de V&V estáticas (inspeções e revisões) defeitos podem ser identificados agilizando o processo de desenvolvimento e aumentando a qualidade dos artefatos. Entretanto, as técnicas estáticas não são capazes de avaliar se o software cumpre todas as necessidades do usuário em relação aos processos operacionais. Ou seja, o software atende às especificações, mas não apoia os processos operacionais conforme as necessidades dea organização. Mais ainda, essas técnicas não são capazes de avaliar aspectos como desempenho, escalabilidade, portabilidade, entre outros requisitos não funcionais.

Já os testes de software estão relacionados às técnicas dinâmicas, através das quais as implementações são avaliadas com a utilização de dados de teste. Estão relacionados à execução do programa, e seus diferentes caminhos, no sentido de identificar os defeitos considerando-se os dados de entrada e saída. A partir dos resultados, anomalias são identificadas e os códigos dos diferentes caminhos são corrigidos. São denominados na literatura de testes funcionais.

6.3 Testes Unitários

Outro tipo de teste que devemos realizar em um sistema durante a etapa de implementação diz respeito aos elementos utilizados. Por exemplo, métodos ou funções devem ser testados considerando-se as diferentes chamads realizadas e os parâmetros utilizados.

46

EADDCC032 – Fundamentos de Engenharia de Software

Ao projetarmos os testes unitários devemos ter certeza de que todos os possíveis

caminhos foram exercitados e que não existem erros em relação à entrada e saída dos

dados esperados. Portanto, todos os valores prováveis dos atributos associados, por

exemplo, a um objeto específico devem ser conhecidos. Adicionalmente, todos os

possíveis estados do objeto também devem ser exercitados com os dados de entrada e

observando as saídas esperadas.

Mas, se considerarmos todos os estados, e as suas possíveis combinações, não

podemos elevar os custos de testes e, como resultado os custos de desenvolvimento?

Certamente, isso é possível. Portanto, devemos selecionar aqueles casos de teste que

nos fornecerão resultados satisfatórios, tanto no que diz respeito às funcionalidades

bem sucedidas, como naquelas que possuem defeitos. Um caso de teste está

relacionado á avaliação de uma funcionalidade específica, por exemplo, “uma tentativa

de matricular um aluno não cadastrado”.

6.4 Testes de Sistema

Esses testes estão relacionados à integração dos componentes. Neste momento,

todos os componentes são avaliados considerando-as suas interfaces e o

comportamento esperados por eles a partir do momento em que são integrados. Não é

uma atividade trivial, e necessita de uma estratégia para que possam ser integrados.

Por exemplo, o acréscimo de um módulo de cadastro de disciplinas, já devidamente

testado, pode levar à identificação de defeitos em outros módulos, tais como, os

módulos de cadastro de alunos e/ou de matrícula.

Exercícios Resolvidos:

(1) Suponha que um determinado sistema seja desenvolvido de acordo com os conceitos do paradigma de orientação a objetos. Assim sendo, os testes funcionais, ou de caixa preta, parecem adequados. Comente esta afirmação.

Resposta: Os testes funcionais, ou de caixa preta, não são suficientes para que todos os caminhos sejam testados. Nos sistemas que implementam o paradigma de Orientação a Objetos é difícil prever todas as combinações de eventos, entradas e saídas, que permitem que os objetos se comuniquem.

47

EADDCC032 – Fundamentos de Engenharia de Software

(2) Testes de software podem ser caros e demorados, tendo em vista a quantidade de testes a serem realizados. Além disso, nem todos os defeitos podem ser detectados. De que forma as revisões e inspeções podem auxiliar no processo de teste de software?

Resposta: A afirmação está correta. Os testes podem ser caros e demorados principalmente quando tratamos de sistemas complexos. Mais ainda, não podemos garantir que todos os defeitos sejam detectados, considerando-se, sobretudo, todos os possíveis conjuntos de dados, e as suas combinações que deveriam ser testados. As inspeções e revisões poderiam reduzir as incertezas de forma que os erros poderiam ser identificados em etapas anteriores aos testes, como também não permitir que os erros sejam propagados para as etapas seguintes do processo de desenvolvimento de software.

Exercícios (1) De que forma a compreensão inadequada dos artefatos pode acarretar erros e defeitos?

Exercícios

(1) De que forma a compreensão inadequada dos artefatos pode acarretar erros e defeitos?

(2) Suponha que um defeito foi identificado e devidamente corrigido. Por que devemos repetir os testes associados ao elemento após o reparo do defeito?

(3) Considere um sistema de administração escolar e apresente, pelo menos, três casos de testes hipotéticos para os seguintes módulos: (i) módulo de matrícula, (ii) módulo de cadastro de aluno, e (iii) módulo de cadastro de disciplina.

(4) Suponha que o sistema especificado em sala de aula será desenvolvido de acordo com os conceitos de orientação a objetos. Assim sendo, os testes de caixa preta, ou funcionais, parecem ser adequados. Comente esta afirmação e utilize exemplos para ilustrar a utilização desta abordagem.

(5) Testes de software podem ser caros e demorados, tendo em vista a quantidade de avaliações a serem realizadas. Além disso, nem todos os defeitos podem ser detectados. Comente essa afirmação e apresente as formas pelas quais as revisões podem auxiliar no processo de teste de software.

(6) Como podemos planejar um teste em um processo de desenvolvimento que adota o RUP?

48

EADDCC032 – Fundamentos de Engenharia de Software

7. Manutenção e Evolução de Software

Este capítulo tem como objetivo apresentar os conceitos de manutenção e evolução de software buscando

Este capítulo tem como objetivo apresentar os conceitos de manutenção e evolução de software buscando ressaltar a importância dessas atividades para a engenharia de software. Ao término deste capítulo, o leitor será capaz de compreender os processos de evolução e por que as mudanças acontecem durante o ciclo de vida do software.

7.1

Introdução

Até o momento vimos os aspectos relacionados ao desenvolvimento de software, incluindo os diferentes processos e os contextos nos quais eles poderão ser utilizados. Posteriormente ao término do desenvolvimento, a entrega do produto ao cliente, e a sua colocação em operação, parece que nenhuma atividade será feita, não é mesmo? Pois não é desta forma que sempre acontece em relação ao software. Começam agora as atividades de manutenção e evolução do produto. Algumas modificações ocorrem para corrigir erros que não foram detectados no momento que deveriam, por exemplo, nas atividades de verificação e validação. Outras modificações acontecem para otimizar alguns requisitos não funcionais, tais como desempenho, portabilidade, escalabilidade, entre outros.

Então, se nada disso acontecer parece que não precisamos modificar o produto. Podemos considerar isso como verdadeiro?

Isso seria verdade se as condições que afetam os requisitos funcionais não alterassem, ou seja, se o contexto no qual o produto executa não modificasse. Dentre as condições que afetam o contexto podemos citar: as regras de negócio, o mercado, as legislações que apoiam o mercado, o surgimento de novos requisitos funcionais, que por sua vez podem demandar alterações nos requisitos não funcionais, as imposições de modificações no orçamento que demandam alterações no cronograma, entre outras.

Mas, dependendo do tempo em que o produto foi desenvolvido, não poderia ser melhor refazer todo o projeto? Às vezes isto pode acontecer, mas é uma decisão difícil de ser tomada levando-se em consideração a importância e o valor que o sistema legado representa para a organização. Os funcionários já foram treinados, o

49

EADDCC032 – Fundamentos de Engenharia de Software

conhecimento adquirido por eles em relação às tecnologias envolvidas, entre outros aspectos que justificam a continuidade do sistema e a sua manutenção.

Mudanças devem acontecer e necessitamos implementar um processo para gerenciá-las. Ao realizar as alterações uma quantidade significativa de versões pode ser gerada e, essas versões precisam ser controladas, sem haver interrupções nos processos organizacionais. Sobre este aspecto já tratamos no Capítulo que discute a etapa de Implementação. Cabe à Gerência de Configuração tratar dos aspectos decorrentes do processo de manutenção de software.

Existem diversos tipos de manutenções, mas no contexto desta disciplina vamos nos basear nos três tipos descritos por Sommerville (2011). São eles: (i) a manutenção corretiva, cujo objetivo é consertar os defeitos no software; (ii) a manutenção adaptativa que busca adaptar o software, por exemplo, a ambientes que utilizam outros sistemas operacionais, outros requisitos que surgiram em decorrência desta necessidade, ou então, outros aplicativos que irão interagir com o software; e (iii) a manutenção evolutiva, cujo objetivo é acrescentar novos requisitos funcionais ao sistema para que ele atenda à necessidades dos usuários ou dos novos processos que surgiram.

Diante dos diferentes tipos apresentados podemos concluir que devemos estar preparados para as modificações do software, pois grande parte dos sistemas irá evoluir. Caso contrário, a execução do processo automatizado por esses sistemas poderá ser interrompida. Devemos, portanto, investir esforços no sentido de utilizar boas práticas de desenvolvimento de software buscando reduzir os custos de manutenção. Quando falamos de boas práticas estamos nos referindo a um vasto conjunto de atividades que contribuem para a qualidade dos artefatos que serão produzidos. Por exemplo, documento de requisitos contendo especificações claras, precisas e completas, projetos arquiteturais que contemplem as características não funcionais e os princípios de projeto prioritários, código aderente aos padrões previamente definidos, entre outras práticas.

Pesquisas em Engenharia de Software têm demonstrado que, mesmo que as boas práticas demandem um

Pesquisas em Engenharia de Software têm demonstrado que, mesmo que as boas práticas demandem um custo adicional, este custo é menor do que os custos adicionais, em manutenção.

50

EADDCC032 – Fundamentos de Engenharia de Software

7.2 Transformação de Arquitetura

Muitas vezes a arquitetura do software necessita ser modificada, por exemplo, de uma arquitetura centralizada para distribuída. Essa modificação pode ser decorrente de alguns fatores, tais como (SOMMERVILLE, 2009): (i) sistemas distribuídos oferecem um custo menor para desenvolvimento; (ii) as interfaces gráficas oferecidas podem promover as interações em diferentes locais; e (iii) o acesso distribuído pode viabilizar os negócios das organizações. Entretanto, migrar sistemas, que foram desenvolvidos em uma ocasião em que as tecnologias eram bem diferenciadas podem oferecer dificuldades para a transformação de arquitetura. Por exemplo, a estrutura em que eles foram projetados, em termos de componentes, pode dificultar a reorganização do sistema.

7.3

Reengenharia

Sistemas legados necessitam ser modificados e, para tanto, é fundamental que eles possuam uma estrutura que facilite a sua compreensão e alteração, considerando- se tempo e custo. Muitas vezes, eles não podem ser descontinuados e, portanto, precisam passar por um processo de reengenharia. Neste processo, nenhuma funcionalidade é acrescentada ao sistema. Envolve alterações na sua estrutura com o objetivo de tornar a manutenção mais fácil.

É sempre possível fazermos reengenharia? Um dos objetivos da reengenharia é reduzir os riscos e os custos de manutenção. Entretanto, os custos dependem de uma série de fatores. Por exemplo, de pessoal qualificado para realizar as atividades de reengenharia e, das tecnologias e recursos de hardware disponíveis.

Em alguns tipos de sistema, em especial aqueles que foram desenvolvidos para web necessitam de modificações frequentes. Essas modificações decorrem de aspectos de usabilidade, de desempenho ou de algum ajuste em outros requisitos não funcionais. Mais ainda, sistemas cujos requisitos têm uma probabilidade maior de alteração e necessitam de um prazo de entrega mais rápido. Como resultado, necessitam de mudanças para adequar a estrutura e arquitetura às necessidades.

51

EADDCC032 – Fundamentos de Engenharia de Software

Exercícios Resolvidos:

(1) Considere os conceitos envolvidos na manutenção de software e cite pelo menos dois fatores, além daqueles já mencionados no texto, e justifique a adoção de cada um deles, que poderiam contribuir para a elevação dos custos das atividades de manutenção.

Resposta: Outros fatores que elevam os custos de manutenção:

Instabilidade da equipe: frequentemente há necessidade de contratações para substituir um participante. Mesmo que a contratação tenha um nível de exigência compatível com o projeto, existem riscos envolvidos em relação á adaptação do participante ao projeto.

Habilidade da equipe para conduzir o processo de manutenção considerando os padrões de qualidade estabelecidos pela empresa.

(2) Considere a necessidade de acrescentar funcionalidades depois que um sistema estiver em operação. Por que os custos de manutenção podem ser altos?

Resposta: Alguns fatores podem contribuir para que o custo de manutenção deste sistema seja alto. São eles:

A equipe que desenvolveu o sistema já foi desfeita e o conhecimento não foi adequadamente armazenado.

A documentação não foi devidamente realizada considerando o relacionamento entre os artefatos produzidos nas diferentes etapas do processo de desenvolvimento.

Não existem ferramentas adequadas para o projeto das novas funcionalidades, nem mesmo mão de obra especializada.

Exercícios (1) Cite os tipos de manutenção e apresente exemplos para ilustrar a sua resposta.
Exercícios (1) Cite os tipos de manutenção e apresente exemplos para ilustrar a sua resposta.

Exercícios

(1) Cite os tipos de manutenção e apresente exemplos para ilustrar a sua resposta. (2) Qual a diferença entre transformação de arquitetura e reengenharia no contexto de manutenção de software? (3) É sempre possível realizarmos manutenções em software? Caso não seja possível, apresente situações nas quais a manutenção não seria viável. (4) Considere um sistema web cujos requisitos sofrem modificações frequentes. Diante desta situação sugira um processo de desenvolvimento e justifique a sua utilização neste contexto. (5) Considerando que um dos objetivos da reengenharia é reduzir os riscos de manutenção, apresente as formas pelas quais esses riscos podem ser reduzidos e cite exemplos para ilustrar a sua resposta. (6) Além da habilidade e estabilidade da equipe, existem outros fatores que poderiam contribuir para a redução dos custos de manutenção?

52

EADDCC032 – Fundamentos de Engenharia de Software

8. Gerência da Qualidade

Após a leitura deste capítulo você será capaz de conhecer o significado de qualidade de software, bem como a sua importância para o processo de construção de software. Além disso, saberá a relação entre o gerenciamento da qualidade e o processo de desenvolvimento de software. Para tanto, discutiremos as influências entre medição de produto e processo. Algumas métricas de software que poderão auxiliar na quantificação do produto serão apresentadas.de Engenharia de Software 8. Gerência da Qualidade 8.1 Introdução Ao falarmos de qualidade de software

8.1

Introdução

Ao falarmos de qualidade de software normalmente estamos preocupados em definir padrões de processos e produtos que serão decorrentes da aplicação desses padrões. Mais ainda, associados a esses padrões devemos encontrar uma vasta documentação que nos auxiliará não só na aplicação desses padrões, na sua conformidade, mas na determinação das medições mais adequadas. Normalmente denominamos de garantia de qualidade o processo de determinação de padrões, tanto de processo quanto de produtos. Já o controle de qualidade se relaciona à verificação se os padrões são aplicados.

Considerando os processos de desenvolvimento de software e o de gerenciamento de qualidade, cabe mencionar que eles não deveriam ser realizados pelo mesmo grupo, ou por pessoas que pertençam a ambos. Isto se deve ao fato de que as pessoas poderiam ser influenciadas pela verificação da conformidade dos produtos gerados nas diferentes etapas do desenvolvimento.

Não basta seguirmos padrões de processo e produtos. O gerenciamento da qualidade vai além da aderência a esta determinação.

Considerando a dificuldade em determinarmos especificações para a qualidade de software, qual o significado de qualidade?seguirmos padrões de processo e produtos. O gerenciamento da qualidade vai além da aderência a esta

53

EADDCC032 – Fundamentos de Engenharia de Software

Podemos dizer que a qualidade de software está associada à aderência do software a sua especificação. Porém, discutimos nos capítulos anteriores sobre a dificuldade de gerarmos uma especificação clara e precisa. Mais ainda, dependendo do contexto de utilização do software os requisitos podem mudar. Certamente esta dificuldade deve ser considerada no processo de construção de um sistema e no gerenciamento da qualidade.

Independente da dificuldade de avaliarmos a qualidade de software baseada nos requisitos cabe mencionarmos que devemos verificar e validar os produtos gerados nas diferentes etapas do processo de desenvolvimento. A qualidade de um produto está associada à realização dos requisitos funcionais e não funcionais. Ou seja, não basta que o sistema implemente as funcionalidades necessárias ao produto, mas que estas funcionalidades sejam atendidas em um nível mínimo de exigência dos requisitos não funcionais. Por exemplo, não basta implementarmos um componente que apresente um vídeo de uma aula em uma qualidade satisfatória se o áudio não está sincronizado em decorrência de uma exigência de desempenho que a rede local não oferece. Portanto, cabe definirmos aqueles requisitos não funcionais prioritários para os sistemas, pois jamais conseguiremos implementar um produto que tenham todos os atributos de qualidade em seu valor máximo.

Podemos então associar os padrões de processo aos padrões de produto? Os processos padronizados certamente terão uma probabilidade maior de gerar produtos com qualidade, mas não podemos garantir que basta apenas considerarmos os processos.

Padrões de

processo

apenas considerarmos os processos. Padrões de processo Padrões de produto Figura 8.1: Relação entre processo e

Padrões de

produto

Figura 8.1: Relação entre processo e produto

Mais ainda, os padrões de produtos, e as medições realizadas nesses produtos são indicadores para que melhorias contínuas no processo possam ser implementadas. O fato é que não podemos abandonar os padrões – de processo e de produto –, pois associados a eles estão representadas as melhores práticas da organização. Por exemplo, ao definirmos um padrão para o documento de requisitos representamos um formato e as informações necessárias para um determinado domínio. Além disso, não

54

EADDCC032 – Fundamentos de Engenharia de Software

deixamos de representar as informações que um determinado usuário gostaria de encontrar neste documento. Como resultado os clientes (internos) também podem adotar as mesmas práticas representadas, dando continuidade ao nível de qualidade inicialmente estabelecida.

Processo

ao nível de qualidade inicialmente estabelecida. Processo Produto Melhorias Medições Figura 8.2: Relação entre

Produto

de qualidade inicialmente estabelecida. Processo Produto Melhorias Medições Figura 8.2: Relação entre métricas

Melhorias

Medições

Figura 8.2: Relação entre métricas de processo e produto

Padrões devem ser fáceis de serem seguidos, e verificados, em termos de tempo e custo. Muitas vezes nos deparamos com situações nas quais os padrões estabelecidos levam os desenvolvedores a um desperdício de tempo e esforço para a sua realização. Como resultado, eles não são seguidos e todo o esforço para implantar um programa de qualidade pode ser perdido.

Mas, então cada organização estabelece os seus padrões? Não existe uma diretriz para que esses padrões sejam estabelecidos e seguidos? Existe sim. Ao desenvolver padrões as empresas devem se basear em determinações de organizações nacionais e internacionais. O IEEE (Institute of Electrical and Electronics Engineers) é uma organização que determina alguns padrões para o desenvolvimento de software, por exemplo, o padrão IEEE 829 para a documentação de testes de software.

Padrões de processos e de produtos estão fortemente relacionados. Ao estabelecermos um processo, que representa as melhores práticas da organização que desenvolve software, podemos avaliá-lo conforme as métricas estabelecidas. Por exemplo, o custo para a sua execução, o seu tempo de execução, entre outras. Esses processos – padronizados – podem gerar produtos também padronizados. Métricas de produtos também podem ser estabelecidas com o objetivo de determinar a sua qualidade. Por exemplo, a quantidade de defeitos encontrados em um código na realização de um teste. Ao confrontarmos os resultados das medições realizadas no processo e nos produtos resultantes da sua execução, é possível avaliarmos a efetividade deste processo, e identificarmos as suas fraquezas e forças. Como resultado, ajustes poderão ser realizados no intuito de melhorar os produtos gerados.

55

EADDCC032 – Fundamentos de Engenharia de Software

Portanto, medições podem ser utilizadas para realizar estimativas e aperfeiçoamentos no processo.

Mas, como podemos aperfeiçoar um processo? Através de atributos específicos como, por exemplo, o tempo médio para aliberação de um artefato para testes, o número de defeitos encontrados em um produto pode significar que o processo de revisão não foi adequadamente conduzido, entre outros indicadores. Entretanto, uma atividade de melhoria de processo não é tão simples quanto parece, pois nem sempre as métricas são facilmente coletadas e relacionadas às atividades de processo que conduzirão a um aperfeiçoamento. Muitas vezes os próprios analistas e desenvolvedores não entendem a necessidade de se fazer uma coleta de métricas e, naturalmente, criam uma resistência.

8.2 Garantia e Padrões de Qualidade

A relação entre processo e produto, que acabamos de discutir, está associada ao conceito de Garantia da Qualidade. De uma forma geral, ela estabelece os padrões de processo e de produto. As atividades podem ser apoiadas por ferramentas computacionais com o objetivo de auxiliar na coleta de dados e na avaliação das medições realizadas. Ao definirmos padrões de processos, portanto, buscamos garantir que os padrões de produtos serão obtidos. Cabe ao processo de garantia da qualidade verificar se esses padrões estão de acordo com as especificações. Através deste processo asseguramos que as melhores práticas da Engenharia de software serão seguidas, bem como a produtividade da equipe de desenvolvimento poderá ser acompanhada e constantemente melhorada. Como resultado, os custos do processo poderão ser reduzidos.

Mas, por que padronizar processos? Não bastaria conhecê-lo através, por exemplo, de sua modelagem em uma linguagem gráfica? Ao padronizar processos, e definir as medições efetuadas, estamos representando não apenas as melhores práticas de desenvolvimento para um contexto específico da organização, mas assegurando que todos seguirão as mesmas práticas em diferentes projetos. Mais ainda, que as atividades relacionadas a todos os projetos poderão ser acompanhadas por um conjunto de medições, evitando assim a repetição de erros em novos projetos. Entretanto, não basta apenas representar um processo através de uma linguagem

56

EADDCC032 – Fundamentos de Engenharia de Software

gráfica. O gerenciamento da qualidade vai além da definição de padrões de processo e produto, como veremos a seguir.

Exemplos de padrões de processos podem ser encontrados em http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/

Exemplos de padrões de processos podem ser encontrados em

http://demoiselle.sourceforge.net/process/ds/1.2.3-BETA1/

O gerenciamento da qualidade envolve a definição de padrões de processo e de produto, bem como o acompanhamento contínuo dos processos de desenvolvimento. Através deste acompanhamento, métricas são estabelecidas e resultados são analisados buscando uma melhoria contínua em busca da qualidade dos produtos. Os resultados são relatados para a gerência e para os clientes (Sommerville, 2011).

8.3 Planejamento de Qualidade

O planejamento da qualidade envolve as atividades que têm por objetivo definir um plano de qualidade que contemple as qualidades para o produto, bem como a forma pela qual elas serão avaliadas. Mas, o que é “qualidade”? Diz respeito aos atributos prioritários para um projeto específico, aqueles que têm uma importância para o contexto no qual ele será aplicado. Portanto, se o contexto modifica então cada plano deve selecionar processos específicos, bem como atributos e a forma pela qual eles serão avaliados. Dentre esses atributos cabe mencionar: segurança, eficiência, escalabilidade, entre outros.

Garantia de

Garantia de Planejamento da Controle de

Planejamento da

Garantia de Planejamento da Controle de

Controle de

Qualidade

Qualidade

Qualidade

Definição de padrões de processo e de produto

Definição de padrões

Verificação da

de processo e de

aderência aos

produto

padrões

Figura 8.3: Etapas da gerência da qualidade

57

EADDCC032 – Fundamentos de Engenharia de Software

8.4 Controle de Qualidade

Envolve os processos de verificação de que os padrões estão sendo utilizados.

Uma maneira de verificarmos se os artefatos gerados durante o processo de

desenvolvimento estão aderentes aos padrões definidos é através de revisões e

inspeções de software. O processo de revisão envolve as atividades que tem por

objetivo descobrir erros, falhas e omissões em relação aos padrões definidos. Com

isso, diferentes artefatos podem estar envolvidos neste processo, tais como:

documentos de especificação, artefatos de projeto, códigos, planos de teste, entre

outros. Ao se descobrir alguma não conformidade decisões podem ser tomadas e

melhorias definidas buscando-se aprimorar a qualidade dos produtos.

As atividades de inspeções buscam identificar erros e defeitos nos programas.

Envolvem atividades tais como, identificação de variáveis não adequadamente

nomeadas e inicializadas, parâmetros que estão indevidamente utilizados e fora de

ordem. Enfim, ao buscar não conformidades, as atividades de inspeções procuram

antecipar a identificação de erros que só poderiam ser identificados posteriormente nos

testes. Como resultado, muitos defeitos são descobertos mais cedo promovendo

ajustes e melhorias que comprometeriam a qualidade se descobertos apenas na etapa

de testes unitários ou de integração, por exemplo.

Pesquise outros tipos de inspeções que poderiam ser realizadas em um processo de garantia de

Pesquise outros tipos de inspeções que poderiam ser realizadas em um processo de garantia de qualidade.

8.5 Melhoria de Processos

Mesmo que os processos sejam padronizados há necessidade de evoluí-los e

modificá-los para atender as exigências e forças de mercado para que o produto

continue competitivo. Evoluir um processo significa melhorá-lo de acordo com o

contexto (tecnológico, organizacional, entre outros tipos) e as prioridades da empresa

que desenvolve software. Para tanto, é necessário, inicialmente, compreendê-lo para

que as atividades, recursos, e produtos possam ser modificados em direção à

qualidade, à produtividade e aos baixos custos.

58

EADDCC032 – Fundamentos de Engenharia de Software

Anteriormente discutimos a relação produto e processo buscando apresentar a

relação entre esses dois fatores. Entretanto, não podemos transpor os efeitos desta

relação, que existe na indústria de manufatura, para a produção de software. Ao

falarmos de software, estamos nos referindo a um produto intangível. Não construímos

software da mesma forma que desenvolvemos um produto na indústria de manufatura.

Existem, portanto, outros fatores que interferem diretamente na produção de software.

São eles: a tecnologia envolvida, os recursos humanos disponíveis, os custos e o

cronograma para liberá-lo, entre outros.

os custos e o cronograma para liberá-lo, entre outros. Figura 8.4: Exemplo de fatores que influenciam

Figura 8.4: Exemplo de fatores que influenciam a gerência da qualidade

Em alguns projetos, um fator terá um peso maior do que outro. Por exemplo, para

um projeto pequeno, com uma equipe reduzida, um processo bem definido não é

garantia de qualidade de produto. Neste contexto, a habilidade, a experiência e o

conhecimento técnico da equipe pode ter um efeito maior nos resultados (Sommerville,

2011).

Pesquise por que, em projetos grandes, que envolvem uma quantidade significativa de módulos, nos quais

Pesquise por que, em projetos grandes, que envolvem uma quantidade significativa de módulos, nos quais as equipe estão geograficamente distribuídas, o processo é um fator importante para a qualidade dos artefatos de software?

Mas, qual o significado de “melhoria de processo”? É muito simples dizermos que

um processo precisa ser melhorado. Entretanto, necessitamos de uma teoria que apoie

as atividades necessárias para que possamos obter resultados satisfatórios. Por

59

EADDCC032 – Fundamentos de Engenharia de Software

exemplo, precisamos identificar que o processo não está adequado, ao mesmo tempo, necessitamos analisar as informações obtidas e tomar as devidas ações para modificar o processo.

Portanto, não existe um processo padrão de desenvolvimento de software que possa ser reutilizado em diferentes processos, nem mesmo existem regras que possam nortear a modelagem de um processo que gere artefatos com qualidade. Existem sim, boas práticas de desenvolvimento de projeto e de programação que podem ser adaptadas às organizações e aos tipos de projeto. Além dos tipos de projeto, do seu tamanho, cada organização tem as suas características que muitas vezes impedem utilizar um processo complexo. Mesmo se uma pequena empresa desenvolvesse o mesmo tipo de software, os processos devem ser adaptados aos diferentes contextos envolvidos.

As atividades de Melhoria de Processos estão relacionadas às definições dos atributos que nortearão os esforços e os recursos necessários. Processos possuem alguns atributos, tais como (Sommerville, 2011): capacidade de compreensão, aderência aos padrões, confiabilidade em relação aos erros que podem influenciar a qualidade do produto, capacidade do processo evoluir, agilidade para entregar um produto, entre outros. De uma forma geral, ao identificarmos as melhorias dos processos estamos relacionando as métricas associados aos seus atributos. Em seguida, com base nos resultados obtidos análises são realizadas e modificações são implementadas nos processos com o intuito de otimizar as suas características prioritárias.

Não é possível tratar de todos os atributos no sentido de otimizá-los. Portanto, é fundamental definirmos aqueles que são prioritários para um determinado contexto. A articulação entre eles também é um desafio que necessita ser devidamente compreendida e tratada.

Podemos então, concluir que as atividades de melhoria de processos envolvem a medição dos atributos – prioritários para a organização –, e a avaliação do processo tendo como base os atributos obtidos. A partir da atividade de análise, as fraquezas são identificadas e as mudanças são implementadas. Suponha, por exemplo, que em um processo de desenvolvimento, a agilidade para a conclusão do processo e a entrega do sistema seja um atributo prioritário. Esta prioridade foi identificada

60

EADDCC032 – Fundamentos de Engenharia de Software

considerando-se os elementos de contexto no qual o projeto está inserido, tais como, as exigências do mercado e dos clientes. Diante disto, algumas medidas foram realizadas e os resultados obtidos conduziram os gerentes a adotarem ações para melhorar o processo de implementação com o objetivo de acelerar as entregas dos artefatos.

8.5.1. Modelos para Melhorias de Processos

Existem diferentes modelos para avaliar a maturidade dos processos das organizações que desenvolvem software. O Instituto de Engenharia de Software (SEI - Software Engeneering Institute) é uma organização que estabeleceu modelos para avaliar esta maturidade. O CMMI (Capability Maturity Model Integration) é um exemplo de modelo cujo objetivo é integrar outros modelos de maturidade. Possui duas instâncias. São elas: por estágio e contínua. A primeira é compatível com o modelo anterior ao CMMI, cujos níveis variam de 1 a 5 (Inicial, Repetitivo, Definido, Gerenciado, e Otimizado). Cada nível oferece algumas áreas chave do processo que permitem o acompanhamento da maturidade em termos de atividades realizadas. Por exemplo, no nível 2, de uma forma geral, o foco está na verificação da repetição contínua de tarefas. Para tanto, são analisadas as seguintes áreas chave de processo:

Gerenciamento de requisitos, Planejamento de projetos de software, Supervisão e rastreamento do projeto de software, Gerenciamento de subcontratação, Garantia da qualidade, e Gerenciamento de configuração.

A segunda instância do CMMI – contínua – oferece um nível de detalhamento maior entre as áreas de processo. Desta forma, 22 áreas com uma escala associada de 0 a 5. Essas áreas são distribuídas entre as seguintes categorias: gerenciamento de processos (5 áreas de processo), gerenciamento de projetos (6 áreas de processo), engenharia (6 áreas de processo), suporte (5 áreas de processo). Por exemplo, para a categoria Engenharia são definidas as seguintes áreas de processo: gerenciamento de requisitos, desenvolvimento de requisitos, solução técnica, integração de produto, verificação, e validação.

61

EADDCC032 – Fundamentos de Engenharia de Software

Outras áreas de processo, bem como uma descrição mais detalhada sobre cada uma delas pode ser encontrada em http://www.sei.cmu.edu/EADDCC032 – Fundamentos de Engenharia de Software O MPS-BR (Melhoria de Processo do Software Brasileiro) é

O MPS-BR (Melhoria de Processo do Software Brasileiro) é um modelo para

avaliar a qualidade dos processos de empressas brasileiras. È dividido em 7 níveis, e,

para cada nível, é atribuído um perfil de processos.

Uma descrição mais detalhada sobre o Modelo de Melhoria de Processo do Software Brasileiro, bem

Uma descrição mais detalhada sobre o Modelo de Melhoria de Processo do Software Brasileiro, bem como os manuais e guias que descrevem as atividades recomendadas podem ser encontrados em http:

www.softex.br/mpsbr/.

Em relação ao MPS-BR, podemos afirmar que ele permite uma implementação

gradual em empresas de pequeno e médio porte.

Exercícios Resolvidos:

(1) Considerando o conceito de padrões de produto e a importância para a determinação de padrões de processo, exemplifique um padrão de um produto e relacione com um processo ressaltando a importância neste contexto.

Resposta: Padrões de comentários para uma classe no desenvolvimento orientado a objetos podem reduzir o esforço de aprendizagem para um trabalho de manutenção que deverá ser realizado posteriormente no código.

(2) O contexto no qual o processo é executado também pode influenciar a relação entre o processo e os resultados gerados. Considere, por exemplo, um processo de implementação de software e exemplifique, pelo menos, dois aspectos de contexto que poderiam alterar os resultados obtidos.

Resposta: Nem todo processo pode ter um impacto positivo nos resultados. Por exemplo: um processo de inspeção pode reduzir o esforço e custo de teste, mas, por outro lado, pode aumentar o tempo de desenvolvimento devido às reuniões.

62

EADDCC032 – Fundamentos de Engenharia de Software

Exercícios (1) Pesquise outros padrões que podem auxiliar no gerenciamento da qualidade de software. (2)

Exercícios

(1) Pesquise outros padrões que podem auxiliar no gerenciamento da qualidade de software.

(2) Cite pelo menos três tipos de inspeções e justifique a sua adoção em um processo de verificação de inspeção.

(3) Considerando os stakeholders e a característica intangível do software, por que não podemos afirmar que a qualidade está associada à verificação dos requisitos previamente especificados.

(4) Defina dois atributos de qualidade, pesquise o seu significado, e determine a forma pela qual eles serão avaliados em um plano de qualidade de software.

(5) Além dos atributos apresentados no corpo do texto, pesquise um atributo de processo e apresente a forma pela qual ele pode se relacionar com a melhoria do processo.

(6) Escolha uma etapa do processo de desenvolvimento, e um processo para a produção de um artefato. Em seguida, identifique um atributo prioritário associado ao processo e justifique a sua escolha no contexto de uma organização.

(7) O processo de gerenciamento de configuração pode ser considerado como parte do processo de gerenciamento da qualidade. De que forma tais processos se relacionam?

(8) O modelo CMMI apresenta algumas vantagens em relação ao modelo anterior (CMM). Dentre elas, podemos citar a possibilidade de integração com outros modelos, tais como: gestão de recursos humanos, aquisição de software e engenharia de sistemas. Comente esta afirmação e apresente as vantagens desta integração.

63

EADDCC032 – Fundamentos de Engenharia de Software

9. Planejamento e Gerenciamento de Software

Este capítulo tem como objetivo apresentar uma visão geral do planejamento e programação de projetos,

Este capítulo tem como objetivo apresentar uma visão geral do planejamento e programação de projetos, bem como discutir alguns apectos sobre estimativa de preço de um software no contexto de gerenciamento de projetos. Ao término deste capítulo, o leitor deve ser capaz de compreender a importância desses conceitos para a construção de software.

9.1

Introdução

Um projeto de desenvolvimento de software pode iniciar de diferentes maneiras. Dentre elas cabe citar: a necessidade de adaptar um sistema existente às novas tecnologias, a necessidade de corrigir um defeito em decorrência de mudanças inadequadas, a necessidade de evoluir as funcionalidades para atender a um determinado mercado ou cliente, ou então a necessidade de criar um novo produto.

Para tanto é necessário planejar projetos e programar as atividades para que elas aconteçam no momento previsto, considerando-se diferentes aspectos, tais como o custo, o prazo de entrega os recursos disponíveis, dentre outros. O planejamento diz respeito à divisão das atividades e à associação aos recursos necessários para o projeto. Além disso, nesta etapa cabe prever não apenas os riscos, e definir formas para mitigá-los, bem como os eventuais problemas que podem ocorrer com o objetivo de planejar as soluções. A partir de um plano de projeto, avaliações e acompanhamentos frequentes podem ser realizados com o objetivo de cumprir as metas e os cronogramas previstos.

O planejamento de projeto não acontece apenas nas etapas iniciais, mas também ao longo do seu desenvolvimento quando necessitamos rever os recursos reais que serão utilizados. Segundo Sommerville (2011), necessitamos de um plano de projetos em três etapas distintas do projeto. Inicialmente, ao propor um orçamento do projeto são previstas algumas atividades e uma estimativa é necessária para propor um custo inicial. Posteriormente, ao iniciar o projeto, as atividades, os recursos, os custos e os prazos são revistos, bem como as entregas são planejadas e acordadas entre os stakeholders. Durante o desenvolvimento do produto, cabe rever os prazos a partir do momento em que novas informações são adquiridas, e mudanças são solicitadas pelos

64

EADDCC032 – Fundamentos de Engenharia de Software

stakeholders, como resultado, negociações são necessárias e novas estimativas ocorrerão. Mais ainda, cabe rever a programação das atividades, bem como o cronograma inicialmente acordado.

9.2 Estimativa de preço do software

Ao iniciarmos um projeto de desenvolvimento de software, uma das primeiras perguntas que fazemos é “qual o preço que devemos atribuir para este produto?”. Muitas vezes os desenvolvedores se enganam ao associar o preço apenas aos custos de desenvolvimento, por exemplo, tempo estimado para o desenvolvimento vezes o valor da hora de trabalho de um analista, mais o lucro desejado. Entretanto, não é a forma adequada para o cálculo do preço do produto, principalmente quando estamos tratando de um sistema complexo, que utiliza uma quantidade significativa de ferramentas e abordagens para a melhoria da qualidade do sistema. Podemos afirmar então que um dos fatores que influenciam diretamente na composição do preço do produto está relacionado aos requisitos (funcionais e não funcionais), e à forma pela qual eles são apresentados ao desenvolvedor.

Mas, cabe aqui uma pergunta: dependendo do modelo de processo utilizado, não

temos uma visão geral, completa, dos requisitos. No modelo incremental, por exemplo,

o produto irá evoluir conforme o conhecimento dos requisitos, do processo de negócios

e do domínio. Neste caso, como podemos realizar uma estimativa do produto? Muitas vezes a estimativa deve ser baseada no conhecimento prévio do domínio da aplicação, ou então nas informações obtidas em um nível de detalhamento nem sempre suficiente. Com o andamento do projeto, novas estimativas devem ser feitas e um replanejamento se faz necessário. Existe, portanto, uma probabilidade de apresentar um custo irreal, mas devemos buscar a utilização de técnicas que nos levem a uma estimativa razoável para compor o custo do software.

Suponhamos que uma empresa deseja desenvolver um sistema de administração escolar e que ela ainda não tem exatamente os requisitos necessários para este sistema. O desenvolvedor estima um valor com base no seu conhecimento e na sua experiência, bem como no orçamento que a escola possui. Posteriormente, negociações serão necessárias para que, de posse dos requisitos, as funcionalidades

65

EADDCC032 – Fundamentos de Engenharia de Software

essenciais sejam implementadas e as entregas realizadas. Requisitos levantados e acordados podem ser acrescentados ao sistema após um novo orçamento.

Ao compor o custo de um software devemos considerar todos os fatores capazes de nos proporcionar uma estimativa mais otimista. Inicialmente, somos levados a considerar apenas os esforços de desenvolvimento dos artefatos. Entretanto, para calcular o custo de um produto é necessário considerarmos os custos dos stakeholders envolvidos, os custos relacionados a alugueis, equipamentos, treinamentos, entre outros.

a alugueis, equipamentos, treinamentos, entre outros. Figura 9.1: Composição do preço de um software Além

Figura 9.1: Composição do preço de um software

Além desses fatores, Sommerville (2011) acrescenta alguns outros que podem indiretamente afetar a composição do preço do produto. Por exemplo: (i) caso o sistema possua requisitos que mudam com frequência, a organização poderá reduzir o custo e, à medida que novos requisitos forem solicitados, novos preços são acordados; (ii) o código-fonte pode não ser entregue ao cliente e reutilizado em outros projetos pelo desenvolvedor, reduzindo assim o custo; (iii) a organização pode reduzir o custo no sentido de conquistar o mercado e gerar oportunidades de expansão; e (iv) em decorrência da situação financeira da organização e do momento em que o mercado se encontra, pode ser vantajoso reduzir os lucros para garantir um contrato. Enfim, são diversos fatores que compõem o custo de um software. Não é objetivo da disciplina, abordar exaustivamente as diferentes técnicas e modelos para estimar o esforço de desenvolvimento e os custos envolvidos.

66

EADDCC032 – Fundamentos de Engenharia de Software

Modelos e técnicas para a estimativa de esforço e custo podem ser encontradas em: (1)

Modelos e técnicas para a estimativa de esforço e custo podem ser encontradas em:

(1) BOEHM, B., 2000, “COCOMO II Model Definition Manual”, Center for Software Engineering, University of Southern California, Disponível em:

<http:// csse.usc.edu/csse/research/COCOMOII/cocomo2000.0/

CII_modelman2000.0.pdf>.

(2) VAZQUEZ, C. E., SIMÕES, G. S., ALBERT, R. M., 2013, “Análise de pontos de função: medição, estimativas e gerenciamento de projetos de software”. 13. ed. – São Paulo: Érica.

9.3 Plano de projeto

Planos de projeto são documentos que contém os registros das atividades que

serão realizadas, bem como os recursos necessários e disponíveis, as pessoas

envolvidas e que estão associadas a alguma atividade, e o cronograma para a

realização do projeto. Marcos e produtos a serem entregues também são

especificados. Adicionalmente, este documento deve conter os riscos que porventura

aconteçam e as formas para gerenciá-los.

Segundo Sommerville (2011) um plano de projeto pode conter a seguinte estrutura:

1. Introdução (objetivo e restrições)

2. Organização de Projeto (equipe de desenvolvimento, pessoas e papéis)

3. Análise de riscos (riscos e estratégias para e redução)

4. Requisitos necessários de hardware e software

5. Estrutura analítica (divisão do trabalho em atividades, identificação dos

marcos, e os produtos a serem entregues)

6. Programação do projeto (dependências entre as atividades, tempo para

atingir cada marco e a alocação das pessoas)

7. Mecanismos de monitoramento e de elaboração de relatórios.

Associado a um plano de projeto, podemos encontrar os seguintes planos: (i)

plano de qualidade, contendo as políticas, procedimento e padrões adotados pela

67

EADDCC032 – Fundamentos de Engenharia de Software

organização; e (ii) plano de gerenciamento de configuração, descrevendo os

procedimentos e políticas para o gerenciamento de configuração, entre outros.

Pesquise outros planos que poderiam estar associados ao plano de projeto, no sentido de definir,

Pesquise outros planos que poderiam estar associados ao plano de projeto, no sentido de definir, claramente, as atividades, as políticas adotadas, e os requisitos necessários para que o mesmo seja bem sucedido.

Durante o tempo do projeto eventos negativos para que as atividades sejam bem

sucedidas podem ocorrer, tais como: um equipamento não foi entregue no momento

previsto, orçamento do projeto foi reduzido, demissões ocorreram, entre outros. Tais

eventos podem significar um risco para o projeto e, portanto necessitam ser

devidamente monitorados e mitigados. Eles podem afetar tanto a programação prevista

quanto a qualidade dos artefatos gerados. Portanto, medidas são necessárias para

evitá-los.

Por que o gerenciamento de riscos é importante para o projeto? Eles devem

receber toda a atenção necessária para que as entregas sejam realizadas conforme

planejadas, bem como para que os produtos sejam desenvolvidos a acordo com os

padrões e procedimentos de qualidade adotados.

Diversos fatores podem gerar riscos para um projeto, tais como: (i) mudança de

tecnologia; (ii) descontinuidade de um processo organizacional; (iii) descontinuidade do

suporte de um fornecedor de uma ferramenta de apoio ao desenvolvimento de

software; (iv) requisitos que modificaram; e (v) estimativas incorretas.

Identificação

Análise Planejamento
Análise
Planejamento

Monitoramento

Figura 9.2: Etapas do gerenciamento de projetos

Após a identificação, cada risco deve ser analisado considerando probabilidade

de ocorrência no contexto do projeto. Entretanto, este contexto se modifica, bem com a

probabilidade e efeitos. Por exemplo, um analista de sistemas, especialista em uma

tecnologia pode sair do projeto tanto no início do cronograma quanto no final do

projeto. Porém, a sua saída no início não terá o mesmo impacto do que na reta final do

projeto. A probabilidade de ocorrência também deve ser levada em consideração

diante do contexto, da motivação, do salário e benefícios, entre outros fatos.

68

EADDCC032 – Fundamentos de Engenharia de Software

O próximo passo do gerenciamento de riscos diz respeito ao planejamento. Esta etapa define as estratégias para gerenciar aqueles riscos prioritários, considerados mais importantes diante do contexto em que o projeto se encontra. Por exemplo, como devemos proceder se, por acaso, um determinado equipamento apresentar um defeito? Para tanto, um plano de contingência descrevendo todas as ações necessárias deve ser criado e, frequentemente avaliado. Além de um plano de contingência outras estratégias são frequentemente encontradas na literatura de gerenciamento de projetos. Dentre elas cabe citar, a estratégia de sobreposição de tarefas. Através desta estratégia, os riscos de se perder um membro do projeto, considerado chave para a atividade que está em andamento, podem ser avaliados e as tarefas podem ser executadas por dois participantes com o intuito de minimizar esses riscos.

Após analisá-los e estabelecer uma estratégia para mitigá-los, os riscos devem ser constantemente monitorados ao longo do projeto. Esta atividade busca evidências para antecipar a ocorrência de um evento (negativo) que possa se materializar em um risco. Por exemplo: atrasos constantes nas entregas de equipamentos fornecidos por um determinado fabricante devem ser monitorados, pois, caso seja necessária uma entrega de emergência não é certo que podemos contar com este fabricante. Outro exemplo: motivação baixa da equipe pode significar solicitações de desligamento, ou então atrasos no cronograma.

Caso algum risco não seja tratado problemas graves podem acontecer a ponto de influenciar o andamento do projeto. Muitas vezes, renegociações de prazos e entregas são necessários não apenas em decorrências dos eventos negativos (riscos) que não foram devidamente monitorados, mas também das ações de mitigação não foram eficazes. Como resultado, cronogramas devem ser revistos e renegociados.

Entretanto, durante o desenvolvimento do projeto uma série de eventos podem ter alterado os objetivos organizacionais, os requisitos inicialmente acordados, e as prioridades da organização. Tais eventos podem até mesmo exigir mudanças severas nas atividades do projeto resultando em outro projeto, ou então na sua interrupção.

69

EADDCC032 – Fundamentos de Engenharia de Software

9.4 Programação de projeto

A partir do momento que as tarefas são planejadas cabe decidir sobre a

organização das mesmas, bem como a forma pela qual elas serão executadas. Tarefas

são dependentes de outras e um atraso na execução de uma tarefa pode acarretar em

um replanejamento do cronograma. Certamente esta não é o único motivo pelo qual

um cronograma pode ser modificado. Caso o plano de projeto seja alterado, novos

requisitos seja elicitados, há uma necessidade de se modificar o cronograma. Portanto,

independente do modelo adotado e do conhecimento adquirido nas etapas iniciais de

projeto, um cronograma é necessário para que o acompanhamento das atividades

possa ser realizado.

Nesta etapa de programa ção de projetos tempo e recursos são estimados e as

atividades são organizadas em um conjunto de diagramas, cada um oferecendo uma

visualização diferenciada. Para tanto, o processo de programação ocorre da seguinte

maneira (Sommerville, 2011): a partir dos requisitos de software as atividades são

identificadas, bem como as suas dependências. Associada a cada atividade

normalmente procuramos informar o seu tempo estimado de duração, o número de

pessoas para realizá-las, e a data de término. Em seguida, cabe estimar os recursos

para que elas possam ser bem sucedidas e alocar as pessoas que executarão cada

atividade. Por fim, diagramas são criados de acordo com as necessidades de

visualização do cronograma. São exemplos desses diagramas: (i) gráficos de barras,

também denominados gráfico de Gantt; e (ii) redes de atividades.

Pesquise exemplos de gráficos de barras e gráficos de Gantt para ilustar o cronograma de

Pesquise exemplos de gráficos de barras e gráficos de Gantt para ilustar o cronograma de um projeto.

70

EADDCC032 – Fundamentos de Engenharia de Software

EADDCC032 – Fundamentos de Engenharia de Software Exercícios (1) Ao se planejar um projeto de software

Exercícios

(1) Ao se planejar um projeto de software marcos devem ser estabelecidos, bem como os produtos a serem entregues devem ser definidos. Com base nesta afirmação, discuta a importância da definição de marcos e de produtos no planejamento e no gerenciamento de projetos de software. Utilize um exemplo para ilustrar a sua resposta.

(2) Considerando os fatores que podem compor os custos de um projeto de software, descreva outros fatores, além daqueles que foram mencionados no corpo do texto, que podem influenciar o preço do produto.

(3) Para cada fator identificado no corpo do texto, que pode gerar um risco para o projeto, exemplifique uma situação associada a um projeto de desenvolvimento de um sistema de administração escolar.

(4) Além dos fatores apresentados no texto, identifique outros fatores de risco e exemplifique com uma situação para ilustrá-lo.

(5) Identifique dois riscos para um projeto de desenvolvimento de software, analise a sua probabilidade de ocorrência e estabeleça uma estratégia para mitigá-los.

71

EADDCC032 – Fundamentos de Engenharia de Software

Referências Bibliográficas

PRESSMAN, R., 2011, “Engenharia de Software: Uma Abordagem Profissional”, 7. ed. , McGraw-Hill.

SOMMERVILLE, I., 2011, “Engenharia de Software”, 9.ed., São Paulo: Pearson Prentice Hall.

SAMETINGER, J., 1997, “Software Engineering with Reusable Components”, Springer-Verlag.

Eclipse.org. Site oficial do ide eclipse. Disponível em: http://www.eclipse.org/. Acesso em: março de 2013.

NetBeans.org. Site oficial do ide netbeans. Disponível em:

http://www.netbeans.org/. Acesso em: março de 2013.

Software Engineering Institute – Disponível em: http://www.sei.cmu.edu/. Acesso em: abril de 2013.

MPS.BR - Melhoria de Processos do Software Brasileiro – Disponível em:

www.softex.br/mpsbr/. Acesso em abril de 2013.

72