Tipos de Projeto Análise de Negócios: Software de Melhoria e Manutenção, Berço, e Terceirização

O tipo de impactos do projeto as categorias de requisitos que provocam, analisar e comunicar em sua análise de negócios. Lembre-se, não one-size-fits-all lista existe em análise de negócios. Em vez disso, certifique-se conhecer todas as ferramentas que você tem ao seu alcance para determinar como você vai completar o seu projeto.

projetos de melhoria de software ou de manutenção

No desenvolvimento de software, manutenção de software refere-se a modificação de produtos de software após a entrega, a fim de corrigir defeitos, melhorar o desempenho ou outros atributos, ou para adaptar o produto para um ambiente modificado.

Com esses projetos, você pode implementar novas funcionalidades ou fazer melhorias de desempenho para manter software up-to-date em uma mudança, ambiente competitivo. Em outras palavras, um projeto de manutenção de software pode envolver quaisquer alterações (orproactive reativa) para softwares ou sistemas existentes.

Aqui estão alguns exemplos de projetos de melhoria e manutenção:

• Adicionando um novo recurso ou função a um sistema existente

• Implementar uma mudança de política empresarial

• Corrigindo um problema com o sistema de corrente ou de melhorar o desempenho do software operacional

• Portando (movendo componentes de software) software operacional para uma plataforma de hardware diferente

projetos de manutenção ou melhoria variam em tamanho e complexidade. Planejamento para pontos comuns em toda a linha com esses tipos de projetos é significativamente desafiando porque muitas variáveis ​​estão em jogo, mas aqui estão algumas dicas para manter em mente quando descrevendo seu plano e tempo estimativas de trabalho:

• O que se concentrar em: Passe algum tempo com foco na provocando, analisar e comunicar os requisitos funcionais e não-funcionais mais do que quaisquer outros requisitos.

• Como lidar com fast-path ou de emergência solicitações: Estes pedidos podem waylay um projeto muito facilmente se você não tiver cuidado. Para manter o seu projeto no caminho certo e no tempo, considere a criação da documentação após a implementação para salvar upfront tempo.

• Como lidar com outras solicitações importantes: Realizar uma avaliação de custo / benefício para determinar se o pedido é viável.

• Como fazer análise de múltiplos pedidos de uma única versão / iteração: Para esses projetos, você tem apenas uma chance de acertar. Realizar a análise no nível do código e construir em postos de controle para reduzir o risco de redundância, o conflito entre os pedidos, bem como a introdução de erros em produção.

  UMA checkpoint é um momento no projeto quando você rever as entregas para se certificar de que eles estão alinhados com os objetivos originais do projeto e escopo. Uma revisão do documento de requisitos funcionais antes de construir a solução é um grande exemplo de um posto de controle.

projetos off-the-shelf comerciais

As pessoas compram software comercial off-the-shelf (COTS) para economizar tempo eo custo de desenvolvimento. Uma empresa pode implementar um pacote COTS como está, personalizar o pacote, ou configurá-lo após a instalação.

O cenário ideal quando se trabalha em um projeto COTS é aquele em que você pode extrair e analisar os requisitos de negócios das partes interessadas antes de escolher um pacote. Na realidade, porém, algumas empresas comprar pacotes de software e, em seguida, perguntar a sua equipe para implementar o software após o fato.

Para projetos COTS, seu foco principal é sobre os requisitos de negócios - incluindo os processos de negócio e requisitos de dados. Você deve fazer menos trabalho em requisitos funcionais e não funcionais, a menos que você está personalizando o sistema.

Se você assumir um projeto COTS, as tarefas que você precisa para construir em seu plano de trabalho depois que você determinou a necessidade do negócio são tipicamente como se segue:

• A realização de uma análise de lacunas na funcionalidade existente para o processo de negócio a ser alterado: Através da realização de uma análise de lacunas dos objetivos, os requisitos de dados, o mapeamento de processos entre o processo atual e o processo associado com o produto COTS, e usabilidade, você pode ajudar a determinar se um produto de prateleira pode ser implementado como está ou precisa personalizações. Este processo é a como é ou como análise.

  Independentemente do tamanho do produto de prateleira, certifique-se o seu plano de trabalho dá-lhe tempo suficiente para determinar a necessidade eo impacto das personalizações ou alterações de processos operacionais. Se personalizações são necessárias, elas podem ficar caro e causar upgrades para ser demorado.

• Confirmando a solução recomendada e determinar se a personalização é necessária: Isto é o ser ou como análise.

projetos de desenvolvimento terceirizados ou off-shore

projectos de hoje geralmente incluem membros da equipe em vários locais e muitas vezes envolvem outsourcing. Estes projectos têm uma maior dificuldade e risco de falha por causa do potencialmente conflitantes cultura e comunicação normas.

As partes interessadas em diferentes locais podem impactar negativamente a dinâmica ea capacidade da equipe para todos ter uma compreensão clara das metas e direção do projeto. Muitas vezes, o planejamento formal é necessário para garantir sucesso que todo mundo é clara sobre como o esforço de análise será conduzida. Em geral, você trabalha com o negócio diretamente para compreender as suas necessidades, em vez de com os membros da equipe de desenvolvimento em outro país.

Ao lidar com projetos de desenvolvimento terceirizados ou off-shore, incluir esses tipos de tarefas em seu plano de trabalho:

• Realizar um estudo de viabilidade para dar os membros da equipe um sentimento de que eles podem realizar.

• Definir objectivos principais e medidas de sucesso para que os membros podem apontar de volta para eles durante o projeto para assegurar que eles estão no caminho certo.

• Ganhar contrato (incluindo um processo de revisão formal) para as entregas.

• Criar um glossário de projeto para todos os termos e definições adequadas.

• Documento e discutir todas as suposições, riscos e limitações.

• Definir critérios de aceitação claras para os requisitos.

• Planeje atividades de comunicação de formação de equipe com a equipe externa.

Além disso, você e sua equipe devem olhar para formas de complementar seus esforços de comunicação usando ferramentas de colaboração.

Tenha em mente que a decisão de terceirizar ou usar de desenvolvimento offshore é muitas vezes feita fora do escopo do seu projeto e seu controle. Sua equipe precisa priorizar claramente os requisitos e tomar uma abordagem para trabalhar de forma incremental em uma função ou característica de cada vez.

Porque muitas equipes de desenvolvimento offshore estão em diferentes fusos horários dos usuários e do resto da equipe, trabalhando em um pequeno subconjunto de recursos de cada vez é mais manejável do que tentar completar os requisitos para todas as funcionalidades. Trabalhando em pequenos pedaços torna mais viável para a equipe.