Engenharia de Requisitos

Prévia do material em texto

<p>Didática no Ensino 1</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>ENGENHARIA DE</p><p>REQUISITOS</p><p>Didática no Ensino 1</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>BRANDÃO, Daniel dos Santos, 2020 -</p><p>Engenharia de Requisitos - Jupiter Press - São Paulo/SP</p><p>61 páginas;</p><p>Palavras chaves: 1. Engenharia 2. Requisitos 3. Requisito Funcional 4. Requisi-</p><p>to não funcional</p><p>Didática no Ensino 2</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>s</p><p>SUMÁRIO</p><p>INTRODUÇÃO ..................................................................................................................................................3</p><p>1. FASES DE CONCEPÇÃO E ELABORAÇÃO ................................................................................4</p><p>1.1 FASE DE CONCEPÇÃO .............................................................................................................5</p><p>1.2 FASE DE ELABORAÇÃO ..........................................................................................................7</p><p>1.3 LEVANTAMENTO DE REQUISITOS ...................................................................................8</p><p>1.4 PREPARAÇÃO PARA ELICITAÇÃO DE REQUISITOS ..............................................11</p><p>2. DISCIPLINAS E TÉCNICAS DE MODELAGEM DE REQUISITOS ...................................13</p><p>2.1 CONFIRMANDO A ELICITAÇÃO ........................................................................................16</p><p>2.2 MODELAGEM DE REQUISITOS .........................................................................................17</p><p>2.3 FLUXO DE PROCESSO DE MODELAGEM ..................................................................19</p><p>3. ESTIMATIVA DE CUSTOS E PRAZOS NA ENGENHARIA DE REQUISITOS .............23</p><p>3.1 ESTIMATIVA DE PRAZOS E CRONOGRAMA .............................................................24</p><p>3.2 ESTIMATIVA DE CUSTOS E ORÇAMENTO ..................................................................27</p><p>4. ANÁLISE E GERENCIAMENTO DE RISCOS ..............................................................................29</p><p>4.1 APLICAÇÃO DO GERENCIAMENTO DE RISCOS ....................................................30</p><p>4.2 PADRÃO DE PROJETO DE SOFTWARE ........................................................................32</p><p>4.3 GERENCIAMENTO DE CONFLITOS ...............................................................................35</p><p>4.4 MAIORES RISCOS NO DESENVOLVIMENTO DE SOFTWARE .......................36</p><p>5. FERRAMENTAS DE ANÁLISE E GERÊNCIA DE REQUISITOS ........................................41</p><p>5.1 FERRAMENTAS VISUAIS .........................................................................................................42</p><p>5.2 COMPARATIVO DE FERRAMENTAS ...............................................................................49</p><p>6. IMPLEMENTAÇÃO DE RESULTADOS COM O MPS.BR .....................................................52</p><p>6.1 PADRÃO DE QUALIDADE DE SOFTWARE NO BRASIL ........................................52</p><p>6.2 PROCESSOS DE PROJETO ...................................................................................................54</p><p>CONSIDERAÇÕES FINAIS ........................................................................................................................56</p><p>REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................................58</p><p>*</p><p>* A navegação deste e-book por meio de botões interativos pode variar de funcionalidade dependendo de cada leitor de PDF.</p><p>Didática no Ensino 3</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>INTRODUÇÃO</p><p>A engenharia de requisitos é uma parte importante ou uma subárea da</p><p>engenharia de software. Através dela, os profissionais da área de desenvolvimento</p><p>de sistemas podem levantar, descobrir e elencar as diferentes necessidades</p><p>dos usuários de uma aplicação em uso ou de um software que ainda precisa ser</p><p>desenvolvido. Atender a tais necessidades é a tarefa do engenheiro de requisitos</p><p>ou de um engenheiro de software, analista de sistemas e outros perfis que exercem</p><p>tal função.</p><p>Um requisito se trata da necessidade ou problema apresentado por um cliente</p><p>e/ou usuário de uma solução de software. De tais problemas, uma documentação</p><p>precisa ser escrita e definida, a partir da aplicação de diferentes técnicas e</p><p>metodologias com o intuito de descrever a problemática a ser solucionada com</p><p>um novo ou com a melhoria de um produto de software.</p><p>Por mais que tenhamos diferentes metodologias e formas de se programar</p><p>e criar softwares, a engenharia de requisitos existe como um elo de ligação entre</p><p>os usuários finais - requisitantes do software - e a equipe de desenvolvimento,</p><p>podendo passar por outros perfis profissionais de dentro de uma organização,</p><p>caso a necessidade exija. A partir disso, temos um campo fértil a ser explorado,</p><p>com técnicas e ferramentas capazes de aprimorar e até mesmo acelerar a forma</p><p>como desenvolvemos softwares, que por diferentes motivos, têm evoluído muitos,</p><p>graças à internet e as novas formas de comunicação e tecnologias da informação</p><p>como um todo.</p><p>A partir disso, espera-se que ao final deste módulo seja capaz de distinguir os</p><p>conceitos relacionados a requisitos e ao desenvolvimento de software, passando</p><p>por especificações técnicas, metodologias e diferentes formas de se atingir tais</p><p>objetivos.</p><p>Didática no Ensino 4</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>1. FASES DE CONCEPÇÃO E ELABORAÇÃO</p><p>Podemos dizer que todo sistema ou software nasce a partir de alguma</p><p>necessidade dos usuários. De maneira geral, os problemas ou as “dores” de quem</p><p>precisa de um software precisa ser transcrito em algumas definições a fim de que</p><p>quem for desenvolver aquele artefato possa realmente tentar compreender em</p><p>que contexto a solução deverá se encaixar para o usuário final de software. As</p><p>primeiras fases de um projeto de software abrangem as citadas no título deste</p><p>tópico: Concepção e Elaboração.</p><p>As fases iniciais abrangem o levantamento da tal necessidade do usuário,</p><p>entendendo e traduzindo os problemas existentes nos chamados requisitos.</p><p>Requisito pode ser definido como a necessidade ou o problema que o usuário ou</p><p>cliente possa ter. De acordo com a IEEE e seu dicionário padrão (2017), requisito</p><p>é uma condição ou capacidade que deve:</p><p>• ser necessária para um usuário resolver um problema ou alcançar um objetivo;</p><p>• satisfazer uma especificação em um sistema ou em um componente;</p><p>• possuir representação documentada.</p><p>Isso nos leva a dizer que requisitos são fundamentais em todo o processo de</p><p>software, em todas as etapas de seu projeto de desenvolvimento, como podemos</p><p>ver na Figura 1 a seguir.</p><p>Figura 1: Fases e Disciplinas de um projeto de software</p><p>Fonte: Adaptado de Kruchten (2003)</p><p>Didática no Ensino 5</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Dada a Figura 1, podemos observar que entre as fases de um projeto de</p><p>software, a de concepção (também chamada de iniciação) é a etapa onde se</p><p>concentra o levantamento do problema a ser resolvido, fase essa onde se pode</p><p>realizar o levantamento de requisitos à cargo da engenharia de requisitos, uma</p><p>subdivisão da engenharia de software específica para estudos relativos a elicitação</p><p>dos tais requisitos.</p><p>De acordo com Sommerville (2011), o objetivo da Engenharia de Requisitos</p><p>é oferecer ao engenheiro de software, métodos, técnicas e ferramentas que</p><p>auxiliem o processo de compreensão e registro dos requisitos que o software</p><p>deve atender (SOMMERVILLE, 2011).</p><p>Percebe-se, então, que se tem na fase de concepção uma maior concentração</p><p>das tarefas (ou disciplinas) relativas a regra de negócio e de requisitos, justamente</p><p>o momento do projeto onde se tenta entender a partir da visão do usuário o</p><p>que se precisa desenvolver. Nesta fase, temos as definições iniciais do projeto</p><p>de software, traduzido da linguagem do usuário para a dos desenvolvedores e</p><p>profissionais de TI (Tecnologia da Informação), o chamado código-fonte.</p><p>A partir disso, um grande salto é dado, chegando à próxima fase, chamada</p><p>os capítulos</p><p>o quadro a seguir:</p><p>1. Introdução</p><p>1.1 Visão Geral do Projeto</p><p>1.2 Entregáveis do Projeto</p><p>1.3 Evolução do Plano de Gerenciamento de Projeto de Software</p><p>1.4 Materiais de Referência</p><p>1.5 Definições e acrônimos</p><p>2. Organização do Projeto</p><p>2.1 Modelo de Processo</p><p>2.2 Estrutura Organizacional</p><p>2.3 Limites e interfaces organizacionais</p><p>2.4 Responsabilidades do Projeto</p><p>3. Processo de Gestão</p><p>3.1 Objetivos e prioridades de gestão</p><p>3.2 Suposições, Dependências e Restrições</p><p>3.3 Gestão de Risco</p><p>3.4 Mecanismos de monitoramento e controle</p><p>3.5 Plano de Pessoal</p><p>4. Processo Técnico</p><p>4.1 Métodos, Ferramentas e Técnicas</p><p>4.2 Documentação de Software</p><p>4.3 Funções de Apoio ao Projeto</p><p>5. Pacotes de trabalho, cronograma e orçamento</p><p>5.1 Pacotes de Trabalho</p><p>5.2 Dependências</p><p>5.3 Requisitos de Recursos</p><p>5.4 Orçamento e Alocação de Recursos</p><p>5.5 Cronograma</p><p>6. Componentes Adicionais</p><p>7. Índice</p><p>8. Apêndices</p><p>Quadro 2 - Plano Padrão de Projeto de Software segundo IEEE</p><p>4.3 GERENCIAMENTO DE CONFLITOS</p><p>Os conflitos fazem parte da vida diária do gerente de projeto. Eles surgem</p><p>desde problemas dentro da equipe, bem como de lidar com partes interessadas</p><p>externas. Clientes e stakeholders mais leigos tendem a ter problemas para</p><p>entender o porquê de alguns custos ou prazos serem acima ou abaixo do esperado</p><p>por eles. Cada projeto tem fontes abundantes de conflito potencial. As fontes mais</p><p>comuns incluem competição por recursos escassos, diferenças relacionadas a</p><p>objetivos e os meios para alcançá-los e divergências sobre custo, cronograma ou</p><p>compensações técnicas.</p><p>Didática no Ensino 36</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Alguns conflitos também surgem das relações interpessoais.</p><p>Independentemente da causa, os gerentes de projeto não podem ignorar</p><p>os conflitos, eles devem identificá-los à medida que surgem, compreender a</p><p>natureza de suas causas e resolvê-las em seus estágios iniciais. Não fazer isso pode</p><p>interromper seriamente um projeto e levar a atrasos desnecessários e estouros de</p><p>custo.</p><p>Conflitos internos tornam-se risco ao projeto uma vez que podem custar caro</p><p>seja pela exigência do aumento de escopo e requisitos do projeto de software ou</p><p>pela troca de mão de obra de algum profissional envolvido. Até mesmo a troca de</p><p>tecnologias, sejam tipos de servidores físicos ou de linguagem de programação,</p><p>afetam em custos e prazos, mudando o que foi antes projetado e se tornando um</p><p>risco a conclusão do projeto.</p><p>Muitas falhas de projeto podem ser atribuídas a uma falha nas comunicações.</p><p>Por isso, é responsabilidade do gerente do projeto criar um ambiente para uma</p><p>boa comunicação dentro da equipe e gerenciar o processo de comunicação</p><p>com as partes interessadas externas, particularmente com a organização do</p><p>cliente. Em um projeto eficaz, os gerentes mantêm todas as partes envolvidas</p><p>informadas, evitando surpreender o cliente. O sucesso também não depende</p><p>apenas de estruturas de relatórios formais. Linguagem corporal em uma reunião</p><p>de status muitas vezes pode fornecer mais informações do que um relatório de</p><p>status escrito.</p><p>Quando uma entidade toma uma decisão de criar um software, ela se expõe</p><p>a uma série de riscos. O total de tais riscos depende do tipo de instrumento que</p><p>for projetado. Esses riscos incluem questões financeiras e podem ser na forma</p><p>de alto risco, volatilidade nos requisitos, abertura de exceções etc. Assim, com</p><p>o objetivo de minimizar e controlar os riscos, os gestores de projetos praticam a</p><p>gestão de riscos. Não dar a devida importância à gestão de risco ao tomar decisões</p><p>de projeto pode causar estragos no processo ao longo do tempo, levando ao</p><p>rompimento de contrato (que não exclui processos por via judicial).</p><p>4.4 MAIORES RISCOS NO DESENVOLVIMENTO DE SOFTWARE</p><p>O reconhecimento de que o desenvolvimento de software possui certa</p><p>complexidade de prever e planejar é natural, visto que o software é algo</p><p>intangível e frequentemente envolve um grande número de partes interessadas.</p><p>Essa combinação de fatores pode criar uma série de riscos que precisam ser</p><p>considerados e gerenciados desde o início de um projeto de software.</p><p>Didática no Ensino 37</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Embora possamos estimar a ameaça que esses riscos terão em um projeto</p><p>de software, a probabilidade e o impacto de sua ocorrência variam dependendo</p><p>da metodologia que se está usando. Experientes profissionais da área de software</p><p>apresentam vários tipos de riscos que um projeto está suscetível. Na perspectiva</p><p>de um gerente de projetos, é de se esperar que alguns problemas ocorram,</p><p>como já citamos anteriormente, mas também existem meios para se prevenir ou</p><p>minimizar os impactos e riscos de um projeto. A seguir, apresentaremos alguns</p><p>dos principais riscos que podem tornar um projeto inviável.</p><p>Estimativas imprecisas</p><p>Embora as estimativas sejam uma parte muitas vezes inevitável do</p><p>desenvolvimento de software (por pressão dos clientes ou stakeholders para obter</p><p>um preço ou prazo), elas podem criar risco se as estimativas criarem expectativas</p><p>que não podem ser atendidas. Estimativas imprecisas ocorrem quando a duração</p><p>de um projeto, marco ou iteração é subestimada pelo grupo do projeto. As</p><p>estimativas de software podem causar problemas entre desenvolvedores e</p><p>clientes porque aumentam os prazos do projeto e, portanto, também as despesas</p><p>com o projeto.</p><p>Variações de escopo</p><p>As variações de escopo ocorrem quando o escopo de uma iteração muda</p><p>depois que um período de tempo foi acordado. Devido ao valor de receber</p><p>feedback frequente do cliente, as partes interessadas ou proprietários do produto</p><p>muitas vezes pedem para variar o escopo de um projeto. No entanto, a variação do</p><p>escopo cria um risco grave para os projetos. Quando um escopo varia, isso afeta</p><p>significativamente a capacidade dos desenvolvedores de seguir o cronograma</p><p>original de um projeto.</p><p>Por isso, gerenciar as expectativas do cliente sobre como a variação do</p><p>escopo pode impactar as estimativas originais de um projeto é uma estratégia de</p><p>mitigação importante para esse risco. Usar uma métrica de variação para medir as</p><p>mudanças de escopo permite maior visibilidade ao cliente de como as solicitações</p><p>impactarão o projeto. A seguir temos algumas estratégias valiosas para lidar com</p><p>variações de escopo:</p><p>• Iterações curtas e gerenciáveis (usando metodologia Ágil) permitem oportunidades</p><p>mais frequentes de refletir e variar o escopo do projeto;</p><p>• Elaboração de apenas trabalhos priorizados.</p><p>•</p><p>• Engajamento do usuário final</p><p>Didática no Ensino 38</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Este risco ocorre quando um produto é lançado no mercado, mas os usuários</p><p>são resistentes a mudanças ou há conflito entre os usuários, por exemplo. Garantir</p><p>que os usuários de um produto realmente adotem o software estará diretamente</p><p>relacionado ao seu sucesso. No caso de uma empresa que desenvolve software</p><p>para um cliente externo, isso se correlaciona com a lucratividade.</p><p>No caso do desenvolvimento de um software para uso interno, ele pode</p><p>determinar se o software realmente melhorará a produtividade dentro da</p><p>empresa. Para melhorar o engajamento do usuário, pode-se surpreender com a</p><p>simples estratégia de ouvir os usuários. De acordo com Buratti (2014), algumas</p><p>estratégias de mitigação possíveis para este risco incluem:</p><p>• Teste de usuário e pesquisas;</p><p>• Prototipação;</p><p>• Lançamentos frequentes;</p><p>• Teste beta.</p><p>Essas estratégias de mitigação são muito mais fáceis de aplicar usando o</p><p>desenvolvimento ágil. A chance de baixo envolvimento do usuário final é muito</p><p>mais provável para projetos que seguem uma metodologia em cascata (método</p><p>mais tradicional de desenvolvimento de software). Isso ocorre porque esses tipos</p><p>de projetos são, muitas vezes, incapazes de se adaptar ao feedback do usuário</p><p>final durante o desenvolvimento. A natureza do desenvolvimento em cascata não</p><p>requer variações de escopo.</p><p>Expectativas das partes interessadas</p><p>Embora se fale sobre o gerenciamento</p><p>das expectativas das partes</p><p>interessadas como uma estratégia de mitigação, a adoção dessa estratégia pode,</p><p>por si só, se tornar um risco do projeto. As partes interessadas são pessoas ou</p><p>grupos que podem impactar ou serão impactados por um resultado do projeto de</p><p>software. Essas partes interessadas podem variar de proprietários de negócios à</p><p>equipe de desenvolvimento ou até mesmo investidores no projeto. É essa relação</p><p>próxima com o resultado do projeto que torna o gerenciamento das expectativas</p><p>de cada uma dessas partes interessadas um desafio.</p><p>Para Macedo e Salgado (2015), definir as expectativas com as partes</p><p>interessadas estão relacionada em algumas características importantes, como:</p><p>• Comunicação efetiva;</p><p>• Obter aprovação frequente e reconhecimento do projeto de uma parte interessada;</p><p>• Seguir metodologias de desenvolvimento testadas;</p><p>Didática no Ensino 39</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>• Envolver as partes interessadas em reuniões importantes;</p><p>• Certificar-se de que as partes interessadas mantenham linhas de feedback constan-</p><p>tes para boa comunicação com as equipes de desenvolvimento.</p><p>Código de má qualidade</p><p>Quando a qualidade de um projeto não se alinha com as expectativas das</p><p>partes interessadas, existe um risco significativo de que o projeto não seja bem-</p><p>sucedido. Pode parecer meio óbvio, mas o código-fonte de baixa qualidade pode</p><p>ocorrer por vários motivos, por exemplo, quando os projetos são subestimados e</p><p>os desenvolvedores se apressam para concluir a iteração.</p><p>Um código ruim ou de baixa qualidade pode significar várias coisas. O código</p><p>pode ser difícil de ler, o que significa que é difícil para outros desenvolvedores</p><p>revisar ou fazer alterações. Pode ter sido apressado e lançado sem teste, portanto</p><p>cheio de bugs que poderiam ter sido evitados. Em outras palavras, um código de</p><p>baixa qualidade cria um risco de déficit técnico.</p><p>Déficit técnico é essencialmente qualquer código que diminui a agilidade</p><p>de um projeto de software no longo prazo. Normalmente, ele é criado por meio</p><p>de atalhos ao escrever o código, a fim de atingir objetivos mais rapidamente.</p><p>No entanto, a qualidade do código é importante porque reduz o esforço de</p><p>desenvolvimento de longo prazo de um projeto, tornando o projeto mais fácil de</p><p>entender, manter e escalar (crescimento).</p><p>Para podermos melhorar a qualidade do código produzido, é importante que</p><p>os desenvolvedores mantenham um alto padrão para seu código. Isso pode ser</p><p>feito considerando as seguintes estratégias:</p><p>• Revisões de código;</p><p>• Padrões e guias de codificação claros;</p><p>• Teste de todo o código;</p><p>• Nomear um Gerente de Produto dedicado para monitorar a qualidade do projeto e</p><p>assumir a responsabilidade de todos os interessados pelo sucesso e falhas;</p><p>• Desenvolvimento em pares;</p><p>A maneira de trabalhar reflete no resultado, em se tratando de linhas de código</p><p>isso não é muito diferente. O uso de frameworks, linguagens de programação mais</p><p>atualizadas e a leitura de manuais podem ser fatores que fazem toda a diferença</p><p>no desenvolvimento de um software de qualidade e com menor riscos.</p><p>Didática no Ensino 40</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Gerenciamento de risco inadequado</p><p>O gerenciamento de risco inadequado pode ocorrer quando qualquer um</p><p>dos riscos específicos do projeto não é devidamente reconhecido e solucionado</p><p>pelas partes interessadas. O gerenciamento de risco adequado para um projeto</p><p>de desenvolvimento de software precisa respeitar o caminho, começando pelo</p><p>reconhecimento de que os riscos existem. A estratégia de se omitir ou fingir que</p><p>pode entregar software sem enfrentar nenhum desses problemas só causará</p><p>estresse e problemas a serem resolvidos a longo prazo.</p><p>Uma solução ideal passa por considerar estratégias de busca dos riscos desde</p><p>o início e continuar tal busca ao longo do projeto de software. Existem muitos</p><p>riscos ao construir um software e, se um risco for efetivamente identificado, ele</p><p>pode ser solucionado. É importante que se determine quais riscos são específicos</p><p>ao projeto e defina métodos para resolvê-los desde o início do projeto. Para ajudar</p><p>a identificar o impacto que um risco específico pode ter no projeto de software, é</p><p>possível usar uma matriz de risco. Para determinar quais são os maiores riscos em</p><p>um projeto, é preciso determinar o impacto e a probabilidade de ocorrência do</p><p>risco.</p><p>Mas, com certeza, existem outros tipos de riscos. Os citados aqui foram</p><p>apenas os mais frequentes e os de maior destaque no cenário de desenvolvimento</p><p>de softwares. Infelizmente, os riscos geralmente só se tornam evidentes quando</p><p>algo dá errado em um projeto. Portanto, é importante ficar bem claro desde o</p><p>início quem é responsável por quais aspectos do projeto e quando ele deve ser</p><p>entregue, a fim de determinar quem deve cuidar para que cada aspecto de risco</p><p>seja mitigado o mais rápido possível.</p><p>Didática no Ensino 41</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>5. FERRAMENTAS DE ANÁLISE E GERÊNCIA DE</p><p>REQUISITOS</p><p>Manter uma boa comunicação é algo difícil na engenharia de requisitos. A</p><p>conversa entre usuários finais e especialistas em TI pode se comparar a duas pessoas</p><p>de países diferentes, falando línguas diferentes. Ou seja, ambos têm experiências</p><p>diferentes e, portanto, muitos mal-entendidos ocorrem frequentemente,</p><p>sem muitas vezes serem percebidos, até chegar a um ponto mais adiante do</p><p>projeto. Isso pode gerar problemas financeiros e desvantagens oportunas, cujo</p><p>envolvimento inicial dos usuários finais para os requisitos elicitação pode ser um</p><p>remédio preventivo. Mas, a comunicação entre usuários finais e especialistas de</p><p>TI é um problema da engenharia de requisitos.</p><p>Estudos mostram que 60% das falhas do projeto saem de alguma das fases da</p><p>engenharia de requisitos e muitas vezes não são descobertos até o final do projeto</p><p>ou quando o sistema já concluiu seu ciclo de vida (Marcelo e Salgado, 2015). Como</p><p>já vimos quando tratamos dos riscos em projetos de software, quanto mais tarde o</p><p>erro for detectado, mais caro é a retificação. Uma vez que requisitos ausentes ou</p><p>incompletos fazem com que os projetos falhem, é importante encontrar soluções</p><p>para melhorar a qualidade dos requisitos.</p><p>Os engenheiros de software esperam requisitos bem formulados, escritos</p><p>de forma detalhada e com uma especificação formal. Para os usuários finais,</p><p>desenvolver tais especificações é muito difícil e demorado. É por isso que os</p><p>analistas de requisitos devem escrevê-los com o apoio das partes interessadas.</p><p>Existem muitos métodos e técnicas para induzir o usuário a definir bem requisitos,</p><p>muito úteis para os analistas de requisitos. Beyer et al (2015) afirmam que entrevistas</p><p>tradicionais, pesquisas e workshops são usados principalmente, mas nem sempre</p><p>são o mais adequado. Para preencher a lacuna de comunicação entre usuários</p><p>finais e especialistas em TI, técnicas e ferramentas são frequentemente utilizadas.</p><p>Existem diferentes abordagens para encontrar ferramentas úteis ao usuário</p><p>para se obter requisitos. Uma abordagem é encontrar uma linguagem comum</p><p>entre os usuários finais, analistas de requisitos e engenheiros de software por</p><p>meio da visualização. Outra abordagem consiste em registrar um requisito</p><p>ou necessidade utilizando um aplicativo de gravação de áudio para registrar</p><p>conversas informais e reuniões de trabalho.</p><p>Didática no Ensino 42</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Mesmo que a participação do usuário final na engenharia de requisitos seja</p><p>muito importante, atualmente não é usado com freqüência. As razões podem ser</p><p>encontradas no grande gasto de tempo para organizar e realizar pesquisas, bem</p><p>como no tempo que leva para entender os requisitos dos usuários. O objetivo</p><p>do envolvimento do usuário em engenharia de requisitos é melhorar o processo</p><p>de design, facilitar a implementação e abordar os princípios éticos do projeto.</p><p>O envolvimento do usuário pode ser realizado ao desenvolver especificações</p><p>de requisitos, validando os requisitos,</p><p>apoiando o projeto detalhado e o</p><p>desenvolvimento, revisando as especificações, inspecionando protótipos e</p><p>aceitando as versões lançadas.</p><p>Para chegar a esse objetivo de interação com o usuário, existem ferramentas</p><p>e aplicações próprias para isso que permitem desenhar e modelar os requisitos</p><p>de maneira bastante prática. OpenProposal é um ferramenta de visualização que</p><p>espera que o usuário final desenhe requisitos em suas telas e envie posteriormente</p><p>para especialistas de TI. A visualização imediata integra o usuário final desde o</p><p>início até o processo de descrição de requisitos. O iRequire é um aplicativo de</p><p>elicitação de requisitos, que os usuários finais podem utilizar a nível local para</p><p>esboçar requisitos. Já o ConTexter é uma ferramenta usada em um ecossistema</p><p>de TI onde um grande público pode relatar seu feedback para diferentes sistemas</p><p>que precisam ser identificados.</p><p>5.1 FERRAMENTAS VISUAIS</p><p>Existem muitas soluções para aquisição de requisitos de maneira visual,</p><p>mas principalmente para analistas de requisitos e engenheiros de software, por</p><p>exemplo Diagramas de casos de uso UML, mockups, técnicas de prototipagem</p><p>rápida. Com tais tipos de ferramentas, os usuários finais podem dar um feedback</p><p>mas precisam de uma certa experiência em TI. É por isso que autores e profissionais</p><p>da área indicam que as ferramentas focadas no usuário final são necessárias,</p><p>pois podem descrever suas necessidades de forma natural por meio de auxílio</p><p>visual. Buratti (2014) afirma que a visualização ajuda o usuário final a identificar</p><p>seus requisitos e é mais intuitivo e fácil de usar do que as linguagens textuais. Para</p><p>entendermos como diferentes ferramentas podem auxiliar de maneira visual</p><p>os usuários e os analistas a compreenderem os requisitos, veremos a seguir a</p><p>especificação de algumas delas.</p><p>5.1.1 OpenProposal</p><p>A abordagem OpenProposal é baseada na ferramenta de anotação Annotate!</p><p>Pro, onde os usuários finais podem anotar os requisitos quando eles acontecerem.</p><p>Possui uma visualização imediata para abordagem de sistemas abrangentes,</p><p>Didática no Ensino 43</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>em que o usuário final está envolvido desde o início. De acordo com Rashid et</p><p>al (2008), o OpenProposal permite aos usuários anotar suas solicitações de</p><p>recursos, erros ou solicitações de aprimoramento diretamente em seu espaço de</p><p>trabalho de aplicativos e enviar essas solicitações para o analista de de requisitos.</p><p>Assim, os usuários finais participam ativamente no processo de desenvolvimento</p><p>de software por meio do envio de requisitos para software, bem como software</p><p>em desenvolvimento.</p><p>Temos na Figura 8 o fluxo de trabalho da engenharia de requisitos com o</p><p>usuário final participando do processo. A OpenProposal é baseada neste fluxo</p><p>de trabalho apresentado na Figura 8.</p><p>Figura 8 - Fluxo de processos do OpenProposal</p><p>Fonte: Elaborado pelo autor (adaptado de Rashid et al, 2008)</p><p>No fluxo de trabalho proposto pelo OpenProposal existem três atores</p><p>principais: o usuário final, o analista de requisitos e o engenheiro de software , bem</p><p>como cinco ações: especificar, discutir, priorizar, decidir e implementar. Os usuários</p><p>finais participam principalmente da especificação e atividades de discussão. Os</p><p>analistas de requisitos são responsáveis pela gestão das demandas de requisitos</p><p>e devem buscar compreender os interesses dos envolvidos nas discussões, na</p><p>atribuição de prioridades e na tomada de decisões. Eles também podem propor</p><p>novos requisitos. Por sua vez, o foco principal dos engenheiros de software é</p><p>entender as propostas do usuário, implementá-las corretamente e contribuir com</p><p>conhecimento técnico profissional para todas as demais atividades.</p><p>Didática no Ensino 44</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>A abordagem OpenProposal é estruturada em três componentes principais,</p><p>o OpenProposal Annotation Tool, OpenProposal Mediator e OpenProposal</p><p>Issue-Tracker. A OpenProposal Annotation Tool (ou ferramenta de anotação</p><p>OpenProposal) é baseada na ferramenta de anotação Annotate! Pro. Ele</p><p>reúne os requisitos anotados (capturas de tela, anotações, metadados) em uma</p><p>especificação XML que é enviada ao OpenProposal Mediator (o mediador).</p><p>O mediador cria um novo problema no OpenProposal Issue-Tracker com as</p><p>especificações recebidas. A partir disso, o problema agora pode ser discutido</p><p>e avaliado na ferramenta Issue-Tracker. Uma lista de requisitos enviados fica</p><p>disponível na ferramenta de anotação do OpenProposal.</p><p>O OpenProposal se destina a apoiar o processo de desenvolvimento de</p><p>software para equipes de desenvolvimento cujos membros da equipe podem</p><p>estar em locais diferentes (trabalho remoto) e podem melhorar a comunicação</p><p>com os recursos visuais do OpenProposal. A pesquisa feita por Rashid et al (2008)</p><p>também mostrou que o software pode melhorar a colaboração entre usuários finais</p><p>e engenheiros de software e tem um desempenho melhor do que ferramentas</p><p>convencionais. A Figura 9 apresenta a tela de utilização do OpenProposal que</p><p>servirá como forma de descrevermos o funcionamento da ferramenta de modo</p><p>geral.</p><p>Figura 9 - Interface do OpenProposal</p><p>Fonte: Rashid et al (2008).</p><p>Conforme a Figura 9, o conjunto de ferramentas OpenProposal pode ser</p><p>Didática no Ensino 45</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>acessado a partir da barra de ferramentas (no topo da Figura 9) e oferece quatro</p><p>ferramentas relacionadas à anotação. A ferramenta “Adicionar” (1) permite aos</p><p>usuários especificar uma posição onde eles gostariam de ter um novo objeto na</p><p>tela. A ferramenta “Remover” (3) é o inverso, o elemento existente é marcado</p><p>como supérfluo. Com a ferramenta “Mover” (2), os usuários primeiro selecionam</p><p>um área que deve ser movida para um local diferente na área de trabalho de</p><p>aplicativos, em seguida, para a nova área-alvo. A ferramenta “Comentário” (4)</p><p>pode ser usada para sugestões de outras ferramentas que não são capazes de</p><p>expressar diretamente, bem como de refinar e adicionar mais detalhes aos outros</p><p>anotações das ferramentas.</p><p>Ainda de acordo com a Figura 9, os usuários podem pausar a anotação, caso</p><p>queiram mudar o layout do aplicativo que estão anotando (A). Todas as anotações</p><p>são representadas como objetos que podem ser editados, movidos ou excluídos</p><p>sempre que os usuários quiserem. Assim que terminarem suas anotações, os</p><p>usuários podem enviar suas solicitações para a plataforma de colaboração (H).</p><p>Antes de enviar, o usuário é solicitado a incluir um título e uma descrição de maneira</p><p>textual. Os usuários podem sair do aplicativo a qualquer momento, clicando no X</p><p>no canto superior direito da tela.</p><p>5.1.2 iRequire</p><p>Geralmente, os usuários finais participam de técnicas de elicitação por meio</p><p>de entrevistas e workshops para discutir suas necessidades, mas muitas práticas</p><p>podem ser esquecidas se uma estiver fora do contexto. Isso exige a documentação</p><p>dos requisitos no momento em que acontecem. O iRequire é uma abordagem</p><p>para uma ferramenta para uso do usuário final.</p><p>Hoje em dia, os usuários finais estão familiarizados com dispositivos móveis,</p><p>portanto, uma aplicação como o iRequire surge como algo convencional,</p><p>uma vez que funciona como um aplicativo para dispositivo móvel. Os usuários</p><p>podem documentar suas necessidades quando e onde quiserem, tendo o tempo</p><p>necessário para terminar sua avaliação. Uma vantagem dos dispositivos móveis é</p><p>que eles suportam a documentação com diferentes tipos de mídia, como imagem,</p><p>áudio, vídeo e texto. Beyer et al (2008) introduzem três etapas de elicitação para</p><p>iRequire:</p><p>1. Obtenção de Informações e Contexto: Fornece percepções do ambiente do</p><p>usuário final com texto, imagem, áudio e vídeo.</p><p>2. Obtenção de Necessidades: Documenta as necessidades futuras com descrições</p><p>textuais ou gravações de áudio.</p><p>3. Obtenção de Justificativa/Tarefa: Explicação textual ou com uma gravação de áu-</p><p>Didática no Ensino 46</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>dio a importância de um requisito ou qual tarefa</p><p>é suportada pelo requisito.</p><p>Para manter a flexibilidade, a ordem das etapas pode ser executada como</p><p>se quiser, embora a sequência descrita acima seja sugerida. É importante notar</p><p>que o iRequire não é uma ferramenta de brainstorming, ela se concentra nos</p><p>requisitos descobertos durante o trabalho diário. Depois de reunir os requisitos,</p><p>os analistas de requisitos podem analisar e transcrevê-los em uma especificação</p><p>de requisitos formal. A implementação do iRequire é baseada em um aplicativo</p><p>para smartphone. As telas são estruturadas em um assistente de quatro etapas,</p><p>que permite uma orientação passo a passo para o usuário final (Figura 10).</p><p>Figura 10 - Interface do iRequire</p><p>Fonte: Seyff et al (2010).</p><p>Na primeira tela apresentada na Figura 10 (à esquerda), os objetos relevantes</p><p>são capturados com fotos. A tela dois (Figura 10, à direita) é onde está a real</p><p>necessidade, descrita com a gravação de um áudio ou a escrita de um texto. Na</p><p>tela três (veja na Figura 11, à esquerda) a justificativa ou tarefa é registrada ou</p><p>descrita. A tela quatro (veja na figura 11, à direita) mostra um resumo do requisito</p><p>capturado, que deve ser confirmado antes de ser armazenado no banco de dados.</p><p>Didática no Ensino 47</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Figura 11 - Outras telas da Interface do iRequire</p><p>Fonte: Seyff et al (2010).</p><p>Observe que, em todas as telas, temos os botões voltar (back), avançar</p><p>(new need) e informações (i), bem como um teclado virtual. Além da entrada do</p><p>usuário final, informações relevantes como localização ou hora da documentação</p><p>é capturada automaticamente usando GPS e captura de data e hora (timestamp).</p><p>Nesta fase, os requisitos coletados são armazenados localmente, portanto,</p><p>se for de interesse distribuir as informações para outros participantes, a ferramenta</p><p>permite que novos usuários sejam incluídos no processo. A proposta do iRequire</p><p>vai além de levantar requisitos, permitindo ter um sistema automatizado de</p><p>transcrição para uma documentação formal. Em seu artigo, Seyff et al (2010)</p><p>apresentam um estudo de avaliação que concluiu que os usuários finais eram</p><p>capazes de executar suas tarefas regulares sem ser interrompido ao registrar suas</p><p>necessidades.</p><p>A ferramenta tem evoluído com o tempo, permitindo a avaliação do iRequire</p><p>e seu processo por parte do usuário, apontando necessidades de melhoria, seus</p><p>benefícios ou limitações. Outros recursos foram acoplados desde a primeira</p><p>versão do software, com tecnologias adicionais, como Bluetooth e RFID (tipos de</p><p>comunicação sem fio com fácil conexão e detecção por outros dispositivos).</p><p>Didática no Ensino 48</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>5.1.3 ConTexter</p><p>Proposto por Schneider et al (2014), o ConTexter é uma solução que vai além</p><p>de um simples aplicativo. Em locais públicos, as pessoas são confrontadas com</p><p>muitos sistemas diferentes para os quais fraquezas e falhas são percebidas. Muitas</p><p>vezes as pessoas gostam de dar feedback, se isso puder ser feito de uma maneira</p><p>fácil e sem esforço. O ConTexter fornece tal abordagem.</p><p>Ele é implementado como um aplicativo de dispositivo móvel bastante</p><p>acessível com feedback rápido e facilmente acesso. Ele também explora os</p><p>recursos dos dispositivos móveis como informações de contexto, geográficas</p><p>e posições lógicas no ecossistema de TI, que podem ser identificadas por meio</p><p>de sensores como GPS, WLAN, Bluetooth e URLs atualmente conectados. A</p><p>proposta é de um ecossistema de TI simplificado com dois objetos para os quais o</p><p>feedback pode ser dado.</p><p>Em seu fluxo, a parte interessada fornece informações de contexto com</p><p>o dispositivo móvel, com os melhores destinatários sendo selecionados</p><p>e apresentados ao usuário para que ele possa decidir a quem enviar seus</p><p>apontamentos. A Figura 12 apresenta as capturas de tela do aplicativo móvel</p><p>ConTexter.</p><p>Figura 12 - Telas de interface do ConTexter</p><p>Fonte: Schneider et al (2014)</p><p>Para um estudo de caso, é apresentado um cenário de serviços universitários,</p><p>software e outros objetos universitários usando o ConTexter. A tela mais à</p><p>esquerda (Figura 12) mostra como escolher uma categoria de feedback, a</p><p>visualização ao meio apresenta a decisão de um destinatário final e, à direita, o</p><p>formulário de feedback para envio é exibido. Muitas questões em aberto podem</p><p>ser incorporadas adicionando campos e, portanto, ampliando a pesquisa junto ao</p><p>Didática no Ensino 49</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>usuário. Uma extensão permite o envio de áudio e vídeo como anexo. Atualmente</p><p>Schneider et al (2014) ainda trabalham em versões para iOS (iPhone) e Android.</p><p>5.1.4 Helix RM</p><p>O Helix RM facilita a colaboração com várias partes interessadas - capturando</p><p>requisitos simultaneamente, realizando revisões, sabendo o que está aprovado</p><p>e, o mais importante, estando ciente das mudanças. Com Helix RM, é possível</p><p>definir uma taxonomia rica de tipos de requisitos e seus relacionamentos para</p><p>garantir especificações completas de requisitos e simplificar a decomposição de</p><p>requisitos.</p><p>Como uma ferramenta autônoma, Helix RM fornece o gerenciamento</p><p>de requisitos. Mas, o software possui componentes adicionais no contexto da</p><p>plataforma Helix ALM, podendo com isso realizar a rastreabilidade para frente</p><p>e para trás a fim de produzir relatórios de maneira bastante rápida, verificar a</p><p>cobertura de teste de requisitos e até mesmo rastrear requisitos para alterações no</p><p>código-fonte (no caso de requisitos alterados após o início da fase de construção</p><p>do software). A Figura 13 apresenta uma interface padrão do Helix RM.</p><p>Figura 13: Interface do Helix RM</p><p>Fonte: Elead ALM (2020)</p><p>5.2 COMPARATIVO DE FERRAMENTAS</p><p>Como forma de preencher a lacuna de comunicação entre usuários finais e</p><p>especialistas em TI, diferentes abordagens para ferramentas de usuário final foram</p><p>Didática no Ensino 50</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>apresentadas. Com ferramentas de visualização, os usuários finais podem anotar</p><p>os requisitos de uma forma mais natural e próxima de sua linguagem habitual</p><p>diária. Os aplicativos móveis são baseados em um dispositivo que o usuário final</p><p>já está familiarizado, portanto, as necessidades de documentação podem ser</p><p>facilmente integradas em atividades rotineiras.</p><p>Em um ecossistema de TI, todos podem ser usuários finais. Em tal sistema</p><p>existem muitos sistemas que devem ser identificados para que os requisitos sejam</p><p>submetidos ao sistema de maneira correta. Todas essas abordagens diferentes</p><p>foram implementadas como uma ferramenta ou protótipo. Estudos realizados,</p><p>em sua maioria, concluíram melhorias necessárias mas que o uso de ferramentas</p><p>para elicitar requisitos é algo que contribui muito em um menor gasto de tempo e</p><p>energia no levantamento de requisitos. As ferramentas apresentadas devem ser</p><p>refinadas e fornecer insights mais profundos para o envolvimento do usuário final.</p><p>Possuindo muitas características semelhantes, também apresentam características</p><p>que fazem com que elas possam ser experimentadas por profissionais e clientes</p><p>de software, a fim de que a ideal seja selecionada para uso.</p><p>Por fim, o quadro 3 representa um resumo das ferramentas apresentadas.</p><p>Porém, é preciso enfatizar o esforço para envolver os usuários finais na abordagem</p><p>inicial e de fácil utilização.</p><p>Ferramenta Benefícios Limitações</p><p>OpenProposal Os usuários finais desenham suas</p><p>próprias necessidades com a ajuda de</p><p>um modelo; Plataforma de rastrea-</p><p>mento e discussão;</p><p>Melhora a colaboração entre os usuá-</p><p>rios finais e especialistas em TI.</p><p>Uso de modelos pode precisar de suporte;</p><p>Os usuários finais devem</p><p>cumprir acordo de privacidade dos dados espontaneamente;</p><p>Sem transcrição automática.</p><p>iRequire Os usuários finais coletam seus</p><p>requisitos durante</p><p>atividades diárias sem</p><p>alterar muito sua rotina diária;</p><p>Sem transcrição automática.</p><p>ConTexter Feedback para múltiplos</p><p>sistemas</p><p>Sem transcrição automática.</p><p>Helix RM Captura requisitos simultaneamente;</p><p>Realiza revisões constantes;</p><p>Permite saber</p><p>o que está aprovado</p><p>em tempo real</p><p>Custo para personalização e suporte.</p><p>Quadro 3 - Comparativo entre características das diferentes ferramentas</p><p>De maneira geral, o gerenciamento de requisitos tem foco em soluções</p><p>Didática no Ensino 51</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>onde os usuários finais possam participar de todo o processo da melhor maneira</p><p>possível. Uma das principais limitações é a dificuldade de comunicação entre</p><p>usuários e especialistas em TI, uma vez que o conhecimento técnico de ambos são</p><p>particulares, muitas vezes sendo o maior obstáculo. Os gerentes de projeto têm</p><p>buscado o uso das ferramentas aqui apresentadas justamente para que sua forma</p><p>de gerenciar projetos evolua, a fim de melhor transcrever os requisitos coletados</p><p>- de preferência de maneira automática - e inserindo numa documentação formal</p><p>pelo modo mais ágil possível.</p><p>Didática no Ensino 52</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>6. IMPLEMENTAÇÃO DE RESULTADOS COM O MPS.BR</p><p>A qualidade de software requer cuidados preventivos e paliativos ao longo</p><p>de todo o projeto de software. Para que essa qualidade seja mantida, existem</p><p>aspectos estruturais que precisam ser mantidos, assim como boas práticas e</p><p>regras de aceitação mínima, sempre no intuito de se ter um padrão de projeto</p><p>aceitável. Desde antes do levantamento de requisitos, todo cuidado é pouco, visto</p><p>que a necessidade do usuário final precisa ser bem atendida, mas o custo para se</p><p>atingir isso precisa sempre ser bem calculado.</p><p>Existem instituições em todo o mundo que visam manter a qualidade</p><p>dos processos e serviços de software. A nível mundial temos alguns padrões</p><p>como o ITIL (Information Technology Infrastructure Library ou Biblioteca de</p><p>Infraestrutura em Tecnologia da Informação) como um conjunto de práticas</p><p>que visa nortear o gerenciamento dos serviços de TI. Temos também o PMBOK</p><p>(Project Management Body of Knowledge ou Conjunto de Conhecimentos</p><p>em Gerenciamento de Projetos) é uma espécie de padronização mais focada a</p><p>gestão de processos e de projetos de software, sendo bastante empregado por</p><p>empresas e na formação de gerentes de projetos.</p><p>Mas, em se tratando de qualidade, outras instituições também aparecem.</p><p>Temos a IEEE (Institute of Electrical and Electronic Engineers ou Instituto de</p><p>Engenharia Elétrica e Eletrônica) que possui seus padrões internacionais, auxiliando</p><p>nas normas em se tratando das várias engenharias, principalmente a elétrica/</p><p>eletrônica e de software. A ISO (International Organization for Standardization</p><p>ou Organização Internacional para Padronização) é, talvez, dessas instituições, a</p><p>mais famosa. Ela é responsável por aprovar padrões em diversas áreas técnicas.</p><p>Suas normais mais famosas são a ISO 9000/9001, ISO 14000. O padrão ISO/IEC</p><p>9126 é o que dita sobre qualidade em produto de software - IEC é a International</p><p>Electrotechnical Commission ou Comissão Eletrotécnica Internacional.</p><p>6.1 PADRÃO DE QUALIDADE DE SOFTWARE NO BRASIL</p><p>A nível de Brasil, temos o MPS.BR (Melhoria de Processos do Software</p><p>Brasileiro). Ele foi criado em 2003 pela Softex (Associação para Promoção da</p><p>Excelência do Software Brasileiro) com o objetivo de melhorar a qualidade</p><p>do software produzido no país, tendo como ponto de partida algumas ações</p><p>norteadoras (SILVA, 2013).</p><p>Didática no Ensino 53</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>O desenvolvimento do MPS-BR se deu em base nas normas internacionais</p><p>como as já citadas ISO/IEC 9126, mas também as ISO/IEC 12207 e ISO/IEC</p><p>15504, além da CMMI (Capability Maturity Model Integration), sendo adaptado</p><p>a realidade do mercado de software brasileiro. Em muitos aspectos, o modelo</p><p>de capacidade e maturidade integrado proposto no CMMI formam a base do</p><p>modelo brasileiro de acompanhamento da qualidade de software. Aspectos</p><p>como a gestão de projetos, acompanhamento dos riscos e da qualidade, além da</p><p>fase de desenvolvimento em si dos produtos de software.</p><p>De acordo com SILVA (2013) e com a documentação oficial do MPS.BR,</p><p>existem sete níveis de maturidade de software que servem como forma de analisar</p><p>em que patamar uma empresa ou equipe de software está a fim de atender a</p><p>qualidade básica de software. Esses níveis são:</p><p>• A - Em Otimização</p><p>• B - Gerenciado Quantitativamente</p><p>• C - Definido</p><p>• D - Largamente Definido</p><p>• E - Parcialmente Definido</p><p>• F - Gerenciado</p><p>• G - Parcialmente Gerenciado</p><p>Os níveis são alcançados de acordo com o grau de implantação do modelo</p><p>em seu projeto de software, sendo escalado de baixo para cima. Ou seja, o nível</p><p>G é o primeiro a ser implementado e o nível A é o nível máximo que a empresa</p><p>poderá atingir. E, para se alcançar o patamar máximo, vários processos precisam</p><p>ser realizados ou implantados a fim de termos uma avaliação, feita por instituição</p><p>externa e imparcial. O Site oficial da Softex (online, 2020) descreve quatro passos</p><p>para a avaliação MPS.BR para chegar a comprovação dos níveis de maturidade da</p><p>organização. Esses passos são:</p><p>Passo 1 - Implementação do modelo MPS.BR: Primeiramente, a</p><p>organização precisa implementar os processos em uma ou mais de suas unidades</p><p>organizacionais no modelo e nível MPS adequados ao seu negócio: Software,</p><p>Serviço, Gestão Pessoas ou uma combinação destes.</p><p>Passo 2 - Contratação da instituição avaliadora: A empresa precisa</p><p>selecionar e contratar uma Instituição Avaliadora (IA-MPS) habilitada pela Softex.</p><p>O site oficial possui uma lista de Instituições Avaliadoras. Existem restrições a serem</p><p>consideradas na contratação de uma avaliação MPS a fim de se ter idoneidade e</p><p>transparência no processo.</p><p>Didática no Ensino 54</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Passo 3 - Avaliação oficial: A avaliação oficial acontece em um período que</p><p>pode levar entre três e seis meses. Ela é realizada em etapas que abrangem a</p><p>avaliação inicial, elaboração, avaliação final e auditoria.</p><p>Passo 4 - Publicação do resultado oficial: A avaliação MPS.BR é considerada</p><p>validada após sua publicação no portal da Softex.</p><p>Ao longo desse processo, profissionais responsáveis deverão assumir o papel</p><p>de representantes da implantação do MPS na organização postulante. Segundo</p><p>a própria Softex (online) “as avaliações MPS.BR devem ter a participação de um</p><p>ou mais representantes da empresa na equipe de avaliação”. Este passo precisa</p><p>ser realizado antes do início do processo de avaliação e pode ser feito, a qualquer</p><p>momento, também pelo portal (Softex, online, 2020). No total são três diferentes</p><p>modelos de processo do MPS: MPS para Software, para Serviços e para Gestão</p><p>de Pessoas (RH). Cada um deles possui seu conjunto de regras e processos a</p><p>serem implantadas a fim de se obter uma avaliação que homologue como bem-</p><p>sucedido tal modelo.</p><p>6.2 PROCESSOS DE PROJETO</p><p>O guia geral do MPS para software - em sua versão 2020 - apresenta</p><p>nove seções que norteiam os processos a serem implantados e gerenciados ao</p><p>longo de um projeto de software. A seção 9 trabalha com a descrição detalhada</p><p>dos processos, tendo a subdivisão de Processos de Projeto (9.1) e Processos</p><p>Organizacionais (9.2).</p><p>6.2.1 Gerência de Projeto</p><p>No guia Geral MPS de software, o tópico 9.1 apresenta o descritivo relativo aos</p><p>processos de Gerência de Projetos (GPR). Segundo o próprio guia, seu propósito</p><p>é “estabelecer e manter atualizados planos que definam as atividades, recursos,</p><p>riscos, prazos e responsabilidades do projeto.” (SOFTEX, online). Esse processo</p><p>também visa demonstrar como está o andamento do projeto a fim de permitir</p><p>que correções sejam feitas caso haja algum tipo de desvio que possa atrapalhar o</p><p>desempenho do projeto de maneira significativa.</p><p>6.2.2 Gerência de Configuração e Requisitos</p><p>Na sequência, temos o processo GCO (Gerência de Configuração) e a GRE</p><p>(Gerência de Requisitos), cujo propósito é “definir, gerenciar e manter atualizado</p><p>os requisitos das partes interessadas e do produto, garantindo que inconsistências</p><p>Didática no Ensino 55</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>entre os requisitos, os planos e</p><p>os produtos de trabalho sejam identificadas”</p><p>(SOFTEX, online). Temos também a DRE (Desenvolvimento de Requisitos),</p><p>que também trabalha dentro do contexto da REQ (Engenharia de Requisitos),</p><p>no intuito de verificar a criação e desenvolvimento dos requisitos de software,</p><p>englobando seu processo de levantamento, definição e documentação.</p><p>6.2.3 Gerência de Risco</p><p>Os aspectos relativos a riscos de desenvolvimento estão na guia de</p><p>Implementação, na parte 5, que trata sobre a fundamentação para implementação</p><p>do nível C do MPS. O tópico número sete deste guia detalha os aspectos</p><p>da gerência de riscos (GRI), seus propósitos, fundamentação teórica e os</p><p>resultados esperados nos processos envolvidos. O propósito da GRI, segundo</p><p>o guia de implantação do MPS, “é identificar, analisar, tratar, monitorar e reduzir</p><p>continuamente os riscos em nível organizacional e de projeto” (Softex, online). Ela</p><p>varia desde o nível G (mais baixo do processo) até o nível C, mais acima, sendo</p><p>acompanhado também pela GPR (Gerência de Projetos).</p><p>Didática no Ensino 56</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>CONSIDERAÇÕES FINAIS</p><p>Ao término deste módulo, podemos concluir que os requisitos são parte</p><p>fundamental na estrutura dos softwares. Uma vez que adotamos os requisitos</p><p>como as reais necessidades das partes envolvidas no projeto de software, é</p><p>primordial que tenhamos um levantamento e elicitação dos requisitos de maneira</p><p>prioritária. A engenharia de software, da qual a engenharia de requisitos faz</p><p>parte como uma espécie de desdobramento, precisa estar em sintonia entre as</p><p>necessidades dos stakeholders e a aplicação dos conhecimentos de negócio</p><p>junto a equipe de desenvolvimento. A partir disso, podemos perceber a real</p><p>necessidade de elencar requisitos com qualidade para que os riscos do projeto</p><p>sejam consideravelmente baixos.</p><p>Nesse aspecto, é elementar que se utilizem diferentes metodologias e</p><p>formas de se desenvolver softwares. Sobre isso, a engenharia de requisitos é</p><p>de fundamental importância pois existe justamente como um elo de ligação</p><p>entre os usuários finais - responsáveis por requisitar o software - e a equipe de</p><p>desenvolvimento, passando por outros perfis profissionais de dentro de uma</p><p>organização, que podem ser especialistas na regra de negócio ou especialistas</p><p>de TI (Tecnologia da Informação).</p><p>Logo, o uso de técnicas e ferramentas que aperfeiçoem os processos iniciais</p><p>de análise até os métodos que podem acelerar o desenvolvimento de softwares,</p><p>precisam ser adotados, caso queiramos um êxito completo. Tais ferramentas, por</p><p>diferentes motivos, têm evoluído muito, graças à internet e as novas formas de</p><p>comunicação e tecnologias da informação como um todo. O encurtamento da</p><p>distância entre as pessoas envolvidas também causa um impacto positivo no</p><p>levantamento de requisitos e, em consequência, no desenvolvimento de software</p><p>pautado na qualidade do produto final.</p><p>De modo geral, vimos que os requisitos passam por diferentes fases de um</p><p>projeto, já que eles estarão sendo criados e/ou alterados desde as fases iniciais</p><p>(concepção e elaboração), passando pela fase de construção ou desenvolvimento,</p><p>indo até a última etapa, já que podem sofrer alterações ou até mesmo novas</p><p>inclusões, de acordo com o andamento do projeto. Usando ferramentas</p><p>apropriadas e com apoio visual, podemos permitir que o usuário final faça parte</p><p>de todo o processo, desde a definição dos requisitos iniciais, seu refinamento e a</p><p>colocação de tais requisitos como funcionalidades práticas do sistema, como um</p><p>RF (Requisito Funcional) ou um RNF (Requisito Não Funcional).</p><p>Didática no Ensino 57</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Por fim, deixamos claro que os papéis precisam ser respeitados. O usuário</p><p>final e o time de stakeholders são tão importantes como os analistas de requisitos,</p><p>analistas de sistemas e engenheiros de software. Todos formarão um só time</p><p>que, coeso, levarão o projeto ao sucesso, com a entrega de um produto final de</p><p>qualidade, sendo mensurado, analisado e validado até que se tenha o software</p><p>totalmente pronto e em uso (e até mesmo depois disso).</p><p>Didática no Ensino 58</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>REFERÊNCIAS BIBLIOGRÁFICAS</p><p>BEYER, H., HOLTZBLATT, K.: Apprenticing with the customer.</p><p>Communications of the ACM, vol.38, no. 5, pp.45-52. ACM Press, New York</p><p>(2015).</p><p>BURATTI, Robson. Desenvolvimento De Software Web Para Gestão De</p><p>Competências Em Projetos De Software. Disponível em: http://repositorio.</p><p>roca.utfpr.edu.br/jspui/bitstream/1/6916/1/FB_DESIDM_I_2014_04.pdf. Acesso</p><p>em: 14 dez. 2020.</p><p>DAVEY, Bill, et al. Requirements Elicitation: What’s Missing? Disponível em:</p><p>Informing Science and Information Technology. Vol. 5, 2008. http://proceedings.</p><p>informingscience.org/InSITE2008/IISITv5p543-551Davey466.pdf</p><p>Elead ALM. Helix RM - Requirements Management. Disponível em: . Acesso em 24 dez. 2020.</p><p>IEEE. EEE/ISO/IEC 12207-2017 - ISO/IEC/IEEE International Standard -</p><p>Systems and software engineering -- Software life cycle processes. Disponível</p><p>em: https://standards.ieee.org/standard/12207-2017.html. Acesso em: 08 dez.</p><p>2020.</p><p>_____. IEEE Standard for Software Project Management Plans. Disponível</p><p>em: http://cs.bilkent.edu.tr/~cagatay/cs413/1058.1-1987_00025325.pdf. Acesso</p><p>em 20 dez. 2020.</p><p>IIBA, International Institute of Business Analysis. BABOK - Um guia para o</p><p>Corpo de Conhecimento de Análise de Negócios. 3ª edição. São Paulo, 2015.</p><p>KRUCHTEN, Philippe. Introdução ao RUP – Rational Unified Process. 2ª</p><p>Edição, Rio de Janeiro: Editora Ciência Moderna, 2003.</p><p>MACEDO, Mateus Henrique Basso; SALGADO, Eduardo Gomes.</p><p>Gerenciamento de Risco Aplicado ao Desenvolvimento de Software. Revista</p><p>Sistema e Gestão, UFF. Disponível em: https://doi.org/10.7177/sg.2015.V10.</p><p>http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/6916/1/FB_DESIDM_I_2014_04.pdf</p><p>http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/6916/1/FB_DESIDM_I_2014_04.pdf</p><p>http://proceedings.informingscience.org/InSITE2008/IISITv5p543-551Davey466.pdf</p><p>http://proceedings.informingscience.org/InSITE2008/IISITv5p543-551Davey466.pdf</p><p>http://cs.bilkent.edu.tr/~cagatay/cs413/1058.1-1987_00025325.pdf</p><p>https://doi.org/10.7177/sg.2015.V10.N1.A13</p><p>Didática no Ensino 59</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>N1.A13. Acesso em 22 dez. 2020.</p><p>MPS.BR. Guia de Implementação – Parte 5: Fundamentação para</p><p>Implementação do Nível C do MR-MPS-SW:2012. Disponível em: . Acesso em: 22 dez. 2020.</p><p>PMI. Who are Project Managers? Disponível em: https://www.pmi.org/</p><p>about/learn-about-pmi/who-are-project-managers. Acesso em 14 dez. 2020.</p><p>PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7ª</p><p>ed. São Paulo: Bookman, 2011.</p><p>RASHID, A., WIESENBERGER, J., MEDER, D., BAUMANN, J.: Bringing</p><p>Developers and Users closer together: The OpenProposal story. Multikonferenz</p><p>Wirtschaftsinformatik, 2008.</p><p>SCHNEIDER, K., MEYER, S., PETERS, M., SCHLIEPHACKE, F., MORSCHBACK,</p><p>J., AGUIRRE, L.: Feedback in Context: Supporting the Evolution of IT-Ecosystems.</p><p>In: Ali, M., Vierimaa, M., Oivo, M. (eds.) Product-Focused Software Process</p><p>Improvement. LNCS, vol. 6156. Springer 2014.</p><p>SEYFF, N., GRAF, F., MAIDEN, N.: Using Mobile RE Tools to Give End-</p><p>Users their Own Voice. In: 18th IEEE International Requirements Engineering</p><p>Conference, pp. 37-46, IEEE Press, New York (2010).</p><p>SILVA, Daiany. O que é o MPS-BR? Disponível em: https://blogdaqualidade.</p><p>c o m . b r / o - q u e - e - o - m p s - b r / # : ~ : te x t = O % 2 0 M P S % 2 D B R % 2 0 o u % 2 0</p><p>Melhoria,de%20software%20nas%20empresas%20brasileiras. Acesso em 28</p><p>dez. 2020.</p><p>SOFTEX. MPS.br. Disponível em: https://softex.br/mpsbr/. Acesso em: 28</p><p>dez. 2020.</p><p>____. Guia Geral MPS de Software. Disponível em: http://www.lucianoaguiar.</p><p>com.br/wp-content/uploads/dlm_uploads/2020/02/MPS.BR_Guia_Geral_</p><p>Software_2020.pdf. Acesso em: 28 dez.</p><p>2020.</p><p>SOMMERVILLE, I. Engenharia de software. 9ª edição. São Paulo: Addison</p><p>Wesley, 2011.</p><p>https://doi.org/10.7177/sg.2015.V10.N1.A13</p><p>https://www.pmi.org/about/learn-about-pmi/who-are-project-managers</p><p>https://www.pmi.org/about/learn-about-pmi/who-are-project-managers</p><p>https://blogdaqualidade.com.br/o-que-e-o-mps-br/#:~:text=O%20MPS%2DBR%20ou%20Melhoria,de%20software%20nas%20empresas%20brasileiras</p><p>https://blogdaqualidade.com.br/o-que-e-o-mps-br/#:~:text=O%20MPS%2DBR%20ou%20Melhoria,de%20software%20nas%20empresas%20brasileiras</p><p>https://blogdaqualidade.com.br/o-que-e-o-mps-br/#:~:text=O%20MPS%2DBR%20ou%20Melhoria,de%20software%20nas%20empresas%20brasileiras</p><p>https://softex.br/mpsbr/</p><p>http://www.lucianoaguiar.com.br/wp-content/uploads/dlm_uploads/2020/02/MPS.BR_Guia_Geral_Software_2020.pdf</p><p>http://www.lucianoaguiar.com.br/wp-content/uploads/dlm_uploads/2020/02/MPS.BR_Guia_Geral_Software_2020.pdf</p><p>http://www.lucianoaguiar.com.br/wp-content/uploads/dlm_uploads/2020/02/MPS.BR_Guia_Geral_Software_2020.pdf</p><p>Didática no Ensino 60</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Desenho Instrucional: Veronica Ribeiro</p><p>Supervisão Pedagógica: Laryssa Campos</p><p>Revisão pedagógica: Camila Martins / Cássio Lima</p><p>Design editorial/gráfico: Darlan Conrado</p><p>2021</p><p>Sumário</p><p>Introdução</p><p>INTRODUÇÃO</p><p>1. Fases de Concepção e Elaboração</p><p>1.1 Fase de Concepção</p><p>1.2 Fase de Elaboração</p><p>1.3 Levantamento de Requisitos</p><p>1.4 Preparação para Elicitação de Requisitos</p><p>2. Disciplinas e Técnicas de Modelagem de Requisitos</p><p>2.1 Confirmando a Elicitação</p><p>2.2 Modelagem de Requisitos</p><p>2.3 Fluxo de Processo de Modelagem</p><p>3. Estimativa de Custos e Prazos na Engenharia de Requisitos</p><p>3.1 Estimativa de Prazos e Cronograma</p><p>3.2 Estimativa de Custos e Orçamento</p><p>4. Análise e Gerenciamento de Riscos</p><p>4.1 Aplicação do gerenciamento de riscos</p><p>4.2 Padrão de Projeto de Software</p><p>4.3 Gerenciamento de conflitos</p><p>4.4 Maiores Riscos no Desenvolvimento de Software</p><p>5. Ferramentas de Análise e Gerência de Requisitos</p><p>5.1 Ferramentas Visuais</p><p>5.2 Comparativo de Ferramentas</p><p>6. Implementação de Resultados com o MPS.BR</p><p>6.1 Padrão de qualidade de software no Brasil</p><p>6.2 Processos de Projeto</p><p>Considerações Finais</p><p>Referências Bibliográficas</p><p>Sumário 51:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 60173:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 60174:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 60175:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 60176:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 60179:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 60188:</p><p>Página 1:</p><p>Página 2:</p><p>Página 3:</p><p>Página 4:</p><p>Página 5:</p><p>Página 6:</p><p>Página 7:</p><p>Página 8:</p><p>Página 9:</p><p>Página 10:</p><p>Página 11:</p><p>Página 12:</p><p>Página 13:</p><p>Página 14:</p><p>Página 15:</p><p>Página 16:</p><p>Página 17:</p><p>Página 18:</p><p>Página 19:</p><p>Página 20:</p><p>Página 21:</p><p>Página 22:</p><p>Página 23:</p><p>Página 24:</p><p>Página 25:</p><p>Página 26:</p><p>Página 27:</p><p>Página 28:</p><p>Página 29:</p><p>Página 30:</p><p>Página 31:</p><p>Página 32:</p><p>Página 33:</p><p>Página 34:</p><p>Página 35:</p><p>Página 36:</p><p>Página 37:</p><p>Página 38:</p><p>Página 39:</p><p>Página 40:</p><p>Página 41:</p><p>Página 42:</p><p>Página 43:</p><p>Página 44:</p><p>Página 45:</p><p>Página 46:</p><p>Página 47:</p><p>Página 48:</p><p>Página 49:</p><p>Página 50:</p><p>Página 51:</p><p>Página 52:</p><p>Página 53:</p><p>Página 54:</p><p>Página 55:</p><p>Página 56:</p><p>Página 57:</p><p>Página 58:</p><p>Página 59:</p><p>Página 60:</p><p>Página 61:</p><p>Botão 628:</p><p>Botão 629:</p><p>Botão 630:</p><p>de Elaboração. Dependendo da metodologia empregada no projeto, essa fase</p><p>concentra tanto a documentação inicial, juntamente com a definição e refinamento</p><p>dos requisitos, assim como a modelagem inicial e as tarefas de implementação,</p><p>que é onde os programadores colocam em prática os conhecimentos teóricos</p><p>obtidos no design do software, através do uso de linguagens de programação,</p><p>de consultas a banco de dados (como SQL) e as de estilo (CSS) e marcação de</p><p>hipertexto (HTML), para sistemas web por exemplo.</p><p>1.1 FASE DE CONCEPÇÃO</p><p>A gestão de um projeto de software tem sido facilitada ao longo do tempo.</p><p>Desde o surgimento dos softwares, por mais complexos que eles tenham se</p><p>tornado, podemos dizer que as ferramentas e técnicas presentes nesse processo</p><p>tem ajudado os profissionais a tomarem as melhores decisões possíveis em se</p><p>tratando de manter ou gerenciar seus projetos.</p><p>Mas, mesmo estando em um estado mais evoluído, por que gerenciar projetos</p><p>ainda pode ser tão difícil? No dia a dia das empresas de desenvolvimento, ainda</p><p>temos visto muitos projetos falharem, e isso é visto com frequência especialmente</p><p>no desenvolvimento de software. Algumas destas dificuldades decorrem da</p><p>Didática no Ensino 6</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>natureza inerente do produto que está sendo criado, já outras estão relacionadas</p><p>com a gestão ou o perfil da equipe a ser gerido. Entre o problemas comuns</p><p>relacionados a software podemos destacar alguns, como:</p><p>• Intangibilidade: O software, ao contrário do hardware, é intangível. Como resulta-</p><p>do, o software pode ser tornar mais difícil de gerenciar porque não contém marcos</p><p>visíveis para medir progresso e qualidade.</p><p>• Complexidade: A grande complexidade de um software torna difícil para as pessoas</p><p>compreendê-lo, criando não apenas problemas técnicos, mas também de gestão.</p><p>• Volatilidade dos requisitos: Os requisitos de software estão sob constante pressão</p><p>por mudança. Isso se dá porque o software pode ser alterado mais facilmente do</p><p>que hardware, levando o cliente a requerer mais da entrega final dada a tal flexibili-</p><p>dade.</p><p>Nisso, o peso sobre o gerenciamento de projetos acaba recaindo sobre</p><p>algumas características bastante visíveis mas, por vezes, difíceis de serem</p><p>combatidas. Entre as dificuldades relacionadas à gestão, as seguintes são as mais</p><p>frequentemente citadas por profissionais e em literaturas sobre gerenciamento</p><p>de projetos:</p><p>• Metas e especificações mal definidas;</p><p>• Falta de plano de projeto;</p><p>• Prazos e orçamentos fora da realidade;</p><p>Embora alguns projetos falhem por razões técnicas, a maioria das falhas de</p><p>projeto são causadas por pessoas que ignoram os princípios da boa gestão de</p><p>projetos. Por isso, antes mesmo da fase de concepção ou iniciação ser começada,</p><p>é importante saber os princípios da gestão de projetos e como eles podem ser</p><p>aplicados ao desenvolvimento de softwares.</p><p>Com isso em mente, podemos dizer que o objetivo fundamental da fase</p><p>de concepção é determinar a viabilidade do projeto. Nessa fase, os requisitos</p><p>precisam ser examinados no contexto do ambiente de negócio, em um processo</p><p>onde alternativas são definidas e avaliadas e estimativas de custo, cronograma</p><p>e risco são feitas. Essa fase é concluída na decisão de prosseguir ou não com</p><p>o projeto. Muitos projetos não avançam além deste estágio pois se mostram</p><p>tecnicamente impraticáveis por serem muito arriscados ou por seus custos</p><p>projetados superarem seus benefícios ao final do projeto.</p><p>Todos esses aspectos são fundamentais, uma vez que o custo ou as condições</p><p>de entrega (que incluem prazo e escopo do projeto) podem ser extrapolados</p><p>ou entregues de maneira a não atender aos anseios dos stakeholders (partes</p><p>Didática no Ensino 7</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>envolvidas e interessadas no produto final). Por isso, o levantamento de requisitos</p><p>se torna etapa importante no processo, uma vez que a gestão de um projeto só</p><p>conseguirá obter sucesso se todas as disciplinas e fases consigam seguir seu</p><p>curso natural, levando em consideração possíveis problemas durante o processo,</p><p>que podem ser corrigidos durante seu ciclo de vida, desde que se tenha um apoio</p><p>de técnicas e metodologias apropriadas desde o início do projeto.</p><p>Tendo tudo isso como base, veremos como as etapas precisam ser respeitadas</p><p>e cada fase poderá ter suas disciplinas atendidas conforme o ciclo mantém</p><p>seu curso. Como forma de aprofundar mais nas etapas iniciais do processo de</p><p>desenvolvimento de software, veremos um pouco mais sobre a fase de elaboração</p><p>a seguir.</p><p>1.2 FASE DE ELABORAÇÃO</p><p>Na fase de elaboração (por vezes chamada de fase de planejamento), as</p><p>estimativas de desempenho, custo e cronograma são refinadas a um ponto em</p><p>que detalha os planos para a execução do projeto e o que pode (e/ou deve) ser</p><p>feito. Nesta etapa, orçamentos e cronogramas são desenvolvidos, a equipe do</p><p>projeto é formada e um sistema de gerenciamento de projeto é estabelecido para</p><p>orientar a gestão do projeto. Dentro das metodologias ágeis, esta etapa pode ser</p><p>dividida em ciclos, permitindo que o projeto se desenvolva de maneira cíclica e</p><p>iterativa.</p><p>Particularmente nessa etapa, a interação com o cliente é bastante importante</p><p>para o sucesso do projeto de software. À medida que um número crescente de</p><p>novos projetos se torna mais estratégico e envolve reengenharia de processos</p><p>de negócios, a gestão de mudanças organizacionais se torna parte integrante</p><p>do gerenciamento de projetos. Além da abordagem tradicional de gerência de</p><p>projetos que é com foco no controle de custos, cronograma e desempenho</p><p>técnico, esta fase se destaca na importância de dois fatores na gestão desses</p><p>processos de software: visibilidade e compromisso.</p><p>A base para um projeto de desenvolvimento de software bem-sucedido é</p><p>um forte planejamento inicial. Muitas falhas de projeto podem ser atribuídas a um</p><p>planejamento inicial inadequado. Começar a construir uma casa pensando no</p><p>teto é, sem dúvidas, uma falha arquitetural. Por isso, muitas vezes será necessário</p><p>que mesmo estando na fase de elaboração, a volta a fase inicial de concepção seja</p><p>necessária para que prazos e orçamentos irreais, metas e objetivos mal definidos</p><p>e falta de plano de projeto sejam revistas e não sejam a causa para o fracasso do</p><p>projeto.</p><p>Didática no Ensino 8</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Levando em consideração as fases de Concepção e Elaboração, é nesse</p><p>momento em que o ciclo de planejamento começa com o estabelecimento de</p><p>metas e objetivos e onde se determina os requisitos para o sistema. Os requisitos</p><p>oferecem uma melhor visão direcionada para o projeto, ajudando a definir as</p><p>entregas. Uma entrega é um resultado tangível apresentado após a conclusão de</p><p>uma dada tarefa.</p><p>Assim, podemos dizer que cada entrega realiza uma tarefa para um ou mais</p><p>requisitos de sistema. A entrega de uma dessas etapas pode ser via formulários,</p><p>um documento, um relatório ou até mesmo um manual ou hardware instalado. É</p><p>importante que durante a fase de elaboração as definições estejam claras para que</p><p>não ocorram equívocos nas entregas essenciais. Para que erros sejam evitados,</p><p>é importante que os requisitos sejam definidos o mais cedo possível. Em muitos</p><p>casos, pode ser necessário construir e testar um protótipo para desenvolver uma</p><p>boa compreensão do sistema quanto às suas necessidades e requisitos. Um</p><p>protótipo é particularmente útil em situações onde o cliente não tem certeza</p><p>sobre os requisitos que ele mesmo levantou, em casos de um sistema bastante</p><p>complexo.</p><p>O quadro a seguir descreve as principais atividades que as fases de concepção</p><p>e elaboração estão envolvidas e as ações de gestão adequadas para cada uma.</p><p>Concepção Elaboração</p><p>Identificar necessidades Preparar planos de trabalho</p><p>Estabelecer metas Definir orçamento</p><p>Determinar a viabilidade Desenvolver cronograma</p><p>Preparar proposta Definir equipe do projeto</p><p>Estimar tempo e recursos Construir e testar protótipos</p><p>Identificar as pessoas-chave Obter a aprovação</p><p>para a próxima</p><p>fase</p><p>Quadro 1 - Características e tarefas das fases de Concepção e Elaboração de Software</p><p>1.3 LEVANTAMENTO DE REQUISITOS</p><p>Como definido anteriormente, requisitos são a tradução das necessidades ou</p><p>problemas levantados junto aos usuários que, em uma documentação, formam as</p><p>tarefas e objetivos a serem desenvolvidos no projeto de software. Sem uma boa</p><p>definição de requisitos, provavelmente teremos um retrabalho enorme ou não</p><p>Didática no Ensino 9</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>atingiremos o objetivo proposto de atender a necessidade do usuário.</p><p>Sommerville (2011) classifica os requisitos de software como requisitos de</p><p>sistema e requisitos de usuário. Os requisitos de sistema seriam os passos que</p><p>precisam ser dados no sistema para que ele apresente o resultado desejado. Já o</p><p>requisito de usuário seria a definição simples de um problema ou necessidade de</p><p>um cliente.</p><p>Na prática, esses requisitos são geralmente definidos como requisitos</p><p>funcionais (RF) ou requisitos não funcionais (RNF). Os requisitos funcionais</p><p>representam os requisitos de usuário, já os não funcionais os de sistema, as</p><p>necessidades que um sistema tem para que funcione de maneira correta.</p><p>A definição dos requisitos apresenta uma fundamental importância para o</p><p>desenvolvimento de software de maneira espontânea e natural, visto que sua</p><p>definição de maneira desejável provavelmente diminuirá muito o número de</p><p>futuros problemas e retrabalhos, pois fundamentará o entendimento de maneira</p><p>clara enquanto o software for sendo desenvolvido. Tanto a documentação de</p><p>requisitos funcionais quanto de não funcionais são igualmente instrumentos</p><p>à sua própria maneira. Ambos os tipos de requisitos coexistem como forma de</p><p>complementarem um ao outro, ou seja, um é diretamente afetado pelo outro.</p><p>Mas, mesmo assim, nem todos os requisitos não funcionais (RNF)</p><p>correspondem diretamente a um requisito funcional (RF). A instalação e</p><p>configuração do servidor, por exemplo, é um requisito não funcional que tem</p><p>impacto na estabilidade de todo um sistema, mas sem uma relação direta de 1</p><p>para 1 com qualquer requisito funcional singular. Isso acontece pelo fato de um</p><p>RNF poder estar ligado ou atender a mais de um RF, como no exemplo citado da</p><p>configuração de um servidor.</p><p>Para termos os requisitos bem definidos, algumas etapas precisam ser</p><p>vistas com cautela, como a de levantamento de requisitos. A importância do</p><p>levantamento de requisitos é frequentemente subestimada em vários níveis.</p><p>Quando os orçamentos são estreitos, os prazos são apertados e o escopo é cada</p><p>vez menor, a documentação dos requisitos tende a ser a primeira entrega a ser</p><p>concluída e a última a ser considerada. Isso deveria surpreender, mas acaba</p><p>se tornando uma praxe de mercado - bastante danosa, diga-se de passagem</p><p>- especialmente quando você considera que ignorar um processo completo</p><p>de coleta de requisitos significa sacrificar um ponto de referência sólido para</p><p>verificações e balanços em toda a produção de um sistema, colocando em risco</p><p>as expectativas do cliente, da equipe e dos usuários finais, deixando muito espaço</p><p>Didática no Ensino 10</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>para erros e ambiguidades futuras.</p><p>À primeira vista, o processo de levantamento e a documentação de requisitos</p><p>podem parecer intimidantes, mas não precisa ser. Veremos a seguir algumas</p><p>razões em dar importância aos requisitos e ao processo de gerenciamento e coleta</p><p>de requisitos, sugerindo algumas técnicas a serem consideradas e abordagens</p><p>a fim de descrever a documentação dos requisitos. Veremos que, embora a</p><p>documentação de requisitos possa ser complicada, o processo não precisa ser. O</p><p>objetivo de uma documentação pautada em regras preestabelecidas é fornecer</p><p>aos envolvidos no processo uma abordagem simplificada e intuitiva para definição</p><p>de requisitos que resultem em uma documentação que represente a realidade</p><p>do que se está desenvolvendo.</p><p>Segundo PRESSMAN (2011), o gerenciamento de requisitos é importante</p><p>por duas razões principais:</p><p>• A documentação dos requisitos serve como um ponto de referência para documen-</p><p>tar a evolução de um projeto, suas partes móveis e sua implementação;</p><p>• A documentação de requisitos serve como um plano para o cliente entender melhor</p><p>o que esperar do projeto (o quê, onde, quando e por que do projeto).</p><p>Além de definir o que eles podem esperar, parte do planejamento de</p><p>gerenciamento de requisitos deve definir o que não se deve esperar. Incluir uma</p><p>seção de suposições e/ou exclusões por parte do cliente é uma abordagem</p><p>inteligente para eliminar o risco da temida “imaginação do cliente”. A qualidade</p><p>do gerenciamento de requisitos está diretamente relacionada com a habilidade</p><p>de gerenciar um projeto, a busca de reduzir áreas nebulosas sobre as expectativas</p><p>do cliente.</p><p>Na grande maioria das vezes, um cliente será receptivo ao aumento de</p><p>escopo desde que isso não aumente também o orçamento demandado. Muitas</p><p>vezes será preciso “educar” o cliente de maneira a deixar bem claro sobre por que</p><p>um recurso será abordado (ou não abordado) e, em seguida, documentar a lógica</p><p>por trás dessa abordagem dentro dos requisitos. Com isso feito, a probabilidade</p><p>de aceitação por parte do cliente será maior por ele fazer parte dessa decisão.</p><p>Nesse sentido, os stakeholders são mais propensos a fornecer sua aprovação e,</p><p>mais adiante, quando estiverem na fase de teste de aceitação do usuário, teremos</p><p>vantagens logo de início para que eles entendam o porquê por trás da solução</p><p>desenvolvida pela equipe de TI.</p><p>Didática no Ensino 11</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Uma descoberta completa dos requisitos de negócios quase nunca está</p><p>disponível de maneira tão clara para o analista. Na verdade, raramente os requisitos</p><p>podem ser pesquisados rapidamente como se reunissemos informações para</p><p>um trabalho de conclusão ou para uma prova avaliativa. Muitos dos requisitos</p><p>comerciais ou técnicos acabam por não serem documentados, permanecendo</p><p>apenas nas mentes das partes interessadas, no feedback que ainda não foi obtido</p><p>dos usuários finais e em um estudo de fluxogramas e pesquisas que ainda não</p><p>foram criados. Por isso, os requisitos devem ser eliciados ou elaborados, e a</p><p>metodologia para fazer isso deve ser lógica e apropriada a cada caso.</p><p>A importância da elicitação não pode ser exagerada, pois ela é a base de</p><p>qualquer projeto de requisitos. Conforme Davey et al (2009), erros cometidos</p><p>na elicitação têm sido mostrados muitas vezes como as principais causas de falha</p><p>ou abandono de sistemas e isso tem um custo muito grande, seja na perda total</p><p>ou na despesa de consertar os erros. O estudo adequado e a preparação para a</p><p>elicitação podem ajudar muito na prevenção desses tipos de erros.</p><p>1.4 PREPARAÇÃO PARA ELICITAÇÃO DE REQUISITOS</p><p>O objetivo do levantamento e elicitação de requisitos é identificar</p><p>completamente as necessidades, riscos e suposições de negócios associados a</p><p>qualquer projeto. Em projetos de software, a definição do modelo de processos</p><p>é uma etapa importante, que irá impactar toda a cadeia de acontecimentos, do</p><p>início ao fim de todo o ciclo. Modelos de processo de software, com algumas</p><p>exceções, todos evoluíram a partir do modelo clássico em cascata, desenvolvido</p><p>no final dos anos 1960 e início dos anos 1970.</p><p>O uso de um modelo de software processo de desenvolvimento reduz</p><p>a complexidade do processo por dividir um projeto em uma série de etapas</p><p>básicas. O ponto de terminação para cada etapa é claramente definida por um</p><p>conjunto distinto de entregáveis, por exemplo, uma especificação de requisitos</p><p>ou módulos de software codificados e testados. Os modelos cíclicos permitem</p><p>que a cada fase ou etapa concluída uma nova possa ser iniciada, completando o</p><p>ciclo de processos de desenvolvimento.</p><p>A elicitação de requisitos é uma etapa importante dentro do desenvolvimento</p><p>de uma aplicação. Para sua definição, é necessário que seja feita uma preparação</p><p>a fim de absorver os</p><p>requisitos de maneira correta. A primeira etapa na elicitação</p><p>de requisitos é obter uma compreensão abrangente e precisa da regra de negócio</p><p>do projeto. Durante o processo de elicitação, o forte entendimento de um analista</p><p>da necessidade do negócio ajudará na manutenção de tais requisitos contra o</p><p>Didática no Ensino 12</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>aumento de escopo e encarecimento do projeto, bem como selecionar as partes</p><p>interessadas adequadas e as técnicas de elicitação apropriadas.</p><p>A próxima etapa de um analista na elicitação de requisitos é garantir que</p><p>uma quantidade adequada e mista de stakeholders sejam garantidas durante</p><p>o projeto. Pois, como observa o BABOK 2.0 (IIBA, 2015), um bom analista deve</p><p>envolver ativamente as partes interessadas na definição de requisitos. Ainda</p><p>de acordo com o BABOK, as partes interessadas de um projeto podem incluir</p><p>clientes/usuários finais, fornecedores, o gerente de projeto, analista de qualidade,</p><p>reguladores, patrocinadores do projeto, suporte operacional, especialistas no</p><p>assunto de domínio e especialistas no assunto de implementação. Um analista</p><p>deve recrutar a participação das partes interessadas apropriadas com base nas</p><p>necessidades de negócios exclusivas de seu projeto. As técnicas e metodologias</p><p>para elicitação de requisitos serão apresentadas a seguir, na próxima seção deste</p><p>documento.</p><p>Didática no Ensino 13</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>2. DISCIPLINAS E TÉCNICAS DE MODELAGEM DE</p><p>REQUISITOS</p><p>Depois que um analista identificar e recrutar as partes interessadas, a escolha</p><p>do método pelo qual se levantará os requisitos é aconselhável para que se abrevie</p><p>o tempo para conduzir esses métodos envolvendo as partes interessadas com</p><p>a maior antecedência possível para assegurar a participação adequada de suas</p><p>partes. Tendo feito isso, o terreno estará pronto para poder ser colocada em</p><p>prática a elicitação de requisitos, podendo ser utilizadas técnicas próprias para</p><p>tal modalidade. Depois de recrutar as partes interessadas adequadas, um analista</p><p>deve determinar as melhores técnicas para elicitar requisitos. Os métodos de</p><p>elicitação de requisitos comumente usados, conforme identificado pelo BABOK</p><p>(2015), que incluem:</p><p>Brainstorming</p><p>Esse método é utilizado por diferentes áreas. Na engenharia de requisitos,</p><p>um analista deve tentar obter um representante de cada grupo de partes</p><p>interessadas participantes na sessão de brainstorming. Um facilitador deve</p><p>garantir que, embora os participantes se sintam livres para propor novas ideias</p><p>e soluções, permaneçam focados na necessidade de negócios em questão e</p><p>não se envolvam em aumento de escopo, enfeitando demais os requisitos ou se</p><p>distraiam com outras questões de negócios. Todas as ideias devem ser registradas</p><p>para que não sejam perdidas. O método de brainstorming é particularmente útil</p><p>se o seu projeto não tiver uma escolha vencedora clara para uma solução, ou se as</p><p>soluções propostas existentes forem consideradas inadequadas. O processo de</p><p>brainstorming e a análise de acompanhamento resultante ajudarão a garantir que</p><p>a melhor solução possível seja alcançada para qualquer objetivo de negócio.</p><p>Análise de documentos</p><p>A análise de documentos envolve a coleta e revisão de toda a documentação</p><p>existente que seja pertinente ao seu objetivo de negócios ou que possa conter</p><p>dados relacionados a uma solução relevante. De acordo com o BABOK, essa</p><p>documentação pode incluir planos de negócios, estudos de mercado, contratos,</p><p>solicitações de propostas, declarações de trabalho, memorandos, diretrizes</p><p>existentes, procedimentos, manuais de treinamento, literatura de produtos</p><p>concorrentes, análises comparativas de produtos publicadas, relatórios de</p><p>problemas, sugestões de clientes, logs e especificações de sistema existentes,</p><p>entre outros. Em outras palavras, qualquer coisa escrita relacionada ao projeto</p><p>pode ser útil. Este tipo de elicitação é especialmente útil quando o objetivo</p><p>Didática no Ensino 14</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>é atualizar um sistema existente ou quando a compreensão de um sistema</p><p>existente irá aprimorar um novo sistema. No entanto, a análise de documentos</p><p>por si só raramente é suficiente para extrair completamente todos os requisitos</p><p>de qualquer projeto.</p><p>Análise de interface</p><p>Visa analisar cuidadosamente a maneira como um usuário interage com um</p><p>aplicativo ou como um aplicativo interage com outro. De acordo com o BABOK,</p><p>uma análise de interface completa irá descrever o propósito de cada interface</p><p>envolvida e extrair detalhes de alto nível sobre ela, incluindo a descrição de seu</p><p>conteúdo. Esse tipo de elicitação é essencial para soluções de software que quase</p><p>sempre envolvem aplicativos interagindo entre si e/ou usuários interagindo com</p><p>aplicativos. Mas, a análise de interface também pode ser útil para soluções que</p><p>não sejam de software (como definir entregas de terceiros, por exemplo).</p><p>Entrevistas</p><p>Entrevistas individuais estão entre os tipos mais populares de elicitação</p><p>de requisitos, e por um bom motivo: elas dão ao analista a oportunidade de</p><p>discutir em profundidade os pensamentos de uma parte interessada e obter</p><p>sua perspectiva sobre a necessidade do negócio e a viabilidade de soluções</p><p>potenciais. Independentemente de o analista optar por uma entrevista estruturada</p><p>(com perguntas pré definidas) ou não estruturada (com conversas abertas), ele</p><p>deve compreender totalmente a necessidade do negócio para conduzir uma</p><p>entrevista bem-sucedida. É uma boa prática para um analista compartilhar suas</p><p>notas de entrevista com o entrevistado depois para garantir que não houve mal-</p><p>entendidos e para movimentar os pensamentos do entrevistado para quaisquer</p><p>insights adicionais.</p><p>Observação</p><p>A observação é bastante útil ao considerar um projeto que mudará ou</p><p>aprimorará os processos atuais. De acordo com BABOK, dois tipos básicos de</p><p>observação estão disponíveis para um analista: observação passiva (onde o</p><p>analista apenas observa alguém trabalhando, mas não interrompe ou engaja</p><p>o trabalhador de qualquer forma) e a observação ativa (onde um analista faz</p><p>perguntas ao longo do processo para ter certeza de que ela entendeu e até mesmo</p><p>experimentou partes do trabalho).</p><p>Prototipagem</p><p>A prototipagem é especialmente valiosa para as partes interessadas, como</p><p>Didática no Ensino 15</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>os clientes e usuários finais que podem não compreender todos os aspectos</p><p>técnicos dos requisitos, mas se relacionarão melhor com uma representação</p><p>visual do produto final. O processo de prototipagem é normalmente iterativo,</p><p>melhorando à medida que mais informações e avaliações são coletadas das</p><p>partes interessadas. A prototipagem pode ser uma tela interativa (normalmente</p><p>consistindo em HTML para aplicações web), um mock-up (simulação de tela</p><p>que pode ser feita em slides do PowerPoint), um fluxo de navegação (como um</p><p>diagrama do Visio) ou um storyboard. Protótipos simples e descartáveis (como</p><p>esboços a lápis) podem ser feitos nos estágios iniciais da descoberta e protótipos</p><p>mais detalhados e interativos podem ser feitos assim que os requisitos de</p><p>negócios forem identificados. No último estágio de protótipo, mais detalhado, os</p><p>recursos do protótipo devem atender às necessidades de negócios previamente</p><p>identificadas, conforme descrito nos requisitos.</p><p>Workshops de requisitos</p><p>O Workshop envolve a reunião de stakeholders previamente identificadas</p><p>em um ambiente estruturado por um período de tempo definido, a fim de</p><p>eliciar, refinar ou editar requisitos. Para ter sucesso, os workshops de requisitos</p><p>devem incluir um gravador (ou alguém que registre em uma ata) para registrar</p><p>a entrada dos participantes e um facilitador para direcionar a discussão. Como</p><p>os participantes também podem fazer um brainstorm juntos e ouvir a opinião</p><p>uns dos outros, eles podem fornecer feedback imediato e refinamentos para</p><p>as necessidades de negócios identificadas, o que pode garantir uma elicitação</p><p>rápida e eficaz dos requisitos. Essa técnica é empregada na metodologia Design</p><p>Sprint, por exemplo.</p><p>Pesquisa ou questionário</p><p>Embora evitem a oportunidade de conversas pessoais diretas, as pesquisas</p><p>são úteis para reunir dados rapidamente de um grande grupo de participantes.</p><p>Como softwares de pesquisa online gratuitos estão prontamente disponíveis</p><p>(como os Forms de Google e Microsoft, por exemplo), as pesquisas são uma</p><p>forma barata de coletar dados objetivos de clientes ou usuários finais em</p><p>potencial. Tal como acontece com a seleção de interessados, uma pesquisa ou</p><p>questionário bem-sucedido deve ter participantes bem escolhidos. As pesquisas</p><p>podem ser estruturadas para oferecer uma série de opções finitas para feedback,</p><p>ou podem oferecer informações abertas, dependendo das necessidades do</p><p>projeto em questão. Pesquisas abertas são úteis para uma descoberta mais</p><p>ampla das necessidades de negócios; no entanto, quanto maior o número de</p><p>participantes em pesquisas abertas, mais difícil e demorada será a análise. O texto</p><p>da pesquisa deve ser bastante preciso. É uma boa prática para um analista solicitar</p><p>educadamente que os participantes da pesquisa respondam dentro de um prazo</p><p>Didática no Ensino 16</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>razoável e que mantenham qualquer informação comercial proprietária contida</p><p>na pesquisa como confidencial.</p><p>A natureza do projeto de um analista ditará o nível de detalhe que uma</p><p>das técnicas vistas deve abranger. Tal como acontece com as entrevistas, as</p><p>observações e análises de uso do usuários (buscando analisar a experiência do</p><p>usuário) formam boas práticas para o analista fornecer notas de suas análises</p><p>e uma descrição verbal de sua compreensão do trabalho para um revisor, a fim</p><p>de se certificar de que não houve mal-entendidos do processo. Como observa</p><p>o BABOK, algumas técnicas como a de questionários podem ser úteis quando a</p><p>população é grande o suficiente e as questões abordadas são claras o suficiente</p><p>para todos os interessados.</p><p>Citando diretamente o que o BABOK (2015, p. 38), “As partes interessadas</p><p>frequentemente consideram a prototipagem um meio concreto de identificar,</p><p>descrever e validar suas necessidades de interface.”. Isso reforça que algumas</p><p>técnicas e metodologias são mais focadas no usuário do que na equipe de</p><p>desenvolvimento em si. Pois, enquanto a documentação bem definida fica mais</p><p>a cargo de explicar aos analistas e programadores, a prototipagem, storyboard</p><p>e storytelling acabam por representar de maneira mais clara ao usuário final</p><p>(geralmente leigo) como será o produto final, baseado em seus requisitos.</p><p>2.1 CONFIRMANDO A ELICITAÇÃO</p><p>As necessidades de negócios do projeto de software e a combinação das</p><p>partes interessadas determinarão qual ou quais métodos de elicitação citados</p><p>anteriormente são os melhores para a necessidade em questão. A elicitação</p><p>normalmente não ocorre apenas antes dos requisitos, mas em todo o projeto,</p><p>durante a descoberta, a modelagem e até mesmo durante testes.</p><p>Sempre que a elicitação ocorre durante o ciclo de vida de um projeto, os</p><p>mesmos princípios se aplicam para torná-lo bem-sucedido, com a combinação</p><p>correta de partes interessadas, uma compreensão completa da necessidade do</p><p>negócio, técnicas de elicitação devidamente selecionadas e atenção meticulosa</p><p>aos detalhes.</p><p>Uma vez que os métodos de elicitação tenham sido empregados, um analista</p><p>deve documentar a elicitação rapidamente, enquanto ela ainda está fresca em</p><p>sua mente, compartilhando os resultados com todos os envolvidos de maneira</p><p>apropriada, a fim de confirmar sua concordância com as descobertas. Este</p><p>Didática no Ensino 17</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>estágio é essencial para garantir que o analista entendeu com precisão e as partes</p><p>interessadas comunicaram com precisão as necessidades do projeto. A elicitação</p><p>serve, então, como pesquisa básica para a fase de criação de requisitos. Assim</p><p>que o analista tiver material suficiente, ele pode começar a elaborar os requisitos.</p><p>A análise pode ser apoiada na modelagem de negócio para melhor compreensão</p><p>do alvo a ser atingido.</p><p>A modelagem de negócio é uma das formas de estabelecer disciplinas que</p><p>realizam o mapeamento das regras de negócio. Os objetivos da modelagem de</p><p>negócios são:</p><p>• Entender a estrutura e a dinâmica da organização na qual um sistema será implanta-</p><p>do (a organização-alvo).</p><p>• Entender os problemas atuais na organização alvo e identificar potenciais de melho-</p><p>ria.</p><p>• Garantir que clientes, usuários finais e desenvolvedores tenham um entendimento</p><p>comum da organização de destino.</p><p>• Derivar os requisitos de sistema necessários para oferecer suporte à organização de</p><p>destino.</p><p>A modelagem de negócios é parte integrante do RUP (Rational Unified</p><p>Process). A disciplina de modelagem de negócios RUP consiste em fornecer uma</p><p>visão das estruturas e processos de negócios da organização em relação a um</p><p>projeto específico, identificando o escopo apropriado do projeto e mostrando</p><p>como o sistema se encaixa e suporta o negócio. Isso é extremamente importante</p><p>para um projeto, mas não é suficiente para a empresa; a disciplina de modelagem</p><p>de negócios abrange as mesmas atividades que a disciplina de modelagem de</p><p>requisitos, mas em nível corporativo.</p><p>2.2 MODELAGEM DE REQUISITOS</p><p>O produto derivado do RUP descreve a necessidade de modelar no</p><p>nível corporativo, mas como não há nenhum mecanismo dentro do RUP para</p><p>representar os problemas entre os sistemas de forma adequada, ele não faz jus</p><p>ao conceito nem fornece uma maneira explícita de compartilhar informações</p><p>entre projetos. Por isso, o RUP se torna mais completo ao juntarmos ele a outras</p><p>disciplinas e processos. Para atingir seus objetivos, a disciplina de modelagem</p><p>de negócios descreve como desenvolver uma visão da organização de destino</p><p>e, com base nessa visão, definir os processos, funções e responsabilidades dessa</p><p>organização em um modelo de caso de uso de negócios e um modelo de objeto</p><p>de negócios.</p><p>Didática no Ensino 18</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Complementarmente a esses modelos, alguns artefatos podem ser</p><p>desenvolvidos, como a especificação complementar de negócios e um glossário,</p><p>que possa traduzir os termos levantados e elicitados a fim de que os requisitos</p><p>possam refletir fielmente o que se pretende ter ao final do ciclo de vida do projeto.</p><p>Os esforços de modelagem de negócios de uma empresa devem explorar uma</p><p>ampla gama de questões. Como resultado, o modelo de negócios corporativo é,</p><p>na verdade, composto de uma coleção de artefatos menores conforme o quadro a</p><p>seguir nos apresenta. Os problemas de negócios que a serem explorados incluem</p><p>os seguintes artefatos:</p><p>Artefato Descrição</p><p>Especificação de regras de</p><p>negócios</p><p>Definição das restrições que influenciam ou orientam o funcionamento diário de um</p><p>negócio ou organização.</p><p>Modelo de processo de ne-</p><p>gócios</p><p>Captura os processos de negócios fundamentais, as entidades externas (clientes,</p><p>fornecedores, parceiros ou concorrentes) e os principais fluxos de trabalho entre</p><p>eles.</p><p>Modelo de domínio de ne-</p><p>gócio</p><p>Descreve as principais entidades de interesse para uma organização e seus relacio-</p><p>namentos.</p><p>Declaração de missão Uma declaração das estratégias a serem seguidas para alcançar a visão de negócio.</p><p>Visão de negócio Uma declaração das metas principais de uma organização.</p><p>Modelo de organização Uma definição da localização, posições, unidades organizacionais e seus inter-rela-</p><p>cionamentos dentro de uma empresa.</p><p>Quadro 2 - Artefatos relativos a problemas de negócios</p><p>O desenvolvimento do documento de modelagem de negócios de uma</p><p>organização começa com uma visão ampla de todo o negócio. Isso não significa</p><p>que você modelará todos os processos do negócio, pois, alguns aspectos serão</p><p>ignorados, dando ênfase aquilo que tem a ver com o problema a ser resolvido</p><p>com o software a ser desenvolvido. Significa dizer que seu modelo irá além do</p><p>escopo de um único projeto.</p><p>O objetivo</p><p>aqui é capturar os fundamentos do negócio, trabalhando com</p><p>os stakeholders em um modelo abrangente, mas superficial - sem detalhes que</p><p>não competem saber ou estejam fora do escopo do problema a ser resolvido. É</p><p>precisa identificar e priorizar áreas de importância para que possam ser exploradas</p><p>em detalhes pelos esforços de modelagem de negócios de equipes de projeto</p><p>individuais.</p><p>As regras de negócio de uma empresa devem definir uma visão geral precisa</p><p>e de alto nível do negócio e deve conter informações que sejam relativamente</p><p>estáveis ao longo do tempo. Por exemplo, dentro de um banco, a necessidade de</p><p>Didática no Ensino 19</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>processar transações bancárias de varejo existe há séculos, mas a maneira como</p><p>isso ocorre mudou drasticamente ao longo do tempo - a necessidade de alto nível</p><p>é estável, enquanto os detalhes são muito fluidos.</p><p>2.3 FLUXO DE PROCESSO DE MODELAGEM</p><p>Devido aos passos necessários para obter requisitos maduros, diversas</p><p>disciplinas e técnicas podem ser empregadas, como vimos anteriormente. O</p><p>fluxo de processo de modelagem se trata de descrever os passos a serem dados,</p><p>de maneira lógica, como uma sugestão sequencial de etapas a serem cumpridas</p><p>com o objetivo de se chegar aos requisitos refinados.</p><p>Para se obter um projeto de sucesso, nunca é muito cedo para começar a</p><p>reunir e documentar os requisitos do projeto. Na verdade, quanto mais cedo</p><p>melhor. A seguir, estão as etapas sobre como reunir requisitos, conduzindo você</p><p>por um processo completo de coleta de requisitos. Essas etapas auxiliam a finalizar</p><p>a documentação de requisitos por meio da colaboração da equipe, verificações</p><p>e balanços e educação do cliente. O fluxo sugerido está apresentado na Figura 3.</p><p>Figura 2 - Fluxo de processos de modelagem de requisitos</p><p>Fonte: Elaborada pelo autor</p><p>As etapas descritas no fluxo da Figura 2 são exemplos de um passo a passo</p><p>a ser dados a fim de se obter ao final o documento de requisitos que atendam</p><p>as demandas internas e externas entre as equipes de desenvolvimento e os</p><p>stakeholders. Para melhor entendimento, vamos descrever cada uma das etapas</p><p>e suas tarefas e objetivos envolvidos.</p><p>Tome Nota</p><p>Em cada reunião em que se fizer, seja interna com sua equipe de projeto ou</p><p>externa com seu cliente, é essencial que se faça anotações. Gerentes de projetos</p><p>Didática no Ensino 20</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>precisam se concentrar no andamento do projeto, logo, é importante que todos</p><p>façam suas anotações mas que também haja alguém responsável por fazer uma</p><p>anotação “oficial”, com a perspectiva de capturar itens de ação, necessidades</p><p>de esclarecimento, oportunidades para pesquisas ou discussões adicionais e</p><p>quaisquer outras informações importantes discutidas nas reuniões. Na hora da</p><p>reunião, pode parecer que todos lembrarão do que foi falado. Mas, confiar apenas</p><p>na memória não é uma boa prática profissional.</p><p>Revise os requisitos criados</p><p>Fornecer requisitos criados desde as primeiras reuniões sempre que possível</p><p>deve estar no cronograma e orçamento do projeto. A orientação criativa é</p><p>inestimável para os desenvolvedores. O ideal é que se tenha wireframes e designs</p><p>de interface de usuário completos para dispositivos móveis e desktops criados por</p><p>algum aplicativo próprio para isso, a fim de irmos modelando requisitos conforme</p><p>o ciclo continua.</p><p>Depois de reunir tais designs, é importante compartilhar com todos os</p><p>envolvidos os modelos criados. Certifique-se de salvar as versões finais desses</p><p>designs em um só lugar, separado de quaisquer versões anteriores, para que</p><p>sua equipe tenha absoluta certeza de que estão fazendo referência aos ativos</p><p>finais do criativo. O versionamento de documentos nasce antes mesmo de se ter</p><p>versionamento de código.</p><p>Faça anotações</p><p>Depois de entregar os resultados desde as primeiras reuniões até a revisão</p><p>de requisitos, é importante continuar anotando os elementos que vão surgindo.</p><p>Anote os insights mesmo enquanto ainda são ideias hipotéticas. Cada elemento</p><p>requer uma anotação. Use uma ferramenta como Invision ou Skitch para fazer</p><p>anotações nos designs de tela, por exemplo.</p><p>Normalmente, se começa anotando as ideias, partindo das anotações feitas</p><p>em cada reunião. Mas, pensando que se quer chegar a uma documentação</p><p>completa, é benéfico manter a mentalidade de “primeiras ideias” em mente ao</p><p>produzir uma solução. Dito isso, é preciso elaborar as versões das anotações, com</p><p>data e nome dos envolvidos em cada parte desses processos. Isso servirá como</p><p>um histórico ou log do que acontece ao longo do projeto.</p><p>Escreva o documento de requisitos</p><p>Ao mergulhar na documentação, é bom lembrar que a primeira tentativa</p><p>Didática no Ensino 21</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>na documentação de requisitos é sempre a mais difícil. Isso geralmente é uma</p><p>verdade, pois quando não se tem um documento anterior para aproveitar, a</p><p>criação do zero requer dedicação por parte do analista. Como auxílio, existem</p><p>modelos de documentação de requisitos que servem como base para um projeto</p><p>de software.</p><p>Faça uma entrevista interna</p><p>Depois de concluir o primeiro rascunho da documentação de requisitos, é</p><p>importante que novas revisões aconteçam. A realização de uma entrevista ou</p><p>bate papo interno a fim de rever o que já se tem levantado de requisitos pode ser</p><p>fundamental. Nesta parte do processo de coleta de requisitos, deve-se agendar</p><p>outra reunião interna com sua equipe de projeto para revisar a documentação de</p><p>seus requisitos todos juntos.</p><p>Esta é uma verificação e equilíbrio internos finais para garantir sua</p><p>compreensão da implementação. Se possível, pede-se à equipe que analise a</p><p>documentação de seus requisitos antes da reunião para que eles possam estar</p><p>prontos com suas perguntas e feedback. Em entrevistas internas, identifica-</p><p>se lacunas no entendimento e verifique a consistência da documentação de</p><p>requisitos.</p><p>Como parte da fase de revisão interna, é preciso fazer as revisões necessárias</p><p>na documentação, com base em discussões internas. Por fim, a documentação</p><p>de requisitos revisada poderá ser passada a equipe e stakeholders para uma visão</p><p>final e aprovação.</p><p>Criar tarefas</p><p>Agora que temos um documento de requisitos elaborado e revisado, é hora de</p><p>passar a documentação de requisitos para sua equipe de desenvolvimento. O ideal</p><p>é que os desenvolvedores ou o líder de desenvolvimento executem a construção</p><p>de tarefas para passarmos a fase de construção. Embora algumas organizações</p><p>possam operar sob um processo em que os gerentes de projeto criem todas as</p><p>tarefas, algumas metodologias apontam que os próprios desenvolvedores criem</p><p>suas próprias tarefas. Isso permite que os desenvolvedores criem tarefas de uma</p><p>forma que se adapte à sua abordagem de desenvolvimento, mais fáceis de serem</p><p>colocadas em ação.</p><p>Didática no Ensino 22</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>As seis etapas citadas são exemplos de aplicação prática da modelagem de</p><p>requisitos, passando por etapas de reuniões, entrevistas e acompanhamento de</p><p>cada um dos passos necessários para a elicitação de requisitos no contexto de um</p><p>projeto de software.</p><p>Didática no Ensino 23</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>3. ESTIMATIVA DE CUSTOS E PRAZOS NA ENGENHARIA</p><p>DE REQUISITOS</p><p>A engenharia de requisitos tem por base para todas as atividades de</p><p>planejamento a Estrutura Analítica do Projeto (EAP). Ela decompõe o projeto</p><p>hierarquicamente em estruturas bem definidas, tarefas ou atividades gerenciáveis.</p><p>Uma EAP pode ter a forma de uma tabela ou de um diagrama. O número de</p><p>níveis de detalhe depende principalmente do tamanho do projeto e preferências</p><p>pessoais do gerente de projeto ou da organização.</p><p>Por isso, é importante que todas as atividades necessárias para concluir o</p><p>projeto sejam incluídas na EAP e atribuídas a um indivíduo ou uma organização</p><p>específica de forma inequívoca. A EAP fornece a estrutura fundamental para</p><p>programação, orçamento e controle de projetos.</p><p>Uma vez que a EAP foi definida,</p><p>a estimativa do processo pode começar. O exemplo de diagrama da Figura 3</p><p>mostra os relacionamentos hierárquicos entre as várias tarefas de um projeto.</p><p>Figura 3 - Estrutura Analítica do Projeto</p><p>Fonte: Elaborada pelo autor (2020).</p><p>Dentro de um fluxo de projeto de software, o primeiro passo ideal é estimar o</p><p>tamanho do software a ser desenvolvido. A qualidade dessa estimativa influencia</p><p>diretamente as estimativas de custo e cronograma. Isto é também a parte mais</p><p>difícil do processo de estimativa, visto que muitas vezes é mal feito, evidenciando</p><p>muitos estouros de custo e atrasos no cronograma do projeto.</p><p>Existem métricas de tamanho do produto que são comumente usadas em</p><p>projetos de software, as mais comuns são as de linhas de código (LOC) e pontos</p><p>de função (PF). A abordagem de linhas de código requer uma estimativa do</p><p>número de linhas de código-fonte, normalmente estimado por analogia com</p><p>projetos anteriores semelhantes. A análise de pontos de função, por outro lado,</p><p>Didática no Ensino 24</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>não requer conhecimento prévio de código fonte. Ele é baseado em uma medida</p><p>sintética de funcionalidade de acordo com as regras de negócio. O número de</p><p>PF é determinado a partir de uma soma ponderada de entradas, saídas, consultas,</p><p>arquivos e interfaces com outros programas.</p><p>O ponto de função bruto é a contagem ajustada para a complexidade</p><p>técnica e fatores ambientais para chegar a uma estimativa final do ponto de</p><p>função. Os pontos de função levam a estimativas razoavelmente confiáveis e são</p><p>independentes de linguagens de programação. Sua análise pode ser feita quase</p><p>totalmente automatizada com o uso de ferramentas de estimativa de software</p><p>comercial que suportam análise de pontos de função.</p><p>Existem outras métricas, como a por Pontos por Casos de Uso (PCU) que tem</p><p>o objetivo de medir recursos de projetos de software de acordo com a quantidade</p><p>e complexidades de casos de uso. Essa métrica é geralmente empregada quando</p><p>se trabalha sob o paradigma orientado a objetos (OO).</p><p>3.1 ESTIMATIVA DE PRAZOS E CRONOGRAMA</p><p>Existem duas abordagens fundamentais para o custo e cronograma do</p><p>projeto de software: de cima para baixo (top-down) e de baixo para cima (bottom-</p><p>up). A abordagem de cima para baixo tenta estimar o custo total do projeto e</p><p>cronograma, normalmente usando software automatizado com modelos de</p><p>estimativa de custos. Este processo consiste em converter a medida de tamanho</p><p>para esforço em termos de pessoal/mês e duração do projeto em quantidade de</p><p>dias ou meses.</p><p>Embora vários algoritmos e regras básicas estejam disponíveis, todas as</p><p>estimativas precisam ser ajustadas à produtividade organizacional e outros</p><p>fatores que influenciam na produtividade. A estimativa geral do tamanho é então</p><p>usada para alocar o esforço em tarefas específicas e atividades a fim de programar</p><p>marcos de entregas de cada atividade.</p><p>Já a abordagem de baixo para cima começa com a estimativa das</p><p>necessidades das pessoas e um cronograma para as tarefas mais baixas,</p><p>agregando-as a estimativas de nível superior. Em um comparativo, a abordagem</p><p>de cima para baixo leva a estimativas superiores, enquanto a abordagem de baixo</p><p>para cima tende a incutir propriedade e compromisso com o plano em todos os</p><p>níveis da equipe do projeto (DAVEY et al, 2008).</p><p>Didática no Ensino 25</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Para obter o melhor de ambos os métodos, muitas empresas usam as duas</p><p>abordagens em conjunto de forma iterativa. A abordagem de cima para baixo</p><p>é usada para definir diretrizes para o projeto como um todo, enquanto uma</p><p>abordagem de baixo para cima é usada para desenvolver estimativas detalhadas</p><p>de custo e cronograma dentro das restrições estabelecidas pela abordagem</p><p>de cima para baixo. Este método requer vários ciclos de estimativas antes de</p><p>convergir para uma estimativa satisfatória.</p><p>Ferramentas comerciais de estimativa de software produzem cronogramas</p><p>nominais alcançáveis por uma equipe eficiente trabalhando em boas condições.</p><p>Muitas ferramentas também fornecem recursos para fazer compensações de</p><p>custo e cronograma. Como exemplo, o horário pode ser reduzido adicionando</p><p>mais membros a uma equipe, mas ao contrário de outros tipos de projetos,</p><p>o desenvolvimento de software não permite compressão significativa de</p><p>cronograma. De acordo com pesquisa publicada por Buratti (2014), praticamente</p><p>todos os esforços para comprimir a programação em mais do que 25% do nominal</p><p>não são bem-sucedidos.</p><p>Um bom cronograma é bastante desafiador, mas deve ser razoável, alcançável</p><p>e deve ter o comprometimento de toda a equipe do projeto. O melhor caminho para</p><p>obter compromisso em uma equipe é ter cada tarefa estimada pelos indivíduos ou</p><p>grupos responsáveis por completá-lo, como vimos no tópico 2. O cronograma para</p><p>grandes projetos geralmente é dividido em um cronograma mestre, mostrando</p><p>apenas atividades e marcos principais, apoiando programações de nível inferior</p><p>para atividades detalhadas.</p><p>A forma mais comum de apresentar informações de cronograma é o gráfico</p><p>de Gantt. Ele retrata as atividades em uma escala de tempo horizontal. Os gráficos</p><p>de Gantt são populares porque são bem compreendidos e fáceis de se criar e rever.</p><p>No entanto, eles não são adequados para mostrar as inter-relações entre as várias</p><p>tarefas (que tarefa deve ser concluída antes de outra começar, por exemplo). A</p><p>Figura 4 a seguir representa um gráfico de Gantt para um cronograma entre os</p><p>meses de janeiro a junho.</p><p>Didática no Ensino 26</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Figura 4 - Gráfico de Gantt</p><p>Fonte: Elaborado pelo Autor (2020).</p><p>Uma análise de rede do cronograma ou diagrama de rede é uma</p><p>representação gráfica de um cronograma mostrando cada atividade em</p><p>sequência e o tempo que leva para terminar cada uma. É usado para identificar</p><p>datas de início antecipadas e atrasadas, bem como datas de término antecipadas</p><p>e atrasadas, para as partes incompletas das atividades do cronograma do</p><p>projeto. Essa análise também ajuda a determinar o caminho crítico, a análise</p><p>de variações hipotéticas e a compactação do cronograma. Um cronograma</p><p>através do diagrama de rede é a ferramenta apropriada para mostrar tais inter</p><p>relações.</p><p>A análise de rede do cronograma mais comumente usada são PERT (Program</p><p>Evaluation and Review Technique ou Programa de Avaliação e Revisão) e CPM</p><p>(Critical Path Method ou Método do Caminho Crítico). Ambos os métodos são</p><p>bastante semelhantes no uso de fluxo gráficos para mostrar as inter-relações entre</p><p>as tarefas. O PERT trabalha com três perspectivas: otimista, pessimista e mais</p><p>provável. Por sua vez, o CPM foca na avaliação do caminho crítico do processo.</p><p>A Figura 5 nos mostra a ideia de um diagrama de rede que representa tarefas e o</p><p>tempo estimado para seu desenvolvimento.</p><p>Figura 5 - Exemplo de um diagrama de rede</p><p>Fonte: Elaborado pelo Autor (2020).</p><p>Didática no Ensino 27</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>Uma vantagem do diagrama de rede e do gráfico de Gantt é que eles</p><p>podem ser usados para identificar e rastrear o caminho crítico de um projeto.</p><p>O caminho crítico é o conjunto de atividades ao longo do caminho que levam</p><p>mais tempo para serem concluídas (linhas mais espessas). Em geral, o caminho</p><p>crítico determina quando o projeto estará realmente completado. As tarefas no</p><p>caminho crítico requerem gerenciamento especial atenção porque qualquer</p><p>atraso de cronograma nessas tarefas leva a um correspondente atraso em todo o</p><p>cronograma, o que impactará na data de conclusão do projeto.</p><p>Deve-se notar que um projeto pode ter vários caminhos críticos e que</p><p>as variações na duração das tarefas podem mudar um caminho crítico de um</p><p>conjunto de atividades para outro. O caminho crítico também é útil para identificar</p><p>riscos graves de programação. É comum que ferramentas mais completas de</p><p>gerenciamento de software incluam os meios de se criar e exibir ambas as formas</p><p>de se apresentar os</p><p>cronogramas, tanto o diagrama de redes como o gráfico de</p><p>Gantt.</p><p>3.2 ESTIMATIVA DE CUSTOS E ORÇAMENTO</p><p>As tarefas principais de estimativa são focadas em determinar e medir custos</p><p>e orçamento. Os custos do projeto de software são gerados principalmente pelos</p><p>custos de pessoal. O número de horas de trabalho pode ser derivado diretamente</p><p>das estimativas de tamanho do projeto com a ajuda de ferramentas de estimativa</p><p>automatizadas ou usando o próprio banco de dados histórico da empresa.</p><p>Em todo caso, as estimativas devem ser ajustadas para corresponder às</p><p>capacidades e experiência da equipe, além dos níveis de habilidade. A estimativa</p><p>também deve cobrir todas as atividades que são identificadas na estrutura analítica</p><p>do projeto (EAP), incluindo gerenciamento de projetos e todas as funções de</p><p>suporte, como garantia de qualidade.</p><p>Além dos custos diretos de mão de obra, a estimativa pode incluir todos os</p><p>custos diretos não trabalhistas e custos diretos ou indiretos. Os custos de mão de</p><p>obra direta são determinados multiplicando as horas de trabalho por taxas de mão</p><p>de obra apropriadas para cada item da EAP. Custos diretos não laborais são todos</p><p>os outros encargos aplicados ao projeto, incluindo tarefas que são terceirizadas,</p><p>consultores, viagens e custos de material.</p><p>O orçamento total do projeto é determinado pela agregação de todos os</p><p>custos indiretos. É uma boa prática incluir alguma reserva de gestão para possíveis</p><p>Didática no Ensino 28</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>problemas e imprevistos por contingência. Uma reserva de 5 a 10 por cento não</p><p>é incomum e pode ser ainda maior para projetos de alto risco. O orçamento (com</p><p>os fundos de contingência removidos) é destinado a organizações ou indivíduos</p><p>designados ao projeto de acordo com a EAP.</p><p>O orçamento se torna a linha de base para controle do projeto, fornecendo</p><p>padrões contra os quais o desempenho do projeto pode ser medido. Uma</p><p>ferramenta útil para gerentes de projeto é um custo cumulativo baseado na</p><p>curva de tempo x custo, às vezes chamada de curva S. Ela fornece visibilidade ao</p><p>representar o orçamento graficamente em função do tempo de acordo com os</p><p>cronogramas do projeto, como visto na Figura 6 a seguir:</p><p>Figura 6 - Curva de custo acumulado ou curva S</p><p>Fonte: Elaborado pelo Autor (2020).</p><p>Ao longo do diagrama, podemos perceber que a estimativa de custo pode</p><p>ir evoluindo e se tornando uma curva em formato de S conforme os custos e o</p><p>tempo vão avançando. É natural que o custo acabe se elevando caso o projeto</p><p>se torne demorado em demasia para chegar a entrega final. Com isso, uma</p><p>progressão do custo sofre acréscimos, visto que geralmente um profissional de</p><p>desenvolvimento de software tem seu pagamento estimado por sua habilidade</p><p>ou função no projeto por hora trabalhada.</p><p>Didática no Ensino 29</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>4. ANÁLISE E GERENCIAMENTO DE RISCOS</p><p>A gestão de riscos é uma parte importante da gestão de projetos de software.</p><p>Na fase de planejamento ou de elaboração, o gerente de projeto precisa realizar</p><p>uma análise realista de avaliação dos riscos e desenvolver um plano de controle</p><p>de tais riscos levantados.</p><p>De acordo com Buratti (2014), os três principais fatores que influenciam o</p><p>risco do projeto são:</p><p>• Tamanho do projeto;</p><p>• Estrutura do projeto;</p><p>• Experiência com tecnologia.</p><p>Percebe-se que, quanto maior o projeto, menos estruturado ele tende a ser</p><p>(ou seja, os requisitos não estão bem definidos e é provável que mude durante</p><p>o projeto). E, no geral, quanto menor a experiência da equipe com a tecnologia</p><p>do projeto, maior o risco de encontrarmos problemas. Buratti (2014) ainda</p><p>recomenda uma abordagem de contingência ao adotar uma estratégia apropriada</p><p>de gestão de projeto para cada tipo de risco. Um conjunto de ferramentas de</p><p>gestão está disponível para implementar cada estratégia, que inclui ferramentas</p><p>de integração externas, ferramentas de integração interna e ferramentas formais</p><p>de planejamento e controle.</p><p>Projetos com relativamente ou pouca estrutura podem se beneficiar de</p><p>ferramentas de integração externa que criam ligações eficazes entre a equipe do</p><p>projeto e o cliente da organização. Tais ferramentas devem incluir as tarefas de:</p><p>• Selecionar o gerente de projeto e os principais membros da equipe do cliente orga-</p><p>nização;</p><p>• Representação frequente do cliente nas reuniões de revisão do projeto;</p><p>• Ampla distribuição de relatórios de status na organização do cliente.</p><p>Para um bom acompanhamento pelas partes envolvidas, é fundamental que</p><p>todo processo seja exposto de maneira clara e franca. Problemas observados</p><p>antes de acontecerem diminuem consideravelmente o risco de um projeto.</p><p>Projetos envolvendo novas tecnologias devem contar mais com ferramentas de</p><p>integração interna que são projetadas para aprimorar a competência técnica da</p><p>equipe e operação como uma unidade integrada. As ferramentas de integração</p><p>Didática no Ensino 30</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>interna típicas incluem:</p><p>• Membros de equipe altamente experientes;</p><p>• Gerente de projeto com forte gestão técnica e de projeto fundo;</p><p>A contingência para gerenciamento de riscos aborda a forma como os riscos</p><p>podem ser categorizados e assim analisados em 3 vertentes. Existem três eixos</p><p>em que a abordagem de contingência de gerenciamento de risco se apoia:</p><p>Estrutura, Tamanho e Tecnologia. A Figura 7 a seguir apresenta uma abordagem</p><p>de contingência para gerenciamento de risco.</p><p>Figura 7 - Abordagem de Contingência para Gerenciamento de Riscos</p><p>Fonte: Elaborado pelo autor</p><p>Como apresentado na Figura 7, a estrutura se apoia em ferramentas de</p><p>integração externa, como em servidores de dados e recursos necessários para um</p><p>sistema funcionar. O eixo tecnologia é firmado com ferramentas de integração</p><p>interna, sendo muito importante como forma de se chegar a soluções através</p><p>de softwares a serem desenvolvidos. O eixo tamanho tem a ver com o escopo</p><p>ou limites do tamanho do projeto em si e leva em consideração ferramentas de</p><p>planejamento e controle, a fim de equilibrar tanto a estrutura como as tecnologias</p><p>empregadas no projeto.</p><p>4.1 APLICAÇÃO DO GERENCIAMENTO DE RISCOS</p><p>Projetos envolvendo novas tecnologias devem contar bastante com</p><p>ferramentas de integração interna que são projetadas para aprimorar a</p><p>competência técnica da equipe e operação como uma unidade integrada. As</p><p>ferramentas de integração interna típicas incluem:</p><p>Didática no Ensino 31</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>• Membros de equipe altamente experientes;</p><p>• Gerente de projeto com forte e profunda gestão técnica de projetos;</p><p>• Reuniões frequentes de status da equipe</p><p>Grandes projetos, principalmente aqueles com uma alta estrutura, devem</p><p>ser gerenciados por ferramentas formais de planejamento e controle. Essas</p><p>ferramentas, descritas com mais detalhes a seguir, representam uma abordagem</p><p>altamente disciplinada e sistemática para o projeto planejamento e controle. Eles</p><p>incluem cronogramas formais, orçamentos e procedimentos de rastreamento</p><p>para controle de gestão.</p><p>Embora a escolha da abordagem de gestão adequada para lidar com risco</p><p>do projeto em alto nível é importante, uma avaliação de risco mais detalhada é</p><p>necessária para lidar com riscos potenciais específicos. A avaliação de risco inclui:</p><p>• Identificação de risco;</p><p>• Análise de risco;</p><p>• Priorização de riscos;</p><p>O objetivo da identificação de risco é desenvolver uma lista de riscos que</p><p>podem gerar impacto no resultado do projeto. A análise de risco consiste em</p><p>avaliar a exposição ao risco, a probabilidade e o impacto de cada risco. A priorização</p><p>de riscos produz uma lista de riscos priorizando-os por impacto que eles possam</p><p>ocasionar, se tornando a base para o planejamento do gerenciamento de risco.</p><p>Um bom plano deve abordar todos os principais riscos, identificar planos de</p><p>contingência para lidar com eles e definir o processo de monitoramento dos</p><p>riscos.</p><p>No Brasil, existe um modelo de qualidade de software que</p><p>visa a busca</p><p>constante da melhoria na qualidade de processos de software, chamado de</p><p>MPS.BR (Melhoria do Processo de Software Brasileiro). Proposto pela Softex</p><p>(Associação para Promoção da Excelência do Software Brasileiro), que possui</p><p>sede em Brasília mas mantém escritórios regionais a fim de dar apoio e formar</p><p>uma comunidade onde todos os agentes envolvidos em software no Brasil</p><p>possam ajudar a fomentar boas práticas no desenvolvimento de sistemas. Nisso,</p><p>as questões de qualidade e de gerenciamento de risco estão incluídas.</p><p>Em seu guia de implementação, a seção 7 (sete) aborda a Gerência de</p><p>Riscos, também chamada de GRI. Segundo o MPS.BR, a gerência de riscos tem</p><p>Didática no Ensino 32</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>por finalidade analisar, tratar, identificar e monitorar os riscos tanto no âmbito da</p><p>organização como do projeto de software (MPS.BR, 2013). Além desta organização</p><p>brasileira, a nível internacional temos a IEEE que estabelece através do padrão</p><p>1540 seu processo para gerenciamento de riscos. A ISO/IEC possui seu padrão</p><p>12207 com o mesmo objetivo, definindo um subprocesso para gerência de riscos.</p><p>O PMBOK (Project Management Body of Knowledge), projeto que funciona</p><p>como um manual ou padrão de boas práticas na gestão de projetos, também</p><p>apresenta sua seção exclusiva para lidar com gerenciamento de riscos, tendo 6</p><p>(seis) subprocessos associados.</p><p>Uma forma útil para monitoramento de risco é uma lista com os principais</p><p>riscos que deve ser mantida e atualizada com frequência para identificar sempre</p><p>os maiores riscos por ordem de prioridade. Isso pode (e deve) ser feito com um</p><p>plano de gestão de software compatíveis com a necessidade de cada projeto,</p><p>cuja importância veremos no próximo tópico.</p><p>4.2 PADRÃO DE PROJETO DE SOFTWARE</p><p>O planejamento do projeto culmina em um plano de projeto de software. Esse</p><p>plano deve levar em consideração, além de aspectos como requisitos, escopo</p><p>do projeto e toda parte de projeto, aspectos técnicos e gerenciais, também a</p><p>gestão de riscos. Este é um documento que descreve a abordagem geral para</p><p>o desenvolvimento de software, especifica todas as entregas, requisitos de</p><p>recursos, cronogramas, orçamentos e organização responsabilidades e define os</p><p>processos de gestão.</p><p>Além disso, o plano descreve todos os fatores de risco e estratégias de gestão</p><p>de risco, descrevendo como as mudanças são gerenciadas e a qualidade deve ser</p><p>garantida. É um documento que deixa clara a situação do projeto para a gestão,</p><p>membros da equipe e os stakeholders escolhidos por parte do cliente. É como</p><p>um roteiro que serve para guiar os membros da equipe do projeto.</p><p>Ele estabelece o custo e a linha de base do cronograma para gerenciar e</p><p>controlar o projeto. Portanto, torna-se uma parte efetiva do sistema de controle de</p><p>projeto. E, para testar a adequação de um plano de projeto, o gerente de projeto</p><p>deve se perguntar:</p><p>• O plano me permite gerenciar o projeto com eficácia?</p><p>• Fornece informações suficientes para os membros da equipe planejar e fazer o tra-</p><p>balho deles?</p><p>• Tem o comprometimento da alta administração e da equipe?</p><p>Didática no Ensino 33</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>O gerente de projeto (GP) geralmente é selecionado no final da fase</p><p>conceitual, fase em que o projeto já está aprovado. O gerente de projeto é a</p><p>pessoa responsável pela gestão de todo o projeto. Sua principal responsabilidade</p><p>é dirigir e coordenar todas as atividades para cumprir os objetivos do projeto</p><p>dentro orçamento e cronograma. Esta função é bastante diferente da função</p><p>do técnico líder ou desenvolvedor, cuja responsabilidade é principalmente pela</p><p>integridade técnica do produto.</p><p>Gerenciar um projeto é um grande desafio. O perfil deste tipo de gerente</p><p>requer que seja uma pessoa bastante organizada, de preferência apaixonada e</p><p>orientada a objetivos. O GP precisa entender o que os projetos têm em comum e</p><p>saber bem oseu papel estratégico na forma como as organizações podem obter</p><p>o sucesso. As responsabilidades específicas do gerente de projeto incluem o</p><p>seguinte:</p><p>• Reportando-se à alta administração</p><p>• Comunicação com usuários</p><p>• Planejamento e programação</p><p>• Coordenar as atividades do projeto</p><p>• Orçamento, cronograma, risco e controle de qualidade</p><p>• Gestão de Pessoas</p><p>• Entregando Resultados</p><p>De acordo com o PMI (online) - Project Management Institute - instituto</p><p>internacional que tem por objetivo equalizar as normas e boas práticas em</p><p>gerenciamento de projetos, os gerentes de projeto são agentes de mudança.</p><p>São eles quem definem os objetivos do projeto e usam suas habilidades e</p><p>conhecimentos para inspirar um senso de propósito compartilhado na equipe do</p><p>projeto. Funcionam bem sob pressão e se sentem confortáveis com mudanças e</p><p>complexidade em ambientes dinâmicos.</p><p>Eles podem alternar prontamente entre o quadro geral de tarefas e os</p><p>detalhes pequenos, mas cruciais, sabendo quando se concentrar em cada</p><p>um. Os gerentes de projeto cultivam as habilidades pessoais necessárias para</p><p>desenvolver confiança e comunicação entre todas as partes interessadas do</p><p>projeto: os stakeholders e aqueles que farão uso dos resultados do projeto, assim</p><p>como aqueles que comandam os recursos necessários e os membros da equipe</p><p>do projeto.</p><p>O gerenciamento de projetos pressupõe o uso de um conjunto de</p><p>ferramentas amplo e flexível, de técnicas que resolvem atividades complexas e</p><p>Didática no Ensino 34</p><p>Volte ao Sumário</p><p>Navegue entre os capítulos</p><p>interdependentes em tarefas e subtarefas que são documentadas, monitoradas</p><p>e controladas. A partir do uso de instrumentos próprios de gestão, adaptam</p><p>a abordagem de metodologias ao contexto e às restrições de cada projeto,</p><p>sabendo que não existe um tamanho único para todo e qualquer tipo de projeto,</p><p>principalmente na área de software.</p><p>O uso correto do gerenciamento de projeto pode atender a toda variedade</p><p>de projetos, permitindo com que gerentes e profissionais que trabalham nos</p><p>projetos estejam sempre melhorando suas próprias habilidades e as das equipes</p><p>por meio de análises de lições aprendidas na conclusão de cada projeto.</p><p>A gestão de risco é o processo de identificação, avaliação e controle de</p><p>ameaças ao capital e lucros de uma organização. Essas ameaças ou riscos podem</p><p>ter origem em uma ampla variedade de fontes, incluindo incerteza financeira,</p><p>responsabilidades legais, erros de gestão estratégica, acidentes e desastres</p><p>naturais. Ameaças à segurança de TI, riscos relacionados a dados e as estratégias</p><p>de gerenciamento de risco para aliviá-los, tornaram-se uma das principais</p><p>prioridades das empresas digitalizadas nos tempos modernos.</p><p>Como resultado, um plano de gerenciamento de risco inclui cada vez mais</p><p>os processos das empresas para identificar e controlar ameaças aos seus ativos</p><p>digitais, incluindo dados corporativos proprietários, informações de identificação</p><p>pessoal de um cliente e propriedade intelectual. Em tempos de LGPD (Lei Geral</p><p>de Proteção de Dados) e seus equivalentes internacionais, todo cuidado é pouco</p><p>e é de extrema importância que coordenadores, diretores e gestores de um modo</p><p>geral tomem cuidados extremos quanto à segurança e os riscos a qual seu projeto</p><p>de software poderá estar envolvido.</p><p>Todas as empresas e organizações enfrentam o risco de eventos inesperados</p><p>e prejudiciais que podem custar dinheiro à empresa ou fazer com que ela feche</p><p>permanentemente. O gerenciamento de riscos permite que as organizações</p><p>tentem se preparar para o inesperado, minimizando os riscos e custos extras antes</p><p>que eles aconteçam.</p><p>Para que tenhamos êxito, um plano de projeto de software precisa estar bem</p><p>alicerçado em seções e tópicos que esclareçam os aspectos organizacionais de</p><p>um projeto. Um plano típico é descrito pela IEEE , no seu documento chamado</p><p>em português de Plano Padrão IEEE para Projeto de Software (IEEE Standard for</p><p>Software Project Management Plans, 1987), apresentado em português conforme</p><p>Didática no Ensino 35</p><p>Volte ao Sumário</p><p>Navegue entre</p>