O artigo discute o método de uso do 1C DSS (Application Design System) para avaliar a duração e o custo dos projetos usando o método COCOMOII.
Como justificar ao cliente que sua avaliação do cronograma do projeto é objetiva?
Como medir a margem de um projeto antes de começar, na fase de pré-venda?
Como avaliar a faixa de negociação ao preço do projeto para evitar perdas?
Como calcular objetivamente a necessidade de um projeto para os membros da equipe que não são desenvolvedores (analistas de negócios, metodologistas, redatores técnicos, etc.), como formalizar o resultado de seu trabalho da maneira mais simples e acessível?Sumário
- Entrada.
- O principal problema do uso do 1C DSS no momento.
- Porquê COCOMOII?
- Por que o 1C DSS?
- Curso mais curto COCOMOII
- Transição da avaliação do trabalho dos desenvolvedores para a avaliação do trabalho de analistas e metodologistas
- Pseudocódigo
- 1 DSS e pseudo-código.
- Sumário
Entrada
O 1C Application Design System foi lançado no mercado há 6 anos e, em julho de 2019, passou para a versão 2. Com base nas tecnologias da SADT e em um modelo de desenvolvimento em cascata. No entanto, permite liderar o desenvolvimento Scrum / Agile em estágios individuais.
Projetado para projetos complexos e demorados, executados por uma equipe de vários componentes, com substituição frequente de pessoal. Inclui a funcionalidade de gerenciamento de projetos, descrições de processos de negócios, design da arquitetura e funcionalidade de sistemas de informação, desenvolvimento de software e manutenção de IP, além de autoteste baseado em Vanessa / Gherkin.
Em primeiro lugar, é útil para integradores de sistemas e franqueados e, em segundo lugar, para todas as organizações que realizam desenvolvimento e manutenção independentes de seus próprios IPs com o envolvimento de artistas externos.
O principal problema do uso do 1C DSS atualmente
O principal problema do uso do 1C DSSR atualmente (a versão 1 é usada principalmente) é o uso extremamente incorreto do 1C DSS como tecnologia.
O 1C DSS é usado com mais frequência no nível de funcionalidade destinado aos desenvolvedores, na melhor das hipóteses para arquitetos. Seu papel geralmente se resume à descrição e desenvolvimento das "Funções" do sistema e à formação de tarefas para programadores. Esse é o erro da abordagem de trabalhar com o DSS.
Os sistemas existentes no mercado (JIRA, etc.) estão fazendo um excelente trabalho ao definir tarefas para programadores e processar tickets de usuário. Com esse uso, os desenvolvedores do DSS têm outro complemento burocrático demorado, que leva tempo para a codificação "pura".
O desenvolvedor fica obrigado a descrever a funcionalidade do sistema implementado / finalizado para garantir a configuração de tarefas para programadores com links para objetos de metadados ("linguagem comum" em termos de Eric Evans em seu trabalho "Design Orientado a Objetos (DDD). Estruturação de sistemas de software complexos").
Ao mesmo tempo, as tarefas da outra metade da equipe do projeto - gerentes de projetos, analistas de negócios, metodologistas são quase completamente ignoradas. Infelizmente, podemos dizer que até o próprio 1C na versão 2.0 do DSS reduziu muito a funcionalidade dessa categoria de participantes, alterando significativamente o modelo do DSS em comparação com a versão 1.0 para desenvolvedores e testadores (por exemplo: requisitos e objetos de dados foram removidos explicitamente).
No entanto, a questão do uso pleno e pleno do DSS é aguda. Neste artigo, em particular, consideraremos como a tecnologia para estimar os termos e o custo de projetos usando o método COCOMOII pode ser usada no 1C DSS.
Todo mundo quer saber quanto tempo um projeto pode ser concluído, sobre o qual o próprio cliente não pode dizer o que ele quer, e até que ponto é razoável negociar com o cliente?
E como convencer o cliente de que o tempo e o custo propostos são justificados? No entanto, o último não é prejudicial para saber por nós mesmos.
E o mais importante, como calcular objetivamente a necessidade de um projeto para os membros da equipe que não são desenvolvedores (analistas de negócios, metodologistas, redatores técnicos etc.), como formalizar o resultado de seu trabalho da maneira mais simples e acessível?
Porquê COCOMOII?
Clientes de qualquer setor preferem ter uma avaliação objetiva, razoável e geralmente aceita do custo e do cronograma do projeto. Eles gostariam de ver a conexão de seu projeto com a experiência de um integrador de sistemas em projetos anteriores. Ao mesmo tempo, um cliente raro tem uma ideia clara do resultado final do projeto, mas em projetos com o desenvolvimento de um modelo conceitual ele definitivamente não tem. E o integrador de sistemas não possui.
Como avaliar o tempo e o custo no estágio de pré-venda na ausência de informações? E no decorrer do projeto, levando em consideração as mudanças (o flagelo de todos os projetos)?
O método COCOMOII permite que você faça essa avaliação, levando em consideração a experiência acumulada do integrador de sistemas e da maneira mais simples, e prontamente, durante o decorrer do projeto, fazendo especificações de preço / prazo e justificando-as para acordo com o cliente.
Por que o 1C DSS?
O fato é que o 1C DSS se baseia na SADT e nas tecnologias de "linguagem comum" (isso é descrito em mais detalhes no meu artigo separado). É a SADT que integra o processo de modelagem com o processo de desenvolvimento baseado na "linguagem comum". Um "idioma comum" permite que você tenha uma base para calcular indicadores estimados de termos.
Curso mais curto COCOMOII
A metodologia COCOMO surgiu em 1963 em resposta à necessidade de uma avaliação rápida e descomplicada da complexidade e do timing do desenvolvimento de software nos próximos projetos. A base do modelo COCOMO e seu próximo estágio, COCOMOII, é o número de linhas de código de programa (KSLOC é um milhar de linhas de código lógico, ou seja, linhas de código que expressam uma operação). Essa base é o resultado de qualquer projeto de desenvolvimento de software, é uma espécie de quintessência do projeto.
(Lembramos que o COCOMO difere do COCOMOII, pois os parâmetros escalares da fórmula COCOMO são substituídos pela tabela de parâmetros COCOMOII, mas a essência do método permanece a mesma).
Assim, tendo a bagagem acumulada dos projetos, qualquer desenvolvedor pode ter uma avaliação básica da estrutura de cada próximo projeto. Obviamente, essa é uma estimativa muito aproximada, mas, na fase de pré-venda, essa estimativa é melhor que nada. Para esclarecer, a base do KSLOC é ajustada de acordo com uma certa fórmula aos coeficientes de refinamento. Não vamos dar a fórmula, é simples e disponível na Internet. A conclusão é que cada desenvolvedor pode desenvolver os coeficientes dessa fórmula com base em estatísticas de projetos anteriores e compará-los com os parâmetros canônicos da fórmula, ou ... não comparar e usar apenas sua própria fórmula.
A presença de uma fórmula com parâmetros indica que todos os projetos do integrador de sistemas (ou todos os projetos internos da organização) devem ser codificados e classificados de acordo com todos esses parâmetros. Quanto mais projetos na bagagem de desenvolvedores, mais projetos do mesmo tipo para um novo projeto que podem ser abertos podem ser selecionados para avaliação (filtrar projetos não essenciais), mais precisa é a avaliação.
Conhecendo o tempo gasto em um projeto concluído por unidade KSLOC (linha de código), você pode avaliar a laboriosa potencial de um projeto futuro. Se os parâmetros armazenarem dados sobre as qualificações (notas) dos funcionários empregados, você poderá obter uma estimativa de custo do projeto.
O detalhamento dos parâmetros do projeto pode ser feito a seu critério e capacidade. Quanto mais detalhes, mais estimado é o tempo e o custo do projeto futuro.
Qual KSLOG é definido no estágio de pré-venda com uma descrição imprecisa do resultado? Somente empírico do banco de dados de projetos do integrador (executor). Nesse caso, um conjunto de parâmetros do projeto pode ser usado. Se houver uma descrição precisa do resultado desejado do projeto (produto de software), um conjunto estendido de parâmetros do projeto poderá ser usado.
Esse é o objetivo do método COCOMO.
Transição da avaliação do trabalho dos desenvolvedores para a avaliação do trabalho de analistas e metodologistas
Leitores atentos e experientes exclamarão:
“Bem então! Com todos os prós e contras do método COCOMO, ele foi projetado para avaliar projetos de software. O trabalho dos desenvolvedores, programadores, pode ser digitalizado no KSLOC condicional. Mas e os analistas e metodologistas, gerentes de projeto e gerentes? E o que o 1C DSS tem a ver com isso? ”
Certo!
Portanto, a tarefa é selecionar uma base semelhante para os membros da equipe listados que permitirá que você use a técnica COCOMOII. Aqui ele entra no palco.
Pseudo código
Um dos tipos de resultados de saída de todos os projetos complexos para o design, criação e desenvolvimento de sistemas de informação são os documentos do projeto. São tarefas técnicas, documentos conceituais, descrições, instruções, registros de objetos de dados, listas de analistas, etc. O índice desses documentos, textos de conteúdo, tabelas, figuras, requisitos coletados, listas é pseudocódigo.
E é esse pseudocódigo que é uma medida dos resultados do trabalho dos membros "não programadores" da equipe do projeto - analistas, metodologistas, escritores técnicos, gerenciamento de projetos, arquiteto, designers e participantes semelhantes.
Se o projeto for enviado de acordo com os requisitos do GOST, a estrutura dos documentos do projeto será definida por esses padrões; caso contrário, ele será criado a critério do contratado ou de acordo com os requisitos do contrato com o cliente.
Um ponto interessante é que, se a equipe do projeto e o cliente decidirem acompanhar os horários e elaborarem os resultados do projeto exclusivamente usando tecnologia sem papel, como o 1C DSS será conectado a isso?
A resposta - da maneira mais direta - o DSS e o conteúdo de seus diretórios preenchidos pelo projeto serão um objeto de dados estruturado e o resultado do trabalho. O que é muito conveniente para transferir para o cliente. Todos os documentos criados durante o projeto serão anexados aos objetos de configuração do DSS.
Os documentos simplificados do projeto de saída são divididos nos seguintes grupos de pseudo-código:
- A estrutura (índice) do documento;
- Teste de documentos;
- Linha da tabela de documentos (tabela);
- Desenho (objeto gráfico).
Nos casos mais simples, para a base COCOMO, a estrutura dos documentos de saída é suficiente. Sua complexidade (o número de níveis de aninhamento), o número de linhas do índice pode servir como base para aplicar as fórmulas do método para estimar os termos e o custo de um projeto por meio de estatísticas semelhantes de projetos anteriores e da estrutura dos participantes nas equipes do projeto (não programadores). Obviamente, a inclusão de todos os tipos de pseudocódigo na base aumentará a precisão da estimativa.
Assim, o analógico KSLOC no COCOMO padrão aqui se torna o índice do documento do projeto de saída e / ou a linha de texto deste documento (cada linha de cada tabela neste documento, cada objeto gráfico). A base não deve incluir elementos de design e layout do documento.
1 DSS e pseudo-código
Surge a questão de como colocar um pseudo-código no 1C DSS.
Isso pode ser feito através do diretório "Data Objects". Um grupo separado “DOCUMENTOS DE SAÍDA” é criado, dentro dos subgrupos para cada tipo de documento, depois outro subgrupo para cada documento separado e dentro desses subgrupos como elementos de um diretório do índice do documento do projeto.
Se for tomada a decisão de incluir conteúdo de texto, tabelas, objetos gráficos dos documentos do projeto de saída na base COCOMOII, o índice do documento do projeto também deve ser feito nos grupos do diretório "Objetos de Dados" e dentro deles devem ser colocados os nomes de tabelas, objetos gráficos e parágrafos de texto.
O texto do documento do projeto em si pode ser digitado em parágrafos como o campo de texto do elemento de diretório "Objetos de Dados".
O que devemos procurar ao descrever a estrutura dos documentos do projeto de saída no livro de referência “Objetos de Dados”?
É necessário se esforçar para garantir que cada elemento do diretório "Objetos de Dados" possa ter um link para um objeto de metadados e / ou para um objeto de dados (de outros grupos do diretório "Objetos de Dados" que descrevam não a estrutura dos documentos de saída, mas outros tipos criados no projeto de dados, por exemplo: listas de analistas).
Esse design permitirá criar documentos de projeto de saída automaticamente, diretamente do 1C DSS. Isso ajudará a reduzir significativamente o tempo gasto no trabalho em equipe no projeto, especialmente em condições de mudanças constantes nos requisitos do cliente, modificações no sistema de informações, incluindo outras equipes e artistas quando for necessário recriar os documentos de saída novamente, mas, ao mesmo tempo, mantenha a coerência dos objetos e suas descrições.
Ao vincular cada elemento ou grupo do diretório “Objetos de Dados” aos Requisitos (formulados pelo cliente e pelos membros da equipe do projeto, detalhados em metadados), você pode finalmente obter um link completo dos documentos do projeto Requisitos - Objetos de metadados - Saída. No DSS 2.0, "Idéias" são equivalentes a "Requisitos".
Com o acúmulo de experiência na implementação de projetos no 1C DSS, essa estrutura de diretórios cristalizará a mesma em todos os projetos semelhantes. Portanto, para um novo projeto, basta copiá-lo. E para projetos idênticos nos resultados de saída, você pode copiar o texto (tabela).
Sumário
Integradores e organizações com um banco de dados bem desenvolvido de projetos, após auditarem os materiais de projetos anteriores, podem obter à sua disposição uma avaliação objetiva do tempo e do custo dos projetos planejados e em andamento.
Isso deve facilitar muito A) negociação com o cliente B) avaliação dos lucros esperados.