Requisitos Funcionais e Não-funcionais Normalmente Esquecidos na Estimativa de Softwares

Terça-feira - hoje é dia de falar de TI

Bem depois de um final de semana, retorno ao trabalho e os desafios do desenvolvimento de software veêm a tona.
E isso não é uma desculpa para não falar de futebol!

Preciso realizar um estimativa de um projeto de software ...

Contexto
Trata-se de um projeto de porte grande que teve sua concorrência dividida pelo cliente por inicialmente não existir a visibilidade suficiente do escopo, consequentemente do tamanho, esforço, prazo, etc...

Então esta concorrencia foi dividida em duas etapas: o projeto lógico e o projeto físico. Ganhamos esta primeira estapa e já efetuamos o projeto lógico.

Desafio
Como definir o tamanho de um projeto de software?
Para os conhecedores do assunto já vem à mente as várias técnicas entre elas Function Point Analisys, WBS ...
A que estou utilizando é a Use Case Point (Pontos de Caso de Uso).

Porém não vou falar da UCP. Mas sim pontuar as dificuldades em se obter uma estimativa completa para o projeto.

Digo isto porque, em geral, mas métricas utilizadas nos levam apenas a conhecer o tamanho do software baseando nas atividades necessárias para especificar, construir e testar este software (sim, isto simplificando um pouco).

Porém, sempre, os profissionais de pré-venda, fábrica de software, planejadores de projeto ... todos os envolvidos em um proposta de desenvolvimento de software acabam deixando de estimar outras atividades que não estarão diretamente envolvidas construção e testes, mas que são parte do projeto e podem ter um peso significativo no custo total.

Base teórica

No livro Software Estimation—Demystifying the Black Art", Steve McConnell cita no tópico 4.5 as atividades omitidas em estimativas como um dos principais erros no provocando falhas em projetos.

Temos como atividades normalmente esquecidas:

Table 4-2: Requisitos Funcionais e Não-funcionais Normalmente Esquecidos na Estimatida de Softwares

Requisitos Funcionais: Configuração/Instalação, Conversão de Dados, Código para conectar e usar uma terceira parte o software open-source, Help do sistema, Deployment mode, Interfaces com sistemas externos.

Requisitos Não-Funcionais: program Accuracy, Interoperabilidade, Manutenabilidade, Performance, Portabilidade, Reliability, Responsiveness, Reusabilidade, Escalabilidade, Segurança, Survivability, Usabilidade.

Tip #17 Include time in your estimates for stated requirements, implied requirements, and nonfunctional requirements—that is, all requirements. Nothing can be built for free, and your estimates shouldn't imply that it can.

Mas o pior não são estas requisitos listados, mas sim as atividades de desenvolvimento de software e também as atividades não ligadas ao desenvolvimento que são esquecida, como:



Table 4-3: Atividades de Desenvolvimento de Software Normalmente Esquecidas nas Estimativas de Software
Ramp-up para novos membros da equipe, Mentoring para novos membros da equipe, Gerenciamento / coordenação /reuniões gerenciais, Cutover/deployment, Conversão de Dados, Instalação , Customização, Requirements clarifications, Maintaining the revision control system,
Supporting the build, Maintaining the scripts required to run the daily build,
Maintaining the automated smoke test used in conjunction with the daily build,
Installation of test builds at user location(s), Creation of test data, Management of beta test program, Participation in technical reviews, Integration work, Processing change requests, Attendance at change-control/triage meetings, Coordinating with subcontractors

Table 4-4: Non-Software-Development Activities Commonly Missing from Software Estimates
Vacations
Company meetings

Holidays
Department meetings

Sick days
Setting up new workstations

Training
Installing new versions of tools on workstations

Weekends
Troubleshooting hardware and software problems


Ação

Hoje vou experimentar este conceitos e dicas na prática e posto aqui para refletirmos.