Engenharia de Software

RONNEESLEY MOURA TELES

ENGENHARIA DE SOFTWARE: UMA ABORDAGEM PRÁTICA

-

SUMÁRIO 1

INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.1 Principais conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

. . . . . . . . . . . . . . .

4

1.3 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.2 Engenharia de software na era da Internet

2

3

PROCESSOS DE SOFTWARE

. . . . . . . . . . . . . . . . . . . . . . . .

6

2.1 Modelos de processo de software . . . . . . . . . . . . . . . . . . . . .

6

2.1.1

Modelo em cascata . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.1.2

Desenvolvimento incremental . . . . . . . . . . . . . . . . . . . . .

8

2.1.3

Integração e configuração . . . . . . . . . . . . . . . . . . . . . . . 10

CICLO DE VIDA E ORGANIZAÇÃO DO PROJETO . . . . . . . . . . . . 12 3.1 O Ciclo de Vida de um Projeto . . . . . . . . . . . . . . . . . . . . . . 12

4

DESENVOLVIMENTO ÁGIL

. . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Programação Extrema . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Histórias do usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3 Refatoração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4 Testes a priori (test-first) . . . . . . . . . . . . . . . . . . . . . . . . . 20 5

ANÁLISE DE SISTEMAS

. . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1 A importância da criação de modelos . . . . . . . . . . . . . . . . . . 21 5.2 Especificação do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3 Os requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.1

Metodologia JAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.3.2

Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3.3

Requisitos não funcionais . . . . . . . . . . . . . . . . . . . . . . . 26

5.4 Documento de requisitos de software . . . . . . . . . . . . . . . . . . 29 5.5 Exercı́cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6

GERENCIAMENTO DE TEMPO DO PROJETO . . . . . . . . . . . . . . 33 6.1 Definir as Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1.1

Entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1.2

Ferramentas e Técnicas . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1.3

Saı́das . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Sequenciar as Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.1

Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.2

Ferramentas e Técnicas . . . . . . . . . . . . . . . . . . . . . . . . 38

6.2.3

Saı́das . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3 Estimar os Recursos das Atividades . . . . . . . . . . . . . . . . . . . . 41 6.3.1

Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3.2

Ferramentas e Técnicas . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3.3

Saı́das . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.4 Estimar os Durações das Atividades . . . . . . . . . . . . . . . . . . . 43 6.4.1

Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.4.2

Ferramentas e Técnicas . . . . . . . . . . . . . . . . . . . . . . . . 45

6.4.3

Saı́das . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.5 Desenvolver Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.5.1

Entradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.5.2

Ferramentas e Técnicas . . . . . . . . . . . . . . . . . . . . . . . . 49

6.5.3

Saı́das . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.6 Controlar o Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.7 Exercı́cios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

1

INTRODUÇÃO De acordo com Somerville (2018) as instituições demandam cada vez mais sistemas

complexos baseados em computadores. A maioria dos produtos elétricos e empresas são dependentes desses sistemas, como exemplo: Netflix, Disney, SpaceX, Google, Meta, bolsas de valores, companhias de energia, etc. Deste modo, produzir e manter software dentro dos custos adequados é fundamental para economia.

Deste modo, Somerville (2018) define Engenharia de Software como “ramo da engenharia cujo foco é o desenvolvimento dentro dos custos adequados de sistemas de software de alta qualidade”. Esta área é importante porque a ausência de limitações fı́sicas no software facilita que ele se torne extremamente complexo.

A Engenharia de Software foi cunhada em uma conferência de 1968 criada para debater a chamada “Crise do software”. Nesta época, o tamanho e complexidade dos programas aumentou significativamente porque o hardware evoluiu. Assim, já não era mais suficiente desenvolver projetos sem um plano formal, pois os projetos desenvolvidos informalmente apresentavam atrasos na entrega, custos altos e deficiências de qualidade. Enquanto o custo do hardware diminuia, o custo do software aumentava. Isto, gerou demanda de novas técnicas de projeto e gerência de software.

É importante notar que não há uma técnica ideal. Isso acontece porque a forma que programamos computadores está em constante evolução, seja pro novos caminhos abertos devido a evolução do hardware ou ao surgimento de novos paradigmas de programação.

1.1

Principais conceitos A Engenharia de Software é a disciplina que lida com todos os aspectos da produção

de software. E, o software é o programa de computador e sua documentação, incluindo: manuais de uso, documentação de usuário, documetações técnicas, etc. Neste sentido, o programa é constituı́do pelo arquivo binário, bibliotecas e arquivos de configuração que são utilizados pelo computador (SOMERVILLE, 2018).

Segundo Somerville (2018) existem dois tipos de produtos de software: 1. Produtos genéricos: são produtos do tipo stand-alone, vendidos para qualquer cliente disposto a comprá-los. Chamados produtos de prateleira, ex: Pacote Office, Corel Draw, MySQL, Oracle, Windows, Jogos, aplicativos de celular.

3

2. Produtos sob encomenda: sistemas encomendados pelos clientes para atender seu negócio de maneira especı́fica e personalizada.

A principal diferença entre estes produtos é quanto a determinação da especificação do sistema. Empresas que desenvolvem produtos genéricos acabam por definir a especificação do software para atender seus potenciais clientes. Já a especificação de produtos sob encomenda é feita pelo próprio cliente. No entanto, atualmente, muitas empresas que desenvolvem produtos genéricos acabam por personalizar os produtos para seus grandes clientes (SOMERVILLE, 2018).

O conjunto de atividades que produzem um software é chamado de processo de software. Este é composto por quatro atividades fundamentais: especificação, desenvolvimento, validação e evolução do software. Os nomes das atividades descrevem bem suas etapas, porém é interessante ressaltar que neste contexto desenvolvimento é representa a etapa de programação e a atividade de validação representa a fase na qual é verificado se o software é o que o cliente deseja (SOMERVILLE, 2018).

Como é comum a produção de vários sistemas computacionais, surgem os modelos de processo de software que são descrições simplificadas do processo de software. Estes modelos incluem as atividades, os produtos de software em cada atividade, os papéis das pessoas envolvidas. A maioria dos modelos são baseados nos modelos: em cascata, iterativo ou engenharia de software baseada em componentes.

Os métodos da engenharia de software incluem estruturas para o desenvolvimento como modelos de sistema, notações, regras, recomendações e guias de processo. Entre eles tem-se: análise estruturada, Jackson System Development (JSD), Unified Modeling Language (UML).

A verdade é que toda essa organização se torna mais viável quando auxiliada por ferramentas Computer-Aided Software Engineering (CASE). Estas ferramentas abrangem desde a análise de requisitos, modelagem de sistema e teste. Geralmente todo método vem com uma tecnologia CASE associada. O principal destaque dessas ferramentas é a geração de documentos ou código-fonte com base em modelos do sistema.

1.2

Engenharia de software na era da Internet Após o surgimento da Internet e a criação da World Wide Web (BERNERS-LEE, 1989)

o software evoluiu ainda mais, pois dessa vez, não era mais preciso instalar um programa no 4

computador do usuário. Para a equipe de desenvolvimento cabia implantar o projeto em um servidor Web, como Apache ou Internet Information Services (IIS), já para o usuário bastava possuir um navegador Web como Google Chrome, Firefox, Edge. Isso reduziu tanto o custo de implantação, quanto o custo de desenvolvimento de interface com o usuário (SOMERVILLE, 2018).

No século XXI, surgiu o conceito de software como um serviço. Neste o software é implantado em uma nuvem computacional que possui vários serviços e o usuário paga uma taxa fixa ou proporcional ao uso, como Dropbox, Google Drive e hospedagens Web. Além disso surgiu o modelo de negócios no qual o usuário não paga pelo consumo do serviço, porém submete-se a visualização de anúncios, como YouTube, Twitch, Facebook, Gmail (SOMERVILLE, 2018).

1.3

Organização Além desse capı́tulo com a introdução à Engenharia de Software, este livro é estruturado

da seguinte forma. O capı́tulo 2 apresenta os processos de software. O capı́tulo 3 apresenta as principais metodologias de desenvolvimento ágil. O capı́tulo 4 apresenta a engenharia de requisitos. O capı́tulo 5 apresenta a modelagem de sistemas. O capı́tulo 6 apresenta o projeto e arquitetura de sistemas. O capı́tulo 7 apresenta o projeto de implatanção. O capı́tulo 8 apresenta o teste de software. E, por fim, o capı́tulo 9 apresenta a evolução de software.

5

2

PROCESSOS DE SOFTWARE Segundo Somerville (2018), um processo de software é um conjunto de atividades

que levam a produção de um software. Estes processos dependem do tipo de software a ser desenvolvido, dos requisitos do cliente e da habilidade da equipe. Porém, todos eles envolvem as quatro atividades fundamentais: especificação, desenvolvimento, validação e evolução.

Os processos são compostos por atividades e estas por subatividades como especificar o modelo de dados, criar a interface gráfica com o usuário. Estas atividades devem ser sequenciadas e deve-se descrever quem está envolvido, o que será produzido e quais condições influenciam a sequência dessa atividade (SOMERVILLE, 2018).

Um exemplo de subatividade poderia ser a programação de um módulo de vendas. A sua entrega seria o módulo de vendas pronto. Os papeis dizem respeito as responsabilidades, ex: programador, gerente de projeto, gerente de configuração. E as condições poderiam ser o cliente ter aprovado o requisito e o módulo de cadastro de produtos estar pronto.

Em sistemas crı́ticos geralmente são adotados processos bem estruturados e registros bem detalhados. Já em sistemas de negócio, os requisitos mudam rapidamente, então frenquentemente emprega-se processos mais flexı́veis e ágeis. Geralmente sistemas grandes encontram um ponto de equilı́brio entre essas duas realidades (SOMERVILLE, 2018).

2.1

Modelos de processo de software Um modelo de processo de software também pode ser chamado de ciclo de vida do

desenvolvimento de software (SDLC1 ). Este é uma representação simplificada do processo de software.

É importante ressaltar que os modelos não são estruturas rı́gidas que uma vez incorporadas nos projetos não permitem mudanças. Além disso, mesmo em um sistema é possı́vel encontrar subsistemas que utilizam abordagens diferentes.

Neste contexto, é comum observar que projetos bem estruturados/definidos utilizam o modelo em cascata enquanto que projetos mais mutáveis ou difı́ceis de entender nos primeiros contatos utilizam abordagem incremental.

Certamente, muitos pesquisadores já tentaram criar um modelo universal de processo e uma das tentativas mais bem sucedidas para esse fim foi o Rational Unified Process (RUP).

1

Software Development Life Cicle

6

Trata-se de um modelo flexı́vel que pode ser instanciado de diferentes maneiras (SOMERVILLE, 2018).

Neste sentido, as subseções a seguir apresentam os principais modelos de processo de software, também chamados de paradigmas de processo.

2.1.1 Modelo em cascata Cada atividade do processo é apresentada em fases distintas como: especificação de requisitos, projeto de software, implementação e testes. A figura 1 apresenta o modelo em cascata como uma série de estágios.

Figura 1 – Modelo em Cascata. Fonte: (SOMERVILLE, 2018).

A seguir a descrição de cada atividade desse modelo: 1. Análise e definição dos requisitos: são definidos os requisitos funcionais e não funcionais do sistema através da consulta ao usuário criando a documentação do software.

2. Projeto do sistema e do software: é definida a arquitetura do sistema, separando os requisitos de hardware e de software, assim como outros artefatos de projeto como diagramas de entidade relacionamento (DER), UML e outros.

3. Implementação e teste de unidade: o código-fonte do programa é produzido e testado através de unidades de teste, como o JUnit, verificando se satisfazem as especificações.

7

4. Integração e teste de sistema: os programas desenvolvidos são integrados e testados como um sistema completo. Isso permite garantir que os requisitos de software foram atendidos. Após a aprovação, o sistema é entregue ao cliente.

5. Operação e manutenção: essa é a fase mais longa no ciclo de vida. O sistema é implantado e colocado em uso. A manutenção envolve corrigir erros e melhoria das implementações.

Cada fase do modelo em cascata requer a produção de documentos que devem ser aprovados. E uma nova fase só começa após a conclusão da anterior. Para o desenvolvimento de hardware, que apresenta alto custo, estas etapas fazem sentido. No entanto, o desenvolvimento de software geralmente apresenta fases que se sobrepoem. O processo de encontrar problemas e retroalimentar as fases anteriores é chamado de feedback (SOMERVILLE, 2018).

A formalidade desse processo acaba por fazer as partes interessadas congelarem, via contrato, os requisitos. Isso acarreta que problemas são deixados para depois, gerando artifı́cios de programação no sistema. Consequentemente, o sistema acaba por não fazer o que o usuário deseja. Tal burocracia processual, acaba por viabilizar esse processo somente em sistemas embarcados, sistemas crı́ticos e grandes sistemas.

Segundo Somerville (2018) esse modelo não é recomendável quando o time se comunica informalmente e os requisitos de software mudam rapidamente. Neste casos os modelos de desenvolvimento iterativo e métodos ágeis são mais adequados.

2.1.2 Desenvolvimento incremental Este modelo intercala as atividades de especificação, desenvolvimento e validação.

Deste modo, o sistema é desenvolvido em um conjunto de versões chamadas incrementos.

Cada incremento adiciona ou corrige funcionalidades da versão anterior através do feedback dos usuários. Assim, atinge-se o sistema necessário através destas correções (SOMERVILLE, 2018). A figura 2 apresenta o processo deste modelo.

8

Figura 2 – Desenvolvimento Incremental. Fonte: (SOMERVILLE, 2018).

O desenvolvimento incremental é a abordagem mais comum para o desenvolvimento de software. Este modelo de processo é melhor que o cascata quando os requisitos estão propensos a mudar. Cada incremento ou versão do sistema adiciona funcionalidades necessárias para o cliente. Os incrementos iniciais, geralmente, contemplam as funcionalidades mais importantes. Assim o cliente pode verificar mais rapidamente se o sistema atende o que ele precisa (SOMERVILLE, 2018).

Existem três grandes vantagens deste modelo em relação ao modelo em cascata: 1. O custo de implementação das mudanças é reduzido, pois a quantidade de análise e documentação refeita é reduzida; 2. É mais fácil obter o feedback do cliente que está usando o software do que quando o cliente está apenas lendo a documentação; 3. O software agrega valor ao cliente desde o inı́cio do desenvolvimento uma vez que ele é implantado logo no começo.

Segundo Somerville (2018), este processo apresenta desvantagens em empresas grandes que evoluı́ram seus processo burocráticos, pois podem existir incompatibilidades dos procedimentos e o processo mais informal.

Além disso, do ponto de vista de gestão há dois problemas com este processo (SOMERVILLE, 2018): 9

1. Uma vez que o sistema evolui rapidamente, não são feitos documentos na mesma velocidade documentando o que está acontecendo, assim o processo da evolução do software não fica visı́vel.

2. A estrutura do sistema vai ficando mais frágil à medida que novos incrementos são lançados, pois o código vai ficando bagunçado. Assim, vai ficando mais difı́cil e caro adicionar novas caracterı́sticas ao sistema. Para diminuir este problema, os métodos ágeis sugerem que o código seja refatorado regularmente.

Para Somerville (2018), os problemas decorrentes desse processo se tornam crı́ticos em sistemas grandes, complexos e de vida longa. Estes sistemas precisam de um framework ou de uma arquitetura estável. Além disso, a responsabilidade dos diferentes times precisa ser claramente definda.

2.1.3 Integração e configuração Este modelo se baseia no reuso de componentes. Deste modo o processo de desenvolvimento se baseia na configuração e integração destes componentes para que eles sirvam um novo contexto de aplicação.

É normal reusar o código de um projeto antigo em um novo projeto. Seja por meio da cópia e adaptação ou pela inclusão de dependências. Mas desde os anos 2000, os processos de desenvolvimento de software se concentram no reúso de código através de componentes de software altamente configuráveis. São três os tipos de componentes frequentemente usados (SOMERVILLE, 2018): 1. Sistemas stand-alone configurados para um ambiente particular; 2. Coleções de objetos desenvolvidos como um componente ou um pacote a se integrado a um framework; 3. Web services disponı́veis através da Internet.

A figura 3 apresenta um modelo de processo genérico voltado para o reúso:

10

Figura 3 – Engenharia orientada ao reúso. Fonte: (SOMERVILLE, 2018).

A descrição dos estágios deste processo: 1. Especificação dos requisitos: elabora-se uma descrição breve ou mais elaborada das necessidades iniciais do sistema; 2. Descoberta e avaliação do software: é feita uma busca para encontrar um sistema ou componentes que atendam os requisitos do sistema; 3. Refinamento dos requisitos: os requisitos são definidos com base nos componentes ou aplicações encontradas.

4. Configuração da aplicação: se houver uma aplicação de prateleira disponı́vel, então ela é configurada para esse fim; 5. Adaptação e integração dos componentes: se não houver uma aplicação de prateleira, são adaptados componentes existentes ou novos componentes são desenvolvidos.

Este tipo de engenharia diminui a quantidade de software a ser desenvolvido, diminuindo os custos e riscos, e levando a uma entrega mais rápida. No entanto, o usuário acaba se adaptando aos requisitos dos sistemas ou componentes já existentes. Isto resulta em um sistema que não satisfaz as necessidades reais do usuário. Além desse problema, existe a falta de controle sobre a evolução dos softwares que permanece com a empresa que os desenvolveu (SOMERVILLE, 2018).

11

3

CICLO DE VIDA E ORGANIZAÇÃO DO PROJETO A organização que desenvolve projetos normalmente possui metodologias e práticas de-

terminadas antes do inı́cio de qualquer projeto. Em alguns casos estas metodologias e práticas podem ser definidas no começo do projeto quando a organização está em seus primeiros anos de vida. Deve-se compreender bem o contexto da empresa contratante para entender seus objetivos com o projeto.

3.1

O Ciclo de Vida de um Projeto Um projeto normalmente é dividido em fases que podem ou não se sobrepor. Cada fase

possui um nome e uma sequência lógica em relação as demais. Elas são estabelecidas pelas organizações envolvidas de acordo com as necessidades e restrições do projeto.

Todos projetos tem um inı́cio e um fim bem definido. Suas entregas e atividades são realizadas neste perı́odo em que o projeto está em andamento. Mesmo possuindo similaridades em relação ao tempo, a natureza das atividades pode variar em cada projeto. Um ciclo de vida estabelece uma estrutura básica das fases do projeto independentemente de sua natureza especı́fica.

Além de variarem na natureza especı́fica, os projetos também são diferentes em relação ao tamanho e complexidade. Independentemente destas caracterı́sticas eles podem ser mapeados de acordo com o ciclo de vida a seguir: 1. inı́cio; 2. organização e preparação; 3. execução do trabalho; e 4. encerramento.

Esta estrutura geral normalmente é utilizada na comunicação com a alta administração.

A partir dela é possı́vel comparar vários projetos que resulta no quadro de referência apresentado na Figura 4.

12

Figura 4 – Nı́veis tı́picos de custo e pessoal ao longo do ciclo de vida. Fonte: (Project Management Institute, 2008, p. 22)

Em resumo a figura 4 apresenta que: • Os custos de pessoal são baixos no inı́cio do projeto e são máximos durante a execução do trabalho e reduzem durante o encerramento; A figura 5 apresenta a influência, riscos e incertezas das partes interessadas. Estes fatores são maiores durante o inı́cio do projeto e reduzem ao longo de sua vida; Além disso, a Figura 5 apresenta os custos de mudança. Eles são menores durante o inı́cio da vida do projeto, durante seu andamento eles aumentam de forma significativa. Desta forma um erro corrigido no inı́cio do projeto tem um custo menor que no encerramento do projeto;

13

Figura 5 – Impacto das variáveis com base no tempo decorrido. Fonte: (Project Management Institute, 2008, p. 22)

14

4

DESENVOLVIMENTO ÁGIL Atualmente o ambiente global opera em rápida mudança. Assim, as empresas também

precisam de ações rápidas para tirar vantagens do ambiente competitivo em que vivem. Como o software é parte das empresas, sua produção também precisa acompanhar o ritmo delas.

Muitas empresas, sacrificam a qualidade em prol da velocidade de entrega (SOMERVILLE, 2018).

A figura 6 mostra um comparativo entre o desenvolvimento dirigido por planos e o desenvolvimento ágil. No desenvolvimento dirigido por planos ocorre a troca de documentos formais entre as etapas do processo. No desenvolvimento ágil os requisitos e o preojto (design) são construı́dos juntos (SOMERVILLE, 2018).

Figura 6 – Desenvolvimento dirigido por plano e desenvolvimento ágil. Fonte: (SOMERVILLE, 2018)

A ideia da metodologia ágil é se concentrar no próprio software, em vez de se concentrar no projeto ou na documentação. A filosofia por trás deste método está no manifesto ágil1 : Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivı́duos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano 1

https://agilemanifesto.org/iso/ptbr/manifesto.html

15

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Além da filosofia ágil tem-se também os doze princı́pios do software ágil: Nós seguimos estes princı́pios: Nossa maior prioridade é satisfazer o cliente através da entrega contı́nua e adiantada de software com valor agregado.

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Construa projetos em torno de indivı́duos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

Software funcionando é a medida primária de progresso.

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Contı́nua atenção à excelência técnica e bom design aumenta a agilidade.

Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial.

As melhores arquiteturas, requisitos e designs emergem de equipes autoorganizáveis.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Os métodos ágeis geralmente são empregados em dois tipos de desenvolvimento: produtos pequenos ou médios; e sistemas personalizados. Nestas situações não há necessidade de integrações e coordenação do fluxo de trabalho de desenvolvimento paralelo. Esse tipo de desenvolvimento ocorre no mesmo local, assim a comunicação informal funciona bem (SOMERVILLE, 2018).

4.1

Programação Extrema Algumas técnicas de desenvolvimento ágil foram desenvolvidas na década de 90. Entre

elas a Programação Extrema2 . Sua ideia é levar aos extremos as boas práticas de programação.

No XP várias novas versões de um sistema podem ser deesenvolvidas por diferentes programadores e integradas e testadas no mesmo dia.

2

Em inglês Extreme Programming (XP).

16

A figura 7 apresenta o ciclo de lançamentos da XP. Nele, os requisitos são expressos como cenários. Os programdores trabalham em pares e, antes de escreverem o código, desenvolvem testes para cada tarefa. Assim, o sistema deve ser aprovado em todos os testes (SOMERVILLE, 2018).

Figura 7 – Ciclo de lançamento (release) da XP. Fonte: (SOMERVILLE, 2018)

Segundo Somerville (2018), na prática o XP se provou mais difı́cil do que previsto.

Isso porque, ela não pode ser integrada imediatamente nas práticas de gestão e cultura das empresas. Em alguns momentos, as empresas adotam o XP em conunto com algum método ágil de gerenciamento como o Scrum.

Figura 8 – Práticas da XP. Fonte: (SOMERVILLE, 2018)

17

A figura 8 apresenta as principais práticas da XP. Segundo (SOMERVILLE, 2018) a principal contribuição da XP foi a introdução de um conjunto de práticas do desenvolvimento ágil na comunidade.

4.2

Histórias do usuário Uma vez que os métodos de desenvolvimento ágil não possuem uma atividade de

engenharia de requisitos, foi desenvolvido a ideia de “histórias do usuário”. Assim, a equipe de desenvolvimento juntamente com o cliente desenvolvem um “cartão de história” que descreve as necessidades do usuário de forma resumida (SOMERVILLE, 2018).

A figura 9 apresenta uma história do sistema Mentcare em um cenário para prescrever medicação para um paciente.

Figura 9 – História sobre a prescrição de medicamento. Fonte: (SOMERVILLE, 2018)

Depois de descrita, a história é decomposta em tarefas para a equipe de desenvolvimento conforme a figura 10. Através destes cartões de tarefas já se tem a estimativa de esforço e recursos necessários para cada uma destas tarefas. Segundo Somerville (2018), isso normal18

mente demanda discussões com o cliente para refinar os requisitos e determinar a prioridade de execução para a próxima iteração.

Figura 10 – Cartões de tarefa par prescrição de medicação. Fonte: (SOMERVILLE, 2018)

As histórias de usuário são mais fáceis de serem compreendidas do que um documento convencional de requisitos ou casos de uso. Assim, os usuários podem se envolver mais de perto nestas atividades. De outro lado, estes histórias não abortam todos os cenários possı́veis e se há histórias suficientes para abranger todos os requisitos essenciais do sistema (SOMERVILLE, 2018).

4.3

Refatoração As metodologias ágeis descartaram o princı́pio da engenharia de projetar visando mudanças

futuras. O principal motivo é porque fazer isto gera um desperdı́cio de trabalho, uma vez que, por vezes as alterações previstas não se concretizam ou as mudanças são completamente diferentes das previstas (SOMERVILLE, 2018).

Por outro lado, na XP o programador deve constantemente refatorar o código, ou seja, deve-se buscar melhorias e implementá-las imediatamente, mesmo que não haja demanda imediata delas (SOMERVILLE, 2018).

Segundo Somerville (2018), quando usamos o desenvolvimento ágil, a estrutra do projeto se degrada e vai ficando cada vez mais difı́cil de realizar alterações. É comum encontrar códigos duplicados, reúso indevido de partes do software e degradação geral da estrutura.

Deste modo, a refatoração é essencial para diminuição desses problemas.

19

Na prática a refatoração é a atividade que reorganiza o código para aumentar sua manutenibilidade. Mas, devido a pressão de desenvolvimento, ela pode ser postergada e a estrutura do software vai cada vez mais se deteriorando.

4.4

Testes a priori (test-first) No desenvolvimento ágil não há especificação, logo não há como uma equipe externa

de testes desenvolver os testes do software. Assim, o teste acaba sendo mais informal quando comparado ao desenvolvimento dirigido por plano. Assim na XP os testes possuem as seguintes caracterı́sticas (SOMERVILLE, 2018): 1. Desenvolvimento com testes a priori (primeiro); 2. Desenvolvimento do teste incremental a partir dos cenários; 3. Envolvimento do usuário no desenvolvimento e validação dos testes; e 4. uso de frameworks de teste automatizado.

Segundo Somerville (2018), essa filosofia evoluiu para técnicas de desenvolvimento dirigido por testes. Nestas técnicas, os testes são escritos antes do código.

20

5

ANÁLISE DE SISTEMAS O analista de sistemas é um profissional capaz de concretizar as necessidades do usuário

em um software. É ele a pessoa capaz de entender o que o usuário precisa e transformar estas necessidades em um produto, mesmo que o próprio usuário não saiba exatamente o que deseja.

5.1

A importância da criação de modelos A história mostra que o homem deu valor a diversos tipos de bens: propriedade, mão de

obra, máquinas e capital. A informação emergiu nesse cenário mostrando seu valor como um novo bem das empresas. A empresa com maior número de informações sobre o seu processo de negócio possui vantagem na competição pelo mercado (BEZERRA, 2014).

“A necessidade é a mãe das invenções”. Com o crescimento da importância da informação, surge a necessidade de gerenciá-la de forma adequada e eficiente, assim surgiram os Sistemas de Informações. Um sistema de informações é a combinação de: pessoas, dados, processos, interfaces, redes de comunicação e tecnologia. Estes elementos interagem com o objetivo de melhorar o processo de negócio de uma empresa (BEZERRA, 2014).

“O objetivo principal e final da construção de um sistema de informações é a adição de valor à empresa ou organização na qual esse sistema será utilizado” (BEZERRA, 2014, p. 1).

Adição de valor quer dizer que os processos da empresa devem ser melhorados para compensar a construção do sistema, ou seja, o sistema deve ser economicamente justificável. Desenvolver um sistema de informações é uma tarefa muito complexa (BEZERRA, 2014, p. 1).

Um dos componentes de um sistema de informações é o sistema de software. Este componente possui “módulos funcionais computadorizados que interagem entre si para proporcionar ao(s) usuário(s) do sistema a automatização de diversas tarefas” (BEZERRA, 2014, p. 2).

Uma caracterı́stica dos sistemas de software é que a complexidade de seu desenvolvimento cresce proporcionalmente ao seu tamanho. Neste sentido, Bezerra (2014) compara os itens necessários para desenvolver uma casa. Se esta casa fosse para um cachorro, seriam necessárias ripas de madeira, pregos, caixa de ferramentas, amor pelo animal e alguns dias de trabalho. No entanto, se fosse uma casa para sua famı́lia a tarefa não seria tão fácil. O tempo e os recursos seriam algumas dezenas de vezes maiores. Já se a construção trate-se de um edifı́cio certamente seria necessário um esforço ainda maior.

21

“Os engenheiros e arquitetos constroem plantas de diversos elementos da habitação antes do inı́cio da construção...” (BEZERRA, 2014, p. 2). As plantas hidráulicas, elétricas, de fundação e outras devem manter consistência entre si.

A construção de sistemas de software também ocorre este aumento da complexidade conforme o tamanho do sistema. “O equivalente ao projeto das plantas da engenharia civil também deve ser realizado” (BEZERRA, 2014, p. 2). Este é o conceito de modelo: “... um modelo pode ser visto como uma representação idealizada de um sistema a ser construı́do.”

(BEZERRA, 2014, p. 2). Por exemplo maquetes de edifı́cios, aviões, plantas de circuitos eletrônicos (BEZERRA, 2014, p. 2).

Segundo Bezerra (2014, p. 2 e 3) os modelos de sistemas são construı́dos para lidar com a complexidade que é a construção de um software. Um sistema pode ter vários modelos para a sua construção, no caso de software constrói-se geralmente o diagrama de casos de uso e o diagrama de classes.

Além disso, estes modelos permitem a comunicação entre as pessoas envolvidas, uma vez que um problema pode ser resolvido de diversas formas, os modelos especificam a forma escolhida pela equipe para a resolução. Cotidianamente pode-se usar os modelos como um contrato entre a empresa que fornece o software e o cliente que o solicita Bezerra (2014, p.

3).

Adicionalmente, os modelos permitem a correção de erros de comunicação e individuais antes mesmo deles ocorrerem. A correção no modelo custa menos tempo e recursos que a correção no software. Finalmente, estes modelos permitem a discussão do comportamento do sistema antes mesmo da construção Bezerra (2014, p. 3).

Estes modelos podem tanto serem representados por diagramas como também por textos. Estas informações textuais geralmente complementam dados apresentados nos diagramas.

Neste sentido um diagrama juntamente aos seus textos associados formam a documentação do modelo Bezerra (2014, p. 4).

5.2

Especificação do sistema A especificação do sistema “é um documento que serve de base para a engenharia

de hardware, engenharia de software, engenharia de banco de dados e engenharia humana” (PRESSMAN, 1995). Após as primeiras reuniões com os usuários são definidos os requisitos do sistema (SOMMERVILLE, 2007, p. 79).

22

5.3

Os requisitos Segundo Macoratti (2012) um requisito é uma função, restrição ou propriedade que

deve ser fornecida pelo software. Os requisitos satisfazem as necessidades dos usuários. De forma geral: “descreve um serviço ou uma limitação”. Devem ser definidos com objetividade e clareza, sendo que a mal definição dos requisitos juntamente as alterações constantes neles são as principais causas de fracasso dos projetos.

Não existe um modelo geral para descobrir os requisitos do sistema. A sugestão é descobri-los em consultas, documentos, pesquisas, entrevistas e JAD (Joint Application Design), análise dos requisitos identificados, refinamento e detalhamento, modelagem e validação dos requisitos (verificação da consistência), e acompanhamento dos requisitos em todas as fases.

Os requisitos são classificados como funcionais e não funcionais. Estes serão descritos nas seções 5.3.2 e 5.3.3.

5.3.1 Metodologia JAD Segundo Rocha (2017) a metodologia JAD foi criada pela International Business Machines (IBM). Baseia-se em reuniões com a filosofia de que todos os participantes são coautores da solução.

Nestas reuniões sugere-se dinâmicas de grupos conduzidas por um facilitador e com participação dos usuários chaves. Sempre quando possı́vel sugere-se o uso de recursos audiovisuais, pois facilitam a comunicação e o entendimento (ROCHA, 2017).

Durante as discussões deve-se analisar todos os pontos do projeto com uma abordagem top-down. Isto quer dizer que o sistema será analisado do ponto mais amplo para os detalhes operacionais (ROCHA, 2017).

Em cada reunião recomenda-se a elaboração de um documento com as decisões tomadas. Este documento deverá ser assinado pelos participantes como uma prova de acordo entre as decisões realizadas (ROCHA, 2017).

Cada etapa do JAD possui fases: adaptação, sessão e finalização. Na adaptação planejase as reuniões e todo o material a ser utilizado e convida-se os participantes, a sessão por sua vez é a própria reunião, é nesta fase então que desenvolve-se e documenta-se os requisitos, e por último, a finalização que converte os requisitos em um documento chamado documento de especificação de requisitos (ROCHA, 2017).

23

5.3.2 Requisitos funcionais Descrevem as funcionalidades do sistema desejadas pelos stakeholders (interessados).

Assim, um requisito funcional determina um comportamento esperado do sistema (MACORATTI, 2012).

Sommerville (2007, p. 80) descreve os requisitos como serviços fornecidos pelo sistema e suas restrições operacionais. O processo que envolve a descoberta, analise, documentação e verificação destes requisitos é chamado de engenharia de requisitos. Os requisitos podem ser especificados com dois diferentes nı́veis de detalhes que são classificados como requisitos de usuários e requisitos de sistema.

Os requisitos de usuários possuem uma descrição abstrata do que o sistema deve fazer, evitando sempre que possı́vel impor a solução para o problema a ser trabalhado no requisito.

Estes requisitos são especificados pelo cliente que demanda a solução. Já os requisitos de sistema são especificados pelos fornecedores, neste determina-se com clareza e objetividade o que o sistema deve fazer. Este último pode ser parte do contrato estabelecido pelas partes (SOMMERVILLE, 2007, p. 80).

A seguir alguns exemplos: 1) O sistema deve fornecer um cadastro de clientes; 2) O sistema deve emitir um relatório de aniversariantes; 3) O sistema deve fornecer um cadastro de fornecedores. As tabelas 1, 2 e 3 sugerem modos de documentar os requisitos funcionais.

Nota-se que também é recomendável anotar informações a respeito do surgimento do requisito como sua fonte, data e local da reunião em que detectou-se o requisito. Estas informações complementam e auxiliam no rastreamento de informações.

Tabela 1 – Requisito Funcional (Exemplo R1): O sistema deve fornecer um cadastro de produtos.

Identificação do Requisito

Exemplo R1

Nome do Requisito

O sistema deve fornecer um cadastro de produtos

Fonte do Requisito

Sebastião

Data

8 de março de 2012

Local e/ou Reunião

Sala 10 da empresa A

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

24

Um produto possui os seguintes dados: código, nome, quantidade em estoque, descrição, preço de compra e preço de venda. A quantidade em estoque de um produto não pode ser negativa. Seu preço de compra deve ser um valor superior a R$ 0,00. O preço de venda do produto não pode ser inferior ao preço de compra. O nome do produto, quantidade, preço de compra e de venda devem ser obrigatoriamente informados.

Tabela 2 – Requisito Funcional (Exemplo R2): O sistema deve fornecer um cadastro de fornecedores.

Identificação do Requisito

Exemplo R2

Nome do Requisito

O sistema deve fornecer um cadastro de fornecedores

Fonte do Requisito

João

Data

13 de março de 2012

Local e/ou Reunião

Empresa X

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

Os fornecedores possui código, nome, CNPJ, telefone e e-mail, sendo que os campos nome e CNPJ são obrigatórios. Cada empresa pode fornecer um conjunto de diferentes produtos.

O e-mail e CNPJ devem ser válidos.

Tabela 3 – Requisito Funcional (Exemplo R3): O sistema deve emitir um relatório dos produtos em estoque.

Identificação do Requisito

Exemplo R3

Nome do Requisito

O sistema deve emitir um relatório dos produtos em estoque

Fonte do Requisito

Marcia

Data

13 de março de 2012

Local e/ou Reunião

Empresa Y 25

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

Devem aparecer no relatório: o código do produto, seu nome, quantidade, preço de venda e total (quantidade vezes preço de venda). O relatório deve ser emitido em formato A4 em orientação retrato.

5.3.3 Requisitos não funcionais Segundo Macoratti (2012) os requisitos não funcionais são as “qualidades e restrições globais do sistema relacionados com: manutenção, uso, desempenho, custo, interface” e outros.

Sommerville (2007, p. 82) descreve os requisitos não funcionais como aqueles que não estão relacionados com as funções especı́ficas do sistema, podendo estar relacionados com as propriedades emergentes do sistema como confiabilidade, tempo de resposta, espaço de armazenamento, desempenho, proteção e disponibilidade. Consideram-se propriedades emergentes aqueles que se manifestam em relação ao conjunto de todas as partes do sistema.

Deste ponto de vista os requisitos não funcionais são geralmente mais importantes que os funcionais, uma vez que a falha em um destes requisitos pode significar que o sistema todo é inútil (SOMMERVILLE, 2007, p. 82).

Ainda neste sentido estes requisitos podem até especificar o processo pelo qual o sistema será desenvolvido, podendo especificar por exemplo as ferramentas que serão utilizadas para tal ou padrões de qualidade de processo. Outra natureza para eles está na definição do orçamento, necessidade de interoperabilidade com outros sistemas (software ou hardware), fatores como legislações ou normas de segurança (SOMMERVILLE, 2007, p. 82). A Figura 11 apresenta os tipos de requistos não funcionais em um software.

26

Figura 11 – Tipos de requisitos não funcionais em um software. Fonte: (SOMMERVILLE, 2007, p. 82).

As tabelas 4, 5, 6 e 7 apresentam exemplos de requisitos não funcionais e sugerem uma forma de documentá-los.

Tabela 4 – Requisito Não Funcional (Exemplo RNF1): O SGBD deve ser protegido com usuário e senha.

Identificação do Requisito

Exemplo RNF1

Nome do Requisito

O SGBD deve ser protegido com usuário e senha

Fonte do Requisito

David

Data

13 de março de 2012

Local e/ou Reunião

Empresa X

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

Não deve haver nenhum usuário sem senha e todas elas devem ser compostas de no mı́nimo 7 caracteres, incluindo números, letras e caracteres especiais. Cada usuário do sistema possui um usuário próprio no SGBD.

27

Tabela 5 – Requisito Não Funcional (Exemplo RNF2): O software deve fucionar no sistema operacional Window e Linux.

Identificação do Requisito

Exemplo RNF2

Nome do Requisito

O software deve fucionar no sistema operacional Window e Linux

Fonte do Requisito

João

Data

13 de março de 2012

Local e/ou Reunião

Centro de Reuniões

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

Todos os componentes do software devem funcionar no sistema operacional Windows e Linux.

Tabela 6 – Requisito Não Funcional (Exemplo RNF3): O software deve consumir no máximo 1GB de RAM, ocupar no máximo 2GB de espaço e funcionar com um CPU de 1GHz. Identificação do Requisito

Exemplo RNF3

Nome do Requisito

O software deve consumir no máximo 1GB de RAM, ocupar no máximo 2GB de espaço e funcionar com um CPU de 1GHz

Fonte do Requisito

João

Data

13 de março de 2012

Local e/ou Reunião

Centro de Reuniões

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

As respostas do software não podem exceder o tempo de 1 minuto.

28

Tabela 7 – Requisito Não Funcional (Exemplo RNF4): O tempo de desenvolvimento do software não pode ultrapassar do dia 15/06/2017.

Identificação do Requisito

Exemplo RNF4

Nome do Requisito

O tempo de desenvolvimento do software não pode ultrapassar do dia 15/06/2017

Fonte do Requisito

João

Data

10 de fevereiro de 2017

Local e/ou Reunião

Centro de Reuniões

Responsável pelo Requisito

Ronneesley Moura Teles Especificação do Requisito

Se o prazo não for executado no tempo previsto haverá multa e o sistema poderá ser rejeitado pelo contratante, uma vez que será utilizado em uma situação promocional da empresa X durante uma data festiva.

5.4

Documento de requisitos de software O documento de requisitos de software também chamado de especificação de requi-

sitos de software (SRS)1 documenta o que os desenvolvedores deverão fazer. Deve incluir os requisitos de usuários e requisitos de sistemas. Caso a quantidade de páginas dos requisitos de sistemas seja muito grante, este pode ser apresentado em um documento separado (SOMMERVILLE, 2007, p. 91).

O detalhamento utilizado na SRS depende do tipo de sistema e do processo de desenvolvimento adotado. Quando o sistema for desenvolvido por um fornecedor externo as especificações devem ser precisas e detalhadas. No entanto, quando o processo for flexı́vel, interno e interativo o documento pode ser menos detalhado, assim as ambiguidades são resolvidas durante o desenvolvimento (SOMMERVILLE, 2007, p. 91).

A organização mais conhecida deste documento é especificada pela IEEE/ANSI 8301998. Este padrão sugere a estrutura do documento de uma forma ampla. Sommerville (2007, p. 92 e 93) expande este padrão com informações úteis a serem adicionadas.

1

O significado da sigla é Software Requeriments Specification.

29

1. Prefácio: define o objetivo do documento, o público-alvo e descreve o histórico de versões, assim como uma justificativa para a mudança de versão; 2. Índices: podem ser incluı́dos diversos tipos de ı́ndices, como: sumário, lista de figuras, lista de tabela, etc. A medida que o documento se torna extenso os ı́ndices são mais necessários, pois permitem encontrar as informações.

3. Introdução: descreve a necessidade do sistema, descreve brevemente suas funções e interconexões com outros sistemas.

3.1. Escopo do produto: nome, objetivos, limites de atuação, benefı́cios.

3.2. Glossário: apresenta todas as definições, os acrônimos, as abreviaturas e o jargão da área 3.3. Referências 3.4. Visão geral do restante do documento: resumo breve das seções do documento 4. Descrição geral 4.1. Perspectiva do produto: descrever situação ambiental de uso do software, interconexões, interfaces externas, operações, restrições de memória primária e secundária; 4.2. Funções do produto: resumir como as funções colaboram para atingir os objetivos do software.

4.3. Caracterı́sticas dos usuários: perfil de conhecimentos esperados dos usuários; 4.4. Restrições gerais: justificar as restrições tecnológicas de desenvolvimento; 4.5. Suposições e dependências: itens ambientais que são externos ao sistema, como a disponibilidade de um SGBD previamente instalado.

5. Requisitos especı́ficos: abrange todos os requisitos (funcionais e não funcionais), sendo a maior parte de todo o documento. a) Requisitos de usuário: deve usar ilustrações e todos os recursos para facilitar a comunicação de forma clara. b) Arquitetura do sistema: apresenta uma visão geral de alto nı́vel da arquitetura do sistema, apresentando a distribuição das funções nos módulos.

30

c) Requisitos de sistema: descreve os requisitos funcionais e não funcionais.

6. Modelos de sistema: apresenta todos os modelos/diagramas desenvolvidos para o sistema, mostrando o relacionamento entre os componentes, sistema e ambiente.

7. Evolução de sistema: descreve mudanças previstas de hardware, necessidades do usuário, tecnológicas, etc.

8. Apêndices 9. Índice O documento de especificação de requisitos é indispensável quando se trata de um fornecedor externo. Alguns métodos ágeis argumentam que os requisitos mudam tão rapidamente que o documento fica desatualizado, realizando assim um esforço desperdiçado (SOMMERVILLE, 2007, p. 93 e 94).

5.5

Exercı́cios

1. Cite três caracterı́sticas importantes de um analista de sistemas.

2. O que são modelos? Cite pelo menos dois modelos que conhece de qualquer área.

3. O que é a relação “ganha-ganha”? Quais outros tipos de relações existem?

4. Cite dois diagramas desenvolvidos para construção de software.

5. O que são requisitos?

6. Quem criou a metodologia JAD? Como acontece o levantamento de requisitos nesta metodologia?

7. Quais as três fases da metodologia JAD? O que acontece em cada uma delas?

8. O que são requisitos funcionais?

9. O que são stakeholders?

10. Qual a diferença entre requisitos de usuários e requisitos de sistema? Quem os descreve?

11. O que são requisitos não funcionais? O que os diferencia dos requisitos funcionais?

31

12. Cite pelo menos três naturezas de requisitos não funcionais.

13. Elabore um requisito funcional e um não funcional para um sistema de bibliotecas.

14. Cite pelo menos dois métodos ágeis.

15. O que é um processo de desenvolvimento iterativo e incremental?

16. Você acha praticável desenvolver um software sem a escrita da SRS? Justifique.

17. Descreva o processo de desenvolvimento Scrum e Extreme Programming.

32

6

GERENCIAMENTO DE TEMPO DO PROJETO O gerenciamento de tempo inclui processos para gerenciar o término pontual do projeto.

Figura 12 – Visão geral do gerenciamento de recursos. Fonte: (Project Management Institute, 2008, p. 114)

A Figura 12 apresenta os processos do gerenciamento de tempo (Project Management Institute, 2008, p. 112): 1. Definir as atividades: identificação das ações especı́ficas para produzir as entregas do projeto; 33

2. Sequenciar as atividades: identificação e documentação dos relacionamentos entre as atividades do projeto; 3. Estimar os recursos das atividades: estimativa dos tipos e quantidades de material, pessoas, equipamentos ou suprimentos que serão utilizados em cada atividade; 4. Estimar as durações da atividade: estimativa do número de perı́odos de trabalho para executar as atividades com os recursos estimados; 5. Desenvolver o cronograma: análise das sequências das atividades, durações, recursos necessários e restrições para criação do melhor cronograma possı́vel; 6. Controlar o cronograma: monitoramento do andamento do projeto visando a atualização do progresso e gerenciamento das mudanças realizadas; Esses processos interagem-se entre si e podem se sobrepor. Envolve esforços de uma pessoa ou uma equipe. Caso o projeto seja dividido em partes, este processo de gerenciamento de tempo pode ocorrer em cada fase.

Alguns profissionais distinguem os dados e cálculos das durações das atividades do desenho realizado para controlá-las. Este desenho é chamado de modelo de cronograma, pois utiliza os dados do projeto para agendar as atividades.

No plano de gerenciamento do projeto a equipe escolhe a metodologia e ferramenta utilizada para elaboração do cronograma. A metodologia define as régras e abordagens para elaboração, a grande maioria das metodologias incluem o método do caminho crı́tico (CPM Critical Path Method) e o método da cadeia crı́tica.

A metodologia, as ferramentas e as técnicas escolhidas são documentadas no plano de gerenciamento do cronograma, o qual está contido no plano de gerenciamneto de projeto.

Após a elaboração do cronograma a maioria dos esfórços concentram-se no processo de controle do cronograma visando o término pontual do projeto. A Figura 13 apresenta um resumo de como estas atividades se juntam para elaboração do cronograma.

De forma resumida a definição do cronograma usa as saı́das dos processos de definição das atividades, o sequenciamento, estimativa dos recursos e durações em combinação com uma ferramenta de elaboração.

34

Figura 13 – Resumo do desenvolvimento do cronograma. Fonte: (Project Management Institute, 2008, p. 115)

6.1

Definir as Atividades É o processo de identificação das ações especı́ficas a serem realizadas afim de produzir

as entregas.

6.1.1 Entrada • os requisitos do projeto: linha base do escopo; 35

• fatores ambientais da empresa; • ativos de processos organizacionais: não incluem polı́ticas, procedimentos, diretrizes e lições aprendidas.

6.1.2 Ferramentas e Técnicas • a decomposição: é o desmembramento dos requisitos em atividades; • o planejamento em ondas sucessivas: nele as atividades de futuro próximo são planejadas em mais detalhes que as mais diantantes; • os modelos: pode-se utilizar uma lista padrão de atividades de projetos anteriores, como os marcos tı́picos do projeto (ex.: planejamento, projeto, desenvolvimento, testes, implantação); • Opniões dos especialistas: é frequente a consulta a especialistas de definição de escopo e cronograma; 6.1.3 Saı́das • Lista de atividades: é uma lista abrangente que inclui um identificador (ID) e uma descrição do escopo da atividade para que os membros entendam o que deve ser feito; • Atributos das atividades: identificação de componentes associados a cada atividade.

Durante os estágios iniciais envolvem o identificador (ID), o ID da EAP (Estrutura Analı́tica do Projeto1 ). Quando completos podem incluir códigos das atividades, sua descrição, atividades predecessoras, sucessoras, relações lógicas, antecipações e esperas, requisitos de recursos, datas impostas, restrições e premissas.

• Lista dos marcos: um marco é um ponto ou evento muito significativo do projeto. Por exemplo entregas parciais exigidas por contrato.

1

A EAP é responsável pela decomposição do escopo em requisitos entregáveis (pacotes de trabalho).

36

Figura 14 – Processo definir as atividades. Fonte: (Project Management Institute, 2008, p.

116)

6.2

Sequenciar as Atividades É o processo de identificação e documentação dos relacionamentos entre as atividades

do projeto. Elas são sequenciadas usando relações lógicas. Cada atividade e marco são conectados a pelo menos um predecessor e um sucessor, exceto a primeira e última atividade e marco. O sequenciamento pode ser feito a mão ou automatizado por um software.

A Figura 15 apresenta de forma linear as entradas, ferramentas e técnicas, e saı́das do processo de sequenciamento das atividades.

Figura 15 – Processo de sequenciamento das atividades. Fonte: (Project Management Institute, 2008, p. 118)

A Figura 16 apresenta um fluxograma do processo de sequenciamento das atividades.

37

Figura 16 – Resumo do processo de sequenciamento das atividades. Fonte: (Project Management Institute, 2008, p. 119)

6.2.1 Entradas • Lista de atividades: descrito na seção 6.1.3; • Atributos das atividades: descrito na seção 6.1.3; • Lista dos marcos: descrito na seção 6.1.3. Podem conter datas agendadas para os marcos; • Declaração do escopo do projeto: contém a descrição do escopo do produto, que possui caracterı́sticas do mesmo que podem afetar a sequência (ex.: interfaces entre subsistemas); • Ativos de processos organizacionais: descrito na seção 6.1.1 6.2.2 Ferramentas e Técnicas • Método do diagrama de precedência (MDP) ou Atividade no Nó (ANN): é um método usado no Método do Caminho Crı́tico (CPM). Serve para construir um diagrama de rede do cronograma do projeto.

38

Ele utiliza de quadrados ou retângulos, chamados de nós, para representar as atividades e conectá-las com flexas que indicam as relações lógicas entre elas. A Figura 17 mostra um diagrama MDP. Figura 17 – Exemplo de diagrama MDP. Fonte: (Project Management Institute, 2008, p. 120)

O MDP possui quatro tipos de dependência ou relações lógicas: – Término para inı́cio (TI): o inı́cio da atividade sucessora depende do término da atividade predecessora; – Término para término (TT): o término da atividade sucessora depende do término da atividade predecessora; – Inı́cio para inı́cio (II): o inı́cio da atividade sucessora depende do inı́cio da atividade predecessora; – Inı́cio para término (IT): o término da atividade sucessora depende do inı́cio da atividade predecessora; No MDP o tipo de dependência mais comum é de término para inı́cio. O relacionamento inı́cio para término é raramente usada.

• Determinação de dependência: utiliza-se três tipos de dependência:

39

– Dependências obrigatórias ou hard logic: são aquelas exigidas no contrato ou inerentes à natureza do trabalho. Geralmente envolve limitações fı́sicas. Exemplo: é impossı́vel construir um prédio sem antes fazer a fundação ou, é impossı́vel testar um software sem antes desenvolvê-lo; – Dependências arbitrárias ou soft logic / lógica preferida: são estabelecidas com base no conhecimento das melhores práticas, ou seja, existem várias sequências aceitáveis.

– Dependências externas: envolve atividades do projeto e outras que não pertencem a ele. Estas dependências não estão sob controle da equipe do projeto.

Exemplo: é impossı́vel testar um software com o arduı́no sem ter que a empresa contratada tenha entregue o microchip.

• Aplicação de antecipações e esperas: defini-se uma antecipação ou uma espera para cada atividade. Isto descreve a relação lógica entre cada atividade. Uma antecipação permite o aceleramento da atividade sucessora, já uma espera provoca um retardo; • Modelos de diagramas de rede de cronograma: forma-se uma rede para o projeto ou para as várias atividades. Quando desmembrado cada parte é chamada de subrede ou fragmentos de rede. Esta técnica é útil quando as entregas são idênticas, por exemplo: andares de um edifı́cio.

6.2.3 Saı́das • Diagrama de rede do cronograma: desenho esquemático do cronograma com as relações lógicas entre as atividades. Pode ser feito manualmente ou via software. Pode incluir detalhes do projeto todo ou ter atividades especificadas a nı́vel macro. Pode ser acompanhado de um sumário descritivo das atividades e da abordagem usada para criá-lo; • Atualizações dos documentos do projeto: lista de atividades (seção 6.1.3), atributos das atividades (seção 6.1.3) e registro dos riscos;

40

6.3

Estimar os Recursos das Atividades É o processo de estimativa dos tipos e quantidades de material, pessoas, equipamentos

ou suprimentos necessários para realização de cada atividade. É um processo vinculado com o processo de estimar os custos. A Figura 18 apresenta um resumo deste processo e a Figura ?? apresenta uma visão geral do processo e suas interações.

Figura 18 – Processo de estimar recursos. Fonte: (Project Management Institute, 2008, p.

122)

Figura 19 – Visão geral da estimativa de recursos. Fonte: (Project Management Institute, 2008, p. 123)

41

6.3.1 Entradas • Lista das atividades: descrito na seção 6.1.3, ele identifica as atividades que necessitarão de recursos; • Atributos das atividades: descrito na seção 6.1.3, já com o sequenciamento e relações lógicas das atividades; • Calendários de recursos: disponibilidade dos recursos nos perı́odos das atividades.

Quando e por quanto tempo o recurso estará disponı́vel. Esta entrada inclui o nı́vel de experiência e/ou a habilidade do recurso; • Fatores ambientais da empresa: fatores ambientais da empresa que influênciem na estimativa de recursos, mas não limitados a disponibilidade e habilidades; • Ativos de processos organizacionais; 6.3.2 Ferramentas e Técnicas • Opinião especilizadas: grupo ou pessoa de conhecimento especı́fico em planejamento e estimativa de recursos; • Análise de alternativas: muitas atividades possuem métodos alternativos para sua execução; • Dados publicados para auxı́lio a estimativas: ı́ndices de produção e custos unitários de recursos de mão-de-obra, material e equipamento publicados por empresas; • Estimativa Bottom-Up: quando uma atividade não pode ser estimada, ela é decomposta. As necessidades de recursos são estimadas para cada subatividade, chegando-se ao total de recursos pela soma das partes; • Software de gerenciamento de projetos: auxı́lio de um software para o gerenciamento dos calendários dos recursos afim de otimizar seu uso; 6.3.3 Saı́das • Requisitos do recurso da atividade: estima os tipos e quantidades de recursos para cada atividade. Desta forma tem-se os recursos para o pacote de trabalho; 42

• Estrutura analı́tica dos recursos: é uma estrutura organizada dos recursos de acordo com a categoria e tipo de recursos. Exemplos de categorias: mão-de-obra, material, equipamento e suprimentos. Os tipos incluem o nı́vel de habilidade; • Atualizações dos documentos do projeto: lista de atividades (seção 6.1.3), atributos das atividades (seção 6.1.3) e calendários dos recursos; 6.4

Estimar os Durações das Atividades É a estimativa da quantidade de perı́odos de trabalho que serão necessários para termi-

nar as atividades com os recursos estimados. Utiliza informações como: atividades do escopo, tipos de recursos necessários, quantidades estimadas de recursos e calendários de recursos.

Quanto mais precisos os dados de entrada deste processo, melhor serão estimadas as durações.

Requer que a quantidade de esforço de trabalho e a quantidade de recursos aplicados seja estimada. Estes dados são utilizados para determinar a estimativa de perı́odos de trabalho necessários.

Figura 20 – Processo de estimar durações. Fonte: (Project Management Institute, 2008, p.

126)

43

Figura 21 – Visão geral da estimativa de durações. Fonte: (Project Management Institute, 2008, p. 126)

6.4.1 Entradas • Lista das atividades: escrito na seção 6.1.3; • Atributos das atividades: descrito na seção 6.1.3; • Requisitos dos recursos das atividades: descrito na seção 6.3.3, os recursos disponibilizados terão um efeito na duração das atividades; • Calendários dos recursos: descrito na seção 6.3.1; • Declaração do escopo do projeto: incluem mas não estão limitados a: condições existentes, disponibilidade de informações, duração dos perı́odos de preparação de relatórios, disponibilidade de recursos com habilidade e termos do contrato e requisitos;

44

• Fatores ambientais da empresa: fatores que influenciem a duração das atividades, não estão limitados a: banco de dados de estimativas de durações, métricas de produtividade e informações comerciais publicadas; • Ativos de processos organizacionais: ativos que influenciem a duração das atividades, não estão limitados a: informação histórica sobre a duração, calendários do projeto, metodologia de elaboração do cronograma e lições aprendidas; 6.4.2 Ferramentas e Técnicas • Opinião especializada: um especialista guiado por informações históricas pode fornecer a duração estimada ou duração máxima recomendada; • Estimativa análoga: usa parâmetros como: duração, orçamento, tamanho, peso e complexidade de um projeto anterior similar como base para estimativas no novo projeto. Usa informações históricas combinadas com a opinião especializada. É menos dispendiosa e menos precisa que as outras técnicas; • Estimativa paramétrica: utiliza relações estatı́sticas entre dados históricos e outras variáveis (ex.: metros quadrados de uma construção) para estimar parâmetros da atividade como: custo, orçamento e duração. Esta técnica possui alta precisão desde que os dados históricos sejam de qualidade; • Estimativas de três pontos: pode-se aperfeiçoar as estimativas de durações considerandose as incertezas das estimativas e riscos. Conceito originário da Técnica de Revisão e Avaliação de Programa (PERT). A PERT usa três estimativas: – Mais provável (tM ): análise realista para execução da atividade; – Otimista (tO ): análise do melhor cenário para a atividade; – Pessimista (tP ): análise do pior cenário para a atividade; A duração esperada da atividade (tE ) é calculada usando a média ponderada das três estimativas: tE =

tO + 4 · tM + tP 6

(6.1)

• Análise das reservas: utiliza de reservas para contingências, também chamadas de reservas de tempo ou buffers, no cronograma geral do projeto para considerar as incertezas 45

do cronograma. Pode-se utilizar um percentual sobre a duração estimada da atividade ou um número fixo de perı́odos de trabalho ou por métodos de análise quantitativa. A medida que mais detalhes sobre a execução chegam pode-se usar as reservas, reduzı́-las ou eliminá-las. Estes valores devem ser claramente identificado na documentação.

6.4.3 Saı́das • Estimativas da duração da atividade: avaliações quantitativas do número provável de perı́odos de trabalho que serão necessários para execução de uma atividade. Os resultados podem ser aproximados como: 2 semanas ± 2 dias, ou 15% de probabilidade de exceder 3 semanas.

• Atualização dos documentos do projeto: devem ser atualizados os documentos: atributos das atividades (seção 6.1.3) e premissas feitas no desenvolvimento da estimativa de duração da atividade, como: nı́veis de habilidade e disponibilidade (seção 6.4.1).

6.5

Desenvolver Cronograma É o processo de análise de sequência de atividades, durações, recursos necessários e

restrições do cronograma com o objetivo de criar o cronograma do projeto. Utiliza-se uma ferramenta de elaboração que recebe estes parâmetros que gera um cronograma com as datas planejadas para realização do projeto.

Este processo pode requerer a revisão de duração e recursos necessários para cada atividade afim de conseguir um cronograma aprovado. A revisão e manutenção do cronograma continua durante todo o projeto a medida em que há progresso, o plano de gerenciamento de projeto muda e os riscos evoluem. A Figura 22 apresenta o processo simplificado de desenvolvimento do cronograma.

46

Figura 22 – Processo de desenvolver o cronograma. Fonte: (Project Management Institute, 2008, p. 130)

A Figura 23 apresenta em detalhes o processo de desenvolvimento do cronograma.

47

Figura 23 – Visão geral de desenvolver o cronograma. Fonte: (Project Management Institute, 2008, p. 130)

6.5.1 Entradas • Lista de atividades: descrito na seção 6.1.3; • Atributos de atividades: descrito na seção 6.1.3; • Diagrama de rede do cronograma do projeto: descrito na seção 6.2.3; • Requisitos do recurso da atividade: descrito na seção 6.3.3; • Calendários dos recursos: descrito na seção 6.3.1; • Estimativas da duração da atividade: descrito na seção 6.4.3; • Declaração do escopo do projeto: documento com a definição do escopo do projeto, contém as premissas e restrições que podem afetar o cronograma; 48

• Fatores ambientais da empresa: fatores que afetam o desenvolvimento do cronograma, não estão limitados apenas à ferramenta de elaboração do cronograma; • Ativos de processos organizacionais: incluem mas não estão limitados a: metodologia de elaboração do cronograma e o calendário do projeto.

6.5.2 Ferramentas e Técnicas • Análise da rede do cronograma: usa várias técnicas analı́ticas como método do caminho crı́tico, o método da cadeia crı́tica, análise e-se e o nivelamento de recursos para calcular as datas de inı́cio, término mı́nimo e máximo (Project Management Institute, 2008, p. 131); • Método do caminho crı́tico: calcula as datas previstas para o inı́cio e término máximo e mı́nimo para todas as atividades, sem considerar limitações de recursos. É executada uma análise dos caminhos de ida e volta através da rede do cronograma. Estas datas de mı́nimo e máximo identificam os perı́odos nos quais as tarefas podem ser agendadas.

A folga livre de uma atividade é dada pela diferença entre a data máxima e mı́nima.

Um caminho da rede possui uma folga total obtida pelas folgas de suas atividades. As atividades do caminho crı́tico possuem folga total zero ou negativa (Project Management Institute, 2008, p. 131 e 132); • Método da cadeia crı́tica: é uma técnica que leva em conta as limitações de recursos.

É utilizada após a determinação do caminho crı́tico. Após saber o caminho crı́tico e a disponibilidade dos recursos utiliza esta técnica para adequar o cronograma às restrições de recursos. O resultado deste processo normalmente tem um caminho crı́tico diferente.

Este novo caminho crı́tico é conhecido como cadeia crı́tica (Project Management Institute, 2008, p. 132); • Nivelamento de recursos: é utilizado para analisar o cronograma após a técnica de caminho crı́tico. Pode ser empregado para manter o uso constante dos recursos e se ajusta bem em situações nas quais eles são escassos ou limitados. Normalmente causa mudança no caminho crı́tico (Project Management Institute, 2008, p. 132); • Análise do cenário “E-se”: deve-se realizar a seguinte pergunta “E se a situação do cenário X acontecer?”. De forma geral utiliza-se estimativas pessimistas nas quais as en49

tregas importantes atrasam e fatores externos (tais como: greves e licenças) atrapalham o andamento do projeto. Neste sentido é testado se o cronograma é usual em situações adversas, emergindo assim planos de contingências e respostas para amenizar problemas.

Calcula-se então várias durações do projeto com os diferentes cenários. É comum o uso da técnica Monte Carlo (Project Management Institute, 2008, p. 133); • Aplicação de antecipações esperadas: utiliza-se de antecipações e esperas para produção de um cronograma mais viável (Project Management Institute, 2008, p. 133); • Compressão do cronograma: esta técnica reduz o cronograma sem mudar o escopo do projeto. Neste sentido duas técnicas são conhecidas (Project Management Institute, 2008, p. 133): – Compressão: é utilizada quando o incremento de recursos ou o aumento das horas de trabalho (horas extras) ou pagamentos para aceleração reduzem a duração das atividades. Nota-se que nem todas tarefas reduzem a duração com o aumento da quantidade de recursos, neste caso a utilização desta técnica pode aumentar desnecessariamente os custos.

– Paralelismo: consiste em executar paralelamente várias atividades ou fases que seriam executadas sequencialmente. Nota-se que esta técnica só funciona se as atividades não possuı́rem interdependências.

• Ferramenta de desenvolvimento do cronograma: utiliza-se de um software para geração do cronograma com base nos dados e restrições do projeto (Project Management Institute, 2008, p. 133).

6.5.3 Saı́das • Cronograma do projeto: inclui pelo menos uma data de inı́cio e término para cada atividade. Até a confirmação da disponibilidade dos recursos o cronograma é considerado preliminar. O cronograma pode ser apresentado num formato resumido chamado de cronograma mestre ou cronograma de marcos. Em geral o cronograma é apresentado de forma gráfica embora possa ser apresentado em uma tabela. Os formatos mais conhecidos são (Project Management Institute, 2008, p. 133 e 134):

50

– Gráfico de marcos: assemelham-se a um gráfico de barras. Apresenta o inı́cio ou término das entregas mais importantes. A Figura 24 apresenta um gráfico de marcos.

Figura 24 – Gráfico de marcos. Fonte: (Project Management Institute, 2008, p. 135)

– Gráfico de barras: as barras representam as atividades, mostrando as datas de inı́cio, término e duração delas. São de fácil leitura e normalmente utilizados em apresentações gerenciais. A Figura 25 apresenta um gráfico de barras.

Figura 25 – Gráfico de barras. Fonte: (Project Management Institute, 2008, p. 135)

– Diagrama de rede do cronograma do projeto: apresenta as datas das atividades e mostram a lógica da rede do projeto e o caminho crı́tico do mesmo. Pode ser apresentado como um diagrama de atividade no nó (Figura 17) ou em um diagrama de rede do cronograma com uma escala de tempo chamado de gráfico de barras lógico. A Figura 26 apresenta um gráfico de barras lógico.

51

Figura 26 – Gráfico de barras lógico. Fonte: (Project Management Institute, 2008, p. 135)

• Linha base do cronograma: é uma versão especı́fica do cronograma desenvolvida a partir da análise de rede (Project Management Institute, 2008, p. 136).

• Dados do cronograma: incluem os marcos, as atividades, os atributos das atividades e a documentação de todas as premissas e restrições identificadas. São exemplos de dados (Project Management Institute, 2008, p. 136): – Frequência de uso de um recurso na forma de histograma; – Cronogramas alternativos para cenários otimistas e pessimistas; – Alocação das reservas de contingências.

• Atualizações dos documentos: todos os documentos atualizados, principalmente (Project Management Institute, 2008, p. 136): – Requisitos dos recursos das atividades: resultados da técnica de nivelamento de recursos que pode alterar os tipos e quantidades necessárias.

52

– Atributos das atividades: quando os requisitos de recursos são revisados muda-se este documento; – Calendário; – Registro dos riscos: percepção de novas oportunidades e ameaças através do agendamento das atividades.

6.6

Controlar o Cronograma

53

6.7

Exercı́cios

1. Por que se deve realizar o gerenciamento do tempo?

2. Quais os seis processos do gerenciamento de tempo? Descreva-os de forma simplificada.

3. Existe um limite claro entre cada processo de gerenciamento de tempo? Justifique.

4. É melhor a realização dos processos do gerenciamento de tempo somente por uma pessoa ou por uma equipe? Justifique sua resposta.

5. O gerenciamento de tempo ocorre uma única vez em todo o projeto? Justifique.

6. O que é um modelo de cronograma?

7. Qual o nome do documento no qual a escolha da metodologia e da ferramenta utilizada na elaboração do cronograma deve ser anotado?

8. Cite o nome de dois métodos para criação do cronograma.

9. Em qual processo concentram-se os esfórços após a concepção do cronograma? Justifique.

10. Faça um esquema que represente a criação do cronograma do projeto. Em seguida descreva as entradas para se criar o cronograma.

11. Quais são os três tipos de entrada do processo de definição de atividades?

12. Quais os quatro componentes das ferramentas e técnicas do processo de definição de atividades?

13. Quais as saı́das do processo de definição de atividades?

54

REFERÊNCIAS BERNERS-LEE, T. Information management: A proposal. 1989. Disponı́vel em: hhttp://www.w3.org/History/1989/proposal.htmli.

BEZERRA, E. Princı́pios de Análise e Projeto de sistemas com UML. 3. ed. Rio de Janeiro: Elsevier, 2014. ISBN 8535226265.

MACORATTI, J. C. Conceitos : Especificação de requisitos. 2012. Disponı́vel em: hhttp://www.macoratti.net/07/12/net fer.htmi. Acesso em: 02 mar. 2012.

PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 1995. ISBN 85-346-0237-9.

Project Management Institute. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. 4. ed. [S.l.]: Project Management Institute, 2008.

ROCHA, C. C. Joint Application Design (JAD). 2017. Disponı́vel em: hhttp: //www.matera.com/br/2014/02/11/joint-application-design-jad/i. Acesso em: 10 fev.

2017.

SOMERVILLE, I. Engenharia de Software. 10. ed. São Paulo: Editora Pearson, 2018.

768 p. ISBN 9788543024974.

SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson - Addison Wesley, 2007. ISBN 978-85-8863-928-7.

55