Criação de software: como você pode avaliar seu projeto e ser mais produtivo?

A avaliação e o cálculo de custos do projeto de software, em especial o tamanho, o esforço, o custo e o tempo envolvidos, geralmente são fonte de discussões animadas entre os avaliadores de software. Os gerentes de projeto geralmente são responsáveis por essa atividade.

O desenvolvimento de software envolve várias atividades diferentes que exigem conhecimento especializado, principalmente nas seguintes áreasEntre elas estão a coleta, a análise e o gerenciamento de requisitos; o projeto, a codificação e a verificação e validação independentes (IV&V) do software; a implementação, a implantação, a instalação e o comissionamento. Cada uma dessas atividades é realizada por uma pessoa qualificada, usando várias ferramentas de diferentes graus de complexidade.

Ver todos os software Software Vendor

O que é produtividade? Definição

A produtividade é definida como a taxa de produção para determinados insumos. A produtividade é expressa como "tantas unidades de produção por dia" ou "tantas unidades de produção por hora". A produtividade também é definida como a relação entre insumos e produtos.

No contexto deste artigo, a produtividade refere-se à taxa de produção de uma unidade de saída usando um conjunto de insumos, em um determinado período de tempo.

Problemas na avaliação do tamanho do software

No atual setor de TI, há várias unidades para medir o tamanho de um software. Essas unidades incluem, por exemplo, pontos de função, pontos de caso de uso (UCP), pontos de objeto, pontos de funcionalidade, pontos de Internet, pontos de teste, análise de ponto de função (FPA), linhas de código (LOC) e assim por diante. Não existe uma medida estabelecida para converter o tamanho do software em nenhuma dessas unidades.

Estranhamente, nessas medições, o tamanho do software é ajustado (aumentado ou diminuído), dependendo de fatores como a complexidade. No entanto, o tamanho é um caráter imutável. Por exemplo, um quilo de queijo não se torna mais pesado ou mais leve se a pessoa que o pesa tem mais ou menos experiência em pesagem, ou se a balança é mecânica ou eletrônica. Vejamos outro exemplo: um quilômetro continua sendo um quilômetro, quer seja um jovem ou um idoso caminhando essa distância, ou se a distância for medida em uma rodovia ou em uma rua movimentada.

Entretanto, a velocidade com que os resultados são obtidos muda. Se considerarmos os exemplos acima, a pessoa idosa certamente percorrerá o quilômetro mais lentamente do que a pessoa mais jovem. Além disso, percorre-se um quilômetro mais rapidamente na autoestrada do que na cidade.

Além disso, não há consenso sobre como contar os LOCs. Devemos contar proposições lógicas ou físicas? E como a documentação on-line deve ser tratada? Ela deve ser levada em conta ou não?

Esses são alguns dos principais problemas associados à avaliação do tamanho de um software.

Preocupações com a produtividade

O setor de publicação de software está obcecado com a possibilidade de declarar uma taxa única e empírica de produtividade, abrangendo todas as atividades.

Foram feitas tentativas de definir a produtividade como 10 pessoas-hora por ponto de função, enquanto a unidade pessoa-hora por ponto de função pode ser definida como uma unidade de produtividade.A unidade pessoa-hora por ponto de função pode variar de 2 a 135, dependendo do tamanho do produto, da equipe e de outros fatores. "Definir a produtividade" significa atribuir um valor que represente o esforço necessário, expresso em pessoas-hora, para desenvolver uma unidade de tamanho de software, de modo que o tamanho do software (em pontos de função) possa ser convertido em esforço de desenvolvimento (em pessoas-hora). Às vezes, são escolhidos intervalos, por exemplo, de quinze a trinta horas por PCU. Em outras ocasiões, fórmulas empíricas são criadas com base em um conjunto de fatores, como no caso do "modelo de custo construtivo" (COCOMO).

O problema com essas medidas de produtividade é que elas combinam todas as atividades - análise de requisitos, projeto, revisão, teste etc. - em uma única medida. - em uma única medida. No entanto, as habilidades necessárias para essas tarefas são diferentes, assim como as ferramentas usadas e as entradas e saídas. Agrupá-las sob o título de "desenvolvimento de software" e fornecer uma única medida de produtividade só pode fornecer uma estimativa muito aproximada, e nunca precisa.

Projetando software melhor e mais rápido: como você pode se tornar mais produtivo?

O desenvolvimento de software envolve as seguintes atividades:

• Atividades de preparação do projeto, incluindo estudos de viabilidade, orçamento financeiro e validação do projeto (aprovação financeira e técnica e "lançamento do projeto")
• Atividades de lançamento do projeto, como a identificação do gerente de projeto, a criação de uma equipe de projeto e a configuração do ambiente de desenvolvimento; planejamento do projeto; estabelecimento de vários protocolos, como acordos de nível de serviço e procedimentos de relatório de progresso; treinamento do projeto
• atividades de engenharia de software, incluindo análise de requisitos do usuário; análise de requisitos de software; projeto de software, codificação e teste de unidadediferentes tipos de testes de integração, funcionais, negativos, de sistema e de aceitação; preparação de documentação
• atividades de implantação, incluindo instalação de hardware e sistema; criação de banco de dados; instalação de software aplicativoinstalação do software aplicativo; teste piloto; treinamento de usuários; fase paralela e implantação real
• atividades de encerramento do projeto, incluindo documentação de boas e más práticas; análise do projeto (fim do projeto); arquivamento de arquivos; publicação de recursos; liberação do gerente de projeto das obrigações; início da manutenção do software.

Quando falamos sobre as "regras básicas" do setor (procedimentos aceitos e de bom senso) para produtividade, é difícil determinar quais atividades estão incluídas na taxa de produtividade. Ninguém apostaria em medir a produtividade, embora essa seja uma regra básica do setor.

Vamos dar uma olhada na natureza dessas atividades:

1. Análise de requisitos: compreender e documentar o que o usuário precisa, deseja e espera para que os projetistas de software compreendam totalmente e possam projetar um sistema em estrita conformidade com os requisitos declarados. A dependência de fatores externos é alta.
2. Projeto de software: considerar as diferentes opções disponíveis de hardware, software de sistema e plataforma de desenvolvimento; chegar à escolha ideal para cada um; projetar uma arquitetura que atenda aos requisitos declarados e às expectativas do cliente. A arquitetura deve ser compatível com as tecnologias atuais e o projeto deve ser documentado de forma que os programadores entendam e forneçam um produto que esteja em conformidade com as especificações originais do usuário. Há várias alternativas e, como o design de software é uma atividade importante e estratégica, os erros podem ter consequências graves.
3. Codificação: desenvolvimento de código de software que esteja em conformidade com o design e contenha o menor número possível de erros (é muito fácil deixar bugs inadvertidamente).
4. Revisão de código: estudar o código escrito por outro programador, decifrar sua funcionalidade e tentar prever os erros que o cliente poderá encontrar ao usar o software.
5. Teste: tentativa de descobrir quaisquer falhas que possam ter sido deixadas no software. Entretanto, é impossível encontrar quase todos os defeitos. Além disso, testar o software em sua totalidade é uma atividade impraticável.

Como a natureza dessas atividades é muito diferente, é óbvio que a produtividade de cada uma delas não é uniforme (e, portanto, não pode ser descrita pela mesma figura). O ritmo de trabalho é diferente para cada uma dessas atividades.

Elas não dependem da quantidade de código produzido, mas de outros fatores, como :

1. requisitos, que dependem da eficiência e da clareza de sua fonte (usuários ou documentação)
2. projeto, que depende da complexidade do processo, das alternativas disponíveis e das restrições sob as quais a funcionalidade deve ser projetada
3. revisão do código, que depende do estilo de codificação
4. verificação, que depende de como o código é escrito (quanto mais erros houver, mais tempo será necessário para testar e retestar)
5. a própria codificação, que depende da qualidade do projeto

Como resultado, precisamos estabelecer diferentes índices de produtividade para cada uma dessas atividades.

Vamos tentar traçar um paralelo para o setor, por exemplo, com a perfuração. As atividades a serem realizadas são: 1) configuração da máquina; 2) configuração das ferramentas; 3) carregamento do trabalho; 4) perfuração do furo; 5) rebarbação do furo; 6) limpeza; 7) entrega da folha para a próxima operação.

Se vários furos forem feitos, o tempo "por furo" diminui, porque as atividades de configuração são atividades únicas.

Portanto, se considerarmos a codificação de uma unidade, por exemplo, as atividades a serem executadas poderiam ser: 1) receber as instruções; 2) estudar o documento de design; 3) codificar a unidade; 4) testar e depurar a unidade para a funcionalidade específica; 5) testar e depurar a unidade para qualquer uso; 6) testar e depurar a unidade para qualquer uso; 7) testar e depurar a unidade para qualquer uso.6) remover o código desnecessário da unidade; 7) testar a regressão da unidade; 8) transferir a unidade para o próximo estágio.

Da mesma forma, podemos propor microatividades para cada fase de desenvolvimento de software.

Números de produtividade: empíricos ou baseados em um estudo metódico?

Cada uma das atividades acima tem uma taxa de sucesso diferente. É necessário estabelecer tempos padrão para cada uma dessas atividades. Feito isso, as técnicas de estudo de trabalho, como a síntese ou a estimativa analítica, devem ser usadas para estimar a duração total da tarefa.

Independentemente de as técnicas de estudo de tempo serem usadas para realizar estudos de produtividade individuais ou para coletar dados empíricos, o desenvolvimento de software não é totalmente mecânico nem totalmente criativo. Também não é realista planejar atividades com um forte componente criativo; os métodos de estudo de trabalho levam em conta esse aspecto do desenvolvimento de software. Muitas pesquisas estão sendo feitas sobre "produtividade executiva", e talvez métodos para "cronometrar" a produtividade no desenvolvimento de software estejam disponíveis no futuro. No momento, os dados empíricos parecem ser a solução preferida.

Onde podemos obter dados empíricos? A primeira opção é por meio de estudos de lead time que usam técnicas de engenharia industrial. A outra maneira, que é mais fácil e mais confiável, é confiar nos dados históricos fornecidos pelas planilhas de horas.

A maioria dos softwares de gerenciamento de tempo usados pelo setor é orientada para folha de pagamento e faturamento. Eles não coletam dados no nível mais baixo para estabelecer tendências de produtividade. A maioria desses softwares registra dois ou três níveis de dados, além de data e hora. Um projeto é sempre registrado no primeiro nível, e o segundo e o terceiro níveis podem ser ocupados por um módulo e um componente, um componente e uma atividade ou uma combinação semelhante. Além da data e da hora em que o funcionário está presente, as planilhas de horas devem registrar cinco níveis de dados: o projeto, o módulo, o componente, a fase de desenvolvimento e a tarefa executada. Dessa forma, os dados estariam disponíveis para estabelecer medidas de produtividade de forma empírica e realista.

Atualmente, as atividades de desenvolvimento de software se concentram na macroprodutividade. Essa tendência precisa mudar, e precisamos passar da macro para a microprodutividade. Para isso, precisamos mudar nosso software de registro de horas e a profundidade dos dados que coletamos.

O estudo da produtividade em nível micro tem as seguintes vantagens:

• Melhor previsibilidade do desenvolvimento de software
• Estimativas de melhor qualidade para melhorar os preços durante as fases de desenvolvimento e finalização do projeto
• Estabelecimento de objetivos mais precisos ao alocar tarefas, o que aumenta a confiança dos editores de software
• Estimativas de custo mais precisas

Ver todos os software Software Vendor

Conclusão

É importante entender a diferença entre os termos produtividade e capacidade. Produtividade é a taxa de sucesso de uma microatividade; capacidade é a taxa de sucesso de uma instalação (fábrica, organização etc.), e várias atividades estão incluídas no diagrama de capacidade. Para fins de avaliação de software, o foco deve mudar da macroprodutividade (capacidade) para a produtividade (para a microatividade). A coleta de dados empíricos é preferível para obter medidas de produtividade para as diferentes atividades de desenvolvimento de software, pois as técnicas de estudo de tempo e tarefas não podem fornecer um quadro completo da produtividade.A coleta de dados empíricos é preferida para a obtenção de medidas de produtividade para as diversas atividades de desenvolvimento de software, pois as técnicas de estudo de prazos e tarefas não podem fornecer resultados satisfatórios quando a missão apresenta um alto grau de criatividade (que é o caso da publicação de software). Para coletar dados empíricos, é necessário aprimorar o software de registro de tempo. Recomendamos esse procedimento para calcular os números de produtividade em todos os níveis micro.

Sobre os autores

Murali Chemuturi é especialista em engenharia industrial da Indian Institution of Industrial Engineering. Ele passou mais de trinta anos em organizações profissionais, incluindo ECIL, TCS, Metamor e Satyam. Trabalhou primeiro em manufatura e depois em TI. Atualmente, dirige a Chemuturi Consultants e tem um interesse especial em software para o setor de desenvolvimento de software. Ele conduziu vários programas de treinamento na empresa para gerenciamento de projetos de software e avaliação de software.

Sarada Kaligotla concluiu seu mestrado em aplicativos de computador e é certificada como Project Management Professional (PMP) pelo Project Management Institute (PMI) e como Certified Software Quality Analyst (CSQA) pelo Quality Assurance Institute (QAI). Atualmente, ela trabalha para a Blue Cross Blue Shield em Massachusetts. Sarada tem seis anos de experiência no setor de software, bem como em gerenciamento de projetos e desenvolvimento.