Engenharia de Software

segunda-feira, 3 de junho de 2013

SCRUM - Implantação XII

Resposta a mudanças, mais que seguir um plano

Toda mudança é bem-vinda. A equipe Scrum reconhece que a única certeza que temos em um projeto são as mudanças. Mesmo porque, não somos especialistas em todos os domínios de negócio existente, e o conceito de unicidade dos projetos nos torna flexíveis, pois ao logo do desenvolvimento podem existir divergências no entendimento, por não conhecermos a fundo o seu domínio. É durante o ciclo de vida do projeto que o time de desenvolvimento aprende sobre o domínio do negócio, em contato constante com o especialista do negócio, representante legal da empresa. Essa flexibilidade, característica fundamental das equipes ágeis, possibilita que o time responda rápido as mudanças.

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XII

Após todo esse processo o que fazer com as entidades que sobraram?

Se não deixamos passar nada teoricamente as entidades que sobram são arquivos lógicos.

Observando as informações

As perspectivas de negócio do usuário quanto aos dados é refletida em como as transações os consultam e/ou atualizam. Verifique como os processos elementares da aplicação matem essas entidades. A inclusão e exclusão conjunta de determinado grupo de entidades é um forte indicador que esse grupo deve ser considerado único arquivo lógico. A alteração de dados normalmente está direcionada apenas para uma única entidade; consequentemente, ela não é uma orientação efetiva para agrupar entidades. Identifique os processos elementares de extração que consultam essas entidades e verifique se elas também são consultadas conjuntamente.

Uma ordem de serviço (OS) de ter as informações que identificam qual cliente a solicitou, a data de entrada, o prazo estimado, seu responsável e os vários itens envolvidos em sua execução. Durante a modelagem de dados foram especificadas as entidades Ordem de Serviço e Item da OS para atender a esse requisito de armazenamento. Os processos OS-Incluir e OS-Excluir também operam sobre estas entidades. Não é possível incluir uma OS sem que os itens sejam incluídos, assim como não é possível manter um itens sem a OS.

Grande Abraço,
Gilberto Ribeiro.

Gestão de Projetos - XII

Escritório de projetos

Um escritório de projetos (Project Management Office, PMO) é um corpo ou entidade organizacional à qual são atribuídas várias responsabilidades relacionadas ao gerenciamento centralizado e coordenado dos projetos sob seu domínio. As responsabilidades de um PMO podem variar desde fornecer funções de suporte ao gerenciamento de projetos até ser responsável pelo gerenciamento direto de um projeto.

Os projetos apoiados ou administrados pelo PMO podem não estar relacionados de outra forma que não seja por serem gerenciados conjuntamente. A forma, função e estrutura específicas de um PMO depende das necessidades da organização à qual ele dá suporte.

Um PMO pode receber uma autoridade delegada para atuar como parte interessada integral e um importante deliberante durante o início de cada projeto, fazer recomendações ou encerrar projetos, ou ainda tomar outras medidas conforme a necessidade para manter os objetivos de negócios consistentes. Além disso, o PMO pode estar envolvido na seleção, no gerenciamento e na mobilização de recursos de projetos compartilhados ou dedicados.

A principal função de um PMO é dar suporte aos gerentes de projetos de diversas maneiras, que incluem mas não se limitam a:

Gerenciamento de recursos compartilhados entre todos os projetos administrados pelo PMO;
Identificação e desenvolvimento de metodologia, melhores práticas e padrões de gerenciamento de projetos;
Orientação, aconselhamento, treinamento e supervisão;
Monitoramento da conformidade com as políticas, procedimentos e modelos padrões de gerenciamento de projetos por meio de auditorias do projeto;
Desenvolvimento e gerenciamento de políticas, procedimentos, formulários e outras documentações compartilhadas do projeto (ativos de processos organizacionais) e
Coordenação das comunicações entre projetos.
Os gerentes de projetos e os PMOs buscam objetivos diferentes e, por isso, são orientados por requisitos diferentes. No entanto, todos esses esforços estão alinhados com as necessidades estratégicas da organização. As diferenças entre o papel dos gerentes de projeto e de um PMO podem incluir:

O gerente de projetos concentra-se nos objetivos especificados do projeto, enquanto o PMO gerencia as principais mudanças do escopo do programa que podem ser vistas como possíveis oportunidades para melhor alcançar os objetivos de negócios;
O gerente de projetos controla os recursos atribuídos ao projeto para atender da melhor forma possível aos objetivos do projeto, enquanto que o PMO otimiza o uso dos recursos organizacionais compartilhados entre todos os projetos;
O gerente de projetos gerencia as restrições (escopo, cronograma, custo e qualidade, etc.) dos projetos individuais, enquanto o PMO gerencia as metodologias, padrões, o risco/oportunidade global e as interdependências entre os projetos no nível da empresa.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - XII

Modelo de Estratégia de Implantação

Considerando os seguintes pontos:

Como iremos estruturar ao deliverables do WBS – Work Breakdown Structure ou EAP - Estrutura Analítica do Projeto?
A estratégia vai ser o desenvolvimento interno de toda a fábrica?
Qual o ciclo de vida a ser adotado para o projeto?
Qual a estratégia para entrega de produto a longo tempo (por partes ou tudo de uma vez?)
Quais os requerimentos do plano de qualidade do projeto?
Quais os requerimentos para estrutura organizacional do projeto?
Quais os requerimentos para o planejamento de recursos?
Quais os requerimentos para o plano de risco?
Quais os requerimentos para o comunicação do projeto?
Quais os requerimentos de envolvimento de pessoas chaves durante o desenvolvimento do planejamento?

As respostas a essas questões vão orientar a equipe responsável pela execução do produto.

Os passos para o desenvolvimento da estratégia do projeto são:

Analisar a especificação da fábrica de software, visando alinhar a estratégia de desenvolvimento do projeto.
Verificar a experiência em projetos com as mesmas características no mercado para obter informações sobre as lições aprendidas.
Definir a estrutura básica do WBS, considerando as frentes de trabalho esperada para o projeto, que mereçam destaque.
Ao definir as frentes de trabalho ou conjunto de deliverables, identificar:

O conjunto principal do produto (produto final).
Os conjuntos de apoio e secundário que são importantes para a geração do produto final.

Decidir sobre a estratégia de desenvolvimento do produto resultante do projeto, considerando:

As alternativa de desenvolvimento interno, integral ou parcial
Contratação de terceiros integral ou parcial
Aquisição de pacotes
Envolvimento de fornecedores

Contratação de pessoas que já vivenciaram projetos dessa natureza etc.

Decidir sobre o ciclo de vida a ser adotado para o desenvolvimento do projeto (podemos utilizar um ciclo de vida para cada tipo de deliverables do projeto, considerando as frentes de trabalho definidas pelas estrutura do WBS – Work Breakdown Structure).
Decidir sobre como os produtos vão ser entregues ao longo do tempo, devido às restrições de prazo e custo (a entrega do produto também está associada ao ciclo de vida selecionado para o projeto)
Definir os requisitos do plano da qualidade do projeto, como decidir sobre uso de revisões, ambientes de testes estruturados, papel do Q.A.- Quality Assurance, uso de padrões etc. (esses requisitos servem de guia para o Plano de Qualidade do Projeto);
Definir os requisitos de Plano Organizacional do Projeto em termos de: (esses requisitos servem de guia para a elaboração do Plano Organizacional do Projeto).

Uso de “Comitê de Projeto”.
Sobre “quem” é imprescindível para participar nesse comitê.
Quais formadores de opinião devem ser trabalhados.
Qual a qualificação dos recursos humanos requeridas etc.

Definir os requisitos para o Planejamento da Aquisição do Projeto em termos de: (também serve de guia para a elaboração do Plano de Aquisições do Projeto)

Tipo e qualificação de recursos
Parceiros e fornecedores
Tipos de equipamentos etc.

Definir os requisitos para o Plano de Riscos em termos de:

Pontos de atenção em função do tipo de projeto.
Indicar os riscos prováveis do projeto, conforme conhecimento de práticas do mercado.

Definir os requisitos para o Plano de Comunicação do Projeto, considerando:

Os meios usuais de comunicação e relatórios já empregado pela empresa ou em função das características da audiência.
Identificar os meios adequados em vista da cultura da empresa.

Definir qual a estratégia básica de envolvimento das pessoas chaves no projeto:

Quem da equipe do projeto deve “trabalhar”.
Quem da equipe dos stakeholders deve ser envolvido no projeto.
Como os stakeholders deverão ser envolvidos durante o planejamento do projeto e nas aprovações e homologações intermediárias, caso seja necessário.

Definir os pontos de revisão dos produtos do planejamento do projeto antes das apresentações para os stakeholders e gestor do projeto.
Definir a estratégia de homologação evolutiva dos produtos do planejamento junto aos stakeholders e gestor do projeto.
Documentar a estratégia de desenvolvimento.

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - XII

Modelo de Qualidade para Qualidade em Uso segundo a Norma ISO 9126

Esta seção define o modelo de qualidade para qualidade em uso. Os atributos de qualidade em uso são categorizados em quatro características: eficácia, produtividade, segurança e satisfação.

Qualidade em uso é a visão da qualidade sob a perspectiva do usuário. A obtenção de qualidade em uso é dependente da obtenção da necessária qualidade externa, a qual, por sua vez, é dependente da obtenção da necessária qualidade interna. Normalmente, são necessárias medidas em todos os três níveis, pois atender aos critérios para medidas internas em geral não é suficiente para garantir o atendimento aos critérios para medidas externas, e atender aos critérios para medidas externas de sub-características em geral não é suficiente para garantir o atendimento aos critérios para qualidade em uso.

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)

Grande Abraço,

Gilberto Ribeiro.

quarta-feira, 29 de maio de 2013

Gestão de Projetos - XI

Projetos e planejamento estratégico

Os projetos são frequentemente utilizados como meio de atingir o plano estratégico de uma organização. Os projetos são normalmente autorizados como resultado de uma ou mais das seguintes considerações estratégicas:

Demanda de mercado (por exemplo, uma companhia automobilística autorizando um projeto para fabricar carros mais econômicos em resposta à escassez de gasolina);
Oportunidade/necessidade estratégica de negócios (por exemplo, uma empresa de treinamento autorizando um projeto para criar um novo curso a fim de aumentar a sua receita);
Solicitação de cliente (por exemplo, uma companhia de energia elétrica autoriza um projeto de construção de uma nova subestação para atender a um novo parque industrial);
Avanço tecnológico (por exemplo, uma empresa de produtos eletrônicos autoriza um novo projeto para desenvolver um laptop mais rápido, mais barato e menor após avanços obtidos em tecnologia para memória e circuitos eletrônicos de computador) e
Requisito legal (por exemplo, um fabricante de produtos químicos autoriza um projeto para estabelecer diretrizes para o manuseio de um novo material tóxico).

Os projetos, em programas ou portfólios, são um meio de atingir metas e objetivos organizacionais, geralmente no contexto de um planejamento estratégico. Embora um grupo de projetos em um programa possa ter benefícios distintos, eles também podem contribuir para os benefícios do programa, para os objetivos do portfólio e para o plano estratégico da organização.

As organizações gerenciam portfólios com base em seu plano estratégico, o que pode ditar uma hierarquia para o portfólio, programa ou projetos envolvidos. Um objetivo do gerenciamento de portfólios é maximizar o valor do portfólio através do exame cuidadoso de seus componentes: os projetos e programas integrantes e outros trabalhos relacionados. Os componentes que contribuem menos para os objetivos estratégicos do portfólio podem ser excluídos. Dessa forma, o plano estratégico de uma organização torna-se o principal fator de orientação para investimentos em projetos. Ao mesmo tempo, os projetos fornecem feedback aos programas e portfólios através de relatórios de progresso e solicitações de mudanças que possam impactar outros projetos, programas ou portfólios. As necessidades dos projetos, incluindo as necessidades de recursos, são encaminhadas e comunicadas no nível do portfólio, o qual, por sua vez, determina a orientação para o planejamento organizacional.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - XI

Como modelar uma Fábrica de Software?

Planejamento - Fase 1

Identificação do Modelo Organizacional.
Definição do modelo de gestão e nível de maturidade. (CMMI - PMI/SCRUM)

Planejamento - Fase2

Levantamento da estrutura onde a Fábrica será implantada.
Levantamento da infraestrutura, instalações e equipamentos (estado da arte ou orçamento)

Planejamento - Fase3

Identificar os itens qualificados e ganhadores do pedido.
Determinar os objetivos de desempenho da operação.

Determinar a estrutura organizacional.
Determinar a infraestrutura operacional.
Especificação da Fábrica.

A estratégia define:

Como vamos estruturar a WBS dos produtos a serem entregues ao longo do projeto.
Qual vai ser o ciclo de vida adotado para o projeto.
Qual a melhor sequência das atividades em função das prioridades.
Quem devemos envolver desde o início do projeto.
Como os formadores de opinião vão ser envolvidos, e assim sucessivamente.

A estratégia depende também da complexidade do projeto, levando em consideração o seu porte e risco. O maior objetivo do planejamento estratégico é a redução da complexidade do projeto.

Grande Abraço,
Gilberto Ribeiro.

SCRUM - Implantação XI

Colaboração com o cliente, mais que negociação de contrato

Existia aqui uma grande queda de braço entre o time de desenvolvimento e o cliente. Com o objetivo de delinear o escopo na elaboração da proposta o time defendia a ideia de enxugar ao máximo a quantidade de funcionalidades, pois não conhecia os meandros do projeto, os seus riscos e a quantidade de mudanças que poderiam encontrar no tempo de projeto. Do outro lado o cliente forçava para colocar o máximo de funcionalidades, pois uma vez fechado o contrato não haveria mais alteração no escopo, sem a geração de custos para o projeto.

Os softwares inteligentes variam de acordo com o negócio do cliente, e são únicos. Um projeto com domínio de negócio complexo não podem seguir um cronograma rígido e cuja participação do cliente só aconteça no final.

A framework ágil tem como fundamento o envolvimento do cliente em todas as fases do projeto, para nós denominado “coautor do sistema”. Nada mais inteligente, pois é ele quem conhece o domínio do negócio e é o feedback regular e frequente do cliente que nos garantirá o sucesso do projeto.

Em um contrato não conseguimos especificar todas as complexidades dos requisitos, e refletir em um cronograma fixo os meandros, as particularidades que o domínio do negócio nos imputará ao logo do ciclo de vida do sistema, pois não somos os especialistas no negócio. Os contratos devem regular as relações entre cliente e fornecedores, norteando o modo como a equipe de desenvolvimento e o cliente trabalharão juntos, e esse foi o nosso diferencial.

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - XI

Portabilidade segundo a Norma ISO 9126

“Capacidade do produto de software de ser transferido de um ambiente para outro”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Adaptabilidade

“Capacidade do produto de software de ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Capacidade para ser instalado

“Capacidade do produto de software para ser instalado em um ambiente especificado”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Coexistência

“Capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Capacidade para substituir

“Capacidade do produto de software de ser usado em substituição a outro produto de software especificado, com o mesmo propósito e no mesmo ambiente”. (NBR ISO/IEC 9126)

A arquitetura emergente no framework Scrum garante este item da Norma ISO.

Conformidade relacionada à portabilidade

Capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à portabilidade.

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XI

Arquivos de Índice

Não possuem funcionalidade de armazenar dados ou informações de controle, portanto não podem ser ALI ou AIE.

Arquivos com Dados Consolidados

Cujo único objetivo fim é agilizar o processamento, não representam requisitos funcionais, mas sim de desempenho, requisito não funcional. Exceção se as informações não forem constituídas a partir dos dados de outras tabelas.

Requisitos não Funcionais – atributos do sistema ou ambiente do sistema.

Extensibilidade
Usabilidade
Confiabilidade
Desempenho
Escalabilidade
Reusabilidade
Capacidade de manutenção
Reutilização de código
Eficiência no desenvolvimento
Confiabilidade nos dados apresentados

Arquivos Temporários e de Passagem de Movimento

Quando sua principal intenção é transportar dados, são de fato mensagens. Neste caso o arquivo original não representa um requisito funcional de armazenamento.

Distribuição de Dados

A distribuição de dados de um mesmo grupo lógico de dados em vários arquivos físicos mantidos em localidades diferentes não é um requisito funcional, portanto não pode ser considerados um ALI ou AIE.

Visões

Não são considerados Arquivos Lógicos, pois não representam requisitos funcionais de armazenamento do USUÁRIO. (visão do negócio)

Entidade de Ligação

As entidades com apenas as chaves de duas ou mais outras entidades como atributos, definindo com isso a intersecção entre elas, representam a implementação de um relacionamento em um modelo de dados normalizado, do tipo “N:M”, não podemos classificar o resultado da intersecção como um ALI ou AIE.

Entidades não Mantidas por Processos Elementares

Não são contadas como ALI ou AIE.

Atenção: Processo Elementar é a menor unidade de atividade significativa para o usuário final.

Grande Abraço,
Gilberto Ribeiro.

segunda-feira, 27 de maio de 2013

Perfil Profissional - X

Criação de diagrama de Casos de Uso

Criamos os diagramas de Casos de Uso que servirão de base para análise do desenvolvimento do sistema.

Atualização do Glossário do Projeto

Atualizar o glossário do projeto.

Grande Abraço,

Gilberto Ribeiro.

Requisitos - XI

Softwares

“Quando um projeto de software falha, raramente a causa é técnica”.
Jim Johnson, do The Standish Group.

Tal afirmação reforça o conceito de que o problema não está na tecnologia que usamos para implementação de um sistemas, mas sim na QUALIDADE dos REQUISITOS, ou seja, o entendimento do domínio do negócio.

A raiz da maioria das falhas está na (ausência de) utilização de metodologias de desenvolvimento adequadas e como elas interagem com os stakeholders em um projeto de software, e principalmente pela dificuldade do entendimento dos conceitos básicos dos processos de negocio.

Por “metodologia de desenvolvimento” entende-se o conjunto das:

Atividades
Responsabilidades
Artefatos (documentos, diagramas, código-fonte etc.)
Orientação e boas práticas usadas para planejar, construir e implementar software.

Um METODOLOGIA estabelece um caminho único no desenvolvimento de sistemas novos ou na evolução de sistemas já existentes. Ela introduz consistência ao longo do desenvolvimento de vários projetos de sistemas, provendo uma lista de todas as atividades a serem realizadas, estabelecendo pontos de verificação para auditoria e controle do projeto.

Então vejamos algumas situações que temos de enfrentar:

“Estou precisando de um website...

Ótimo, podemos fazê-lo. Gostaria de marcar uma reunião para fazermos um briefing do que precisa, conhecer alguns detalhes de design, tipo de hospedagem...

Não, não, você não está entendendo, é pra ontem!”

IMPORTANTE:

Nem se estresse tentando definir requisitos de sistemas em prazos absurdos que não permitam o seu correto entendimento e especificação.
Sistemas não são feitos da noite para o dia, eles englobam muito mais que linhas de programação, horas de testes, manuais, documentação e treinamento fazem parte do que chamamos de software.
Se o cliente exige um prazo absurdamente curto, rediscuta ou não o faça, pois o resultado da pressa é proporcional à qualidade do resultado de sistema.
Se o cliente do projeto de sistema quer que você converse, faça levantamento de requisitos em curto espaço de tempo, com agendas apertadas, lembre-se de que você não tem como estar levantando informações e necessidades de um grupo de usuários ao mesmo tempo em que de outro, de áreas distintas, ou operações distintas.
Conhecer e dominar uma linguagem de programação é bom, mas não é tudo, assim como conhecer processos como CMMI ou MPS-BR. É preciso mais que um bom processo ou boa linguagem e bons analistas e programadores.

A necessidade de estabelecer os requisitos de maneira e de forma precisas é crítica à medida que o tamanho e a complexidade do software aumentam.

Os requisitos exercem influências uns sobre os outros, logo não podemos realizar análise de necessidades sem buscar sempre o entendimento do todo. Isso é o que chamamos de ter Visão Sistêmica de Processo, enxergar e abstrair de cada necessidade a sua implicação com as outras dentro do contexto operacional do negócio. Então, vemos que a análise de requisitos e análise de processos estão intimamente ligadas.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - X

Fundamentando o Conhecimento

Como estabelecer uma operação de software mais efetiva em termos de custo, agregação de valor ao negócio, qualidade, previsibilidade do atendimento aos serviços de desenvolvimentos e manutenção? Por onde começar o processo de implantação de gestão e de operação na área de TI? (Em especial na área de desenvolvimento de sistemas)

Gestão de Operações

Garante que os processos ocorram de acordo com padrões estabelecido, garantindo aos clientes os produtos e serviços previstos na contratação. Isso envolve planejamento prevendo estratégias para o entendimento dos diferentes domínios de negócio, sua transformação em sistema e aplicação produzindo os resultados esperados.

Operação de Software

Toda operação de software envolve custo, é preciso agregar valor ao negócio do cliente, os requisitos deve atender as necessidade do cliente e adequá-lo ao negócio, envolve também previsibilidade no atendimento aos serviços de desenvolvimentos e manutenção, garantido a continuidade da prestação de serviço.

Uma série de atividades como as listadas abaixo compõe a operação de software:

Análise da OS (Ordem de Serviço)
Especificação dos Requisitos
Desenvolvimento do Projeto
Construção do Sistema
Planejamento de Testes
Teste Unitário
Teste de Integração
Teste de Sistema
Instalação
Teste de Aceitação
Implantação
Ajustes

No modelo fabril as operações acima pertencem a disciplina Construção de Produto de Software, que fazem parte do Sistema de Gestão, podemos citar:

Gestão Estratégica
Gestão da Operação
Gestão do Projeto
Construção de Produto de Software

Aprendemos que o maior desafio neste novo cenário é manter a Fábrica de Software de forma regular e consistente ao longo do tempo, gerindo operações de software em larga escala e todas as suas variáveis e elementos que as fundamentam, e isso só será possível com um processo bem definido.

Uma empresa que pretende trabalhar com o conceito de Fábrica de Software, precisa ter fundamentado as fases clássicas do processo de engenharia de software, como:

Planejamento
Especificação de Requisitos
Projeto de especificação
Especificação física
Construção (que abrange a programação)
Implantação
Transição (passagem para produção)

Pontos de atenção na evolução contínua do modelo Fabril:

Estabelecer objetivos da manufatura de software.
Focar no produto e nos processos - Software de Prateleira e Software Customizados.
Coletar os dados sobre o processo existente - Mapeamento dos processos existentes.
Estabelecer Sistemas de controle - Modelos de gestão PMI, SCRUM e etc.
Ferramentas para apoiar o controle dos projetos.
Estabelecer controle de qualidade e círculos da qualidade.
Revisar dos padrões.

Padronizar os métodos para o desenvolvimento - Conceito de "Pronto".
Desenvolver em ambiente on-line - ex. GSD - Global Software Development.
Implantação de Plano de Capacitação para os recursos, padronizando suas habilidades.
Criação de Base do conhecimento - Bibliotecas de código-fonte.
Metodologias integradas e ferramentas de desenvolvimento.
Ferramentas para geração de código, teste e documentação.
Intregrar ferramentas com banco de dados e plataformas de desenvolvimento.
Introduzir ferramentas de apoio à reutilização.
Introduzir ferramentas de automação e design.
Introduzir ferramentas de apoio à análise de requisitos.
Integrar ferramentas em plataforma de desenvolvimento.
Aumento da capacidade das ferramentas existentes.
Transferências de métodos e ferramentas para as subsidiárias.
Evolução dos métodos e ferramentas.

Quality Assurance

Importantes recomendações visando a qualidade na codificação, focar na qualidade dos processos de desenvolvimento e programação, ao invés de remover defeito em software através de teste, ou seja, antes de enviar o resultado do desenvolvimento para a equipe de Q.A., certificar se a equipe de desenvolvimento seguiu o prescrito nos processos delineado para a área.

Alguns princípios

Eliminar qualquer especificação ou porção de código que não adiciona valores efetivos às funções do software.
Eliminar, simplificar e automatizar os processos que possam causar problemas na fase de teste.
Testar e aperfeiçoar o processo, em vez do produto.
Enfatizar o treinamento e a aplicação disciplinada e consistente de padrões.
Promover autonomia às equipes para construir e implantar a arquitetura da Fábrica de Software.
Fazer grande uso de componentes reutilizáveis.

Referências

CMMI – Capability Maturity Model Integration - principal referência em gestão de processos de software em nível mundial.
RUP – Rational Unified Process
Série ISO
PMI – Project Management Institute.
SCRUM
XP - Extreme Programming

Resumo Código de Ética dos Engenheiros de Software

Os engenheiros de software devem estar convictos a fazer do conjunto da análise, da especificação, do projeto, do desenvolvimento, do teste e da manutenção de software, uma profissão benéfica e respeitada. De acordo com o seu comprometimento com a saúde, segurança, e bem-estar do público, os engenheiros de software devem adotar os oito princípios.

Público. Engenheiros de Software devem atuar consistentemente com os interesses públicos.

Clientes e empregados. Engenheiros de Software devem atuar de modo a atender os melhores interesses dos seus clientes e empregados, consistentemente com os interesses públicos.

Produto. Engenheiros de Software devem assegurar que seus produtos e modificações relacionadas atendam os melhores padrões profissionais possíveis.

Julgamento. Engenheiros de Software devem manter a integridade e independência nos seus julgamentos profissionais.

Administração. Administradores e líderes de Engenharia de Software devem aderir e promover uma abordagem ética ao gerenciamento do desenvolvimento e manutenção de software.

Profissão. Engenheiros de Software devem desenvolver a integridade e reputação da profissão consistentemente com os interesses do público.

Companherismo. Engenheiros de Software devem ser justos e dispostos a auxiliar seus colegas.

Identidade. Engenheiros de Software devem participar do aprendizado de suas vidas valorizando a prática da sua profissão e devem promover uma abordagem ética à prática da profissão.”

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - X

Gerenciamento de programas

Um programa é definido como um grupo de projetos relacionados gerenciados de modo coordenado para a obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados individualmente. Os programas podem incluir elementos de trabalho relacionado fora do escopo de projetos distintos no programa. Um projeto pode ou não fazer parte de um programa, mas um programa sempre terá projetos.

O gerenciamento de programas é definido como o gerenciamento centralizado e coordenado de um programa para atingir os objetivos e benefícios estratégicos do mesmo. Os projetos dentro de um programa são relacionados através do resultado comum ou da capacidade coletiva. Se a relação entre projetos for somente a de um cliente, vendedor, tecnologia ou recurso compartilhado, o esforço deve ser gerenciado como um portfólio de projetos e não como um programa.

O gerenciamento de programas se concentra nas interdependências do projeto e ajuda a determinar a melhor abordagem para gerenciá-los. As ações relacionadas a essas interdependências podem incluir:

Solução de restrições e/ou conflitos de recursos que possam afetar múltiplos projetos no sistema;
Alinhamento da orientação estratégica/organizacional que afeta as metas e objetivos do projeto e do programa e
Solução de problemas e gerenciamento de mudanças em uma estrutura de governança compartilhada.

Um exemplo de programa seria um novo sistema de satélite de comunicação com projetos para o design do satélite e das estações terrestres, construção de cada uma delas, integração do sistema e lançamento do satélite.

Grande Abraço,
Gilberto Ribeiro

Métrica de Software - X

Dados de Código (Metadados)

Os requisitos de armazenamento, funcionais e não funcionais, de uma aplicação são classificados em:

Dados de Negócio
Dados de Referência
Dados de Código

Aqueles enquadrados como Dados de Código, apesar de poderem representar até metade das entidades em um modelo de dados em terceira forma normal, não devem ser considerados Arquivos Lógicos. Eles são uma implementação de requisitos técnicos e não devem influenciar no tamanho funcional da aplicação, ou seja, os pontos de função não ajustados. As transações que existem exclusivamente para a manutenção de dados de código não devem ser consideradas processos elementares, assim como os dados de código não devem ser contados como arquivos referenciados nos processos elementares que os leiam e/ou atualizem.

Exemplos: data de início e término de vigência, sigla e nome das unidades federativas e etc... Não são especificados pelo usuário, mas identificado pelo desenvolvedor em resposta a um ou mais requisitos técnicos (fase de normalização) e ainda:

Arquivos que sempre armazenam apenas uma ocorrência e cujo conteúdo de seus atributos raramente mude.

Exceção: arquivos com apenas um registro, armazenar informação de controle do negócio (parâmetro).

Em que tanto a quantidade de ocorrências quanto seu respectivo conteúdo raramente mudam.
Templates que armazenam valores padrão para alguns atributos de uma nova ocorrência de um objeto de negócio.
Com apenas um atributo. Cada ocorrência representa somente um valor válido.
Com dados que raramente mudem e que representem uma faixa de valores válidos. Tabelas com valores da mão de obra.

Dados de Código

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - X

Manutenibilidade segundo a Norma ISO 9126

“Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais”. (NBR ISO/IEC 9126)