Os gerentes e a equipe de funcionários técnica em a maioria de companhias são todo o demasiado rápidos selecionar métodos novos e ferramentas e proseguir para a prática moderna da tecnologia de programação. O problema é que muitos destes mesmos gerentes e povos técnicos têm uma compreensão fraca do desenvolvimento e do processo da manutenção que está sendo aplicado atualmente dentro de suas organizações. Proseguem sem uma fundação firme ou uma compreensão de onde estejam. Em conseqüência, as tecnologias novas às vezes não fornecem os benefícios que se esperam.
As companhias esforçam-se com a tecnologia de programação porque os gerentes não compreendem que uma aproximação da tecnologia de programação é uma porção de uma filosofia mais larga da gerência de qualidade total. Mesmo quando este fato é compreendido, alguns gerentes nunca conectam o conceito de kaizen, ou melhoria process contínua, às atividades do desenvolvimento do software.
Qualidade definida Deming de W. Edwards como striving para o excellence na confiabilidade e nas funções pela melhoria (process) contínua, suportada pela análise estatística das causas da falha. Se uma organização quiser melhorar a qualidade de seu software, permitindo desse modo a tecnologia de informação de melhorar o saque o negócio, deve focalizar sua atenção em melhorar o processo com que o software é desenvolvido. O ponto começar é avaliação — um a aproximação do olh-em-$$$-ESPELHO que permite gerentes e a equipe de funcionários técnica de compreender mais melhor suas forças e fraquezas do desenvolvimento do software. A avaliação process é uma primeira etapa para a criação de uma estratégia viable que sirva como um mapa de estrada para a melhoria process do software contínuo.
A avaliação process é a etapa inicial em um ciclo da transição da tecnologia que meça muitas atividades da melhoria process. O ciclo começa com a avaliação e abrange diversas outras atividades:
|
|
- a instrução — a maioria gerentes e de colaboradores do software sabe relativamente pouco sobre a tecnologia de programação. Para aumentar o nível do conhecimento da tecnologia de programação, uma organização deve desenvolver uma estratégia eficaz da instrução que seja amarrada aos resultados da avaliação process e que coordena índice e sincronismo do treinamento com projeto imediato necessite de modo que o benefício máximo possa ser alcançado.
- a seleção — da seleção define objetivos e critérios específicos para procedimentos escolhendo da tecnologia de programação, métodos, e ferramentas computer-aided da tecnologia de programação; conduz ao desenvolvimento de um mecanismo racional para custar, justificar, e adquirir estes elementos importantes da tecnologia da tecnologia de programação.
- as despesas — da justificação para procedimentos da tecnologia de programação, métodos, instrução, ferramentas do CASO, e atividades associadas da sustentação devem ser mostradas para fornecer um retorno no investimento antes que o dinheiro esteja cometido. Um modelo da justificação é usado demonstrar a linha inferior benefícios da melhoria process.
- a instalação — para instalar com sucesso tecnologias da tecnologia de programação, uma planta da transição deve ser planejada e executado. A planta define tarefas, responsabilidades, marcos miliários, e deliverables e especifica uma programação começando o trabalho feito.
- a avaliação — alguns gerentes faz mudanças para melhorar o processo do desenvolvimento, seleciona e instala a tecnologia nova, e fura então suas cabeças na areia, dedicando pouca hora à avaliação se a tecnologia está trabalhando. A etapa da avaliação inicía uma avaliação ongoing do processo da instalação da engenharia de CASE/software.
Todas estas etapas definem a estratégia da transição, e todas dependem de uma avaliação process bem sucedida.
Embora os exames informais do processo do software sejam conduzidos por muitos anos, o uso de uma avaliação process formal é relativamente novo, e não foi até que a avaliação process estêve endossada pelo instituto da tecnologia de programação (SEI) que os corporation e as agências de governo principais começaram a adotar a prática. A avaliação do processo do termo consulta ao recolhimento qualitative e quantitative da informação. Quando a avaliação process é conduzida corretamente, satisf a seus objetivos perto:
- fornecendo uma estrutura para uma examinação objetiva das práticas do desenvolvimento do software de uma organização
- indicar técnico e forças e fraquezas da gerência em uma maneira que permita a comparação às normas da indústria
- indicando a maturidade relativa do desenvolvimento do software de uma organização
- conduzindo a uma estratégia para a melhoria process e, indiretamente, à melhoria da qualidade do software
Atributos Do Processo
Para realizar estes objetivos, a aproximação process da avaliação deve ser projetada em uma maneira que sonde cada um dos seguintes atributos process:
- as políticas organizational que guiam o uso da tecnologia de programação praticam
- treinamento que suporta o uso dos procedimentos, dos métodos, e das ferramentas
- a estrutura (modelo processual) que foi estabelecida para definir um processo da tecnologia de programação
- atividades da garantia de qualidade (QA) para o software
- as tarefas da gerência de projeto que planeiam, controlam, e monitoram o trabalho do software
- métodos da tecnologia de programação que permitem que a equipe de funcionários técnica construa as aplicações de alta qualidade
- ferramentas do CASO que suportam os métodos
- metrics e medida do software que fornecem a introspecção no processo e em seu produto
Embora haja muitas aproximações process diferentes da avaliação, todos têm a mesma estrutura básica. Primeiramente, um jogo das perguntas que sondam a maturidade process é feito e respondido. As perguntas podem focalizar unicamente em edições processuais ou podem delve na aplicação da tecnologia da tecnologia de programação. As respostas às perguntas da avaliação são avaliadas e um nível process da maturidade é computado. O nível da maturidade representa o compromisso e o adherence de uma organização para soar a tecnologia de programação e as práticas do QA. Finalmente, os resultados da avaliação são interpretados e usados desenvolver uma estratégia da melhoria process. A interpretação pode ser global ou pode alvejar atributos process específicos.
Perguntas Da Avaliação
As perguntas da avaliação são projetadas permitir um assessor (quem pode ser um consultante exterior ou membros da equipe de funcionários extraídos da organização que se submete à avaliação) de recolher bastante informação para compreender a organização do software, a aplicação da tecnologia dentro dela, e o sophistication relativo da estrutura da gerência de projeto para aplicar a tecnologia. Uma aproximação eficaz da avaliação do processo da tecnologia de programação usa três tipos de perguntas: qualitative, booleano, e quantitative.
Perguntas Qualitative. As perguntas nesta categoria requerem uma explanação narrativa. Algumas perguntas qualitative são:
- como as equipes de projeto são dadas forma? Uma organização funcional ou de matriz é usada?
- quem são os clientes para o software dentro da organização?
- que é o relacionamento entre o cliente e os povos que desenvolve o software? Quem especifica inicialmente produtos com índice do software? A que grau as práticas do desenvolvimento do software são compreendidas pelo cliente? Que problemas de comunicação ocorrem entre clientes e a organização da tecnologia de programação?
- o que é o papel da garantia de qualidade, do manufacturing, e das organizações de serviço no que diz respeito ao software.
- que são as ferramentas de desenvolvimento do software individual (disponíveis como se operar características de sistema e como funções sozinhas do carrinho) usadas durante o desenvolvimento do software?
- Questions.Questions booleanos nesta categoria não elicíam um yes ou nenhuma resposta. As perguntas booleanas são usadas avaliar as seguintes três áreas:
- o projeto — faz o uso da organização do desenvolvimento do software um método específico para o projeto dos dados? Para o projeto architectural? O projeto processual é confinado ao uso das construções de programação estruturadas? Há um método definido para o ser humano - projeto da relação do computador?
- programando e codificando — é mais de 90 por cento do código escritos em uma língua high-order? As convenções específicas para a documentação do código são definidas e usadas?
- testando — são os métodos específicos usados para o projeto do caso do teste? O planeamento do teste começa antes que o código esteja escrito? Os resultados de testar são armazenados para a referência histórica? Há uns mecanismos para rotineiramente executar a regressão que testa e para assegurar-se de que as tampas testando todas as exigências do software?
Perguntas Quantitative. As perguntas nesta categoria permitem uma organização de obter a informação numérica que pode ser usada conjuntamente com o metrics do software computar custos e o payback potencial para a tecnologia nova. A seguinte informação é representativa:
- o rendimento anual relatou por um componente
- o orçamento anual para o processo de dados ou É
- orçamento anual para o desenvolvimento do software de engineering/product-oriented
- orçamento anual para o software - treinamento relacionado
- orçamento anual para a ferragem de computador
- orçamento anual para ferramentas do software (diferencie entre a ferragem e o software)
- número dos sistemas e dos practitioners do software em todas as áreas de aplicação
- o número de É pessoa pela categoria de trabalho
- número dos povos do software que trabalham em produtos e em sistemas projetados
- número atual dos contratantes exteriores que trabalham no software in-house
- porcentagem dos povos do software que trabalham na manutenção
- crescimento ou diminuição projetada para cada artigo acima mencionado
A maioria de questionários da avaliação são organizados em uma maneira que o processo específico das pontas de prova atribua (aproximação por exemplo, do software de qualidade da garantia ou da gerência de projeto); a maioria sugerem um esquema classificando para respostas de modo que as forças e as fraquezas relativas possam ser verificadas; e a maioria dirigem-se à gerência e a tópicos técnicos. A estrutura do questionário, os tipos de perguntas pediram, o esquema classificando que é proposto, e a utilidade dos resultados são determinadas pelo modelo process total da avaliação (os exemplos de que são discutidos nos modelos process “dirigidos seção da avaliação ”).
Avaliação Da Resposta
As respostas ao questionário da avaliação são avaliadas para determinar o nível process da maturidade. Embora as aproximações específicas da avaliação variem, as seguintes etapas são comuns:
- as respostas às perguntas booleanas são usadas derivar um valor de maturidade. Os valores de maturidade podem ser baseados em uma contagem simples de respostas de yes/no, em um jogo específico das perguntas que devem ser respondidas positivamente para conseguir um nível dado da maturidade, ou em um esquema tornando mais pesado que defina o nível da maturidade de uma organização que responda a uma pergunta específica positivamente.
- as respostas às perguntas quantitative são comparadas com as médias da indústria, quando disponíveis. os dados da qualidade e da produtividade são coletados, e as médias comparadas são publicadas na literatura técnica.
- as respostas às perguntas qualitative são usadas derivar a introspecção adicional no processo atual. Documentando circunstâncias e confinamentes locais, as respostas qualitative estabelecem uma linha de base para a interpretação.
Interpretando os resultados
Os valores de maturidade computados das respostas às perguntas booleanas da avaliação podem fornecer meios para desenvolver uma planta da transição para a melhoria process. Idealmente, os valores de maturidade são atribuídos a um do diversos atributos process. Na base de cada valor de maturidade, uma organização pode espesso atributos process de acordo com seus importância e impacto em esforços locais melhorar o processo. Depois que as prioridades foram atribuídas para áreas process do atributo, a interpretação começa com o objetivo de desenvolver organizationally um jogo do específico dos findings e das recomendações.
Os findings descrevem áreas específicas de força ou de fraqueza; as recomendações definem as ações requeridas para melhorar o processo do desenvolvimento do software.
Um modelo process da avaliação define a estrutura e as logísticas totais da avaliação process, a organização e a aplicação de perguntas da avaliação, os atributos do processo que são consideradas durante a avaliação, e a maneira em que a maturidade process é determinada. Os modelos da avaliação podem amplamente ser categorizados como segue:
- os modelos tornaram-se por companhias grandes e pretenderam-se originalmente para o uso interno, tal como a análise da qualidade e da produtividade do software de Hewlett-packard (SQPA) e o método da avaliação da potencialidade do desenvolvimento do software Bell Canada
- modelos desenvolvidos como um adjunct aos serviços consultando, tais como Howard Rubin Associar, R.S. Pressman & Associar, Inc., Software Produtividade Pesquisa, Inc., e muito outro
- os modelos tornaram-se por consortiums de government/industry tais como o modelo da maturidade da potencialidade do instituto da tecnologia de programação, que é sabido melhor destes
- modelos empacotados como produtos do do-it-yourself para o uso por alguma organização do desenvolvimento do software
Além, a organização de padrões internacional (ISO) está atualmente no trabalho em um padrão para que a avaliação do processo da tecnologia de programação assegure a conformidade aos padrões de qualidade do ISO 9000. No presente, nenhum modelo da avaliação encontra-se com todas as exigências propostas para o padrão da avaliação do ISO.
Uma discussão detalhada de todos os tipos de modelos da avaliação é além do espaço deste artigo. Entretanto, para fornecer uma compreensão mais adicional da aproximação da avaliação, dois modelos representativos da avaliação são considerados nas seguintes seções.
O Modelo Da Avaliação de SEI
O modelo detalhado da avaliação do instituto da tecnologia de programação é predicado em um jogo das potencialidades da tecnologia de programação que devem estar atuais enquanto as organizações alcançam níveis diferentes da maturidade process. Para determinar o estado atual da maturidade process de uma organização, o SEI usa um questionário da avaliação e um esquema classificando do fivepoint. O esquema classificando fornece uma medida da eficácia global das práticas da tecnologia de programação de uma companhia e estabelece cinco níveis process da maturidade:
- 1 nivelado: Rubrique — o processo do software é caracterizado como o anúncio hoc. Poucos processos são definidos, e o sucesso depende do esforço individual.
- 2 nivelados: Os processos — básicos repetíveis da gerência de projeto são estabelecidos para seguir o custo, a programação, e a funcionalidade. A disciplina process necessária está no lugar para repetir uns sucessos mais adiantados em projetos com aplicações similares.
- 3 nivelados: Definiu — o processo do software para a gerência e as atividades da engenharia são documentadas, estandardizadas, e integradas em um processo do software do organizationwide. Este nível inclui todas as características definidas para o nível 2.
- 4 nivelados: As medidas — detalhadas controladas do processo do software e da qualidade de produto são coletadas de modo que o processo e os produtos do software sejam quantitatively controlados. Este nível inclui todas as características definidas para o nível 3.
- 5 nivelados: A melhoria — process contínua optimizing é permitida pelo gabarito quantitative do processo e de testar idéias e tecnologias inovativas. Este nível inclui todas as características definidas para o nível 4.
Para conseguir níveis específicos da maturidade process, as perguntas selecionadas do questionário de SEI devem ser respondidas positivamente. O SEI associou as áreas process chaves (KPAs) com o cada um dos níveis da maturidade. KPAs descreve aquelas funções da tecnologia de programação que devem estar atuais constituir a prática boa em um nível particular. Através do modelo 18 KPAs da maturidade são definidos e traçados em níveis diferentes da maturidade process. As perguntas da avaliação são projetadas sondar para a existência (ou a falta) das práticas chaves que revelam se os objetivos de um KPA estiveram conseguidos.
A aproximação de SEI representa uma realização significativa na avaliação process, mas tem alguns inconvenientes. Embora a análise detalhada do questionário da avaliação possa conduzir a uma avaliação do efficacy das áreas process chaves e de práticas chaves relacionadas, o nível da maturidade sozinho diz pouco sobre KPAs individual. O nível process da maturidade é computado em uma maneira que cause uma classe baixa se as perguntas específicas estiverem respondidas negativamente, mesmo se outras perguntas que representam o sophistication razoável estão respondidas com sim. O questionário de SEI é criticado às vezes underemphasizing a importância da tecnologia e enfatizando demasiadamente a importância das políticas e dos padrões. Os consultantes que são assessores acreditados são geralmente needed fornecer o detalhe e a introspecção adicionais que falta com o questionário de SEI sozinho.
O modelo da avaliação proposto pelo SEI representa o olhar o mais detalhado no espelho para a indústria. Requer o compromisso organizational broad-based, um orçamento da avaliação nos milhares dos dólares, e a presença de assessores acreditados fazer o trabalho.
O Modelo Process Da Avaliação Do Conselheiro
O modelo process da avaliação do conselheiro permite o self - avaliação dirigida para aquelas organizações que querem começar atividades da transição da tecnologia da tecnologia de programação sem incorrer a despesa inicial substancial. Ao contrário do questionário da avaliação de SEI (que contem somente perguntas booleanas), o modelo process do conselheiro incorpora perguntas qualitative, quantitative, e booleanas. As perguntas qualitative e quantitative da avaliação seguem a estrutura discutida mais cedo neste artigo. As respostas a estas perguntas são avaliadas usando um sistema do quasi-perito que seja construído no modelo. Cada resposta ao questionário é comparada com um jogo de respostas típicas. O sistema do quasi-perito fornece um jogo dos inferences que ajudam a uma organização desenvolver os findings e as recomendações baseados na resposta.
Atributos process do endereço oito booleanos das perguntas: políticas organizational, treinamento, processo do desenvolvimento do software, garantia de qualidade, gerência de projeto, métodos da tecnologia de programação, ferramentas computer-aided da tecnologia de programação, e metrics e medida do software. As respostas às perguntas booleanas geram classes process do atributo para cada um dos oito atributos. Estes dão forma a uma pegada process da maturidade para uma organização do software.
A maioria de modelos da avaliação (dois including descritos nas seções precedentes) permite uma organização de computar sua maturidade process. A gerência deve então saber usar este número.
Tudo demasiado frequentemente, um gerente sênior se decide que um nível process específico da maturidade deve se transformar um objetivo da organização. Isto é, uma organização que tenha atualmente uma maturidade process de 1.0 é fretada com transformar-se uma organização 3.0 dentro de 24 meses. Embora não haja nada inerente errado com ajuste de objetivos process da maturidade, focalizar unicamente em melhorar o valor de maturidade process falta o ponto. Os objetivos de cada organização do desenvolvimento do software devem ser melhorar a qualidade das aplicações ele configurações, satisfer a seus clientes e usuários, e para realizar o trabalho no tempo. Melhorar a maturidade process ajuda em conseguir estes objetivos, mas não deve transformar-se o objetivo.
No general, a maturidade process (e as classes process do atributo) devem ser usadas nas seguintes maneiras:
- para alvejar áreas de força e de fraqueza
- para levantar o consciousness da gerência
- para definir as áreas em que uma investigação mais adicional (por exemplo, reuniões da avaliação com equipe de funcionários relevante) pode ser needed
- para fornecer uma comparação à indústria comum e à mais melhor prática
- para servir mais tarde como uma linha de base para o reassessment no ciclo de vida da transição
Usando a maturidade process nestas maneiras, uma organização pode estabelecer uma fundação em que a planta da transição da tecnologia é construída.
Os findings e as recomendações são derivados dos resultados da avaliação. Entretanto, é às vezes difícil interpretar os resultados da avaliação em uma maneira que aquele conduz às recomendações pragmatic para a mudança. Um self - a aproximação dirigida da avaliação deve fornecer um jogo dos guidelines inference-baseados que são amarrados aos níveis diferentes da maturidade para cada um dos atributos process sob a avaliação. Uma vez que a avaliação foi terminada, a classe da maturidade para cada atributo process está determinada. A escala da classe fornece uma indicação contínua de findings e de recomendações. Ilustrar inference-baseou guidelines, os findings da amostra e as recomendações são reproduzidas do manual de instruções process do conselheiro.
As perguntas na seção do processo da tecnologia de programação do questionário focalizam em padrões como uma maneira determinar se uma organização codified sua aproximação. Examine a classe e coloque-a no contexto das escalas da classe:
| Classifique A Escala | Identificador |
| Abaixo de 1.65 | E |
| 1.65 a 2.25 | D |
| 2.26 a 2.75 | C |
| 2.76 a 3.25 | B |
| Acima de 3.26 | A |
Interpretação:
- as classes E e D — é improvável que a organização desenvolveu uma descrição escrita de seu processo ou definiu um processo em qualquer maneira explícita.
ação de o: A organização deve criar uma estrutura esqueletal para a tecnologia de programação, isto é, um jogo das atividades, dos deliverables, dos marcos miliários, e das ações do QA que podem ser aplicadas como o software está sendo desenvolvido. Uma descrição da estrutura é necessitada então solicit comentários e recomendações dos gerentes e da equipe de funcionários técnica. Sobre o tempo, a estrutura deve reworked e mais detalhe ser adicionada até que evolua em um padrão.
- as classes C e B — a organização codified muitas das atividades associadas com o desenvolvimento do software. É provável que a mesma aproximação está aplicada através dos projetos diferentes e que o planeamento do projeto, o controle, e a garantia de qualidade do software são mais fáceis de conseguir em conseqüência. Entretanto, apenas porque os padrões existem não significa que o processo é eficaz ou caracterizado corretamente.
ação de o: Cada um dos padrões deve ser revisto para determinar se reflete a prática moderna da tecnologia de programação e se há os aspectos que podem ser aerodinâmicos ou que não trabalham bem. O tempo deve ser equipe de funcionários gastada do desenvolvimento da votação para determinar se os padrões estão sendo usados tão extensamente como estas escalas da classe implicam. As áreas técnicas específicas sem padrões podem ser determinadas revendo respostas às perguntas individuais. Pode ser de valor desenvolver uma aproximação da estrutura para uma área técnica específica (por exemplo, testar) em uma maneira similar àquela descrita no parágrafo da ação para escalas de E e de D.
As perguntas na seção das atividades do QA do questionário process da avaliação exploram a ênfase de uma organização na documentação, nas revisões, e nas outras funções do QA. Examine a classe e coloque-a no contexto das escalas da classe (alistadas na seção precedente). Se uma ou mais das classes da subseção forem significativamente diferente da classe total da seção, uma investigação mais adicional nessa área está autorizada.
Interpretação:
- as classes E e a qualidade — do software de D e as atividades necessitadas assegurá-la não são um foco preliminar dentro da organização do desenvolvimento do software. A documentação é provavelmente fraca, porque não há nenhum formato padrão para guiar colaboradores. As revisões eficazes não estão sendo conduzidas e os resultados das revisões não são aplicados para melhorar o processo. A garantia de qualidade do software não é uma atividade formalmente definida.
ação de o: A organização deve desenvolver uma planta para melhorar a documentação, as revisões, e a garantia de qualidade do software. Começando com os originais e as revisões, a primeira ação deve escolher um ou dois originais e desenvolver um formato padrão (ser breve é o mais melhor) e desenvolver então um jogo de guidelines da revisão para eles. Sobre o tempo, as ações podem broadened até que a maioria de originais importantes estejam definidos, estiverem sendo produzidos, e revistos.
- classifique C — a aproximação organizational à documentação predictable, revisões eficazes, e as atividades básicas da garantia de qualidade estão vindo junto.
ação de o: A organização deve rever respostas a cada uma das subseções para determinar que áreas necessitam a maioria de melhoria. As funções da garantia de qualidade são prováveis necessitar um rovement mais adicional do imp; se assim, focalize em estabelecer mecanismos para assegurar a conformidade com padrões da documentação e do processo. A organização pôde também broaden sua aproximação da revisão, se este pudesse ser custo feito - eficazmente. Ao mesmo tempo, as ferramentas computer-aided da tecnologia de programação devem ser empregadas para criar a documentação eficaz em uma maneira mais produtiva.
- a classe B — a organização está no estado da prática na área do QA. Entretanto, não pode usar dados quantitative analisar o processo da tecnologia de programação.
ação de o: Uma idéia considerar é um programa do fledgling no QA estatístico para o software. Por primeiros dados de coleta nos defeitos descobertos com outras atividades do QA, a organização pode trabalhar para melhorar métodos para reduzir defeitos. Pode então adquirir as ferramentas que permitirão a organização de construir mais eficazmente o software da qualidade.
A avaliação process pode ser conduzida por uma organização consultando interna, por outsiders, ou em um self - forma dirigida. Não obstante a aproximação que é escolhida, a avaliação deve ser coordenada perto É gerência.
É vital que a gerência prepara uma organização para a atividade process da avaliação antes que a atividade comece. A intenção da avaliação, e os benefícios a ser derivados dela, devem ser comunicados aos gerentes e à equipe de funcionários técnicos. Os tipos de dados da avaliação a ser coletados e o uso de dados da avaliação devem completamente ser explicados. Os resultados da avaliação devem ser compartilhados com todos os participants. Todos envolvidos devem compreender que a finalidade da avaliação é estabelecer uma base para a melhoria process, não punir ou não julgar a proficiência técnica.
Se uma organização for cometida à melhoria process do desenvolvimento do software, sua primeira etapa é avaliar o estado atual da prática da tecnologia de programação. É o gerente é recomendado:
- ajuste o estágio para a melhoria process fornecendo o treinamento preliminar na tecnologia de programação para gerentes, a equipe de funcionários técnica, e os usuários. O treinamento deve introduzir opções do processo e da tecnologia, emfatizar os benefícios da qualidade melhorada do software, e explicar o ciclo da transição da tecnologia.
- selecione um campeão local controlar a aproximação da avaliação do interior. O campeão local deve dirigir o processo da avaliação as.well.as facilita aqueles que estão conduzindo a avaliação e aqueles que estão fazendo exame da parte.
- selecione uma aproximação da avaliação que seja apropriada para a organização, seus orçamentos, e sua filosofia da gerência. Se os orçamentos forem limitados ou os consultantes exteriores não puderem ser usados, considere o uso de um self - modelo dirigido da avaliação. Se os orçamentos consultando estiverem disponíveis, empregue uma firma consultando competente para conduzir a avaliação. Se as exigências do cliente ditarem uma aproximação específica da avaliação (por exemplo, muitos contratantes do governo são incentivados a
use o assessment) do instituto da tecnologia de programação, desenvolva uma planta que permita essa aproximação de ser usada.
- determine o nível da maturidade do processo do desenvolvimento do software para a organização. O nível process da maturidade faz possível comparar a organização com a prática comum e mais melhor na indústria. Entretanto, não deve ser usado comparar grupos internos ou forçar a transição da tecnologia.
- examine os findings e as recomendações derivados em consequência dos resultados da avaliação para estar certo que refletem exatamente a organização. As recomendações devem ser realísticas.
- comece o desenvolvimento de uma planta da transição que conduza à melhoria process do software. A planta da transição descreve a estratégia da instrução, a aproximação a ser feita exame selecionando o processo muda e os melhoramentos da tecnologia, e as tarefas, os marcos miliários, e os deliverables associados com o processo e a instalação da tecnologia.
Online: 613 users browsing the articles directory
|
|