O Propósito do Guia SCRUM - VI

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)

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - VI

Funcionalidade segunda a Norma ISO 9126

“Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas”. (NBR ISO/IEC 9126)

A Norma ISO define como funcionalidade do sistema as funções em uso que atendam aos requisitos funcionais e não funcionais com base no domínio do negócio do cliente, o que nos serviu como definição para elaboração do Backlog do Produto.

Adequação

“Capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados”. (NBR ISO/IEC 9126)

A Norma ISO define como adequação as funcionalidades que atendam os objetivos do usuário. Esta orientação contribui para elaboração da Sprint durante o seu planejamento.

Acurácia

“Capacidade do produto de software de prover, com o grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados”. (NBR ISO/IEC 9126)

A Norma ISO define como acurácia o grau de precisão e resultados corretos, atingidos com base no domínio do negócio. A acurácia passou a fazer parte a cada entrega de release, contribuindo para os três valores do Scrum: transparência, inspeção e adaptação.

Interoperabilidade

“Capacidade do produto de software de interagir com um ou mais sistemas especificados”. (NBR ISO/IEC 9126)

A Norma define como interoperabilidade a capacidade integração do sistema em desenvolvimento com outros sistemas no ambiente em que ele irá operar, englobando sistemas operacionais e sistemas que interagem com ele, porém fora da fronteira da aplicação em desenvolvimento, mas com possiblidade de fornecimento de informações.

Segurança de acesso

“Capacidade do produto de software de proteger informações e dados, de forma que pessoas ou sistemas não autorizados não possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou sistemas autorizados”. (NBR ISO/IEC 9126)

Conformidade relacionada à funcionalidade

“Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas à funcionalidade”. (NBR ISO/IEC 9126)

Faz parte do entendimento do domínio do negócio a imersão in totum nas peculiaridades do negócio do cliente. A não observância da Norma, a empresa desenvolvedora, corre o risco infringir a legislação que regulamenta o negócio do cliente.

Grande Abraço,

Gilberto Ribeiro.

Métrica de Software - VI

ALI – Mantido dentro da fronteira da aplicação. (ex. tabelas de banco de dados atualizadas pela aplicação)

Como Identificar se é um ALI:

• É um grupo de dados reconhecido pelo usuário?
• Arquivo é mantido por algum processo elementar?
• É mantido pela aplicação que está sendo contada?

Exemplos:

• Dados das transações da aplicação.
• Segurança da Aplicação: Dados de password mantidos dentro da aplicação.
• Dados de Auditoria mantidos dentro da aplicação.
• Dados de Controle mantidos dentro da aplicação.
• Arquivos de Erros mantidos dentro da aplicação.
• Dados de Histórico mantidos separadamente dentro da aplicação.

AIE – Mantido fora da fronteira da aplicação. (ex. tabelas de banco de dados lida pela aplicação, mas atualizada em outra aplicação).

TODAS as seguintes regras devem ser aplicadas para o grupo de dados ser identificado como um AIE: 

• O grupo de dados ou informação de controle é reconhecido pelo usuário. 
• O grupo de dados é externo e referenciado pela aplicação sendo contada. 
• O grupo de dados NÃO é mantido pela aplicação sendo contada. 
• O grupo de dados é mantido em um Arquivo Lógico Interno de outra aplicação.  

Como Identificar se é um AIE: 

• É um grupo de dados reconhecido pelo usuário?
• Arquivo é mantido por algum processo elementar?
• É mantido pela aplicação que está sendo contada?
• É mantido por um processo elementar de outra aplicação?

Exemplos:

• Dados de outra aplicação APENAS Referenciados.
• Segurança da Aplicação: Dados de password mantidos fora da aplicação.
• Dados de Auditoria mantidos fora da aplicação.
• Dados de controle mantidos fora da aplicação.
• Arquivos de Erros mantidos fora da aplicação.
• Dados de Histórico mantidos fora da aplicação.

Atenção: Entender ARQUIVO como um grupo de dados logicamente relacionados e reconhecidos pelo usuário, eventualmente pode estar mapeado em um ou mais arquivo do sistema operacional ou em tabelas de banco de dados.

·         Arquivo:

1º      Grupo de dados logicamente relacionados e reconhecidos pelo usuário.

2º      Arquivo do sistema operacional.

3º      Tabelas do banco de dados.

Dois aspectos que devem ser observado quando fazemos a AFP:

• Visão do Desenvolvimento.
• Visão do Negócio.

Quando implementamos um cadastro de clientes simples, ao normalizarmos as tabelas de banco de dados (visão do desenvolvedor) nos deparamos com várias tabelas, cuja relação é de 1 para N, como telefone fixo, celular e etc. Sob a óptica do desenvolvedor teremos diversas tabelas, mas sob óptica do negócio teremos um ALI.

Visão do Negócio

 

Visão do Desenvolvedor

Visão APF = 1 ALI

Para entendermos melhor a visão de negócio basta imaginarmos a operação do negócio sem o software, com os processos manuais. Então teríamos as fichas cadastrais como arquivo ou armários onde as informações dos clientes ficariam guardadas. As fichas dos clientes são guardadas em armários distintos das fichas de pedido e assim sucessivamente de acordo com o negócio.

Quando informatizamos o negócio, os armários viram tabelas de um banco de dados, mas o que importa para APF são os armários e não as tabelas de banco de dados.

Grande Abraço,
Gilberto Ribeiro. 

Fábrica de Software - VI

Observando o movimento das empresas americanas e européias para contratação de Fábrica de Software no modelo offshore, em países como Polônia, Hungria, India, Malásia, Russia e China, constatamos a tendência do mercado mundial em implementar uma plataforma de exportação de serviços de programação e desenvolvimento de software, pode ser mais uma opção para empresas brasileira, mas temos que estar preparados.

O mercado é muito competitivo e exige certificações das empresas, como o CMMI, no Brasil ainda temos poucas empresas certificada no CMMI no nível 5. 

Dentre elas podemos citar:

• Accenture SP 2005
• BRQ SP 2006
• Ci&T SP 2007
• CPM Braxis BA 2007 e 2010
• EDS SP 2006
• EDS SP 2008
• IBM RJ 2005
• Instituto Atlantico CE 2009
• Politec DF 2006
• Spread Systems – MSA-Infor Unit MG 2010
• Stefanini SP 2005
• Tata Consultancy Services DF 2004
• Unisys MG 2005

 

Grande Abraço,

Gilberto Ribeiro.

Perfil Profissional - VI

Identificação de Risco e Restrições

Nesta fase identificamos os possíveis riscos e restrições que poderão impactar no projeto a fim de evitarmos surpresas no futuro. Podemos citar como risco de projeto, por exemplo, o prazo de entrega do sistema e como restrições as novas tecnologias, ambiente e plataformas, fatores econômicos como os custos não cobertos pelas métricas e licenças de software, incompatibilidade com sistemas existente ou com Sistema Operacional, e ainda fatores como prazos legais, indisponibilidade de recursos ou ainda rotatividade de recurso.

Produto de Entrada

Modelo V - Documento de Visão (arquivo anexo)
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VI - Glossário do Projeto (arquivo anexo)
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VIII - Lista de Requisitos funcionais
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo VIII - Lista de Requisitos não funcionais
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo XII – Documento de Arquitetura
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo IV – Plano de Gerenciamento de Requisitos
Cenários Operacionais e Matriz de Rastreabilidade

Produtos de saída

Modelo VII - Lista de Riscos
O arquivo contém o modelo do documento e instruções de preenchimento.

Modelo III - Plano de Projeto de Software
O arquivo contém o modelo do documento e instruções de preenchimento.

Grande Abraço,

Gilberto Ribeiro.