Descrição dos Ciclos de Vida da Organização
Versão do documento: 3.3, 06/07/2021
Objetivo
O ciclo de vida de um projeto é constituído de fases e atividades, que são definidas de acordo com o escopo, os recursos e a natureza (características) do projeto, visando oferecer maior controle gerencial.
A cada fase do ciclo de vida do projeto, são gerados produtos de trabalho necessários para o desenvolvimento das fases posteriores.
Essa organização em fases permite planejar o projeto, incluindo os marcos importantes para seu controle. Os marcos do projeto são os finais das fases pelas quais passa a iteração em questão. Seu planejamento é definido ao realizar-se o planejamento do projeto.
Aplicação
Esse procedimento é aplicado à Fábrica de Software da Basis Tecnologia e a todos os seus projetos de desenvolvimento de software.
Responsabilidades e Autoridades
As responsabilidades e autoridades estão descritas no item referente à descrição das atividades desempenhadas.
Ciclo de Vida
A BASIS define seu ciclo de vida padrão conforme descrito abaixo.
Iterativo-Incremental
A BASIS define que seu ciclo de vida padrão é o Iterativo-Incremental. Neste ciclo, a construção do produto ocorre em pequenos passos (iterações), que evoluem para o produto final. A abordagem prevê a organização em fases que possuem objetivos distintos. Em cada fase, são realizadas atividades em uma ordem sequencial. Para cada fase, ocorrerão tipicamente múltiplas iterações, e todas as fases podem ter iterações. O número de iterações pode variar, dependendo dos requisitos especiais do projeto.
Fases
As fases deste modelo de ciclo de vida são:
-
Iniciação: Nessa fase, o fluxo começa com a chegada de uma solicitação de proposta técnica. Essa proposta é preparada e revisada, juntamente com o Documento de Visão. A partir desses documentos, é feita uma estimativa em pontos de função seguindo as normas e regras do IFPUG. A proposta técnica deve ser atualizada com os custos e pontos estimados, e um plano de execução deve ser criado. Por fim, a proposta técnica deve ser enviada.
-
Planejamento: A fase de planejamento só é iniciada depois que a proposta técnica for aprovada pelo cliente. Uma vez aprovada, é solicitada a preparação de toda a infraestrutura e ambiente necessários para o projeto, para que em seguida seja gerado um Plano de Projeto no dentro do SGO. Esse produto passa por qualidade para que posteriormente seja coletada a aprovação do planejamento por toda a equipe.
-
Iteração: A fase de Construção é dividida em algumas subfases: Requisitos (1), Arquitetura e Design (2), Codificação (3), Testes (4) e Liberação (5). Na subfase (1), começa-se especificando os requisitos. Pode-se também, caso contratado, elaborar protótipo, realizar engenharia reversa do produto ou realizar mapeamento de processos de negócio. Eventualmente, pode-se receber as especificações do cliente e a partir delas elaborar especificações internas ou revisar os requisitos submetidos de acordo com os padrões internos de qualidade. Os requisitos são registrados e validados, e, uma vez aprovados, é gerada uma baseline destes. Casos de teste tem sua elaboração iniciada e passa-se para a subfase (2). Nela, a arquitetura do projeto é elaborada e/ou revisada, para que em seguida seja validada pelo cliente. A subfase (3) inicia-se depois que a arquitetura é aprovada pelo cliente. Nela é feita a codificação e testes unitários sobre o código desenvolvido. Em casos em que se aplicar a integração contínua, esta deve verificar também a qualidade e cobertura do código-fonte bem como o deploy do sistema em ambientes de testes. Já na subfase (4) são feitos os testes funcionais sobre o sistema por uma equipe diferente da equipe de desenvolvimento, num ambiente similar ao que o software será implantado e homologado com o cliente. O objetivo é validar se os requisitos implementados refletem as especificações. A subfase (5) começa após a baseline de código. É preparado um plano de implantação, preparado o ambiente de homologação e disponibilizado o sistema para homologação. IMPORTANTE: todas as subfases inerentes à iteração poderão ser executadas CONCORRENTEMENTE, de acordo com o planejamento feito pelo gestor junto à equipe de desenvolvimento, e respeitando as dependências técnicas entre requisitos, seu design e sua implementação. A figura abaixo mostra as fases do ciclo de vida da BASIS e as subfases em "múltiplas instancias" dentro de uma mesma iteração. As instancias podem ser divididas com base nos requisitos, num conjunto de requisitos ou então considerando todo o escopo definido.
-
Liberação: Nessa fase, realiza-se a liberação de uma versão do software ao cliente. A fase de liberação poderá ocorrer para cada iteração ou para um conjunto de iterações, de acordo com o planejamento em conjunto com o cliente.
-
Encerramento: Nessa fase, emite-se o Termo de Recebimento (provisório ou definitivo), evidenciando o aceite do recebimento do sistema. Registram-se as lições aprendidas do projeto e em seguida é realizado o fechamento interno do projeto, com procedimentos como fechamentos de repositório e remoção de acessos.
-
Monitoração e Controle: Esta fase acompanha todo o ciclo de vida do projeto após sua aprovação e tem como objetivo garantir a saúde do planejamento realizado. Caso haja desvios significativos, o gestor deverá tomar as ações cabíveis para que o projeto volte à normalidade, renegociando condições entre todos os interessados.
-
Auditorias de Qualidade: As auditorias de qualidade deverão ocorrer também durante todo o ciclo de vida para garantir que os processos e procedimentos padrões da BASIS estão sendo seguidos.
Descrição detalhada das atividades de cada fase
O mapeamento das atividades do processo padrão de desenvolvimento, com as fases do modelo de ciclo de vida, está definido no fluxo do SGO.
Alteração nas fases
Uma ou mais fases relacionadas ao ciclo de vida do projeto podem não fazer parte do escopo da Proposta. Com isso, o percentual de esforço utilizado em cada uma delas deverá ser redistribuído. Estas informações deverão constar no planejamento do projeto. Isso significa que nem todos os projetos terão todas as fases do ciclo de vida, porque depende do escopo acordado na Proposta Técnica. Além disso, o Escopo da fase de Construção também varia de acordo com o definido na Proposta Técnica.
Caso o cliente defina entregáveis específicos, já com formato próprio, o gerente de projetos tem a prerrogativa de elaborá-los no padrão fornecido, não seguindo os padrões de especificação da BASIS. Essa adaptação poderá ocorrer para os artefatos de engenharia (documento de visão, especificações de requisitos, especificações técnicas, documento de arquitetura, MER, plano de implantação e quaisquer outros documentos de engenharia aplicáveis ao projeto)
Caso o cliente/contrato não obrigue a elaboração de documento de visão, este poderá ser abdicado pelo gerente de projetos
Os testes utilizados pelo projeto são especificados em casos de testes que podem ser as próprias EPEs pois são desenvolvidas para esse fim com cenários de validação.
As evidências de execução dos testes somente são necessárias caso não se utilize testes automatizados que já possuem os resultados dos testes executados.
| Os processos organizacionais não poderão conter adaptações. |
Histórico de Revisão
| Data | Versão | Autor | Revisor | Observação |
|---|---|---|---|---|
30/01/2015 |
1.0 |
Marcelle Misrky |
Miguel Negrelli |
Versão inicial |
21/05/2015 |
2.0 |
Marcelle Mirsky |
Miguel Negrelli |
Segunda versão para adequação às alterações do SCAMPI B |
08/07/2015 |
2.1 |
Marcelle Mirsky |
Miguel Negrelli |
Correção realizada para explicitar os marcos do projeto |
12/01/2018 |
3.0 |
Cédric Lamalle |
Miguel Negrelli |
Alteração para abordar novo ciclo de vida baseado em métodos ágeis |
17/08/2018 |
3.1 |
Cédric Lamalle |
Miguel Negrelli |
Ajustes nas adaptações possíveis do Processo |
18/10/2018 |
3.2 |
Jonathan Silva do Nascimento |
Guilherme Peres |
Revisão ortográfica do documento |
06/07/2021 |
3.3 |
Cédric Lamalle |
Wilson Carlos |
Revisão da definição de marcos |
Política da Basis
Versão do documento: 4.2, 19/10/2018
Diretrizes Gerais
-
Todos os projetos e colaboradores da organização deverão executar os processos e procedimentos definidos no BASIS FOUNDATION.
-
Todos os projetos, independentemente do tamanho, deverão obrigatoriamente seguir os processos, os procedimentos e as diretrizes estabelecidos para a sua execução.
-
Os processos podem ser adaptados para cada projeto, levando-se em conta a Metodologia de Desenvolvimento de Software (MDS) dos clientes. Qualquer alteração/exclusão de atividades do processo padrão só pode ser realizada mediante aprovação do Grupo de Processos (EPG) e registro da justificativa da alteração/exclusão na tarefa do SGO.
-
Todo colaborador deverá conhecer e executar as práticas definidas pelo EPG e formalizadas no BASIS FOUNDATION. A organização, mediante sua área de gestão de recursos humanos é responsável por garantir que os colaboradores conhecem e são capacitados para executar as práticas ali definidas.
-
A aderência a estes processos é avaliada pela Equipe de Qualidade ao longo do processo definido. Qualquer adaptação necessária aos processos e procedimentos do BASIS FOUNDATION, que não aqueles já previstos em sua definição, deverão ser aprovadas pelo EPG da BASIS e/ou por sua diretoria.
-
Alterações no documento de descrição dos processos são de responsabilidade do EPG. Qualquer colaborador a qualquer momento poderá solicitar correções e adequações e/ou sugerir melhorias nos processos definidos. Para isto, deve ser registrada uma ocorrência de melhoria no SGO.
-
A BASIS tem por objetivo estratégico com a definição dos seus processos o alcance e manutenção do Nível 5 (nível máximo de maturidade) do CMMI-Dev como forma de aumentar a competitividade da empresa, garantir a entrega de produtos e serviços com qualidade, de forma diferenciada do restante do mercado. Isso trará a liderança em seu setor.
-
Gerência de Projetos e Gerência Quantitativa de Projetos: O objetivo do processo de Gerência de Projetos é estabelecer e manter planos, que definam as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. O planejamento do projeto é realizado pelo gerente do projeto e se inicia com o planejamento do processo, que significa adaptar o processo padrão da organização para o projeto específico a partir de suas características e conforme a baseline organizacional, gerada estatisticamente. A escolha dos subprocessos deve ser feita neste momento e mantida ao longo do ciclo de vida do projeto. A política organizacional para este processo estabelece a obrigatoriedade do seguimento das atividades, fluxos de trabalho, templates e subprocessos definidos no documento de descrição do processo.
-
Definição do Processo Organizacional, Desempenho de Processo Organizacional e Análise Causal e Resolução: O objetivo do processo de Definição do Processo Organizacional é estabelecer e manter um conjunto de ativos de processo organizacional e padrões do ambiente de trabalho usáveis e aplicáveis às necessidades de negócio da organização. Durante as análises quantitativa dos resultados dos projetos, a equipe de processos identifica novos subprocessos ou ajusta os existentes, considerando as análises estatísticas realizadas periodicamente. Estas análises estatísticas devem resultar em um baseline de processos para auxiliar no planejamento e na monitoração do projeto, considerando características como: utilização de ferramentas, equipe do projeto e reuso. Ao detectar pontos fora do controle e/ou fora dos limites, a análise das causas deve ser realizada para identificar as causas e corrigir os problemas ou estabelecer uma nova baseline. Planos de ação devem ser criados na ferramenta de controle de projetos. Os subprocessos e perfis de equipe identificados estão definidos na ferramenta de controle de projetos da organização. A política organizacional para este processo estabelece a obrigatoriedade do seguimento das atividades, diretrizes e fluxos de trabalho definidos no documento de descrição do processo.
-
Os processos de Gerência de Projetos e de Engenharia de Software são executados exclusivamente ao longo das fases do processo padrão de desenvolvimento da BASIS, sendo planejados/adaptados para cada projeto durante a adaptação do processo padrão para os projetos de desenvolvimento. Eles consideram todas as definições de fases e atividades definidas no Ciclo de Vida da BASIS. Maiores informações sobre os procedimentos operacionais de cada atividade ou subatividade poderá ser encontrada no fluxo de processos.
-
Gerência de Projetos: O objetivo dos processos de gestão de projetos é apoiar o estabelecimento e a manutenção dos planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto, que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. Este processo é aplicável apenas no contexto de projetos de desenvolvimento. Também é objetivo deste processo identificar potenciais problemas (riscos), antes que eles ocorram de forma que atividades de gerenciamento de riscos possam ser planejadas e executadas conforme for surgindo a necessidade durante o ciclo de vida do projeto, visando mitigar o impacto no atingimento dos objetivos dos projetos e processos. Além de estabelecer planos, os processos de gestão também têm por objetivo orientar a monitoração e controle dos projetos, de forma a proporcionar um entendimento do progresso dos projetos, que permita a criação de ações corretivas quando a performance desvie do planejado. Outro propósito é estabelecer e gerenciar o envolvimento dos stakeholders, de forma integrada, seguindo os processos padrão da organização e suas customizações. A monitoração da execução dos projetos é realizada diariamente pelos gestores destes projetos, ao longo da execução do processo do projeto, por meio do SGO, Comentários nas ocorrências dos projetos e eventuais tarefas incluídas por ajustes de desvios. Semanalmente o SGO criará um dashboard de indicadores dos projetos que deverá ser analisado pelo Gestor, devendo esse realizar uma análise e definição novas ações ou registrar ações tomadas no período vigente.
-
Requisitos: Este processo tem por objetivo desenvolver e gerenciar os requisitos do produto e dos componentes do produto do projeto, bem como suas relações e consistência com os demais planos e produtos gerados pelos projetos de desenvolvimento, na medida em que estes são transformados em produto final. Também é objetivo deste processo explicitar, analisar e estabelecer os requisitos que darão origem ao produto e/ou componentes do produto.
-
Análise e Projeto: Este processo tem por objetivo prepara uma solução técnica para os requisitos do projeto.
-
Arquitetura: O objetivo deste processo é assegurar que é feito um projeto (design de solução técnica) que irá conduzir o desenvolvimento dos produtos.
-
Análise e Decisão: O objetivo desse processo é analisar possíveis decisões críticas usando um processo formal de decisão, utilizando critérios e métodos de avaliação das possíveis alternativas de solução levantadas. Este processo é executado de acordo com as diretrizes estabelecidas para a organização. O processo formal de tomada de decisão deverá ser executado em situações que envolvam alta criticidade e/ou impacto no projeto em questão, seja ele organizacional (ex: processo de portfólio para decisão sobre as demandas entrantes, escolha de ferramentas, etc. ) ou projeto de desenvolvimento de software (decisões técnicas e arquiteturais). Por exemplo, para escolha de soluções de arquitetura, para escolha de ferramentas, para decisões que afetem o andamento do projeto e para a decisão sobre a compra, desenvolvimento ou reutilização de um componente do produto. Este processo pode ser executado por qualquer um que componha a equipe do projeto e/ou da organização.
-
Codificação: O objetivo deste processo é desenvolver o produto considerando as restrições e os requisitos ora estabelecidos e assegurar que cada produto de trabalho do processo ou do projeto atenda aos requisitos especificados.
-
Testes: O objetivo deste processo é garantir que os requisitos implementados entregues integrados e testados, de forma a atender seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido. Deve-se garantir que os componentes estejam funcionais com as unidades, levando-se em conta o ambiente tecnológico no qual a aplicação será implantada. Também é objetivo deste processo assegurar que cada produto de trabalho do processo ou do projeto atenda apropriadamente aos requisitos especificados. Visa assegurar que o produto esteja sendo desenvolvido de modo correto, apropriado e consistente.
-
Liberação: O objetivo deste processo é confirmar que um produto ou componente do produto, produzido pela execução do BASIS FOUNDATION, está em consonância com seus requisitos, com o uso pretendido quando colocado à disposição do usuário para o qual foi desenvolvido.
-
Mudança: O objetivo deste processo é gerenciar eventuais mudanças de projeto que possam ocorrer no curso da execução do processo de desenvolvimento de software.
-
Melhoria: Este processo tem por objetivo estabelecer e manter um conjunto de ativos de processo organizacional, determinar o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização no planejamento, na realização e na implantação de melhorias contínuas nos processos definidos no BASIS FOUNDATION, com base no entendimento de seus pontos fortes e fracos. O processo de melhoria é aplicável aos projetos cujo objetivo é melhorar os processos, procedimentos, metodologias, ferramentas e templates de apoio à organização na execução de suas atividades. Este processo é executado de forma organizacional e poderá impactar os projetos de desenvolvimento que utilizem a biblioteca de ativos corrente da BASIS. O planejamento desse processo é feito de acordo com o Plano do Projeto de melhoria e de acordo com os objetivos estratégicos da organização.
-
Gerencia de Recursos Humanos: O objetivo desse processo é prover a organização e os projetos com os recursos humanos adequados à execução dos projetos de software e manter suas competências consistentes com as necessidades do negócio. É importante ter em conta os benefícios para a produtividade e para os resultados dos projetos quando se pode contar com pessoal capacitado.
-
Medição: Este processo tem por objetivo definir a forma de coletar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos executados na organização e em seus projetos, como forma de apoiar o atingimento dos objetivos estratégicos organizacionais. A eficácia quanto à realização de medições pode ser verificada em função das decisões e ações tomadas pela organização como resposta à análise dos dados. O processo de medição é aplicável tanto aos projetos de desenvolvimento (indicadores de acompanhamento dos projetos) quanto ao processo organização (indicadores organizacionais). Seu planejamento e execução está de acordo com o Plano do Projeto de Melhoria vigente.
Histórico de Revisões
| Data | Versão | Autor | Revisor | Observação |
|---|---|---|---|---|
08/05/2013 |
1.0 |
Lygia Mian |
Miguel Negrelli |
Criação da versão inicial |
09/05/2013 |
1.1 |
Miguel Negrelli |
Lygia Mian |
Atualização do documento |
29/01/2015 |
1.2 |
Marcelle Mirsky |
Miguel Negrelli |
Ajustes para ficarem mais claros os textos contidos na política. |
30/01/2015 |
1.3 |
Rafael Rodrigues |
Miguel Negrelli |
Ajuste no Item Requisitos. |
30/01/2015 |
1.4 |
Rafael Rodrigues |
Miguel Negrelli |
Ajuste dos Itens Gerência de Projeto e Definição dos Processos |
30/01/2015 |
1.5 |
Rafael Rodrigues |
Miguel Negrelli |
Ajustes dos Itens Geral e Gerência de Configuração |
30/01/2015 |
1.6 |
Rafael Rodrigues |
Marcelle Mirsky |
Atualização das diretrizes de medição. |
30/01/2015 |
1.7 |
Rafael Rodrigues |
Marcelle Mirsky |
Atualização das diretrizes de treinamento |
04/03/2015 |
1.8 |
Marcelle Mirsky |
Miguel Negrelli |
Atualização das diretrizes de Gestão de Projetos, Verificação e Validação |
10/03/2015 |
1.9 |
Rafael Rodrigues |
Marcelle Mirsky |
Atualização na Política de Verificação |
12/03/2015 |
1.10 |
Rafael Rodrigues |
Marcelle Mirsky |
Atualização na Política de Qualidade |
15/03/2015 |
1.11 |
Marcelle Mirsky |
Rafael Rodrigues |
Inclusão das adaptações dos processos organizacionais |
15/03/2015 |
2.0 |
Marcelle Mirsky |
Miguel Negrelli |
Alteração significativa da política para inclusão de novas diretrizes gerais e retirada de diretrizes já contidas no BASIS FOUNDATION |
08/07/2015 |
2.1 |
Marcelle Mirsky |
Miguel Negrelli |
Alteração das diretrizes de gerencia de projetos. |
27/07/2015 |
2.2 |
Marcelle Mirksy |
Miguel Negrelli |
Alteração da política de Validação para refletir o processo atual. |
19/09/2017 |
3.0 |
Cédric Lamalle |
Miguel Negrelli |
Enxugamento da política da definição das diretrizes básicas de atuação da organização. |
24/08/2018 |
4.0 |
Cédric Lamalle |
Miguel Negrelli |
Adicionar itens relativos à Gerência Quantitativa de Projetos e Desempenho de Processo Organizacional e Análise Causal e Resolução |
08/09/2018 |
4.1 |
Cédric Lamalle |
Miguel Negrelli |
Adicionar políticas por área de processo. |
19/10/2018 |
4.2 |
Jonathan Silva do Nascimento |
Guilherme Peres |
Revisão ortográfica do documento |
Estratégia de Gerência de Portfólio de Projetos
Versão do documento: 1.0, 01/08/2018
Objetivo
O objetivo deste documento é descrever a Estratégia de Gerência de Portfólio de Projetos na BASIS
Papéis e Responsabilidades
No contexto do gerenciamento do portfólio de projetos, o Diretor Técnico é responsável por manter e monitorar o portfólio da organização, com informações fornecidas pelos gestores de projetos/contratos.
Critérios de seleção
Os critérios de qualificação, priorização e seleção que devem ser utilizados para pontuar os projetos candidatos, bem como trata-los ao longo da manutenção do Portfólio de Projetos, estão descritos na planilha de portfólio, sob controle e confidencialidade da diretoria:
Critérios de aprovação/rejeição de contratos
Os critérios para aprovação dos contratos é obter pontuação no ranking apurado nas Planilhas de Portfólio (novas oportunidades e renovações ) superior ou igual a 300 pontos. Caso a pontuação seja inferior a 300 a demanda estará rejeitada, contudo através de decisão da Diretoria da Organização devidamente justificada poderá ocorrer a aprovação da mesma. O mesmo poderá ocorrer com contratos acima de 300 pontos que poderão ser rejeitadas por questões de contexto.
Monitoração do Portfólio de Projetos
O Portfólio de Projetos é gerenciado por meio de reuniões mensais onde os gestores apresentam os dados reais de execução de seus contratos inseridos nas Planilhas de Controle Financeiro. Por se tratarem de concorrências públicas, a gestão é feita no contexto do contrato, que pode englobar mais de uma OS de execução, considerada um projeto. A manutenção ou realocação dos recursos do projeto será realizada de acordo com os indicadores coletados pelos projetos e seus limites estabelecidos na Base de Medição Organizacional. O cancelamento dos projetos no meio da vigência do contrato não é possível no contexto da organização, podendo ocorrer somente no momento da solicitação de renovação contratual.
Os critérios de priorização dos projetos para realocação de recursos ou alocação de novos investimentos são: desvios de indicadores (principalmente prazo) e multa contratual. Sendo assim tem prioridade de tratamento durante as reuniões mensais ou mesmo durante o período de monitoração os projetos que tiverem desvio de indicadores (ex: prazo) e cujo contrato estiver com risco de multa ou glosa. Esses critérios deverão ser analisados mês a mês.
| Data | Versão | Autor | Revisor | Observação |
|---|---|---|---|---|
01/08/2018 |
1.0 |
Cédric Lamalle |
Miguel Negrelli |
Versão inicial. |