Definindo Escopo em Projetos de Software

Carlos Alberto Debastiani

Novatec

Copyright © 2015 da Novatec Editora Ltda.

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora.

Editor: Rubens Prates Revisão de texto: Patrizia Zagni Editoração eletrônica: Carolina Kuwabata Capa: Carolina Kuwabata Assistente editorial: Priscila A. Yoshimatsu ISBN: 978-85-7522-429-8 Histórico de impressões Abril/2015 Primeira edição Novatec Editora Ltda.

Rua Luís Antônio dos Santos 110 02460-000 São Paulo, SP – Brasil Tel.: +55 11 2959-6529 E-mail: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Definição de escopo ontem e hoje

Há quatro ou cinco décadas, quando os profissionais do setor de processamento de dados (como era conhecida a área da empresa responsável pelo desenvolvimento de sistemas computadorizados) iniciavam um projeto de desenvolvimento, não havia uma preocupação exacerbada com o escopo do trabalho a ser realizado. Normalmente, o usuário tinha necessidades muito específicas, expectativas e ambições muito modestas em relação ao novo sistema, poucas funcionalidades que precisavam ser suportadas em um ambiente corporativo normalmente formado por sistemas estanques, que processavam separadamente, com pouca ou nenhuma interferência entre si.

Nessa época ainda não existiam as Extranets, as cadeias de comunicação com clientes e fornecedores (EDI), o processamento distribuído, a integração de sistemas nem o processamento colaborativo. Também não existia uma forte demanda por desenvolvimento, o que deixava os profissionais dedicados a essa tarefa com mais folga para trabalhar, sem prazos muito apertados para cumprir. Construir um sistema melhor do que tinha sido previsto inicialmente era justificativa suficiente para esticar prazos (e custos) que não eram mensurados nem controlados com tanta avidez.

Os padrões para desenvolvimento não era rígidos demais. Normalmente, os analistas e programadores simplesmente entrevistavam os usuários e inferiam, segundo as necessidades elencadas por eles, as entradas e saídas dos processos que eles mesmos definiam. Baseados na própria criatividade, definiam os padrões de interface e a forma como 15

16

Definindo Escopo em Projetos de Software

o sistema deveria interagir com o usuário, o formato das bases de dados que mais facilitava o processamento e a forma como a informação seria apresentada.

Pelo fato de os sistemas serem estanques, setorizados, os usuários normalmente usavam apenas os aplicativos de sua própria área. Não era incomum encontrar padrões de interface totalmente diferentes de um sistema para outro. A forma de interagir, de organizar menus de acesso ou teclas de função, por exemplo, podia ser totalmente diferente entre os sistemas da área de RH, da engenharia de produto ou do setor financeiro.

Com o passar dos anos, esse quadro foi mudando de forma drástica.

A crescente adoção de processamento online com característica real time trouxe uma nova dinâmica para o mundo dos negócios, que foi se tornando cada vez mais dependente da automação e da sistematização.

Essa dependência trouxe consigo outra característica: a necessidade de integração. Os usuários já não eram mais setorizados, passando a acessar sistemas de diversas áreas para trabalhar de forma integrada e colaborativa. Com isso, começaram a sofrer com a falta de padrões para formatação, comportamento e resposta entre os diversos sistemas que agora estavam utilizando.

Essa nova demanda forçou a maioria das empresas a adotar padrões de funcionamento, resposta e formatação para desenvolver seus sistemas, tornando a aderência a esses padrões um quesito importante na avaliação de qualidade do sistema que está sendo desenvolvido. Mais recentemente, essas premissas, já bastante debatidas e melhoradas, foram publicadas pela ABNT sob a forma de norma: a NBR ISO/IEC 9126, que será discutida com mais detalhes no capítulo 2.

Com o aumento expressivo na demanda e na complexidade dos novos sistemas, a definição do escopo de cada novo desenvolvimento passou também a ganhar importância, principalmente por ter de considerar a necessidade de aderência a padrões dos mais diversos tipos, desde a formulação das funcionalidades, até a definição e o tratamento das bases de dados.

Em face dessa evolução, atualmente, definir com precisão o escopo de um projeto de software é, com certeza, o mais crucial fator de sucesso.

Quanto mais avança a tecnologia e mais complexos e inter-relacionados

Capítulo 1 ■ Definição de escopo ontem e hoje

17

tornam-se os sistemas de informação, mais esse quesito transforma-se em fator essencial para o sucesso, e mais impacto sua deficiência provoca na execução dos projetos de software. Essa máxima parece ser opinião unânime entre autores da área de gestão de projetos.

Ricardo Vargas, em Análise de valor agregado em projetos (2008), ao citar outro autor (Cleland, 1999), afirma que “não existe um fator mais relacionado com o sucesso do que uma adequada definição de escopo”.

Harold Kerzner, em Gestão de projetos: as melhores práticas (2004), também afirma que: (...) o conceito de sucesso em um projeto tem mudado bastante ao longo das últimas décadas. Antes o sucesso era garantido apenas pela boa utilização da técnica e o funcionamento adequado do produto ou serviço gerado. Hoje, no entanto, os projetos são julgados por sua capacidade de gerar resultados dentro do prazo, do custo e da qualidade desejados. Em projetos de software, cada um desses elementos (prazo, custo e qualidade) tem profundas raízes fincadas na definição suficientemente precisa do escopo.

Vargas, em seu livro Gerenciamento de projetos: estabelecendo diferenciais competitivos (2005), cita como quesitos para considerar o sucesso de um projeto: • Ser concluído dentro do prazo previsto.

• Ser concluído dentro do orçamento previsto.

• Ter atingido a qualidade e o desempenho desejados.

• Ter sido concluído com o mínimo possível de alterações em seu escopo.

• Ter sido aceito sem restrições pelo contratante ou cliente.

Sem conhecer profundamente o trabalho que um sistema de informação deve realizar e os objetivos operacionais e de negócio que precisa atender, não conseguiremos atingir a satisfação de nenhum deles.

Em projetos de software, a gestão do escopo deve se fixar sobre a questão das funcionalidades desenvolvidas para o aplicativo, ou seja, o escopo funcional, tão bem definido por Kerzner (2004):

18

Definindo Escopo em Projetos de Software Escopo funcional – conjunto de características funcionais do produto, ou serviço, a ser desenvolvido pelo projeto, como capacidade, mercado, filosofia etc. Normalmente são direcionados ao cliente e também denominados requisitos funcionais.

Entender e delinear com precisão o escopo em um projeto de software não é uma tarefa fácil. Um sistema de informação sempre tem por finalidade cobrir uma necessidade estratégica de negócio ou viabilizar a execução automatizada de um processo operacional dentro da empresa. Foram-se aqueles tempos em que sistemas de informação eram instâncias estanques de processamento, isolados dentro de seus próprios mundos, proprietários soberanos de seus dados e processos.

Nos dias atuais, os sistemas de informação precisam conviver e, frequentemente, atuar ativamente em complexos emaranhados de inter-relacionamentos com outros sistemas, muitas vezes residentes em outros sites da empresa ou mesmo em outras empresas, como clientes, fornecedores ou órgãos governamentais e reguladores, com o objetivo de obter ou fornecer informações sob as mais diversas formas.

Desenvolver um novo aplicativo ou remodelar e ampliar software em operação significa, hoje, encaixar-se perfeitamente em uma complexa composição de engrenagens sistêmicas que precisam funcionar harmoniosamente. Não raro, esse cuidadoso encaixe tem de ocorrer com as engrenagens em movimento.

Em um ambiente tão complexo, é comum que as pessoas envolvidas com o funcionamento de cada uma dessas engrenagens não possuam conhecimento suficientemente detalhado ou não tenham a visão do conjunto funcional como um todo. Normalmente, a percepção é segmentada e a transparência dos processos faz com que pouco se saiba sobre como as coisas realmente funcionam. É nesse ponto que começam os problemas da equipe de projeto; problemas que podem conduzir à má definição de escopo.