1.4 - Apostila Engenharia de Software

Centro Federal de Educação Tecnológica de Minas Gerais

Técnico em Informática

Engenharia de Software

Apostila de Engenharia de Software

Professor: Marcelo Corrêa Mussel

Varginha

2015

.

Sumário

1 Engenharia de Software - Conceitos Básicos 1

1.1 Introdução à Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Principais aspectos do software . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Software: Mitos e Realidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.3 Princípios da Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . 5

2 Paradigmas de Desenvolvimento de Software 7

2.1 Modelos de Desenvolvimento de software . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 O Modelo Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Prototipação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.3 Desenvolvimento Iterativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.4 O Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Ciclos de Desenvolvimento de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Fase de Definição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 Fase de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.3 Fase de Manutenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Modelos de Melhoria do Processo de Desenvolvimento . . . . . . . . . . . . . . . . . 13

2.3.1 O Modelo CMM - Capability Maturity Model . . . . . . . . . . . . . . . . . . 13

2.3.2 CMMI - Capability Maturity Model Integrated . . . . . . . . . . . . . . . . . 19

2.3.3 MPS.BR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Gestão de Projetos de Software 27

3.1 Conceitos de Gestão de Projetos de Software . . . . . . . . . . . . . . . . . . . . . . 27

3.2 O espectro da gestão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 O pessoal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.2 O produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.3 O processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.4 O projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Planejamento e acompanhamento do projeto . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1 PMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.2 Ferramentas computacionais para acompanhamento do projeto . . . . . . . . 30

3.3.3 Métricas de processo e projeto de software . . . . . . . . . . . . . . . . . . . . 32

3.3.4 Técnicas de estimativa do tamanho do software . . . . . . . . . . . . . . . . . 35

iii

iv SUMÁRIO

4 Requisitos de Software 37

4.1 Conceitos Fundamentais de Engenharia de Requisitos . . . . . . . . . . . . . . . . . . 37

4.2 Processo de Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2.1 Tipos de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2 Requisitos de usabilidade, acessibilidade e segurança; . . . . . . . . . . . . . . 38

4.2.3 Técnicas de Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.4 Técnicas de Entrevistas e de Coleta de Dados . . . . . . . . . . . . . . . . . . 44

4.2.5 Formas Alternativas de Coleta de Dados . . . . . . . . . . . . . . . . . . . . . 48

Apostila de Engenharia de Software Prof. Marcelo C. Mussel

.

Capítulo 1

Engenharia de Software - Conceitos

Básicos

1.1 Introdução à Engenharia de Software

O objetivo deste curso é apresentar propostas de soluções às questões relacionadas ao desen-volvimento de software, através da transferência dos principais conceitos relativos à Engenharia deSoftware, particularmente no que diz respeito ao uso de técnicas, metodologias e ferramentas dedesenvolvimento de software.

1.1.1 Principais aspectos do software

Software: definição e características

Pode-se definir o software, numa forma clássica, como sendo: ”um conjunto de instruçõesque, quando executadas, produzem a função e o desempenho desejados, estruturas de dados quepermitam que as informações relativas ao problema a resolver sejam manipuladas adequadamentee a documentação necessária para um melhor entendimento da sua operação e uso”.

Entretanto, no contexto da Engenharia de Software, o software deve ser visto como um produtoa ser ”vendido”. É importante dar esta ênfase, diferenciando os ”programas” que são concebidos numcontexto mais restrito, onde o usuário ou ”cliente” é o próprio autor. No caso destes programas, adocumentação associada é pequena ou (na maior parte das vezes) inexistente e a preocupação coma existência de erros de execução não é um fator maior, considerando que o principal usuário é opróprio autor do programa, este não terá dificuldades, em princípio, na detecção e correção de umeventual ”bug”. Além do aspecto da correção, outras boas características não são também objeto depreocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização.

Um produto de software (ou software, como vamos chamar ao longo do curso), por outro lado,é sistematicamente destinado ao uso por pessoas outras que os seus programadores. Os eventuaisusuários podem, ainda, ter formações e experiências diferentes, o que significa que uma grandepreocupação no que diz respeito ao desenvolvimento do produto deve ser a sua interface, reforçadacom uma documentação rica em informações para que todos os recursos oferecidos possam serexplorados de forma eficiente. Ainda, os produtos de software devem passar normalmente por umaexaustiva bateria de testes, dado que os usuários não estarão interessados (e nem terão capacidade)de detectar e corrigir os eventuais erros de execução.

Resumindo, um programa desenvolvido para resolver um dado problema e um produto de soft-ware destinado à resolução do mesmo problema são duas coisas totalmente diferentes. É óbvio que oesforço e o consequente custo associado ao desenvolvimento de um produto serão muito superiores.

Dentro desta ótica, é importante, para melhor caracterizar o significado de software, é importantelevantar algumas particularidades deste, quando comparadas a outros produtos, considerando queo software é um elemento lógico e não físico como a maioria dos produtos:

1

2 Capítulo 1. Engenharia de Software - Conceitos Básicos 1.1

• o software é concebido e desenvolvido como resultado de um trabalho de enge-nharia e não manufaturado no sentido clássico;

• o software não se desgasta, ou seja, ao contrário da maioria dos produtos, o software nãose caracteriza por um aumento na possibilidade de falhas à medida que o tempo passa (comoacontece com a maioria dos produtos manufaturados);

• a maioria dos produtos de software é concebida inteiramente sob medida, sem autilização de componentes pré-existentes.

Em função destas características diferenciais, o processo de desenvolvimento de software podedesembocar um conjunto de problemas, os quais terão influência direta na qualidade do produto.

Tudo isto porque, desde os primórdios da computação, o desenvolvimento dos programas (ou,a programação) era visto como uma forma de arte, sem utilização de metodologias formais e semqualquer preocupação com a documentação, entre outros fatores importantes. A experiência doprogramador era adquirida através de tentativa e erro. A verdade é que esta tendência ainda severifica. Com o crescimento dos custos de software (em relação aos de hardware) no custo totalde um sistema computacional, o processo de desenvolvimento de software tornou-se um item defundamental importância na produção de tais sistemas.

A nível industrial, algumas questões que caracterizaram as preocupações com o processo dedesenvolvimento de software foram:

• por que o software demora tanto para ser concluído?

• por que os custos de produção têm sido tão elevados?

• por que não é possível detectar todos os erros antes que o software seja entregue ao cliente?

• por que é tão difícil medir o progresso durante o processo de desenvolvimento de software?

Estas são algumas das questões que a Engenharia de Software pode ajudar a resolver. En-quanto não respondemos definitivamente a estas questões, podemos levantar alguns dos problemasque as originam:

• raramente, durante o desenvolvimento de um software, é dedicado tempo para coletar dadossobre o processo de desenvolvimento em sí; devido à pouca quantidade deste tipo de informa-ção, as tentativas em estimar a duração/custo de produção de um software têm conduzido aresultados bastante insatisfatórios; além disso, a falta destas informações impede uma avali-ação eficiente das técnicas e metodologias empregadas no desenvolvimento;

• a insatisfação do cliente com o sistema ”concluído” ocorre frequentemente, devido, principal-mente, ao fato de que os projetos de desenvolvimento são baseados em informações vagas sobreas necessidades e desejos do cliente (problema de comunicação entre cliente e fornecedor);

• a qualidade do software é quase sempre suspeita, problema resultante da pouca atenção quefoi dada, historicamente, às técnicas de teste de software (até porque o conceito de qualidadede software é algo relativamente recente);

• o software existente é normalmente muito difícil de manter em operação, o que significaque o custo do software acaba sendo incrementado significativamente devido às atividadesrelacionadas à manutenção; isto é um reflexo da pouca importância dada à manutenibilidadeno momento da concepção dos sistemas.


1.1 1.1. Introdução à Engenharia de Software 3

1.1.2 Software: Mitos e Realidade

É possível apontar, como causas principais dos problemas levantados na seção anterior, trêsprincipais pontos:

• a falta de experiência dos profissionais na condução de projetos de software;

• a falta de treinamento no que diz respeito ao uso de técnicas e métodos formais para odesenvolvimento de software;

• a ”cultura de programação” que ainda é difundida e facilmente aceita por estudantes e profis-sionais de Ciências da Computação;

• a incrível ”resistência” às mudanças (particularmente, no que diz respeito ao uso de novastécnicas de desenvolvimento de software) que os profissionais normalmente apresentam.

Entretanto, é importante ressaltar e discutir os chamados ”mitos e realidades” do software, oque, de certo modo, explicam alguns dos problemas de desenvolvimento de software apresentados.

Mitos de Gerenciamento

Mito 1. ”Se a equipe dispõe de um manual repleto de padrões e procedimentos dedesenvolvimento de software, então a equipe está apta a encaminhar bem o desenvolvi-mento.”

Realidade 1.Isto verdadeiramente não é o suficiente... é preciso que a equipe apliqueefetivamente os conhecimentos apresentados no manual... é necessário que o que consteno dado manual reflita a moderna prática de desenvolvimento de software e que este sejaexaustivo com relação a todos os problemas de desenvolvimento que poderão aparecerno percurso...

Mito 2. ”A equipe tem ferramentas de desenvolvimento de software de última gera-ção, uma vez que eles dispõem de computadores de última geração.”

Realidade 2. Ter à sua disposição o último modelo de computador (seja ele ummainframe, estação de trabalho ou PC) pode ser bastante confortável para o desenvol-vedor do software, mas não oferece nenhuma garantia quanto à qualidade do softwaredesenvolvido. Mais importante do que ter um hardware de última geração é ter ferra-mentas para a automatização do desenvolvimento de software (as ferramentas CASE)...

Mito 3. ”Se o desenvolvimento do software estiver atrasado, basta aumentar a equipepara honrar o prazo de desenvolvimento.”

Realidade 3. Isto também dificilmente vai ocorrer na realidade... alguém disse umdia que ”... acrescentar pessoas em um projeto atrasado vai torná-lo ainda mais atra-sado...”. De fato, a introdução de novos profissionais numa equipe em fase de condução deum projeto vai requerer uma etapa de treinamento dos novos elementos da equipe; paraisto, serão utilizados elementos que estão envolvidos diretamente no desenvolvimento, oque vai, consequentemente, implicar em maiores atrasos no cronograma.

Mitos do Cliente

Mito 4. ”Uma descrição breve e geral dos requisitos do software é o suficiente parainiciar o seu projeto... maiores detalhes podem ser definidos posteriormente.”



Realidade 4. Este é um dos problemas que podem conduzir um projeto ao fracasso,o cliente deve procurar definir o mais precisamente possível todos os requisitos impor-tantes para o software: funções, desempenho, interfaces, restrições de projeto e critériosde validação são alguns dos pontos determinantes do sucesso de um projeto.

Mito 5. ”Os requisitos de projeto mudam continuamente durante o seu desenvolvi-mento, mas isto não representa um problema, uma vez que o software é flexível e poderásuportar facilmente as alterações.”

Realidade 5. É verdade que o software é flexível (pelo menos mais flexível do que amaioria dos produtos manufaturados). Entretanto, não existe software, por mais flexívelque suporte alterações de requisitos significativas com adicional zero em relação ao custode desenvolvimento. O fator de multiplicação nos custos de desenvolvimento do softwaredevido a alterações nos requisitos cresce em função do estágio de evolução do projeto,como mostra a figura 1.1.

Figura 1.1: Influência das alterações de requisitos no custo de um sistema.

Mitos do Profissional

Mito 6. ”Após a edição do programa e a sua colocação em funcionamento, o trabalhoestá terminado.”

Realidade 6. O que ocorre na realidade é completamente diferente disto. Segundodados obtidos a partir de experiências anteriores, 50 a 70% do esforço de desenvolvimentode um software é despendido após a sua entrega ao cliente (manutenção).

Mito 7. ”Enquanto o programa não entrar em funcionamento, é impossível avaliara sua qualidade.”

Realidade 7. Na realidade, a preocupação com a garantia do software deve fazerparte de todas as etapas do desenvolvimento, sendo que, ao fim de cada uma destasetapas, os documentos de projeto devem ser revisados observando critérios de qualidade.

Mito 8. ”O produto a ser entregue no final do projeto é o programa funcionando.”

Realidade 8. O programa em funcionamento é uma das componentes do soft-ware...além do software, um bom projeto deve ser caracterizado pela produção de umconjunto importante de documentos, os quais podem ser identificados com auxílio dafigura 1.2.


1.1 1.1. Introdução à Engenharia de Software 5

Figura 1.2: Influência das alterações de requisitos no custo de um sistema.

1.1.3 Princípios da Engenharia de Software

Os princípios da Engenharia de software são Formalidade,Abstração,Decomposição ,Generali-zação e Flexibilização.

Formalidade

Ter programas mais confiáveis com baixo custo e bom desempenho e o software deve ser desen-volvido de acordo com passos definidos com precisão e seguidos de maneira efetiva. A formalidadeestará contida no projeto (descrição formal), na programação (programas. são componentes for-mais), nas rotinas de teste, nos procedimentos da instalação etc.

Abstração

É o processo de identificação de um determinado fenômeno da realidade considerando apenasos aspectos mais relevantes, ou seja ignorar os detalhes.

• Modelos são abstrações da realidade.

• O sistema de informação é uma abstração do processo real.

• Linguagens de programação abstraem ao programador, detalhes da máquina e da solução(algoritmo em baixo nível)

• O encapsulamento é uma técnica de abstração para diminuir a complexidade e melhorar areusabilidade dos objetos

Decomposição

A decomposição é uma técnica utilizada para permitir que lidemos com a complexidade. É o pro-cesso de dividir o problema para que cada subproblema seja resolvido de uma maneira específica.Éusado para controlar a complexidade do software.

• Decomposição do processo

– Atividades de controle da qualidade



– Atividades de gerenciamento do cronograma

– Atividades de gerenciamento de fornecedores externos

– Atividades de teste

– Atividades de documentação

• Decomposição do produto

– Programas

– Módulos ou rotinas

– Componentes

• Programação procedural → refinamento sucessivo;

• Programação OO → Programa é um conjunto de objetos que se intercomunicam prestando/-solicitando serviços;

• Decomposição do Processo em Sub-Processos;

• Decomposição estrutural do Sistema em módulos/programas;

• Decomposição funcional do Sistema em entradas e correspondentes saídas;

Generalização

A generalização é também uma forma de abstração, buscando-se as características comuns eesquecendo-se as características específicas dos itens a serem generalizados. Uma solução mais ge-nérica tem maior potencialidade de ser reutilizada (reusabilidade e generalização dos componentes).A generalização é o processo inverso da decomposição (generalização e especialização em OO). Existeum custo do desenvolvimento associado à generalização que deve ser medido versus o benefício quese tem com a reutilização.

Flexibilização

A flexibilização irá conferir ao produto de software a facilidade de adaptação a novos ambientes,a mudanças ocorridas no ambiente, a casos de uso não implementados e às manutenções que sefizerem necessárias.

• Flexibilização do produto de software:

– Customização das saídas do sistema;

– Parametrização do processo e inclusão de variações do algoritmo original;

– Facilidade em agregar novos módulos/funções

– Facilidade em porta-lo para outras plataformas

• Flexibilização do processo de software. Procedimentos e técnicas alternativas no processo desoftware visando:

– Corrigir erros.

– Corrigir atrasos.

– Adaptar técnicas de outros paradigmas.

– Atender às constantes mudanças de requisitos.


Capítulo 2

Paradigmas de Desenvolvimento de

Software

Os problemas apontados na seção 1.1.1 não serão, é claro, resolvidos da noite para o dia, masreconhecer a existência dos problemas e definí-los da forma mais precisa e eficaz são, sem dúvida,um primeiro passo para a sua solução.

Em primeiro lugar, é preciso estar ciente também de que não existe uma abordagem mágicaque seja a melhor para a solução destes problemas, mas uma combinação de métodos que sejamabrangentes a todas as etapas do desenvolvimento de um software.

Além disto, é importante e desejável que estes métodos sejam suportados por um conjunto deferramentas que permita automatizar o desenrolar destas etapas, juntamente com uma definiçãoclara de critérios de qualidade e produtividade de software. São estes aspectos que caracterizam demaneira mais influente a disciplina de Engenharia de Software.

Num ponto de vista mais formal, a Engenharia de Software pode ser definida como sendoa aplicação da ciência e da matemática através das quais os equipamentos computacionais sãocolocados à disposição do homem por meio de programas, procedimentos e documentação associada.De modo mais objetivo, pode-se dizer que a Engenharia de Software busca prover a tecnologianecessária para produzir software de alta qualidade a um baixo custo. Os dois fatores motivadoressão essencialmente a qualidade e o custo. A qualidade de um produto de software é um parâmetrocuja quantificação não é trivial, apesar dos esforços desenvolvidos nesta direção. Por outro lado, ofator custo pode ser facilmente quantificado desde que os procedimentos de contabilidade tenhamsido corretamente efetuados.

2.1 Modelos de Desenvolvimento de software

O resultado de um esforço de desenvolvimento deve resultar normalmente num produto. Oprocesso de desenvolvimento corresponde ao conjunto de atividades e um ordenamento destas demodo a que o produto desejado seja obtido.

Um modelo de desenvolvimento corresponde a uma representação abstrata do processo de de-senvolvimento que vai, em geral, definir como as etapas relativas ao desenvolvimento do softwareserão conduzidas e interrelacionadas para atingir o objetivo do desenvolvimento que é a obtençãode um produto de software de alta qualidade a um custo relativamente baixo.

As seções que seguem vão descrever alguns dos modelos conhecidos e utilizados em desenvolvi-mento de software.

2.1.1 O Modelo Cascata

Este é o modelo mais simples de desenvolvimento de software, estabelecendo uma ordenaçãolinear no que diz respeito à realização das diferentes etapas. Como mostra a figura 2.1, o ponto departida do modelo é uma etapa de Engenharia de Sistemas, onde o objetivo é ter uma visão global do

7

8 Capítulo 2. Paradigmas de Desenvolvimento de Software 2.1

sistema como um todo (incluindo hardware, software, equipamentos e as pessoas envolvidas) comoforma de definir precisamente o papel do software neste contexto. Em seguida, a etapa de Análisede Requisitos vai permitir uma clara definição dos requisitos de software, sendo que o resultado seráutilizado como referência para as etapas posteriores de Projeto, Codificação, Teste e Manutenção.

Figura 2.1: Modelo Cascata.

O modelo Cascata apresenta características interessantes, particularmente em razão da definiçãode um ordenamento linear das etapas de desenvolvimento. Primeiramente, como forma de identificarprecisamente o fim de uma etapa e o início da seguinte, um mecanismo de certificação (ou revisão)é implementado ao final de cada etapa; isto é feito normalmente através da aplicação de algummétodo de validação ou verificação, cujo objetivo será garantir de que a saída de uma dada etapa écoerente com a sua entrada (a qual já é a saída da etapa precedente). Isto significa que ao final decada etapa realizada, deve existir um resultado (ou saída) a qual possa ser submetida à atividadede certificação.

Estas saídas, obtidas ao final de cada etapa, são vistas como produtos intermediários e apresentam-se, normalmente, na forma de documentos (documento de especificação de requisitos, documentode projeto do sistema, etc...).

Outra característica importante deste modelo é que as saídas de uma etapa são as entradas daseguinte, o que significa que uma vez definidas, elas não devem, em hipótese alguma ser modificadas.

Duas diretivas importantes que norteiam o desenvolvimento segundo o modelo Cascata são:

• todas as etapas definidas no modelo devem ser realizadas, isto porque, em projetos de grandecomplexidade, a realização formal destas vai determinar o sucesso ou não do desenvolvimento;a realização informal e implícita de algumas destas etapas poderia ser feita apenas no caso deprojetos de pequeno porte;

• a ordenação das etapas na forma como foi apresentada deve ser rigorosamente respeitada;apesar de que esta diretiva poderia ser questionada, a ordenação proposta pelo modelo, porser a forma mais simples de desenvolver, tem sido também a mais adotada a nível de projetosde software.

É importante lembrar, também que os resultados de um processo de desenvolvimento de softwarenão devem ser exclusivamente o programa executável e a documentação associada. Existe umaquantidade importante de resultados (ou produtos intermediários) os quais são importantes parao sucesso do desenvolvimento. Baseados nas etapas apresentadas na figura 2.1, é possível listar osresultados mínimos esperados de um processo de desenvolvimento baseado neste modelo: Documentode Especificação de Requisitos, Projeto do Sistema, Plano de Teste e Relatório de Testes, CódigoFinal, Manuais de Utilização, Relatórios de Revisões.

Apesar de ser um modelo bastante popular, pode-se apontar algumas limitações:


2.1 2.1. Modelos de Desenvolvimento de software 9

• o modelo assume que os requisitos são inalterados ao longo do desenvolvimento; isto em boaparte dos casos não é verdadeira, uma vez que nem todos os requisitos são completamentedefinidos na etapa de análise;

• muitas vezes, a definição dos requisitos pode conduzir à definição do hardware sobre o qualo sistema vai funcionar; dado que muitos projetos podem levar diversos anos para seremconcluídos, estabelecer os requisitos em termos de hardware é um tanto temeroso, dadas asfrequentes evoluções no hardware;

• o modelo impõe que todos os requisitos sejam completamente especificados antes do prossegui-mento das etapas seguintes; em alguns projetos, é às vezes mais interessante poder especificarcompletamente somente parte do sistema, prosseguir com o desenvolvimento do sistema, e sóentão encaminhar os requisitos de outras partes; isto não é previsto a nível do modelo;

• as primeiras versões operacionais do software são obtidas nas etapas mais tardias do processo,o que na maioria das vezes inquieta o cliente, uma vez que ele quer ter acesso rápido ao seuproduto.

De todo modo, pode vir a ser mais interessante a utilização deste modelo para o desenvolvimentode um dado sistema do que realizar um desenvolvimento de maneira totalmente anárquica e informal.

2.1.2 Prototipação

O objetivo da Prototipação é buscar contornar algumas das limitações existentes no modeloCascata. A idéia por trás deste modelo é eliminar a política de ”congelamento” dos requisitos antesdo projeto do sistema ou da codificação.

Isto é feito através da obtenção de um protótipo, com base no conhecimento dos requisitos iniciaispara o sistema. O desenvolvimento deste protótipo é feito obedecendo à realização das diferentesetapas já mencionadas, a saber, a análise de requisitos, o projeto, a codificação e os testes, sendoque não necessariamente estas etapas sejam realizadas de modo muito explícito ou formal.

Este protótipo pode ser oferecido ao cliente em diferentes formas, a saber:

• protótipo em papel ou modelo executável em PC retratando a interface homem-máquinacapacitando o cliente a compreender a forma de interação com o software;

• um protótipo de trabalho que implemente um subconjunto dos requisitos indicados;

• um programa existente (pacote) que permita representar todas ou parte das funções desejadaspara o software a construir.

Colocado à disposição do cliente, o protótipo vai ajudá-lo a melhor compreender o que será osistema desenvolvido. Além disso, através da manipulação deste protótipo, é possível validar oureformular os requisitos para as etapas seguintes do sistema.

Este modelo, ilustrado na figura 2.2, apresenta algumas características interessantes, tais como:

• é um modelo de desenvolvimento interessante para alguns sistemas de grande porte os quaisrepresentem um certo grau de dificuldade para exprimir rigorosamente os requisitos;

• através da construção de um protótipo do sistema, é possível demonstrar a realizabilidade domesmo;

• é possível obter uma versão, mesmo simplificada do que será o sistema, com um pequenoinvestimento inicial.



Figura 2.2: Esquema de evolução da prototipação.

Os protótipos não são sistemas completos e deixam, normalmente, a desejar em alguns aspectos.Um destes aspectos é normalmente a interface com o usuário. Os esforços de desenvolvimento sãoconcentrados principalmente nos algoritmos que implementem as principais funções associadas aosrequisitos apresentados, a interface sendo, a este nível parte supérflua do desenvolvimento, o quepermite caracterizar esta etapa por um custo relativamente baixo.

Por outro lado, a experiência adquirida no desenvolvimento do protótipo vai ser de extremautilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo reduzir certamenteo seu custo, resultando também num sistema melhor concebido.

2.1.3 Desenvolvimento Iterativo

Este modelo também foi concebido com base numa das limitações do modelo Cascata e combinaas vantagens deste modelo com as do modelo Prototipação. A idéia principal deste modelo, ilustradana figura 2.3, é a de que um sistema deve ser desenvolvido de forma incremental, sendo que cadaincremento vai adicionando ao sistema novas capacidades funcionais, até a obtenção do sistemafinal, sendo que, a cada passo realizado, modificações podem ser introduzidas.

Uma vantagem desta abordagem é a facilidade em testar o sistema, uma vez que a realizaçãode testes em cada nível de desenvolvimento é, sem dúvida, mais fácil do que testar o sistema final.Além disso, como na Prototipação, a obtenção de um sistema, mesmo incompleto num dado nível,pode oferecer ao cliente interessantes informações que sirvam de subsídio para a melhor definiçãode futuros requisitos do sistema.

No primeiro passo deste modelo uma implementação inicial do sistema é obtida, na forma deum subconjunto da solução do problema global. Este primeiro nível de sistema deve contemplaros principais aspectos que sejam facilmente identificáveis no que diz respeito ao problema a serresolvido.

Um aspecto importante deste modelo é a criação de uma lista de controle de projeto, a qual deveapresentar todos os passos a serem realizados para a obtenção do sistema final. Ela vai servir tambémpara se medir, num dado nível, o quão distante se está da última iteração. Cada iteração do modelode Desenvolvimento Iterativo consiste em retirar um passo da lista de controle de projeto atravésda realização de três etapas: o projeto, a implementação e a análise. O processo avança, sendo quea cada etapa de avaliação, um passo é retirado da lista, até que a lista esteja completamente vazia.A lista de controle de projeto gerencia todo o desenvolvimento, definindo quais tarefas devem serrealizadas a cada iteração, sendo que as tarefas na lista podem representar, inclusive, redefiniçõesde componentes já implementados, em razão de erros ou problemas detectados numa eventual etapade análise.

2.1.4 O Modelo Espiral

Este modelo, proposto em 1988, sugere uma organização das atividades em espiral, a qualé composta de diversos ciclos. Como mostrado na figura 2.4, a dimensão vertical representa ocusto acumulado na realização das diversas etapas; a dimensão angular representa o avanço dodesenvolvimento ao longo das etapas.


2.1 2.1. Modelos de Desenvolvimento de software 11

Figura 2.3: O modelo Desenvolvimento Iterativo.

Cada ciclo na espiral inicia com a identificação dos objetivos e as diferentes alternativas parase atingir aqueles objetivos assim como as restrições impostas. O próximo passo no ciclo é a avali-ação das diferentes alternativas com base nos objetivos fixados, o que vai permitir também definirincertezas e riscos de cada alternativa. No passo seguinte, o desenvolvimento de estratégias permi-tindo resolver ou eliminar as incertezas levantadas anteriormente, o que pode envolver atividadesde prototipação, simulação, avaliação de desempenho, etc... Finalmente, o software é desenvolvidoe o planejamento dos próximos passos é realizado.

A continuidade do processo de desenvolvimento é definida como função dos riscos remanescentes,como por exemplo, a decisão se os riscos relacionados ao desempenho ou à interface são maisimportantes do que aqueles relacionados ao desenvolvimento do programa. Com base nas decisõestomadas, o próximo passo pode ser o desenvolvimento de um novo protótipo que elimine os riscosconsiderados.

Por outro lado, caso os riscos de desenvolvimento de programa sejam considerados os maisimportantes e se o protótipo obtido no passo corrente já resolve boa parte dos riscos ligados adesempenho e interface, então o próximo passo pode ser simplesmente a evolução segundo o modeloCascata.

Como se pode ver, o elemento que conduz este processo é essencialmente a consideração sobre osriscos, o que permite, de certo modo, a adequação a qualquer política de desenvolvimento (baseadaem especificação, baseada em simulação, baseada em protótipo, etc...).

Figura 2.4: O modelo Espiral.

Uma característica importante deste modelo é o fato de que cada ciclo é encerrado por umaatividade de revisão, onde todos os produtos do ciclo são avaliados, incluindo o plano para o próximopasso (ou ciclo). Numa aplicação típica do modelo, pode-se imaginar a realização de um ciclo zero,onde se avalie a realizabilidade do projeto, o resultado devendo ser a conclusão de que será possívelimplementar ou não o projeto de desenvolvimento. As alternativas consideradas neste caso são demuito alto nível, como por exemplo, se a organização deve desenvolver o sistema ela própria ou sedeve contratar o desenvolvimento junto a uma empresa especializada.



O modelo se adequa principalmente a sistemas que representem um alto risco de investimentopara o cliente.

2.2 Ciclos de Desenvolvimento de Software

Analisando os modelos apresentados na seção precedente, é possível observar que, apesar deapresentar denominações às vezes diferentes e de estarem associadas de modo relativamente distinto,as etapas apresentadas são caracterizadas por atividades similares.

De um modo geral, pode-se organizar o processo de desenvolvimento de um software a partir detrês grandes fases: a fase de definição, a fase de desenvolvimento e a fase de manutenção as quaisserão discutidas nas seções abaixo.

2.2.1 Fase de Definição

A fase de definição está associada à determinação do que vai ser feito. Nesta fase, o profissi-onal encarregado do desenvolvimento do software deve identificar as informações que deverão sermanipuladas, as funções a serem processadas, qual o nível de desempenho desejado, que interfa-ces devem ser oferecidas, as restrições do projeto e os critérios de validação. Isto terá de ser feitonão importando o modelo de desenvolvimento adotado para o software e independente da técnicautilizada pra fazê-lo.

Esta fase é caracterizada pela realização de três etapas específicas:

• a Análise (ou Definição) do Sistema, a qual vai permitir determinar o papel de cadaelemento (hardware, software, equipamentos, pessoas) no sistema, cujo objetivo é determinar,como resultado principal, as funções atribuídas ao software;

• o Planejamento do Projeto de Software, no qual, a partir da definição do escopo dosoftware, será feita uma análise de riscos e a definição dos recursos, custos e a programaçãodo processo de desenvolvimento;

• a Análise de Requisitos, que vai permitir determinar o conjunto das funções a seremrealizadas assim como as principais estruturas de informação a serem processadas.

2.2.2 Fase de Desenvolvimento

Nesta fase, será determinado como realizar as funções do software. Aspectos como a arquiteturado software, as estruturas de dados, os procedimentos a serem implementados, a forma como oprojeto será transformado em linguagem de programação, a geração de código e os procedimentosde teste devem ser encaminhados nesta fase.

Normalmente, esta fase é também organizada em três principais etapas:

• o Projeto de Software, o qual traduz, num conjunto de representações gráficas, tabularesou textuais, os requisitos do software definidos na fase anterior; estas representações (diversastécnicas de representação podem ser adotadas num mesmo projeto) permitirão definir, comum alto grau de abstração, aspectos do software como a arquitetura, os dados, lógicas decomportamento (algoritmos) e características da interface;

• a Codificação, onde as representações realizadas na etapa de projeto serão mapeadas numaou em várias linguagens de programação, a qual será caracterizada por um conjunto de ins-truções executáveis no computador; nesta etapa, considera-se também a geração de código deimplementação, aquele obtido a partir do uso de ferramentas (compiladores, linkers, etc...) eque será executado pelo hardware do sistema;

• os Testes de Software, onde o programa obtido será submetido a uma bateria de testes paraverificar (e corrigir) defeitos relativos às funções, lógica de execução, interfaces, etc...


2.3 2.3. Modelos de Melhoria do Processo de Desenvolvimento 13

2.2.3 Fase de Manutenção

A fase de manutenção, que se inicia a partir da entrega do software, é caracterizada pela reali-zação de alterações de naturezas as mais diversas, seja para corrigir erros residuais da fase anterior,para incluir novas funções exigidas pelo cliente, ou para adaptar o software a novas configuraçõesde hardware.

Sendo assim, pode-se caracterizar esta fase pelas seguintes atividades:

• a Correção ou Manutenção Corretiva, a qual consiste da atividade de correção de errosobservados durante a operação do sistema;

• a Adaptação ou Manutenção Adaptativa, a qual realiza alterações no software para queele possa ser executado sobre um novo ambiente (CPU, arquitetura, novos dispositivos dehardware, novo sistema operacional, etc...);

• o Melhoramento Funcional ou Manutenção Perfectiva, onde são realizadas alteraçõespara melhorar alguns aspectos do software, como por exemplo, o seu desempenho, a suainterface, a introdução de novas funções, etc...

A manutenção do software envolve, normalmente, etapas de análise do sistema existente (enten-dimento do código e dos documentos associados), teste das mudanças, teste das partes já existentes,o que a torna uma etapa complexa e de alto custo.

Além disso, considerando a atual situação industrial, foi criado, mais recentemente, o conceito deEngenharia Reversa, onde, através do uso das técnicas e ferramentas da Engenharia de Software,o software existente sofre uma ”reforma geral”, cujo objetivo é aumentar a sua qualidade e atualizá-locom respeito às novas tecnologias de interface e de hardware.

2.3 Modelos de Melhoria do Processo de Desenvolvimento

A causa mais comum do insucesso dos projetos de desenvolvimento de software é a má utilizaçãoou a completa indiferença aos métodos e ferramentas orientados à concepção. É possível que, emempresas de desenvolvimento de software onde o uso de metodologias consistentes não seja práticaadotada, os projetos possam ter bons resultados. Mas, em geral, estes bons resultados são muitomais uma consequência de esforços individuais do que propriamente causadas pela existência deuma política e de uma infra-estrutura adequada à produção de software.

2.3.1 O Modelo CMM - Capability Maturity Model

O modelo CMM - Capability Maturity Model - foi definido pelo SEI - Software Engineering Ins-titute - com o objetivo de estabelecer conceitos relacionados aos níveis de maturidade das empresasde desenvolvimento de software, com respeito ao grau de evolução que estas se encontram nos seusprocessos de desenvolvimento.

O modelo estabelece também que providências as empresas podem tomar para aumentarem,gradualmente o seu grau de maturidade, melhorando, por consequência, sua produtividade e aqualidade do produto de software.

Um Processo de Desenvolvimento de Software corresponde ao conjunto de atividades,métodos, práticas e transformações que uma equipe utiliza para desenvolver e manter software eseus produtos associados (planos de projeto, documentos de projeto, código, casos de teste e manuaisde usuário). Uma empresa é considerada num maior grau de maturidade quanto mais evoluído foro seu processo de desenvolvimento de software.

A Capabilidade de um processo de software está relacionada aos resultados que podem serobtidos pela sua utilização num ou em vários projetos. Esta definição permite estabelecer umaestimação de resultados em futuros projetos.



O Desempenho de um processo de software representa os resultados que são correntementeobtidos pela sua utilização. A diferença básica entre estes dois conceitos está no fato de que, enquantoo primeiro, está relacionado aos resultados ”esperados”, o segundo, relaciona-se aos resultados queforam efetivamente obtidos.

A Maturidade de um processo de software estabelece os meios pelos quais ele é definido,gerenciado, medido, controlado e efetivo, implicando num potencial de evolução da capabilidade.Numa empresa com alto grau de maturidade, o processo de desenvolvimento de software é bementendido por todo o staff técnico, graças à existência de documentação e políticas de treinamento,e que este é continuamente monitorado e aperfeiçoado por seus usuários.

À medida que uma organização cresce em termos de maturidade, ela institucionaliza seu pro-cesso de desenvolvimento de software através de políticas, normas e estruturas organizacionais,as quais geram uma infra-estrutura e uma cultura de suporte aos métodos e procedimentos dedesenvolvimento.

O modelo CMM define cinco níveis de maturidade no que diz respeito ao processo de desenvol-vimento de software adotado a nível das empresas, estabelecendo uma escala ordinal que conduz asempresas ao longo de seu aperfeiçoamento.

Um nível de maturidade é um patamar de evolução de um processo de desenvolvimento desoftware, correspondendo a um degrau na evolução contínua de cada organização. A cada nívelcorresponde um conjunto de objetivos que, uma vez atingidos, estabilizam um componente funda-mental do processo de desenvolvimento de software, tendo como consequência direta o aumento dacapabilidade da empresa.

A figura 2.5 apresenta os cinco níveis de maturidade propostos no modelo CMM, na qual sepode observar também o estabelecimento de um conjunto de ações que permitirão a uma empresasubir de um degrau para o outro nesta escala.

Figura 2.5: Os níveis de maturidade de um processo de desenvolvimento de software.

Nível Inicial

No nível inicial, o desenvolvimento de software é realizado de forma totalmente ”ad hoc”, semuma definição de processos. No caso de problemas que venham a ocorrer durante a realização deum projeto, a organização tem uma tendência a abandonar totalmente os procedimentos planejadose passa a um processo de codificação e testes, onde o produto obtido pode apresentar um nível dequalidade suspeito.

A capabilidade de uma empresa caracterizada como nível 1 é totalmente imprevisível, uma vezque o processo de desenvolvimento de software é instável, sujeito a mudanças radicais frequentes,não apenas de um projeto a outro, mas também durante a realização de um mesmo projeto.

Neste nível, estimação de custos, prazos e qualidade do produto é algo totalmente fora docontexto e da política de desenvolvimento (que política?).

Embora não se possa ”assegurar” o fracasso de um projeto desenvolvido por uma empresa situadaneste nível, é possível dizer que o sucesso é, geralmente, resultado de esforços individuais, variandocom as habilidades naturais, o conhecimento e as motivações dos profissionais envolvidos no projeto.



Nível Repetível

Neste nível, políticas de desenvolvimento de software e tarefas de suporte a estas políticas sãoestabelecidas, o planejamento de novos projetos sendo baseado na experiência obtida com projetosanteriores.

Para que uma empresa possa atingir este nível, é imprescindível institucionalizar o gerenciamentoefetivo dos seus projetos de software, de modo que o sucesso de projetos anteriores possam serrepetidos nos projetos em curso.

Neste nível, os requisitos do software e o trabalho a ser feito para satisfazê-los são planejados esupervisionados ao longo da realização do projeto. São definidos padrões de projeto, e a instituiçãodeve garantir a sua efetiva implementação.

A capabilidade de uma empresa situada neste nível pode ser caracterizada como disciplinada,em razão dos esforços de gerenciamento e acompanhamento do projeto de software.

Nível Definido

No nível definido, o processo de desenvolvimento de software é consolidado tanto do ponto devista do gerenciamento quanto das tarefas de engenharia a realizar; isto é feito através de documen-tação, padronização e integração no contexto da organização, que adota esta versão para produzire manter o software.

Os processos definidos nas organizações situadas neste nível são utilizados como referência paraos gerentes de projeto e os membros do staff técnico, sendo baseado em práticas propostas pelaEngenharia de Software.

Programas de treinamento são promovidos ao nível da organização, como forma de difundir epadronizar as práticas adotadas no processo definido.

As características particulares de cada projeto podem influir no aprimoramento de um processode desenvolvimento, sendo que para cada projeto em desenvolvimento, este pode ser instanciado.

Um processo de desenvolvimento bem definido deve conter padrões, procedimentos para o de-senvolvimento das atividades envolvidas, mecanismos de validação e critérios de avaliação.

A capabilidade de uma empresa no nível 3 é caracterizada pela padronização e consistência,uma vez que as políticas de gerenciamento e as práticas da Engenharia de Software são aplicadasde forma efetiva e repetida.

Nível Gerenciado

No nível gerenciado, é realizada a coleta de medidas do processo e do produto obtido, o quevai permitir um controle sobre a produtividade (do processo) e a qualidade (do produto).

É definida uma base de dados para coletar e analisar os dados disponíveis dos projetos de soft-ware. Medidas consistentes e bem definidas são, então, uma característica das organizações situadasneste nível, as quais estabelecem uma referência para a avaliação dos processos de desenvolvimentoe dos produtos.

Os processos de desenvolvimento exercem um alto controle sobre os produtos obtidos; as varia-ções de desempenho do processo podem ser separadas das variações ocasionais (ruídos), principal-mente no contexto de linhas de produção definidas. Os riscos relacionados ao aprendizado de novastecnologias ou sobre um novo domínio de aplicação são conhecidos e gerenciados cuidadosamente.

A capabilidade de uma organização situada este nível é caracterizada pela previsibilidade, umavez que os processos são medidos e operam em limites conhecidos.

Nível Otimizado

No nível otimizado, a organização promove contínuos aperfeiçoamentos no processo de de-senvolvimento, utilizando para isto uma realimentação quantitativa do processo e aplicando novasideias e tecnologias. Os aperfeiçoamentos são definidos a partir da identificação dos pontos fracose imperfeições do processo corrente e do estabelecimento das alterações necessárias para evitar a



ocorrência de falhas. Análises de custo/benefício são efetuadas sobre o processo de desenvolvimentocom base em dados extraídos de experiências passadas.

Quando os problemas relacionados à adoção de um dado processo de desenvolvimento não podemser totalmente eliminados, os projetos são cuidadosamente acompanhados para evitar a ocorrênciade problemas inerentes do processo.

Definição operacional do modelo CMM

O modelo CMM, além de definir os níveis de maturidade acima descritos, detalha, cada umdeles, com respeito aos objetivos essenciais de cada um e das tarefas chave a serem implementadaspara que estes objetivos sejam atingidos.

Para isto, foi realizado, à exceção do nível 1, um detalhamento nos diferentes níveis, estabe-lecendo uma estrutura que permitisse caracterizar a maturidade e a capabilidade do processo dedesenvolvimento de software. A figura 2.6 ilustra os componentes relacionados a este detalhamento.

Figura 2.6: Estrutura dos níveis CMM.

Como se pode notar na figura 2.6, cada nível de maturidade é composto por diversas ÁreasChave, as quais identificam um conjunto de atividades que, quando realizadas conjuntamente, per-mitem atingir os objetivos essenciais do nível considerado, aumentando a capabilidade do processode desenvolvimento de software.

A Tabela 2.1 apresenta as áreas chave associadas a cada um dos níveis do CMM (à exceção donível 1, como já foi explicado).

Os Fatores Comuns indicam o grau de implementação ou institucionalização de uma dadaÁrea Chave. No modelo, os Fatores Comuns foram definidos em número de cinco, como mostra aTabela 2.2.

As Tarefas Chave correspondem às atividades que, uma vez realizadas de modo conjunto,contribuirão para o alcance dos objetivos da área chave. As tarefas chave descrevem a infra-estruturae as atividades que deverão ser implementadas para a efetiva implementação ou institucionalizaçãoda área chave. As tarefas chave correspondem a uma sentença simples, seguida por uma descriçãodetalhada a qual pode incluir exemplos.

A figura 2.7 apresenta um exemplo de estrutura de uma tarefa chave para a Área Chave dePlanejamento do Projeto de Software.

Utilização do modelo CMM

O objetivo fundamental do estabelecimento deste modelo é fornecer parâmetros para:

• de um lado, que as instituições que pretendam contratar fornecedores de software possamavaliar as capacidades destes fornecedores;



Nível Áreas Chave

Repetível (2)

Gerenciamento de requisitosPlanejamento do processo de desenvolvimentoAcompanhamento do projetoGerenciamento de subcontrataçãoGarantia de qualidadeGerenciamento de configuração

Definido (3)

Ênfase ao processo na organizaçãoDefinição do processo na organizaçãoPrograma de treinamentoGerenciamento integradoEngenharia de softwareCoordenação intergrupoAtividades de revisão

Gerenciado (4)Gerenciamento da qualidade de softwareGerenciamento quantitativo do processo

Otimizado (5)Prevenção de falhasGerenciamento de mudança de tecnologiaGerenciamento de mudança do processo

Tabela 2.1: Áreas Chave por nível de maturidade

Fator Comum Objetivos

Passível de realizaçãoDescreve as ações a realizar para definir e estabilizarum processo

Capacidade de realizaçãoDefine pré-condições necessárias no projeto ou organizaçãopara implementar o processo de modo competente

Atividades realizadasDescreve os procedimentos necessários para implementaruma área chave

Medidas e análisesIndica a necessidade de realização de atividades de medição eanálise de medidas

Verificação da implementaçãoCorresponde aos passos necessários para assegurar quetodas as tarefas foram realizadas adequadamente

Tabela 2.2: Fatores comuns

Figura 2.7: Exemplo de uma tarefa chave numa estrutura CMM.



• por outro lado, para que as empresas de desenvolvimento de software possam identificar quaisos procedimentos a serem implementados ou institucionalizados no âmbito da organização demodo a aumentar a capabilidade do seu processo de software.

Embora os dois objetivos sejam diferentes, é definido no modelo um procedimento similar paraa realização dos dois tipos de análise. As etapas deste procedimento, descritas a seguir, deverão serrealizadas num esquema sequencial:

• seleção de uma equipe, cujos elementos serão treinados segundo os conceitos básicos do modeloCMM, sendo que estes já deverão ter conhecimentos de engenharia de software e gerenciamentode projetos;

• selecionar profissionais representantes da organização, para os quais será aplicado um questi-onário de maturidade;

• analisar as respostas obtidas do questionário de maturidade, procurando identificar as áreaschave;

• realizar uma visita (da equipe) à organização para a realização de entrevistas e revisões dedocumentação relacionadas ao processo de desenvolvimento; as entrevistas e revisões deverãoser conduzidas pelas áreas chave do CMM e pela análise realizada sobre o questionário dematuridade;

• ao fim da visita, a equipe elabora um relatório enumerando os pontos fortes e os pontos fracosda organização em termos de processo de desenvolvimento de software;

• finalmente, a equipe prepara um perfil de áreas chave, que indica as áreas onde a organizaçãoatingiu/não atingiu os objetivos de cada área.

SW-CMM

O CMM que é conhecido pelo público geral é mais propriamente chamado de Software-CMM (ouCMM para software). Isto porque diversos outros CMMs foram criados, procurando cobrir outrasáreas de interesse. Assim, surgiram os seguintes modelos:

• CMMI: CMM Integration

• SW-CMM: Capability Maturity Model for Software

• P-CMM: People Capability Maturity Model

– avalia a maturidade da organização em seus processos de administração de recursoshumanos no que se refere a software; recrutamento e seleção de desenvolvedores, treina-mento, remuneração etc.

• SA-CMM: Software Acquisition Capability Maturity Model

– usado para avaliar a maturidade de uma organização em seus processos de seleção, com-pra e instalação de software desenvolvido por terceiros.

• SE-CMM: Systems Engineering Capability Maturity Model

– avalia a maturidade da organização em seus processos de engenharia de sistemas, con-cebidos como algo maior que o software. Um ”sistema” inclui o hardware, o software equaisquer outros elementos que participam do produto completo. Se um novo Boeingestá sendo desenvolvido, o avião é o ”sistema”, incluindo aí todo o software que neleesteja embarcado.



• IPD-CMM: Integrated Product Development Capability Maturity Model

– ainda mais abrangente que o SE-CMM, inclui também outros processos necessários àprodução e suporte ao produto, tais como suporte ao usuário, processos de fabricaçãoetc.

• O surgimento de todos estes modelos gerou alguns problemas:

– Nem todos usavam a mesma terminologia, de modo que um mesmo conceito podia recebernomes diferentes em cada modelo, ou que o mesmo termo quisesse dizer coisas diferentesnos vários modelos.

– A estrutura carecia de um formato padrão. Os modelos tinham diferentes números deníveis ou formas diferentes de avaliar o progresso.

– Altos custos de treinamento, avaliação e harmonização para organizações que tentassemusar mais de um modelo.

• Por outro lado, a experiência no uso do SW-CMM durante uma década serviu para identificarpontos em que o modelo poderia ser melhorado.

Figura 2.8: Modelos CMM.

2.3.2 CMMI - Capability Maturity Model Integrated

Seus principais objetivos são:

• Suprir as limitações do modelo CMM, com a criação de um framework comum, eliminandoinconsistências e permitindo a inclusão de novos modelos ao longo do tempo, sempre quesurgirem necessidades específicas.

• Preservar os investimentos já realizados pelos organismos governamentais, pelas empresasprivadas, pelos fornecedores e pela indústria no processo de transição

• Unificar os vários modelos CMM existentes

• Propiciar melhorias no SW-CMM a partir das experiências adquiridas com os projetos jáimplementados.



• Reduzir custo do treinamento das implementações de melhorias e da formação de avaliadoresoficiais.

A principal mudança do CMMI em relação ao SW-CMM é a possibilidade de utilização deduas diferentes abordagens para a melhoria de processos. Estas abordagens são conhecidas como omodelo contínuo e o modelo em estágios.

O SW-CMM é um modelo em estágios. Existem cinco níveis de maturidade, e a organizaçãoé avaliada como estando em apenas um deles. Em cada nível, a partir do segundo, existem aschamadas ”áreas chave do processo”. O SW-CMM possui 18 áreas-chave, e cada uma situa-se emapenas um nível. Assim, para uma organização estar no nível 2, é necessário que as 6 áreas-chavedeste nível estejam institucionalizadas.

Uma organização no nível 2 pode, por exemplo, possuir práticas de níveis mais altos, mas serapenas nível 2, por não possuir o conjunto completo das áreas do nível mais alto.

No modelo contínuo cada área-chave de processo possui características relativas a mais deum nível. Neste modelo, cada área-chave é classificada separadamente, de modo que a organizaçãopode ter áreas no nível 1, outras no nível 2, ainda outras no nível 3 e assim por diante.

A representação por estágios (staged) tem por foco a maturidade organizacional e provêum caminho evolutivo para a melhoria do processo. Esta representação direciona e auxilia às or-ganizações que desejam estabelecer a melhoria de processos de software. As áreas do processo sãoagrupadas em níveis de maturidade, que devem ser atendidas na sua totalidade para viabilizar umestágio definido de melhorias.

Já a representação contínua (continuous) tem por foco a capabilidade do processo e ofereceum caminho flexível para a implementação de melhorias. Permite que as organizações escolhamáreas específicas do processo para a implementação de melhorias, bem como implementar níveisdiferentes de capabilidade para diferentes processos.

A estrutura do CMMI apresenta algumas diferenças em relação ao CMM. Quanto aos níveis dematuridade, o foco do nível 2 de maturidade dos dois modelos se concentra nas práticas relacionadascom a gerência de projetos. Na representação por estágios a única diferença é a inclusão no CMMIda Área de Processo (PA - Process Área) Measurement and Analysis, que no SW-CMM era umacaracterística comum.

Já para os demais níveis de maturidades, de modo resumido, as seguintes modificações foramintroduzidas:

• No nível 3: Duas novas PAs foram criadas: Risk Management e Decision Analysis and Reso-lution.

• A maior alteração se deu na KPA de software Product Engineering, que foi expandida em seisáreas de processo, oferecendo uma maior cobertura para o ciclo de vida do software.

• A KPA PR do SW-CMM está contida na PA Verification do CMMI.

• Nível 4 poucas alterações em termos do número de práticas: 2 KPAs no SW-CMM e 2 PAsno CMMI.

• Nível 5 - poucas alterações em termos do número de práticas: 3 KPAs no SW-CMM / 2 PAsno CMMI.

O CMMI adotada outro método de avaliação, o SCAMPI (Standart CMMI Appraisal Methodfor Process Improvement), baseado no ARC (Appraisal Requirements for CMMI), combina as ca-racterísticas do CBA-IPI e SCE e também pode suportar a condução de avaliações ISO/IEC 15504(SPI CE). O SCAMPI avalia o processo de engenharia (software, sistemas e hardware) e tantopode ser utilizado para avaliar a maturidade de um processo de software como a capabilidade deprocessos para efeito de benchmarking entre organizações. A avaliação oficial é conduzida por umLead Appraiser e possui uma maior ênfase na coleta e análise de dados, buscando mais evidências.



2.3.3 MPS.BR

O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvol-vimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência doSoftware Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT),da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento(BID).

A coordenação do Programa MPS.BR conta com duas estruturas de apoio para o desenvolvi-mento de suas atividades, o Fórum de Credenciamento e Controle (FCC) e a Equipe Técnica doModelo (ETM). Através destas estruturas, o MPS.BR obtém a participação de representantes deUniversidades, Instituições Governamentais, Centros de Pesquisa e de organizações privadas, osquais contribuem com suas visões complementares que agregam qualidade ao empreendimento.

O FCC tem como principais objetivos assegurar que as Instituições Implementadoras (II) eInstituições Avaliadoras (IA) sejam submetidas a um processo adequado de credenciamento e quesuas atuações não se afastem dos limites éticos e de qualidade esperados, além de avaliar e atuarsobre o controle dos resultados obtidos pelo MPS.BR.

Por outro lado, cabe a ETM atuar sobre os aspectos técnicos relacionados ao Modelo de Refe-rência (MR-MPS) e Método de Avaliação (MA-MPS), tais como a concepção e evolução do modelo,elaboração e atualização dos Guias do MPS.BR, preparação de material e definição da forma de trei-namento e de aplicação de provas, publicação de Relatórios Técnicos e interação com a comunidadevisando a identificação e aplicação de melhores práticas.

Em 2003, no início da concepção do MPS.BR, dados da Secretaria de Política de Informáticae Tecnologia do Ministério da Ciência e Tecnologia (MCT/SEITEC), mostravam que apenas 30empresas no Brasil possuíam avaliação SW-CMM (Capability Maturity Model): 24 no nível 2; 5no nível 3; 1 no nível 4; e nenhuma no nível 5. Observando-se esta pirâmide pôde-se concluir quea qualidade do processo de software no Brasil podia ser dividida em dois tipos de empresas. Notopo da pirâmide, normalmente, estavam as empresas exportadoras de software e outras grandesempresas que desejavam atingir níveis mais altos de maturidade (4 ou 5) do CMMI-SE/SW porestágio e serem formalmente avaliadas pelo SEI (Software Engineering Institute), em um esforçoque pode levar de 4 a 10 anos. Na base da pirâmide, em geral, encontrava-se a grande massa demicro, pequenas e médias empresas de software brasileiras, com poucos recursos e que necessitamobter melhorarias significativas nos seus processos de software em 1 ou 2 anos.

O foco principal do MPS.BR, embora não exclusivo, está neste segundo grupo de empresas.Busca-se que ele seja adequado ao perfil de empresas com diferentes tamanhos e características,públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Tambémespera-se que o MPS.BR seja compatível com os padrões de qualidade aceitos internacionalmentee que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões emodelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos deprocessos definidos nos modelos de melhoria de processo e atende a necessidade de implantar osprincípios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras,estando em consonância com as principais abordagens internacionais para definição, avaliação emelhoria de processos de software.

O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliaçãoe melhoria da qualidade e produtividade de produtos de software e serviços correlatos. Dentrodesse contexto, o MPS.BR possui três componentes: Modelo de Referência (MR-MPS), Método deAvaliação (MA-MPS) e Modelo de Negócio (MN-MPS).

O MPS.BR está descrito através de documentos em formato de guias:

• Guia Geral: contém a descrição geral do MPS.BR e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação.

• Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. Édescrito como forma de apoiar as instituições que queiram adquirir produtos de software eserviços correlatos apoiando-se no MR-MPS.



• Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitospara avaliadores líder, avaliadores adjuntos e Instituições Avaliadoras (IA).

Figura 2.9: Componentes do MPS.BR

Descrição do MR-MPS

O Modelo de Referência MR-MPS define níveis de maturidade que são uma combinação entreprocessos e sua capacidade.

Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando es-tágios de melhoria da implementação de processos na organização. O nível de maturidade em quese encontra uma organização permite prever o seu desempenho futuro ao executar um ou maisprocessos. O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quan-titativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado)e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A.Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam ondea organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nívelde maturidade MPS se obtém quando são atendidos os propósitos e todos os resultados esperadosdos respectivos processos e dos atributos de processo estabelecidos para aquele nível.

A divisão em estágios, embora baseada nos níveis de maturidade do CMMI-SE/SW tem umagraduação diferente, com o objetivo de possibilitar uma implementação e avaliação mais adequadaàs micros, pequenas e médias empresas. A possibilidade de se realizar avaliações considerando maisníveis também permite uma visibilidade dos resultados de melhoria de processos em prazos maiscurtos.

Os processos são agrupados, por uma questão de organização, de acordo com a sua natureza,ou seja, o seu objetivo principal no ciclo de vida de software. Esse agrupamento resultou em três(3) classes de processos, que são:

• Processos fundamentais: atendem o início e a execução do desenvolvimento, operação oumanutenção dos produtos de software e serviços correlatos durante o ciclo de vida de software;

• Processos de apoio: auxiliam um outro processo e contribuem para o sucesso e qualidadedo projeto de software;

• Processos organizacionais: uma organização pode empregar estes processos em nível cor-porativo para estabelecer, implementar e melhorar um processo do ciclo de vida.

A capacidade do processo é representada por um conjunto de atributos de processo descritoem termos de resultados esperados. A capacidade do processo expressa o grau de refinamento e



Figura 2.10: Processos do MR-MPS

institucionalização com que o processo é executado na organização. No MPS, à medida que aorganização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar oprocesso deve ser atingido pela organização.

O atendimento aos atributos do processo (AP), através do atendimento aos resultados esperadosdos atributos do processo (RAP) é requerido para todos os processos no nível correspondente aonível de maturidade, embora eles não sejam detalhados dentro de cada processo. Os níveis sãoacumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nívelF que inclui os atributos de processo dos níveis G e F para todos os processos relacionados nonível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar donível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível decapacidade correspondente ao nível F.

A capacidade do processo no MPS possui cinco (5) atributos de processos (AP) que são: AP1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2. Cada AP está detalhado em termos de resultados esperadosdo atributo de processo (RAP) para alcance completo do atributo de processo, conforme definido aseguir:

• AP 1.1 O processo é executado

– Este atributo é uma medida da extensão na qual o processo atinge o seu propósito.

– Resultado esperado: RAP1. O processo atinge seus resultados definidos.

• AP 2.1 O processo é gerenciado

– Este atributo é uma medida da extensão na qual a execução do processo é gerenciada.

– Resultados esperados:

∗ RAP 2. Existe uma política organizacional estabelecida e mantida para o processo;∗ RAP 3. A execução do processo é planejada;∗ RAP 4 (para o Nível G). A execução do processo é monitorada e ajustes são reali-

zados para atender aos planos;∗ RAP 4 (a partir do Nível F). Medidas são planejadas e coletadas para monitoração

da execução do processo;



∗ RAP 5. Os recursos necessários para a execução do processo são identificados edisponibilizados;

∗ RAP 6. As pessoas que executam o processo são competentes em termos de formação,treinamento e experiência;

∗ RAP 7. A comunicação entre as partes interessadas no processo é gerenciada deforma a garantir o seu envolvimento no projeto;

∗ RAP 8. O estado, atividades e resultados do processo são revistos com os níveisadequados de gerência (incluindo a gerência de alto nível) e problemas pertinentessão tratados.

• AP 2.2 Os produtos de trabalho do processo são gerenciados

– Este atributo é uma medida da extensão na qual os produtos de trabalho produzidospelo processo são gerenciados apropriadamente.

– Resultado esperado: RAP 9. Os produtos de trabalho são documentados, revistos econtrolados em níveis apropriados de gerência de configuração.

• AP 3.1. O processo é definido

– Este atributo é uma medida da extensão na qual um processo-padrão é mantido paraapoiar a implementação do processo definido.

– Resultados esperados:

∗ RAP 10. Um processo padrão é definido, incluindo diretrizes para sua adaptaçãopara o processo definido;

∗ RAP 11. A sequência e interação do processo-padrão com outros processos são de-terminadas;

• AP 3.2 O processo está implementado

– Este atributo é uma medida da extensão na qual o processo-padrão é efetivamente im-plementado como um processo definido para atingir seus resultados.

– Resultado esperado: RAP 12. Dados apropriados são coletados e analisados, consti-tuindo uma base para o entendimento do comportamento do processo, para demonstrara adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínuado processo.

A Tabela 2.3 apresenta os níveis de maturidade do MR-MPS, os processos e os atributos deprocesso correspondentes a cada nível.



Nível Processos Atributos de Processo

A (mais alto)Implantação de Inovações na organização AP 1.1, AP 2.1, AP 2.2,Análise de causas e resolução AP 3.1 e AP 3.2

BDesempenho do processo organizacional AP 1.1, AP 2.1, AP 2.2,Gerência quantitativa do projeto AP 3.1 e AP 3.2

CAnálise de decisão e resolução AP 1.1, AP 2.1, AP 2.2,Gerência de riscos AP 3.1 e AP 3.2

D

Desenvolvimento de requisitosSolução técnica AP 1.1, AP 2.1, AP 2.2,Integração do produto AP 3.1 e AP 3.2VerificaçãoValidação

E

TreinamentoDefinição do processo organizacional AP 1.1, AP 2.1, AP 2.2,Avaliação e melhoria do processo organizacional AP 3.1 e AP 3.2Adaptação do processo para Gerência do projeto

F

MediçãoGerência de configuração AP 1.1, AP 2.1 e AP 2.2AquisiçãoGarantia da qualidade

GGerência de requisitos AP 1.1 e AP 2.1Gerência do projeto

Tabela 2.3: Níveis de Maturidade do MR-MPS


Capítulo 3

Gestão de Projetos de Software

3.1 Conceitos de Gestão de Projetos de Software

O que é? A gestão do projeto de Software envolve: o planejamento, a monitoração e o controledo pessoal, processo e eventos que ocorrem à medida que o software evolui de um conceito preliminarpara uma implementação operacional.

Quem faz? Todos ”gerenciam” em uma certa medida, mas o escopo das atividades de gestãovaria de acordo com as pessoas que as executam. Um engenheiro de software gerencia suas atividadesdo dia-a-dia, planejando, monitorando e controlando tarefas técnicas. Gerentes de projeto planejam,monitoram e controlam o trabalho de uma equipe de engenheiros de software. Gerentes seniorescoordenam a interface entre o negócio e os profissionais de software.

Por que é importante? A construção de software de computador é um empreendimento com-plexo, particularmente se envolver muitas pessoas trabalhando durante um período relativamentelongo. Essa é a razão pela qual projetos de software precisam ser geridos.

Gerencia de Projetos: É a aplicação de conhecimentos, habilidades e técnicasna elaboração de atividades relacionadas para atingir um conjunto de objetivos pré-definidos, num certo prazo, com um certo custo e qualidade, através da mobilização derecursos técnicos e humanos.

3.2 O espectro da gestão

A gestão efetiva de projetos de software focaliza os quatros Ps: pessoas, produto, processo eprojeto. A ordem não é arbitrária. O gerente que esquece que o trabalho de engenharia de softwareé um empreendimento intensamente humano nunca vai ter sucesso na gestão de projetos. Um gerenteque deixa de encorajar uma comunicação ampla com o cliente, desde cedo na evolução de um projeto,se arrisca a construir uma solução elegante para o problema errado. O gerente que presta poucaatenção no processo corre o risco de empregar métodos e ferramentas técnicas competentes numvazio. O gerente que começa sem um plano de projeto sólido compromete o sucesso do produto.

3.2.1 O pessoal

O cultivo de pessoal de software motivado e altamente qualificado tem sido discutido desde osanos 60. De fato, o ”fator pessoal” é tão importante que o Software Engineering Institute desenvolveuum modelo de maturidade da capacidade de gestão de pessoal (people management capabilitymaturity model, PM-CMM), para melhorar a capacidade de organizações de software de desenvolveraplicações cada vez mais complexas, ajudando-as a atrair, desenvolver, motivar, empregar e reter otalento necessário para melhorar sua capacidade de desenvolvimento de software.

O modelo de maturidade de gestão de pessoal define as seguintes áreas de práticas- chave parapessoal de software: recrutamento, seleção, gestão de desempenho, treinamento, remuneração, de-senvolvimento de carreira, organização e projeto do trabalho, e desenvolvimento de equipe/cultura.

27

28 Capítulo 3. Gestão de Projetos de Software 3.2

Figura 3.1: Um projeto é assim?

Organizações que atingem altos níveis de maturidade na área de gestão de pessoal têm uma grandeprobabilidade de implementar práticas efetivas de engenharia de software.

O PM-CMM faz par com o modelo de maturidade da capacidade de software, que orientaorganizações na criação de processos de software amadurecidos.

3.2.2 O produto

Antes que um projeto possa ser planejado, devem ser estabelecidos os objetivos e o escopodo produto, as soluções alternativas devem ser consideradas e as restrições técnicas e gerenciaisdevem ser identificadas. Sem essas informações é impossível definir estimativas de custo razoáveis(e precisas), avaliações efetivas do risco, relações realísticas de tarefas de projeto ou cronogramasde projeto gerenciáveis que proporcione uma indicação significativa do progresso.

O desenvolvedor de software e o cliente devem se reunir para definir os objetivos e o escopodo produto. Em muitos casos essa atividade começa como parte da engenharia de sistemas ou daengenharia de processo do negócio e continua como o primeiro passo da análise de requisitos desoftware. Os objetivos identificam as metas gerais para o produto (do ponto de vista do cliente) semconsiderar como essas metas serão atingidas. O escopo identifica os dados principais, as funções e oscomportamentos que caracterizam o produto e, mais importante, tenta definir essas característicasde forma quantitativa.

Uma vez entendidos os objetivos e o escopo do produto, soluções alternativas são consideradas.Apesar de poucos detalhes serem discutidos, as alternativas permiten a gerentes e profissionaisselecionar uma "melhor"abordagem, dadas as restrições impostas pelos prazos de entrega, restriçõesorçamentárias, disponibilidade de pessoal, interfaces técnicas e muitos outros fatores.

3.2.3 O processo

As fases genéricas que caracterizam o processo de software - definição, desenvolvimento e manu-tenção - são aplicáveis a todo software. O problema é selecionar o modelo de processo que é adequadopara o software a ser trabalhado por uma equipe de engenharia de projeto: Modelo Cascata; Modelode prototipagem; Modelo incremental; Modelo de desenvolvimento baseado em componentes, entreoutros.

O gerente do projeto deve decidir qual modelo de processo é mais apropriado para:


3.3 3.3. Planejamento e acompanhamento do projeto 29

• o cliente que solicitou e as pessoas que executarão o trabalho,

• as características do produto propriamente dito e

• o ambiente de projeto no qual a equipe de software trabalha.

Selecionado o modelo de processo, a equipe então definir um plano preliminar de projeto, combase no conjunto de atividades de processo. Uma vez estabelecido o plano preliminar, a decompo-sição do processo tem início. Isto é, deve ser criado um plano completo que reflita as tarefas detrabalho necessárias para preencher as atividades necessárias.

3.2.4 O projeto

Sobre projeto podemos dizer que: É um esforço para se atingir um objetivo específico por meiode um conjunto único de tarefas interrelacionadas e da utilização eficaz de recursos. Tem que ternecessariamente um objetivo bem definido: pode ser um resultado de um produto desejado.

Um objetivo de um projeto costuma ser definido em termos de: escopo, cronograma e custo.

Lançar no mercado, em dez meses, dentro de um orçamento de R$ 100.000,00, umnovo ar condicionado com sistema de regulagem da temperatura automático e de acordocom os níveis de umidade relativa do ambiente e que atenda demais especificidades dedesempenho predefinidas no projeto de produtos.

É conduzido por meio de uma série de tarefas independentes. Tarefas que devem ser concluidasem sequencia uma após a outra. Um projeto utiliza vários recursos para realizar as tarefas inter-dependentes: Inputs de recursos transformados - materiais, informações e consumidores; ou aindarecursos de transformação que são - pessoal, equipamento e instalações.

Antes de lançar no mercado o novo ar condicionado ele precisou ser projetado, tes-tado, avaliado ... Para isso requereu: informações dos engenheiros, do pessoal no desen-volvimento de protótipos para testes, requereu ainda uma estrutura de testes, máquinas,equipamentos, recursos financeiros ... outros ...

Um projeto tem um tempo de vida finito. Uma característica de todo e qualquer projeto é queele tem hora para iniciar e hora para terminar, mesmo que esse momento de término seja atrasadoem muitos dias, meses ou anos. Um dia ele acaba, mesmo que não esteja concluido, será abortado.

Um projeto tem sempre um cliente (pessoa física ou jurídica), não existe projeto para ninguém,somente desenvolvemos projetos se for para alguém, ou grupo de pessoas. O cliente é a figura quefinancia o projeto, portanto as especificações devem atender as suas necessidades.

3.3 Planejamento e acompanhamento do projeto

3.3.1 PMI

O Project Management Institute (PMI R©) é uma entidade mundial sem fins lucrativos voltadaao gerenciamento de projetos. Estabelecido em 1969 e com sede na Filadélfia, Pensilvânia, EstadosUnidos, o Project Management Institute ( PMI ) foi fundado por cinco voluntários. O PMI tambémedita o Project Management Body of Knowledge (PMBOK) e oferece diversas certificações.

PMBOK

O Project Management Body of Knowledge, também conhecido como PMBOK é um conjuntode práticas em gestão de projetos ou gerência de projetos levantado pelo PMI e constituem a baseda metodologia de gerência de projetos do PMI. Estas práticas são compiladas na forma de um



guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou GuiaPMBOK.

O Guia PMBOK é o guia que identifica um subconjunto do conjunto de conhecimentos emgerenciamento de projetos que seria amplamente reconhecido como boa prática na maioria dosprojetos na maior parte do tempo, sendo em razão disso utilizado como base pelo PMI. Uma boaprática não significa que o conhecimento e as práticas devem ser aplicadas uniformemente a todosos projetos sem considerar se são ou não apropriados.

Figura 3.2: PMBOK

3.3.2 Ferramentas computacionais para acompanhamento do projeto

A melhor ferramenta é aquela que atende as necessidades da sua empresa no momento da escolhae num futuro próximo.

Não adianta achar que a escolha de hoje será eterna, com o surgimento quase que diário desoluções para o gerenciamento de projetos, equipes, atividades e produtividade, sempre surge umaferramenta melhor que a que você está usando. E, infelizmente, as empresas que desenvolvemsoftwares nem sempre estão atentas às necessidades dos clientes e por isso, demoram muito arealizar atualizações. O que torna suas soluções defasadas.

Para escolher um software de gerenciamento de projetos você deve verificar se ele:

• permite a criação de listas de tarefas de forma simples e que também permita a priorizaçãodessa lista de tarefas.

• permite que todos os envolvidos no projeto possam ajudar na solução de problemas e acom-panhar a evolução de cada uma das tarefas e o andamento das metas do projeto.

• mostra graficamente como está o nível de produtividade da equipe e o quanto você e suaequipe estão dedicando a cada projeto.

• permite a análise dos seguintes indicadores: total estimado de custo x total realizado decusto, consumo de recursos escassos (humanos ou não) e cronograma previsto x cronogramarealizado.

• permite upload e download de documentos referentes às tarefas e projetos.

• mede o tempo de realização de cada tarefa.



Artia - artia.com

Software de Gestão de Projetos - onLine - desenvolvido por uma empresa brasileira e totalmenteem português.

Video de demonstração: http://artia.com/produto/videos/webinar-completo-sobre-o-artia/

Figura 3.3: artia

streber

Streber é uma ferramenta para gerenciamento de projetos em formato wiki, escrito em php5.Freelancers e pequenas equipes podem facilmente configurar projetos e manter controle sobre: tare-fas,bugs etc. Controle de Usuários pode ser ajustado para prover a clientes somente uma limitadavisão do estado do projeto atual.

Figura 3.4: streber



Redmine

Redmine é um software livre, gerenciador de projetos baseados na web e ferramenta de gerenci-amento de bugs. Ele contém calendário e gráficos de Gantt para ajudar na representação visual dosprojetos e seus deadlines (prazos de entrega). Ele pode também trabalhar com múltiplos projetos.

O design do Redmine foi influenciado pelo Trac, um pacote de software semelhante.O Redmine é escrito usando o framework Ruby on Rails. Ele é multiplataforma e suporta

diversos Banco de Dados.Além de ser um software multilíngue, também possibilita o uso integrado com vários repositórios

tais como Svn, Git, Mercurial, Darcs, Cvs e Bazaar.Um tutorial de como instalá-lo no ubuntu 14.04, pode ser acessado em:

http://www.redmine.org/projects/redmine/wiki/HowTo_Install_Redmine_25x_on_Ubuntu_1404_with_Apac

3.3.3 Métricas de processo e projeto de software

Métrica é um conjunto de medidas. Medição existe em qualquer processo de construção dequalquer coisa. A medição é realizada não apenas na Engenharia de Software. É fundamental paraqualquer atividade, principalmente de engenharia. Seu propósito é avaliar alguma coisa. A partirdela, podemos ter o entendimento da eficácia de algumas situações, como do processo de software.

Por exemplo, para avaliar se o processo pelo qual uma empresa produz software é bom ou ruim,como se faz? O CMM é um modelo para avaliar a qualidade do processo. Ele se baseia em medidascomo tempo, número de erros, de linhas de código, de manutenções, etc., para saber se o processoestá funcionando bem. Não é possível avaliar algo sem alguma medição.

Os processos que estão no nível máximo do CMM têm um melhoramento contínuo, o que significaque eles são constantemente medidos. As métricas são aqui quantitativas (números).

Medidas de qualidade e medidas de produtividade são extraídas do processo de software.A medição, além de ajudar na avaliação do processo de software, ajuda ainda nas estimativas,

por exemplo, para estimar quanto tempo é necessário para a produção de um sistema. Atualmenteerra-se muito nessas estimativas por não se ter muito conhecimento ou medição do processo. Coma medição, aperfeiçoamentos reais podem ser conseguidos ao longo do tempo.

Então, as razões para medir processos, produtos e recursos de software podem ser:

• para caracterizar;

• para avaliar;

• para prever;

• para aperfeiçoar.

Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores.Medida é um valor real, quantidade, dimensão, capacidade ou tamanho de algum atributo. Ex.

número de erros encontrados.Métrica é um conjunto de medidas tentando obter algum sentido. Ex. erros encontrados por

pessoa-hora empregada. Traz alguma informação que pode ser útil.Indicador é uma métrica, ou conjunto de métricas, que fornece compreensão de um processo

de software, de um projeto de software ou do produto propriamente dito. Ex. comparando duasmétricas, chega-se a uma conclusão que permite embasar uma tomada de decisão.

Exemplo:

1. Defina duas medidas, uma métrica e um indicador para avaliar um carro.

• Medidas: potência, peso bruto;

• Métrica: potência por peso bruto;



• Indicador: comparando-se a potência por peso bruto de dois carros, pode-se concluir qualé mais veloz.

Métricas do processo e do projeto de software são medidas quantitativas que permitem aopessoal de software ter idéia da eficácia do processo de software. Indicadores de projeto permitem àorganização de engenharia de software ter idéia da eficácia de um determinado processo existente,enquanto os indicadores de processo tentam identificar problemas que atingem a produção de todosos projetos na empresa.

• A medição é fundamental para qualquer atividade de engenharia.

• A medição nos permite obter entendimento nos dando um mecanismo para avaliação objetiva.

• A medição pode ser aplicada ao processo de software, com o objetivo de melhorá-lo continu-amente.

• Métricas do processo e do projeto de software são medidas quantitativas que permite aopessoal de software ter idéia da eficácia do processo de software.

– Dados básicos de qualidade e de produtividade são coletados.

• Com medições, as tendências (boas ou más) podem ser detectadas, melhores estimativaspodem ser feitas e aperfeiçoamentos reais podem ser conseguidos ao longo do tempo.

• Há quatro razões para medir processos, produtos e recursos de software: para caracterizar,para avaliar, para prever ou para aperfeiçoar.

• Medidas, Métricas e Indicadores

– Uma medida fornece uma indicação quantitativa da extensão, quantidade, dimensão,capacidade ou tamanho de algum atributo de um produto, ou de um processo.

– A IEEE define métricas como ”medida quantitativa de grau em que um sistema, compo-nente ou processo possui um determinado atributo”.

– Quando dados de um único ponto são coletados (por exemplo, quantidade de erros des-cobertos na revisão de um único módulo, pessoas-horas gastas na revisão de um únicomódulo, etc?), uma medida é estabelecida. Um medição ocorre como resultado da coletade um ou mais pontos.

– Uma métrica de software relaciona as medidas individuais de alguma forma (por exem-plo, um número médio de erros encontrados por revisão ou um número médio de errosencontrados por pessoa-hora, emprega nas revisões).

– Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indi-cadores.

– Um indicador é uma métrica, ou combinação de métricas, que fornece compreensão deum processo de software, de um projeto de software, ou do produto propriamente dito.

• Exemplo:

– Quatro equipes de software estão trabalhando em um grande projeto de software. Cadaequipe precisa conduzir revisões de projeto, mas pode selecionar o tipo de revisão que iráusar. Pelo exame da métrica, erros encontrados por pessoa-hora empregada, o gerentede projeto nota que duas equipes que estão usando métodos de revisão mais formais,exibem um valor para os erros encontrados por pessoa-hora empregada, que é 40

– Considerando todos os outros parâmetros iguais, isso, para o gerente de projeto, é umindicador de que os métodos de revisões formais podem fornecer um retorno maior doinvestimento em tempo que outra abordagem de revisão menos formal. Este pode, então,decidir sugerir que todas as equipes usem a abordagem menos formal.



• A métrica pode fornecer compreensão ao gerente de um projeto. E compreensão leva a umatomada de decisão mais precisa.

• A medição é comum no mundo da engenharia. Medimos consumo de energia, peso, dimensõesfísicas, temperatura, voltagem, relação entre sinal e ruído?..

• Na engenharia de software a medição é muito menos comum - temos dificuldade em concordarquanto ao que medir e dificuldade em avaliar as medidas que são coletadas.

• Métricas devem ser coletadas de modo que os indicadores de processo e de produto possamser determinados.

Métricas de Processo

• Indicadores de processo permitem à organização de engenharia de software ter idéia da eficáciade um processo existente.

• Elas permitem aos gerentes e profissionais avaliarem o que funciona e o que não funciona.

• Métricas de processo são coletadas ao longo de todos os projetos e durante longos períodos.

• Seu objetivo é fornecer indicadores que levem ao aperfeiçoamento do processo de software alongo prazo.

Métricas de Projeto

• Indicadores de Projeto permitem ao gerente de projeto de software:

1. Avaliar o status de um projeto em andamento;

2. Acompanhar riscos potenciais;

3. Descobrir áreas-problemas antes que elas se tornem críticas;

4. Ajustar o fluxo de trabalho ou tarefas;

5. Avaliar a capacidade da equipe de projeto e controlar a qualidade dos produtos dotrabalho de software.

• Em alguns casos, as mesmas métricas de software podem ser usadas para determinar indica-dores de projeto e de processo de software.

Métricas de Processo e aperfeiçoamento do processo de software

Medimos a eficácia de um processo de software indiretamente - originamos um conjunto demétricas, baseadas nas saídas que podem ser derivadas do processo.

As saídas incluem - medidas de erros descobertos antes da entrega do software, defeitos entreguesaos usuários finais e por ele relatados, produtividade dos produtos de trabalho entregues, esforçohumano despendido, tempo gasto, cumprimento de cronograma e outras medidas.

Algumas dessas medidas, tais como defeitos entregues aos usuários finais, só podem serutilizadas para avaliar o processo, enquanto que outras, tais como erros descobertos antes daentrega do software, podem ser utilizados para avaliar tanto o processo quanto um projeto emespecífico.

As métricas de processo de software podem fornecer benefícios significativos, à medida que aorganização trabalha para aperfeiçoar seu nível gerencial de maturidade de processo.

Todavia, essas métricas podem ser mal utilizadas, criando mais problemas do que conseguemresolver.

Grady(1992) sugere uma etiqueta de métricas de software, que é apropriada tanto para osgerentes quanto para os profissionais, quando eles instituem um programa de métricas de processo:

Use bom senso e sensibilidade empresarial quando interpretar dados de métricas.Forneça regularmente realimentação aos indivíduos e equipes que coletam medidas e métricas.



• Não use métricas para avaliar indivíduos.

• Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem serusadas para alcançá-las.

• Nunca use métricas para ameaçar indivíduos ou equipes.

• Dados de métricas que indicam uma área problemática não devem ser considerados ?negati-vos?. Esses dados são meramente um indicador para melhoria do processo.

• Não fique obcecado com uma única métrica em detrimento de outras métricas importantes.

À medida que uma organização sente-se mais confortável, coletando e usando métricas de pro-cesso, a derivação de indicadores simples dá lugar a uma abordagem mais rigorosa, chamada me-lhoria estatística de processo de software - statistical software process improvement (SSPI).

A SSPI usa a análise de falhas de software para coletar informação sobre todos os erros e defeitosencontrados à medida em que uma aplicação, sistema ou produto é desenvolvido e usado.

Erro - falha num produto de trabalho de engenharia de software, ou resultado a ser produzido,que é encontrado por engenheiros de software antes do software ser entregue ao usuário final.

Defeito - falha encontrada depois da entrega ao usuário final. A análise de falhas funciona daseguinte maneira:

1. Todos os erros e defeitos são categorizados por origem (por exemplo: falha na especificação,falha de lógica, não atendimento à padrões)

2. O custo para corrigir cada erro e defeito é registrado.

3. A quantidade de erros e defeitos de cada categoria é contada e ordenada de forma decrescente.

4. O custo total de erros e defeitos de cada categoria é calculado.

5. Os dados resultantes são analisados, para descobrir as categorias que produzem um maiorcusto para a organização.

6. São desenvolvidos planos para modificar o processo, com o objetivo de eliminar (ou reduzir afrequência das) classes de erros e defeitos que são mais dispendiosas.

3.3.4 Técnicas de estimativa do tamanho do software

Atualmente no mercado existem vários tipos de métricas para análise de dimensão de tama-nho de software. Estas técnicas surgiram com o objetivo de estimar o esforço para dimensionar aquantidade de pessoas-hora e ao mesmo tempo estimar os prazos associados ao desenvolvimento dosoftware.A maioria das técnicas possuem uma padronização para a sua apuração de contagem e nasua elaboração de estimativa de tempo e custo do projeto.Todas as técnicas de contagem exigemtambém uma nota de recomendação para que se tenha sempre em mãos um conhecimento sobretécnicas de estimativas , base histórica e conhecimento sobre o projeto a ser estimado, procedimentoessencial para contagem tempo e custo.

Para podermos estimar o custo do software e estimar o prazo deste desenvolvimento, inclusiveestimar a quantidade de horas-homens para o projeto precisamos dimensionar o esforço necessáriopara o desenvolvimento, e com isso determinar o esforço tamanho do projeto de software.

Desta forma , determinar o tamanho de um projeto de software é uma das primeiras e principaisatividades relacionadas às estimativas a serem efetuadas durante o ciclo de vida do projeto.

1. Por Analogia - As estimativas de tamanho do projeto atual são baseadas em estimativas jádesenvolvidas em projetos similares ou as chamadas bases históricas de outros projetos ou;



2. desenvolvendo as técnica de medições das características do produto e usando uma metodo-logia e algoritmo para converter a medição em uma estimativa de tamanho.

Existem várias técnicas de estimativas de tamanho de software:

• COCOMO (Constructive Cost Model) [COCOMOII] - Modelo desenvolvido paraestimar o esforço de desenvolvimento, prazos e tamanho da equipe para projetos de soft-ware. Utiliza equações desenvolvidas por Boehm (BARRY,1981) para prever o número deprogramadores-mês e o tempo de desenvolvimento; podem ser calculados usando medidas delinhas de código ou Pontos de Função. Devem ser realizados ajustes nas equações a fim derepresentar as influências sobre os atributos , hardware e software durante o ciclo de vida doprojeto. Uma desvantagem desta técnica é que os coeficientes da métrica (a,b,c,d) não sãoaplicáveis a tamanho ou seja a produtividade é diferente, o que torna difícil realizar compa-rações.

• Linhas de Código - (LOC) - A técnica de mensuração por linhas de código é uma dasmais antigas medidas de tamanho de projeto de desenvolvimento de software. Ela consiste nacontagem da quantidade de número de linhas de código de um programa de software. Alémde ser muito simples é também muito fácil automatizar sua implementação , mas, apresentaalgumas desvantagens dentre as quais citamos: a dependência da linguagem de software edo desenvolvedor (PRESSMAN,1995); ausência de padrão de contagem e o fato de somentepoder ser aplicada na fase de codificação.

• Análise por Pontos de Função (ALBRECHT,1983) - Busca medir a complexidade doproduto pela quantificação de funcionalidade expressa pela visão que o usuário tem do mesmo.O modelo mede o que é o sistema , o seu tamanho funcional e não como este será, além demedir a relação do sistema com usuários e outro sistemas. È independente da tecnologia usadae mede uma aplicação pelas funções desempenhadas para/e por solicitação do usuário final.;podendo também ser usada em estimativas.

• PCU - Pontos por Caso de Uso - Foram criados por Gustav Karner em 1993 como umaadaptação específica dos Pontos de Função para medir o tamanho de projetos de softwareorientados a objeto. Explora o modelo e descrição do caso de uso, substituindo algumascaracterísticas técnicas proposta pelos Pontos de Função. É um método simples e de fácilutilização mas ainda esta em fase de pesquisas e não existem regras de contagem padronizadas.Têm se estudado a aplicação em conjunto da PCU e APF tentando explorar a relação entreelas existente.

a estimativa de tamanho de um projeto de software é uma atividade crítica pois tem um impactotanto na solução técnica apresentada como no gerenciamento do projeto de software devendo serefetuada não somente no início do projeto mas durante o ciclo de vida do projeto. As técnicas apre-sentadas acima são apenas algumas dentre as muitas existentes, sendo que cada uma abrange umadeterminada área; não existe uma métrica que completa o estudo por si só, desta forma, recomenda-se que seja utilizada a técnica mais adequada para medir projeto de software ou a utilização de maisde uma técnica em conjunto. Dentre as técnicas descritas, a mais popular atualmente é a técnicade Análise por Pontos de Função. Esta técnica é respaldada pelo IFPUG (International FunctionPoint Users Group), que é responsável, entre outros, pela elaboração e divulgação de um manualde práticas de contagem (CPM ? Counting Practices Manual), além de manter um programa decertificação de profissionais especializados em aplicar a técnica APF. A Análise de Pontos de Fun-ção (APF) é uma das métricas de estimativa de tamanho mais sedimentadas no mercado e queproporciona resultados cada vez mais precisos à medida que artefatos da fase de análise e projetosão gerados.


Capítulo 4

Requisitos de Software

O interesse por uma abordagem sistemática do conhecimento de problema, levou à busca deapoio de uma nova área de pesquisa, a engenharia de requisitos.

A Engenharia de Requisitos, pode ser definida como o processo sistemático de desenvolvimentode requisitos através de um processo iterativo e cooperativo de análise de problema, de documen-tação de observações resultantes em uma variedade de formatos de representação e de checagem daprecisão do entendimento obtido.

O processo de engenharia de requisitos é um conjunto estruturado de atividades para extrairrequisitos, validá-los e mantê-los.

As técnicas de engenharia de requisitos referem-se ao conjunto de ferramentas aplicáveis aodesenvolvimento dos processos.

Requisitos, simplesmente, podem ser definidos como ”algo que um cliente necessita”. Entretanto,do ponto de vista de um desenvolvedor, requisito pode também ser definido como ”algo que necessitaser projetado”.

Stackholders, são todos aqueles que são afetados ou que têm direta ou indiretamente influênciasobre os requisitos para um sistema (clientes, usuários, desenvolvedores, gerentes,...).

4.1 Conceitos Fundamentais de Engenharia de Requisitos

Engenharia de Requisitos é um termo relativamente novo que foi inventado para cobrir todasas atividades envolvidas em descobrimento, documentação e manutenção de um conjunto de requi-sitos para um sistema baseado em computador. O uso do termo engenharia implica em técnicassistemáticas e repetitíveis a serem usadas para assegurar que os requisitos do sistema sejam com-pletos, consistentes, relevantes,... O termo engenharia de requisitos vem da antecedente engenhariade sistemas, correspondendo à fase de análise de sistemas.

Engenharia = aplicação de princípios matemáticos e científicos às construções.

Requisito = condição que se precisa para atingir um fim, como exigência legal ou ne-cessária para certos efeitos.

4.2 Processo de Engenharia de Requisitos

A Análise de Requisitos ou Engenharia de Requisitos é um aspecto importante no Gerenciamentode Projetos, é a responsável por coletar dados indispensáveis, necessários, exigências de que o usuárionecessite para solucionar um problema e alcançar seus objetivos. Assim como determinar as suasexpectativas de um usuário para determinado produto.

Segundo a IEEE (1990) a análise de requisitos é um processo que envolve o estudo das necessi-dades do usuário para se encontrar uma definição correta ou completa do sistema ou requisito desoftware.

37

38 Capítulo 4. Requisitos de Software 4.2

Essa análise de requisitos é vital para o desenvolvimento do sistema, ela vai determinar o sucessoou o fracasso do projeto. Os requisitos colhidos devem ser quantitativos, detalhados e relevantespara o projeto. Pois eles fornecerão a referência para validar o produto final, estabelecerão o acordoentre cliente e fornecedor sobre o que e o software fará e consequentemente reduzirão os custos dedesenvolvimento, pois requisitos mal definidos implicam num retrabalho.

Dentro deste contexto é importante a comunicação e o envolvimento constante com os usuáriosdo software, pois eles influenciarão no resultado final do produto.

A Análise de Requisitos consiste em:

• Reconhecer o problema - nesta fase encontra-se a especificação do sistema, o planejamento,o contato do analista com o cliente com a intenção de entender a visão do cliente com relaçãoao problema.

• Avaliar o problema e a síntese da solução - tem-se o entendimento do problema, e faz-sea identificação das informações que serão necessárias ao usuário, identificação das informaçõesque serão necessárias ao sistema e a seleção da melhor solução possível dentro das soluçõespropostas.

• Modelar (Modelagem) - é um recurso usado para o suporte da síntese da solução, o modelovai apresentar ferramentas que facilitarão o entendimento do sistema, como as funcionalidades,informações e comportamento do sistema.

• Especificar os requisitos - consolida funções, interfaces, desempenho, o contexto e as res-trições do sistema.

• Revisar (Revisão) - Juntos, cliente e analista, avaliarão o objetivo do projeto com o intuitode eliminar possíveis redundâncias, inconsistências e omissões do sistema, obtendo uma mesmavisão.

4.2.1 Tipos de Requisitos

• Requisitos do projeto - requisitos do negócio, gerenciamento e entrega do produto.

• Requisitos do produto - requisitos técnicos, de segurança, de desempenho, etc.

• Requisitos funcionais: eles vão estabelecer como o sistema vai agir, e o que deve fazer, asfuncionalidades e serviços do sistema, devendo ser descritos detalhadamente. Nesta fase, pode-se usar o MER (Modelo Entidade e Relacionamento, modelos de casos de uso, fluxogramas,para facilitar o entendimento das funções do sistema.

• Requisitos não funcionais: definem as propriedades do sistema e suas restrições. Ex.: aconfiabilidade do sistema, o tempo de resposta do programa, o espaço em disco.

4.2.2 Requisitos de usabilidade, acessibilidade e segurança;

Usabilidade

Usabilidade: pode ser definida como o grau de facilidade com que o usuário consegue inte-ragir com determinada interface.

Partindo da IHC (Interface Homem Computador), a usabilidade aborda a forma como o usuáriose comunica com a máquina e como a tecnologia responde à interação do usuário, considerando asseguintes habilidades, de acordo com a norma ISO 9241:

• Facilidade de aprendizado: a utilização do sistema requer pouco treinamento;

• Fácil de memorizar: o usuário deve lembrar como utilizar a interface depois de algumtempo;


4.2 4.2. Processo de Engenharia de Requisitos 39

• Maximizar a produtividade: a interface deve permitir que o usuário realize a tarefa deforma rápida e eficiente;

• Minimizar a taxa de erros: caso aconteçam erros, a interface deve avisar o usuário epermitir a correção de modo fácil;

• Maximizar a satisfação do usuário: a interface deve dar-lhe confiança e segurança.

Partindo da Engenharia de Software, a usabilidade é englobada dentro da qualidade e visagarantir uma parte da eficiência e eficácia do sistema. A eficiência refere-se a uma interação pro-dutiva entre o usuário e o sistema, permitindo a realização de tarefas com menor esforço sob umaexperiência agradável. A eficácia pode ser entendida como a capacidade do sistema e da interfacepossibilitarem ao usuário a completude da tarefa e o alcance de seus objetivos no sistema.

A usabilidade se encaixa em qualquer tipo de projeto de interface, tendo amplitude diferentede acordo com a criticidade do projeto, ou seja, quanto mais crítico for o sistema, maiores serão asperdas caso ele não seja de fácil utilização e proporcione satisfação. Ela deve ser pensada desde oplanejamento do projeto, até a etapa de desenvolvimento e teste.

Sistemas difíceis de usar implicam em erros e perda de tempo, fatores que se multipli-cam com a frequência das tarefas e o número de usuários. A perda de dados e informa-ções pode implicar na perda de clientes e de oportunidades. Acontecimentos deste tipocausam desde uma resistência ao uso do sistema até a sua subutilização e abandonocompleto, com o devido consentimento da empresa. O barato terá custado caro.

Figura 4.1: O escopo da Usabilidade

acessibilidade

Um grande número de pessoas com paralisias, amputações, dificuldades de controle dos mo-vimentos, cegueira e surdez encontram nas tecnologias da informação importantes alternativas eoportunidades para a aprendizagem, para o acesso à informação, ao lazer e ao exercício de umaatividade ou vocação.

A acessibilidade a estas tecnologias é um fator decisivo para a sua qualidade de vida.Em primeiro lugar é importante interiorizar que as limitações de interação com um programa

de computador estão do lado da interface, composta pelo hardware e software, e não do lado dascapacidades das pessoas com deficiência.

Para conceber um software sem barreiras para pessoas com deficiência é necessário ter presenteas suas dificuldades e as soluções que as permitem contornar.



Dependendo do equipamento para o qual o software é desenvolvido, das funcionalidades deacessibilidade presentes no sistema operacional e das tecnologias de acesso existentes no mercado,a tarefa do programador poderá ser mais ou menos simples. Em qualquer dos casos os conceitos-chave da acessibilidade são a redundãncia tanto ao nível da interacção como da informação e acompatibilidade com as tecnologias de acesso existentes.

ACESSIBILIDADE PARA A DEFICIÊNCIA MOTORAAs deficiências motoras podem ser provocadas por artrites, tendinites, enfartes, paralisias cere-

brais, esclerose múltipla e pela paralisia ou perda de membros ou dedos, entre outros motivos.Um reduzido controle dos movimentos e fraquezas musculares podem tornar difícil a utilização

de teclados e mouses padrão, bem como a execução de ações que impliquem precisão e rapidez.Por exemplo, algumas pessoas não conseguem pressionar duas teclas ao mesmo tempo, enquanto

outras tendem a pressionar várias teclas ou repetir letras quando as liberam.Estes utilizadores recorrem a vários sistemas específicos que aperfeiçoam ou eliminam a utilização

do teclado e do mouse.Um programa para simular teclas presas permite às pessoas que não conseguem manter pressio-

nadas duas ou mais teclas ao mesmo tempo (como CTRL+P) obter o mesmo resultado pressionandouma tecla de cada vez. Um software específico pode simular o estado dos botões e o movimento domouse, por exemplo, através do teclado numérico. Também existem teclados exibidos no monitorcomo alternativa ao teclado em hardware. Em situações mais graves, um simples interruptor ativadopor um movimento, som ou sopro pode ser suficiente para interagir com o computador.

Tendo em vista estas situações, a concepção de software deve assegurar a interação nas seguintesmodalidades:

• Sem o mouse (dispositivo apontador)

• sem o teclado

• personalizando o comportamento e a configuração dos periféricos de entrada com as opçõesde acessibilidade do sistema operacional;

• sem movimentos precisos;

• sem a necessidade de efetuar ações simultâneas;

• sem limitações no tempo de resposta.

ACESSIBILIDADE PARA DEFICIÊNCIA AUDITIVAAs pessoas surdas ou com deficiência auditiva não utilizam nenhum programa ou equipamento

auxiliar. As principais dificuldades que encontram são a percepção e localização de sinais sonoros eo acesso a mensagens faladas ou a qualquer tipo de informação em áudio.

Figura 4.2: Informação redundante (sonora e visual) para garantir de acessibilidade auditiva

A estratégia de acessibilidade passa pela disponibilização de texto ou legendagem de conteúdose instruções por voz e a sinalização visual de avisos sonoros.

A informação de um conteúdo em formato de áudio ou vídeo poderá ser apresentada num textofixo ou através de uma legenda dinâmica sincronizada em tempo real com o som.

ACESSIBILIDADE PARA A DEFICIÊNCIA VISUALAs pessoas cegas utilizam um programa genericamente designado por leitor de tela que possibilita

a interação com o computador sem recurso à visão. Este leitor envia a informação sobre os elementos



que são visualizados no monitor e a interatividade com o software para um sintetizador de fala(software ou hardware) e/ou terminal eletrónico de braille (hardware).

Contudo, o leitor de tela não resolve todos os problemas de uma interação ”às cegas”. Não épossível, por exemplo, ler um gráfico ou um texto sob a forma de imagem ou tornar fácil a utilizaçãodo mouse.

As pessoas com baixa visão recorrem a programas que permitem aumentar o contraste e otamanho dos textos, do cursor ou de uma zona parcial do monitor. Nestas condições, os utilizadorespoderão ter dificuldade em ler um texto e executar tarefas que requeiram coordenação visual emanual, como, por exemplo, mover um mouse.

Assim, o programador deverá assegurar a interação com o software e o acesso à informação comrecurso:

• ao teclado

• a leitores de tela

• às opções de alto contraste do sistema operacional

• a programas de ampliação

ACESSIBILIDADE DA DOCUMENTAÇÃOAs funcionalidades do software e as facilidades de usabilidade para pessoas com deficiência

devem estar documentadas com redação e formato acessíveis.A documentação em papel apresenta várias desvantagens face à versão eletrônica tendo em conta

as dificuldades associadas à manipulação ou leitura por parte de pessoas com deficiência motora evisual, respectivamente.

A informação e apresentação do texto não deve apoiar-se exclusivamente em cores e referênciasa imagens.

Adote as regras de acessibilidade aos conteúdos da Web na criação de um documento em ver-são eletrónica. Assegure que o texto associado à ligação das páginas é esclarecedor para quem asouve com um sintetizador de fala. Evite o uso do mesmo texto para ligações diferentes pois geraambiguidade para utilizadores de leitores de tela.

Segurança

Os requisitos de segurança de software são o conjunto de necessidades de segurança que o soft-ware deve atender, sendo tais necessidades influenciadas fortemente pela política de segurança daorganização, e compreendendo aspectos funcionais e não-funcionais. Os aspectos funcionais des-crevem comportamentos que viabilizam a criação ou a manutenção da segurança e, geralmente,podem ser testados diretamente. Na maioria dos casos, remetem a mecanismos de segurança como,por exemplo, controle de acesso baseado em papéis de usuários (administradores, usuários comuns,entre outros.), autenticação com o uso de credenciais (usuário e senha, certificados digitais, entreoutros.), dentre outros. Os aspectos não funcionais descrevem procedimentos necessários para queo software permaneça executando suas funções adequadamente mesmo sob uso indevido. São exem-plos de requisitos não funcionais: validação de dados de entrada e a registro eventos em log deauditoria com informações suficientes para análise forense.

A elicitação de requisitos de segurança de software consiste na definição das necessidades deproteção exigidas pelo software. Tal atividade exige uma colaboração intensa entre os interessados nosoftware, especialmente daqueles com visão negocial, que podem ter consciência das consequênciasno negócio decorrentes de incidentes de segurança, cujo vetor de ataque se localize no software.

Segue, a título de ilustração, alguns exemplos de requisitos de segurança:Confidencialidade

• Senha e outros campos de entrada de dados sensíveis necessitam ser mascarados.



• Senhas não devem ser armazenadas as claras nos sistemas backend, e quando armazenadasdevem passar por processo de hash com uma função pelo menos equivalente a SHA-256.

• Transport Layer Security (TLS) como Secure Socket Layer (SSL) deve ser colocado em prá-tica para proteger contra ameaças internas de Man in the Middle (MITM) para todas asinformações de cartão de crédito que seja transmitida.

• O uso de protocolos reconhecidamente inseguros como, por exemplo, File Transfer Protocol(FTP) para transmitir credenciais de contas em texto claro a terceiros fora de sua organizaçãodeve ser proibido.

• Arquivos de log não devem armazenar qualquer informação sensível como definido pelo negó-cio, de modo que seja compreensível por seres humanos.

Integridade

• Todos os formulários de entrada e query strings necessitam ser validadas frente a um conjuntode entradas aceitáveis, antes do software aceita-los para processamento.

• O software a ser publicado deve ser disponibilizado juntamente com o checksum e a funçãohash usada pra computar o checksum, de modo que o interessado possa validar sua precisãoe completude.

• Todos os personagens não humanos como um sistema ou processos batch devem ser identi-ficados, monitorados e impedidos de alteração de dados, a medida que ele passa no sistemaque eles rodam, a não ser que explicitamente autorizado para tal.

Disponibilidade

• O software deve oferecer alta disponibilidade de oito (8) noves (9), como definido pelo SLA.

• O software deve estar preparado para atender capacidade máxima de 300 usuários simultâneos.

• O software e seus dados devem ser replicados por todos os centros de dados para proverbalanceamento de carga e redundância.

• A funcionalidade de missão crítica no software deve ser restaurada a operação normal noprazo de 1 hora de descontinuidade; funcionalidade de missão essencial no software deve serrestaurada a operação normal no prazo de 4 horas da interrupção, e funcionalidade de missãosuporte no software deve ser restaurada a operação normal no prazo de 24 horas.

Autenticação

• O software será implantado somente na Intranet e o usuário autenticado deve fornecer nova-mente suas credenciais para acessar a aplicação, uma vez que esteja autenticado na rede.

• O software deverá suportar single sign on a terceiros e fornecedores que estão definidos nalista de interessados.

• A política de autenticação garante a necessidade para dois ? ou autenticação com múltiplosfatores para todos os softwares de processamento financeiro.

Autorização

• O acesso a arquivos secretos de alta sensibilidade deve ser restrito somente a usuários comníveis de permissão secreto e super-secreto.



• Os usuários não devem ser demandados a enviar suas credenciais sempre, uma vez que eletenha se autenticado com sucesso.

• Todos os usuários autenticados herdarão a permissão de leitura somente que são parte dopapel do usuário convidado enquanto os usuários autenticados por padrão terão permissãode leitura e escrita como parte do papel de usuário regular. Somente os usuários com acessoadministrativo, terão todos os direitos dos usuários regulares, adicionalmente a execução deoperações.

Auditing and Logging

• Os logs de auditoria devem sempre ser adicionados de novos registros e nunca sobrescritos.

• Os logs de auditoria devem ser mantidos de forma segura por um período de 3 anos.

Erros e Gerenciamento de Exceção

• Todos os erros e exceções devem ser explicitamente manipulados a partir de blocos try, catche finally.

• Mensagens de erro que são mostradas ao usuário revelarão somente a informação necessária,sem vazamento de detalhes internos do sistema na mensagem de erro.

• Detalhes de exceções de segurança devem ser auditados e monitorados periodicamente.

• Senhas e chaves de criptografia não devem ser registradas no código fonte do software.

• A inicialização e a liberação de variáveis globais necessitam ser monitoradas com muito cui-dado.

4.2.3 Técnicas de Análise de Requisitos

• Entrevista - Consiste na investigação direta com os clientes e usuários, fazendo entrevistaspara coletar suas expectativas.

• Brainstorming - conhecida também como ”Tempestade de idéias” essa técnica consiste emcoletar idéias, não descartar ou desprezar qualquer tipo de idéia que surja no processo eselecionar a melhor idéia possível podendo ser uma combinação de idéias.

• Questionários e pesquisas - podendo ser os questionários com perguntas fechadas no qualcaiba apenas as respostas sim ou não, ou perguntas abertas, na qual possibilita a descrição se-gundo o usuário de suas atividades e possíveis problemas, levando em consideração as opiniõesexpressas do usuário.

• Observação - o analista dispõe de tempo para observar as atividades do usuário, como utilizao sistema e como se comporta diante de situações problemáticas.

Neste contexto há outras técnicas tais como workshops, mapas mentais, protótipos, etc.A análise de requisitos vai ser o processo a determinar as necessidades e interesses dos steakhol-

ders para atingir seus objetivos.



4.2.4 Técnicas de Entrevistas e de Coleta de Dados

A forma mais comum de entrevista é uma reunião pessoal e direta entre você (talvez acom-panhado por até dois analistas auxiliares do projeto) e um ou mais interlocutores (entrevistados).Normalmente são efetuadas anotações por um dos entrevistadores; menos costumeiramente, a en-trevista pode ser gravada ou um(a) secretário(a) tomará notas durante a entrevista.

Pode-se perceber que as informações obtidas em uma entrevista também podem ser obtidas poroutros meios, por exemplo, solicitando-se que os entrevistados respondam por escrito a um ques-tionário formal, ou solicitando que descrevam por escrito os requisitos do novo sistema. Tambémpodemos aumentar as entrevistas pela presença de vários especialistas (que podem até conduzir aentrevista enquanto o analista de sistemas participa como assistente), como peritos em indústria/-comercio, psicólogos comportamentais e negociadores. E, finalizando, deve-se lembrar que outrosmeios de obtenção de dados (ex.: filmadoras, gravadores, etc...) podem ser utilizados para registraruma entrevista.

Durante a década de 80, uma forma especializada de entrevista tornou-se popular em algumasempresas; conhecida como JAD (Joint Application Development) ou projeto acelerado, ou análiseem equipe, e por vários outros nomes. Ela consiste em uma rápida entrevista e um processo aceleradode coleta de dados em que todos os principais usuários e o pessoal da análise de sistemas agrupam-seem uma única e intensiva reunião (que pode prolongar-se de um dia a uma semana) para documentaros requisitos do usuário. A reunião costuma ser supervisionada por um profissional experiente ebem treinado que atua como mediador para encorajar melhores comunicações entre os analistasde sistemas e os usuários. Freqüentemente, este supervisor é apoiado por algumas pessoas que sededicam integralmente ao processo.

Embora todas essas variações tenham de fato sido utilizadas, elas são relativamente raras e nãoserão discutidas em maiores detalhes no nosso curso. A entrevista mais utilizada ainda é a reuniãopessoal entre um analista de sistemas e um usuário final.

Problemas Fundamentais

Inicialmente pode parecer que o processo de entrevistar um usuário seja uma questão simples edireta. Afinal, o analista e o usuário são pessoas inteligentes e capazes de expressarem. Os dois sãopessoas racionais e ambos têm o mesmo objetivo: passar informações relativas a um novo sistemaproposto da mente do usuário para a do analista. Qual é o problema?

Na realidade, existem muitos problemas que podem ocorrer. Em muitos projetos de alta tecno-logia, tem-se observado que a maioria dos problemas difíceis não envolvem hardware nem software,mas sim o pleopleware. Os problemas de peopleware na análise de sistemas são muitas vezes encon-trados nas entrevistas. Os problemas mais comuns a que você deve estar atento são:

• Entrevistar a pessoa errada no momento errado. É muito fácil, por causa dos problemase interesses organizacionais, falar com a pessoa que é o perito oficial na orientação do usuário,que demonstra nada saber a respeito dos verdadeiros requisitos do sistema; também é possívelperder a oportunidade de falar com o usuário desconhecido que realmente sabe quais são osrequisitos. Mesmo que encontre a pessoa certa, talvez o analista tente entrevistá-la duranteum período em que o usuário não está disponível ou esteja mergulhado sob outras pressões eemergências.

• Fazer perguntas erradas e obter respostas erradas. A análise de sistemas é, comoTom DeMarco gosta de dizer, uma forma de comunicação entre estranhos. Os usuários e osanalistas de sistemas têm vocabulários diferentes, experiências básicas diferentes e muitasvezes um diferente conjunto de pressuposições, percepções, valores e prioridades. Desse modo,é fácil fazer ao usuário uma pergunta racional sobre os requisitos do sistema e o usuárionão entender absolutamente a pergunta, sem que nenhum dos dois perceba o fato. E é fácilpara o usuário prestar-lhe algumas informações sobre os requisitos e o analista não entenderessas informações, novamente sem que nenhum dos dois perceba o fato. As ferramentas de



modelagem são uma tentativa de fornecer uma linguagem comum e sem ambigüidades paradiminuir esses mal entendidos. Porém as entrevistas costumam ser realizadas em uma línguacomum (inglês, espanhol, francês, português etc.),portanto o problema é real. Isso explicaporque é tão importante marcar entrevistas subseqüentes para confirmar que ambas as partesentenderam as perguntas e as respostas.

• Criar ressentimentos recíprocos. existem algumas razões pelas quais o usuário pode nãose sentir à vontade ou mesmo colocar-se em posição antagônica na entrevista com um analistade sistema (ex.: porque ele percebe que o verdadeiro objetivo do novo sistema que o analistaestá especificando é tomar-lhe o emprego). E o analista pode ressentir-se do modo como ousuário está respondendo as perguntas. Em qualquer caso, o ressentimento pode surgir entreas duas partes, tornando a comunicação muito mais difícil.

Não existe um modo mágico de garantir que esses problemas não ocorrerão; eles são a conseqüên-cia das interações pessoa-a-pessoa, e cada uma dessas interações é única. Contudo, as sugestõesdadas a seguir podem ajudar a reduzir a probabilidade desses problemas; fora isso, dependerá deprática para melhorar cada vez mais em cada entrevista subsequente.

Diretrizes Para a Realização de Entrevistas

• Desenvolva um Plano Geral de Entrevistas

– Antes de tudo, é extremamente importante que o analista descubra quem deve ser en-trevistado. Caso contrário, desperdiçará o tempo de todos e criará um enorme tumulto,por falar com pessoas erradas sobre coisas erradas.Isso requer que obtenha um organograma da empresa que mostre as pessoas da organi-zação usuária, bem como a hierarquia entre elas. Se não existir um organograma formal,encontrar alguém que saiba como a organização funciona e pedir ajuda. Se o organo-grama existir, certificar-se de que esteja correto e atualizado; as empresas muitas vezesmodificam-se com muito mais freqüência do que o ciclo editorial anual em que os dia-gramas são produzidos!O fato de conhecer o esquema organizacional não diz necessariamente com quem o ana-lista deve entender-se; às vezes, a pessoa que mais sabe a respeito de algum aspecto deum sistema é um funcionário administrativo ou burocrata que sequer aparece no orga-nograma. Muitas vezes existem três níveis de usuários em uma organização grande ecomplexa (o usuário verdadeiro, o usuário supervisor operativo e o usuário supervisorexecutivo) e é muitas vezes de grande importância falar com todos os três níveis.Em muitos casos também é importante conversar com os usuários na sequência adequadae na combinação certa. Por vezes o analista poderá saber em que seqüência os usuáriosdeverão ser entrevistados face a seu conhecimento geral da organização e por vezes ospróprios usuários lhe dirão uma vez que saibam que serão entrevistados.

• Certifique-se de que tem Autorização para Falar com os Usuários

– Em algumas organizações informais não haverá restrições na escolha dos usuários comquem falar ou sobre como as entrevistas serão marcadas. Porém isso não é comum emempresas grandes; é politicamente perigoso vagar pela organização usuária realizandoentrevistas sem prévia autorização.Na maioria dos casos, a autorização virá ou do encarregado de um setor usuário (umdepartamento ou divisão) ou do representante da empresa que estará auxiliando o projetode desenvolvimento do sistema. Em qualquer caso, os usuários têm legítimas razões emquerer aprovar, antecipadamente, quem será entrevistado:

∗ Eles podem saber que alguns usuários não serão capazes de compreender ou exprimirbem os requisitos do sistema.



∗ Eles podem desconfiar de que alguns dos usuários do nível operativo sejam rebeldesque apresentarão requisitos falsos (ou requisitos que a direção não aprova).

∗ Eles podem recear que as entrevistas interfiram com as atribuições normais de tra-balho que os usuários tenham de executar. Por causa disso, desejarão marcar asentrevistas para os momentos apropriados.

∗ Eles podem recear que as entrevistas sejam vistas como o início de um esforço desubstituição dos usuários humanos por um sistema computadorizado, provocandodemissões e coisas desse gênero.

∗ Eles podem considerar que eles próprios (os diretores) sabem mais a respeito dos re-quisitos do sistema do que qualquer outro e por isso não desejam que você entrevistequalquer usuário de nível operativo.

∗ Pode estar havendo uma batalha política em andamento em um nível de chefia muitomais elevado, entre o setor usuário e a organização de desenvolvimento de sistemas.Desse modo, o gerente usuário pode não ter reais objeções a suas entrevistas, porém,impedindo que elas sejam feitas, ele estará enviando uma mensagem política para ochefe do chefe do seu chefe.

Por todos esses motivos, é uma boa medida obter uma prévia autorização. Na maior partedos casos, basta uma autorização verbal; se a organização for terrivelmente burocráticaou paranóica, pode?se precisar de uma autorização escrita. Isso, a propósito, tambémsignifica que o analista deve estar atento à política organizacional se tiver certeza danecessidade de falar com um usuário (normalmente um usuário do nível operativo) comquem tenha sido avisado para não conversar.

• Planeje a Entrevista para Fazer Uso Eficiente do Tempo

– O principal aspecto desta sugestão é que deve-se compreender que está tomando o tempodo usuário e que ele (ou o chefe dele) pode achar até que o analista esteja desperdiçando otempo dele. Assim sendo, é importante o planejamento e preparação tão antecipadamentequanto possível para poder fazer uso eficiente da entrevista.A primeira coisa a fazer é certificar-se de que o usuário conhece o assunto da entrevista.Em alguns casos isso pode ser feito por telefone; em outros, pode ser adequado prepararuma lista das perguntas que serão feitas, ou dos tópicos que serão abordados, ou dos DFDque necessita ser revisados, e remetê-la ao usuário com um dia ou dois de antecipação.Se não puder fazer isso, é um indício de que de fato o analista não está preparado paraa entrevista. E se o usuário não tiver lido o material remetido, é sinal de que:

∗ está muito ocupado,∗ está desinteressado,∗ opõe-se a toda a idéia da entrevista ou∗ é incapaz de entender as perguntas apresentadas.

Um aspecto relacionado: coletar, antes da entrevista, tantos dados pertinentes quantopossível. Se houver formulários ou relatórios que sejam pertinentes à discussão, geral-mente poderá obtê-los antecipadamente. Se existirem outros documentos escritos dousuário descrevendo o novo ou o antigo sistema consiga-os e estude-os antes da entre-vista.Se tiver preparado as perguntas antecipadamente, o analista deve ser capaz de realizar aentrevista em uma hora ou menos. Isso é importante; não só o usuário é geralmente inca-paz de reservar mais do que uma hora de cada vez, mas também as pessoas normalmentenão conseguem se concentrar intencionalmente (principalmente se estiverem examinandodiagramas um tanto estranhos) por mais do que uma hora. Isso naturalmente significaque deve-se organizar a entrevista para abranger um escopo relativamente limitado, fo-calizando normalmente uma parte do sistema. Isso também pode significar que tenha demarcar algumas entrevistas com o mesmo usuário para abranger inteiramente a área em



que ele está envolvido.Finalizando, marcar uma reunião subsequente para rever o material que foi coletado.Normalmente, após a entrevista, o analista irá para sua mesa com todas as informaçõescolhidas na entrevista, e executará bastante trabalho com os dados brutos. Pode haverDFD a serem desenhados ou itens a serem criados no dicionário de dados; cálculos decusto/benefício podem precisar ser feitos; as informações provenientes da entrevista po-dem precisar ser correlacionados com dados de outras entrevistas, e assim por diante. Emqualquer caso, os dados dessa entrevista serão manipulados, documentados, analisados econvertidos em uma forma que o usuário pode nunca ter visto antes. Desse modo, podeser necessário marcar uma entrevista posterior para verificar:

∗ que o analista não cometeu nenhum engano em seu entendimento do que o usuáriolhe disse,

∗ que o usuário não mudou de opinião nesse ínterim,∗ que o usuário entende a notação ou a representação gráfica dessas informações.

• Utilize Ferramentas Automatizadas que Sejam Adequadas, Mas Não Abuse

– Durante a entrevista, pode-se achar conveniente utilizar ferramentas de prototipação,principalmente se o objetivo da entrevista for discutir a visão que o usuário tem da in-terface pessoa-máquina. De modo semelhante, se estiver revisando um diagrama de fluxode dados e discutindo possíveis modificações, poderá achar prático usar uma ferramentasCASE.Lembre-se, que o objetivo dessas ferramentas é facilitar as discussões e não complicá-las;elas devem permitir que o analista e o usuário examinem alternativas e modificações comrapidez e facilidade; elas podem ajudar a registrar o conhecimento de um requisito dousuário e corrigir imediatamente quaisquer erros que tenha sido cometido.Se, a tecnologia introduzir-se no assunto, deve-se deixar fora da entrevista. Se o usuáriotiver de aventurar-se além de seu ambiente normal de atividade (para outro prédio, nasala do computador) poderá encarar a ferramenta como um aborrecimento. Se o usuárionão estiver familiarizado com a tecnologia de computadores e for solicitado a utilizar aferramenta, poderá rejeitá-la. E se o analista não estiver familiarizado com a ferramenta(ou se a ferramenta for lenta, apresentar erros ou de emprego limitado) isso interfe-rirá sensivelmente na entrevista. Em qualquer desses casos, talvez seja preferível usara ferramenta off-line depois da entrevista; então, poderá mostrar ao usuário a saída daferramenta sem causar quaisquer problemas desnecessários.

• Tente Descobrir quais Informações o Usuário tem mais Interesse

– Se o analista tiver de desenvolver um modelo completo de sistema para alguma parte deum sistema, possivelmente necessitará determinar entradas, saídas, funções, caracterís-ticas tempo-dependentes e a memória armazenada do sistema. Porém a ordem em quese obtém essas informações costumam não ter muita importância. Mas pode significarmuito para o usuário, e deve deixá-lo começar a entrevista por onde ele preferir. Algunsusuários desejarão começar pelas saídas, isto é, pelos relatórios e valores de dados queeles querem que o sistema produza (na realidade, eles talvez nem saibam que entradasserão necessárias para produzir as saídas desejadas). Outros usuários poderão estar maisinteressados nas entradas ou nos detalhes de uma transformação funcional. Outros aindapreferirão falar sobre os detalhes dos dados de um depósito de dados. Deve-se esforçarpara enxergar os requisitos do sistema da perspectiva desses usuários, e conservar estaperspectiva em mente quando fizer as perguntas necessárias sua entrevista.

• Use um Estilo Adequado de Entrevistar

– Como diz William Davis [Davis, 1983]: Sua atitude em relação à entrevista é importantena determinação de seu sucesso ou fracasso. Uma entrevista não é uma competição.



Evite ataques; evite o uso excessivo do jargão técnico; conduza uma entrevista, não umatentativa de persuasão. Fale com as pessoas, não fale muito alto, nem muito baixo, nemindiretamente. Uma entrevista não é um julgamento. Faça perguntas detalhadas, masnão faça perguntas para confirmar outras respostas. Lembre-se que o entrevistado é operito e que é você que precisa de respostas. Para concluir, de modo algum critique acredibilidade de outras pessoas.Fazer perguntas detalhadas nem sempre é fácil; dependendo da personalidade do entre-vistado e do tema da entrevista, pode-se precisar de um conjunto de estilos para extrairas informações necessárias. Alguns estilos que podem mostrar-se úteis:

∗ Relacionamentos. Pedir ao usuário para explicar o relacionamento entre o queestá em discussão e as demais partes do sistema. Se o usuário estiver falando sobreum assunto (p.ex.: um cliente), pedir-lhe que explique seu relacionamento sob outrosaspectos; se ele estiver descrevendo uma função (ex.: uma bolha de um DFD), pedir-lhe que explique seu relacionamento com outras funções. Isso não só o auxiliará adescobrir mais detalhes sobre o item em pauta, mas também o ajudará a descobririnterfaces (ex.: fluxos de dados de uma bolha para outra no DFD) e relacionamentosformais.

∗ Pontos de vista alternativos. Solicitar ao usuário que descreva o ponto de vista deoutros usuários em relação ao item que esteja sendo discutido. Perguntar ao usuário,por exemplo, o que seu chefe pensa sobre uma bolha do DFD, ou um tipo de objetodo DER; ou pergunte o que pensa seu subordinado.

∗ Detalhamento. Solicitar ao usuário uma informal descrição narrativa do item emque estiver interessado. Fale-me sobre o modo como você calcula o valor das remessas.Ou, se estiver falando com o usuário sobre um tipo de objeto no DER, poderia dizer-lhe: Fale-me a respeito de um cliente. O que você sabe (ou precisa saber) sobre umcliente?

∗ Dependências. Perguntar ao usuário se o item em discussão depende, para suaexistência, de alguma outra coisa. Isso é especialmente útil quando se discutempossíveis tipos de objetos e relacionamentos no DER. Em um sistema de controlede pedidos, por exemplo, pode-se perguntar ao usuário se seria possível haver umpedido sem que haja um cliente.

∗ Confirmação. Dizer ao usuário o que acha que ouviu ele dizer; usar suas própriaspalavras em lugar das dele e peça confirmação. Pode-se dizer: Deixe-me ver se entendio que você disse...

4.2.5 Formas Alternativas de Coleta de Dados

As entrevistas não são o único modo de coleta de informações sobre os requisitos de um sistema.Na realidade, quanto mais informações puder colher de outras fontes, mais produtivas poderão seras entrevistas pessoais. Alternativas para as entrevistas:

• Questionários. Pode remeter questionários escritos para os usuários dentro da organização,para as pessoas (ou setores) que interagem com o sistema, para os diretores que aprovaram oprojeto e para outros.

• Demonstrações feitas pelos fornecedores. Os fornecedores de hardware e os fornecedoresde software podem já haver desenvolvido sistemas prontos para a aplicação em que vocêesteja interessado. Solicitando-lhes uma demonstração dos recursos desses sistemas pode nãosomente auxiliá-lo a decidir se o produto é uma boa solução, mas também revelar funções edados armazenados que você pode não ter percebido.

• Visitas a outras instalações. Procure outras empresas que estejam no mesmo ramo de ati-vidades ou que tenham sistemas semelhantes aquele em que você esteja trabalhando. Combine



uma visita à instalação para obter informações diretas sobre as características e aptidões dosistema.

• Coleta de dados. Procure formulários, relatórios, manuais, procedimentos escritos, registros,imagens de tela de terminais e listagens de programas que já existam na organização usuária.Lembre-se, todavia, que esses recursos normalmente estão relacionados com a implementaçãoatual do sistema; devemos lembrar que isto costuma incluir informações redundantes e/oucontraditórias e/ou obsoletas. Não obstante, isto muitas vezes é um bom ponto de partidapara você familiarizar-se com o terreno antes de iniciar as entrevistas pessoais com o usuário.

• Pesquisa externa. Se você estiver construindo um sistema para uma nova aplicação, para aqual o usuário não dispõe de qualquer experiência para descrever os requisitos, talvez sejanecessário tentar obter informações em sociedades profissionais, ou em periódicos e livrostécnicos e em relatórios de pesquisas.

Questionário de Pesquisa

Essa ferramenta é muito conveniente quando há um grande número de usuários ou vários gruposde usuários em locais diferentes. Nestas situações não é prático entrevistar todas as pessoas, mas tãologo as informações obtidas através dos questionários tenham sido analisadas, podem ser realizadasentrevistas com usuários selecionados.

Podem ser usados diversos formatos para o questionário de pesquisa, tais como: de múltiplaescolha, lista de verificação (checklist), questões abertas (descritivas) e combinações das anteriores.Os passos para a utilização do questionário de pesquisa são:

1. Preparação do questionário:

• Identifique o tipo de informação que deseja obter, como problemas experimentados ouoportunidades a explorar;

• Definidos os requisitos, escolha um formato apropriado para o questionário;

• Monte questões de forma simples, clara e concisa;

• Se incluir questões abertas, observar o espaço necessário para a resposta;

• Agrupar as questões por tópicos ou áreas afins;

• Se possível, enviar junto com o questionário uma carta da direção da empresa explicandoos motivos e a importância da pesquisa para a organização.

2. Identificação dos respondentes

• O questionário deve ser personalizado com o nome, função e localização do respondente;

• Elaborar um controle de identificação das pessoas que receberão os questionários. Utilizaro controle para monitorar a situação dos questionários.

3. Distribuição do questionário

• Distribua o questionário junto com as instruções de preenchimento;

• Indique claramente o prazo para a devolução do questionário e a forma de devolução.

4. Análise das respostas

• Consolide e análise as informações fornecidas pelos questionários devolvidos;

• Documente as principais descobertas;

• Envie uma cópia do relatório com as principais descobertas para cada respondente comouma cortesia pelo tempo dedicado à pesquisa.



Observações no ambiente

A análise de observação é uma técnica de observação de fatos muito efetiva. Ela pode serusada para diversas finalidades, como processamento e confirmação de resultados de uma entrevista,identificação de documentos que devem ser coletados para análise, esclarecimento do que está sendofeito no ambiente atual.

Esta técnica é simples. Durante algum tempo, o analista fica observando os usuários em seuambiente enquanto eles executam suas tarefas diárias. Freqüentemente o analista fará perguntaspara conhecer o funcionamento e as atividades desenvolvidas. É importante explicar para as pessoasque serão observadas o que será observado e porque. Os passos para a observação são:

1. Antes:

• Identifique as áreas a serem observadas;

• Obter a aprovação da gerencia apropriada para executar a observação;

• Obter os nomes e funções das pessoas-chaves que serão envolvidas no estudo de observa-ção;

• Explicar a finalidade do estudo;

2. Durante:

• Familiarizar-se com o local de trabalho a ser observado;

• Observar os agrupamentos organizacionais atuais;

• Observar as facilidades manuais e automatizadas em uso;

• Coletar amostras de documentos e procedimentos escritos que são utilizados nos proces-sos observados;

• Acumular informações estatísticas das tarefas observadas: freqüência que ocorrem, esti-mativas de volumes, tempo de duração, etc...

• Enquanto interage com os usuários, tente ser objetivo e não comentar as formas detrabalho de maneira não construtiva;

• Observar também as exceções;

• Terminando as observações, agradeça às pessoas o apoio e a colaboração dispensada aoseu trabalho.

3. Após:

• Documente as descobertas resultantes das observações;

• Consolide os resultados;

• Reveja os resultados consolidados com as pessoas observadas e/ou com seus superiores.


Documents

1.4 - Apostila Engenharia de Software