SCRUM - Implantação XIII

Os 12 Princípios Ágeis

1. Nossa maior prioridade é satisfazer o cliente, por meio da entrega adiantada e continua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam às mudanças, para que o cliente possa obter vantagens competitivas.
3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
6. Contínua atenção à excelência técnica e com design, aumenta a agilidade.
7. O método mais eficiente e eficaz de transmitir informações para e por dentro de um time de desenvolvimento é através de uma conversa cara a cara.
8. Software funcional é a medida primária de progresso.
9. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
12. Em intervalos regulares, o time reflete em como ficar efetivo, então, se ajustam e otimizam seu comportamento de acordo.

(http://manifestoagil.com.br)

Métrica de Software - XIII

Entidades Atributivas

É a entidade dependente que estende conceitualmente outra entidade, a entidade principal, descrevendo uma ou mais de suas características e cujas ocorrências podem substituir a repetição pode substituir a repetição de um mesmo subgrupo de dados em uma única ocorrência da principal, ou seja, a entidade INDEPENDENTE, principal, em conjunto com todas as entidades dependentes que a descrevem, são contadas como um único arquivos lógico.

Na contagem quando uma ocorrência da entidade principal puder existir se o respectivo par na entidade dependente deve-se contar dois tipos de registro, sendo a entidade principal e a entidade dependente. Quando OBIGATÓRIAMENTE para cada ocorrência da entidade principal houver necessidade de uma ocorrência da entidade dependente, ou seja, uma só tem sentido para o negócio acompanhada do preenchimento da outra, deve-se contar apenas um tipo de registro, compreendendo os tipos de dados de ambas as entidades.

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - XIII

Gerenciamento de projetos e gerenciamento de operações

As operações são uma função organizacional que realiza a execução contínua de atividades que produzem o mesmo produto ou fornecem um serviço repetitivo. Exemplos incluem: operações de produção, de fabricação e de contabilidade. Embora temporários em natureza, os projetos podem ajudar a atingir os objetivos organizacionais quando estão alinhados com a estratégia da organização. Às vezes, as organizações mudam suas operações, produtos ou sistemas pela criação de iniciativas estratégicas de negócios. Os projetos exigem um gerenciamento de projetos enquanto que as operações exigem gerenciamento de processos de negócios ou gerenciamento de operações. Os projetos podem cruzar com as operações em vários pontos durante o ciclo de vida do produto, tais como:

• Na fase de encerramento de cada um;
• No desenvolvimento ou atualização de um novo produto, ou ampliação de saídas;
• Na melhoria de operações ou do processo de desenvolvimento do produto ou
• Até a venda de ativos das operações no final do ciclo de vida do produto.

Em cada ponto, as entregas e o conhecimento são transferidos entre o projeto e as operações para implementação do trabalho entregue. Isso ocorre por meio da transferência de recursos do projeto para operações perto do término do mesmo ou pela transferência de recursos operacionais para o projeto no seu início.

As operações são esforços permanentes que geram saídas repetitivas, com recursos designados a realizar basicamente o mesmo conjunto de atividades, de acordo com as normas institucionalizadas no ciclo de vida de um produto. Diferente da natureza contínua das operações, os projetos são esforços temporários.

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - XIII

Modelo de Estratégia de Implantação

A documentação da estratégia que irá guiar o planejamento do projeto pode conter, pela ordem, os seguintes itens:

1. Estrutura analítica do projeto – WBS – Work Breakdown Structure.
2. Alternativas de aquisição.
3. Ciclos de vida selecionados.
4. Estratégia de liberação de produtos.
5. Requisitos para o plano da qualidade.
6. Requisitos para o plano organizacional.
7. Requisitos para o plano de riscos.
8. Requisitos para o plano de comunicação.
9. Critérios para as estimativas.
10. Estratégia de envolvimento.
11. Necessidades de recursos.
12. Plano do planejamento.
13. Pontos de revisão do planejamento.
14. Estratégia de homologação.

Algumas sugestões práticas para a implementação de um projeto de Fábrica de Software são:

1. Selecionar um gerente de projeto com autoridade (formal e informal) e conhecimento dentro da empresa para ser o responsável pelo projeto.
2. Adotar uma abordagem incremental para a implantação da Fábrica (dificilmente se consegue implantar tudo de uma vez só).
3. Dar prioridade para:
1. •    A gestão da operação
2. •    A gestão de projeto
3. •    O processo de construção.
4. Implementar as ferramentas básicas para a automação da Fábrica, principalmente gestão de demanda.
5. Se for fazer o desenvolvimento interno de ferramentas de apoio, alocar recursos dedicados.
6. O projeto tem que ter um orçamento específico e deve haver comprometimento da empresa em seguir o planejamento.

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - XIII

Qualidade em Uso
   
“Capacidade do produto de software de permitir que usuários especificados atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso especificados”. (NBR ISO/IEC 9126)

Eficácia

“Capacidade do produto de software de permitir que usuários atinjam metas especificadas com acurácia e completitude, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Produtividade

“Capacidade do produto de software de permitir que seus usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Segurança

“Capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Satisfação

“Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Grande Abraço,
Gilberto Ribeiro.