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)
O que
entendemos sobre Fábrica de Software? Qual o nosso nível de maturidade
sobre o assunto, será que basta reutilizar componentes desenvolvidos em outros
projetos para usarmos o termo Fábrica de Software, ou isto seria apenas
o antigo conceito reutilização, que é uma pequena parte que compõe o todo
complexo, e que está relacionada à operação de TI.
Uma Fabrica
de Software vai além dos conceitos simplórios e de domínio público, porém para
atendermos as suas expectativas precisamos da visão orientada para Gestão de
Operações.
Não podemos entender uma revendedora de peças de automóvel como uma fábrica de peças, nem a segunda como uma fábrica de veículos.
Outro ponto polemico é a utilização de boas práticas, baseadas em modelos de qualidade consagrados, mas que sem o conhecimento da gestão de operações de várias demandas e projetos e seus requisitos, não produzem os resultados esperados. Atribuo aqui à falta de conhecimento na implantação dos processos na Fábrica de Software.
Nosso maior
desafio neste novo cenário será aprender a manter a Fábrica de Software (ou
Fábrica de Serviços) 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.
Uma vez
absorvido todos os conceitos sobre a Fábrica de Software, vamos expandir
nossos horizontes para nichos de mercado como offshore, que tem como
objetivo a prestação de serviço para as empresas globalizadas e também como
implementar uma plataforma de exportação de serviços de programação e
desenvolvimento de software.
Nos próximos
textos faremos uma viagem conceitual formando a base, os pilares da Fábrica de
Software.
O conceito
de FÁBRICA DE SOFTWARE surgiu em 1980 e foi aplicado em escala comercial em
1993, em São Paulo.
Pasmem mas
no período de 1960 a 1990, a área de software, não era vista como uma operação
que necessitava de gerenciamento, melhoramento contínuo, com a responsabilidade
de dar retorno para a empresa. A globalização foi a grande responsável pela
transformação do senário que perdurou por três décadas.
Influenciado
pelo novo conceito de Fábrica, e com os resultados positivos, surge o conceito
de “Outsourcing de Sistema”, que é, ou pelo menos deveria ser, uma operação de
desenvolvimento e manutenção de software terceirizada com alguns atributos de
uma operação fabril.
Da
abrangência do termo Fábrica de Software, derivam conceitos que são partes
integrantes da totalidade, como o SPL – Software Product Line, cujo objetivo é
criar uma manufatura de software aos moldes de uma linha de montagem de
automóveis, o que vem a resolver a questão da Fábrica de Componentes. Começamos
aqui a dissecar o sistema, cuja complexidade se resume no termo Fábrica de
Software. Este conceito tende a disseminação à medida que as novas plataformas
de ambientes distribuídos forem generalizadas e novas ferramentas de apoio ao
desenvolvimento surjam também com o passar do tempo.
Com a disseminação das práticas da Gestão da
Qualidade Total, começou um forte movimento nos EUA, para introduzir esses
conceitos na gestão do software. Este movimento deu origem ao modelo de
maturidade de software CMMI – Capability Maturity Model Integration, hoje a
principal referência em gestão de processos de software em nível mundial. Na
dinâmica do mercado surgiram também diversos outros modelos como o ERP –
Enterprise Resource Planning, como a ASAP, o RUP – Rational Unified Process, os
modelos ISO 9000-3, ISO 15504 e o modelo do PMI – Project Management Institute.
Em termos de adoção no mercado, a quantidade de
empresa é muito insignificante ainda, mas o assunto está bem disseminado nas
empresas e no meio profissional o que vem mudando o cenário no mercado
brasileiro e mundial. Quem nunca ouviu falar em Fábrica e Software ou modelos
de gestão como CMMI, RUP, ISO e outros? Mas quantas empresas fazem uso? Será
que isto é de fato um diferencial?
Derivando dos processos mais elaborados, surgem as
“metodologias leves”, pois não precisam do rigor dos processos voltados para
ambientes estruturados.
Metodologias leves, também conhecidas popularmente
como metodologia ágil, como:
- XP - Extreme Programming
- SCRUM
- ASD – Adaptive Software Development
- LD – Lean Development
Ficamos parados durante 20 anos com a análise
estruturada e a essencial, sem nenhuma novidade até o surgimento da análise
orientada a objetos. Sofremos ainda com a disparidade na evolução das
plataformas de software e os processos de gestão. A complexidade do desenvolvimento
de software para plataformas distribuídas aumentou. Requisitos não funcionais
como segurança, compliance[1] entre outros fazem parte do novo cenário.
A responsabilidade para solucionar este problemas
passa para o desenvolvimento orientado a componentes, por métodos de projetos
de arquiteturas de software e de investigação de legados, objetivando a
descoberta de possíveis componentes candidatos a SPL – Software Product Line.
Vamos explorar no próximo texto o atual cenário das operações de software.
[1] Compliance – é o conjunto de disciplinas para fazer cumprir as normas legais e
regulamentares, as políticas e as diretrizes estabelecidas para o negócio e
para as atividades da instituição ou empresa, bem como evitar, detectar e
tratar qualquer desvio ou inconformidade que possa ocorrer.
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
O
que torna uma operação de software ágil é o planejamento das atividades
pertinentes as disciplinas de Engenharia de Sistemas, o que é diferente de
Engenharia de Software, quando a equipe sabe o que fazer com base nos processos
bem definidos e praticados na empresa, garantimos a qualidade na linha de
produção, ao passo que sem planejamento perdemos a agilidade no processo
de desenvolvimento de sistema, e sempre estaremos voltando a estaca
zero, isso sim é engessar o processo.
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
Processo de Suporte
Até
o momento podemos entender que Fabrica de Software é um modelo de
desenvolvimento de sistemas inspirado na linha de produção, modelo fabril, com
toda a complexidade pertinente ao modelo como as instalações, a infraestrutura
tecnologia, os processos e ferramentas, a estrutura organizacional, o sistema
de gestão, a capacitação, a garantia da qualidade e a gestão de projetos, não
basta só reutilizar componentes, ou os ativos da fábrica, pois a reutilização é
o resultado do processo produtivo e não o fim, compõe a base de conhecimento do
modelo e é aí que tornamos o processo lucrativo para empresa, o cliente paga
pelos ATIVOS gerados pela fábrica e a cada projeto mais ATIVOS são gerados,
reutilizados e contabilizados com patrimônio da empresa.
ATIVOS - Entender como ativos os componentes, “as peças”
desenvolvidas em um projeto que poderemos reaproveitar em outros sistemas,
conceito de OBJETOS, é um termo contábil que expressar o conjunto de bens, valores, créditos, direitos e assemelhados
que forma o patrimônio.
Não
podemos entender uma revendedora de peças de automóvel como uma fábrica de
peças, nem a segunda como uma fábrica de veículos.
Outro
ponto polemico é a utilização de boas práticas, baseadas em modelos de
qualidade consagrados, mas que sem o conhecimento da gestão de operações de
várias demandas e projetos e seus requisitos, não produzem os resultados
esperados.
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 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)
Entendemos
que não é nenhuma novidade, o conceito de FÁBRICA DE SOFTWARE e que
surgiu em 1980 e foi aplicado em escala comercial em 1993, em São Paulo,
mudando também o conceito de gestão, melhoria contínua, com a responsabilidade
gerar lucro para a empresa no processo de operação de software, conceitos que
não eram vistos como necessários até então. Nesta trajetória surge o conceito
de “Outsourcing de Sistema”, que é, ou pelo menos deveria ser, uma operação de
desenvolvimento e manutenção de software.
SPL
– Software Product Line
Cujo
objetivo é criar uma manufatura de software aos moldes de uma linha de montagem
de automóveis, o que vem a resolver a questão da Fábrica de Componentes.
Começamos aqui a dissecar o sistema, cuja complexidade se resume no termo Fábrica
de Software. Este conceito tende a disseminação à medida que as novas
plataforma de ambientes distribuídos sejam generalizadas e novas ferramentas de
apoio ao desenvolvimento surjam também com o passar do tempo.
Gestão
da Qualidade Total
Deu
origem ao modelo de maturidade de software CMMI – Capability Maturity Model
Integration, hoje a principal referência em gestão de processos de software
em nível mundial. Na dinâmica do mercado surgiram também diversos outros
modelos como o ERP – Enterprise Resource Planning, como a ASAP, o RUP –
Rational Unified Process, os modelos ISO 9000-3, ISO 15504 e o modelo do
PMI – Project Management Institute.
Resumo do Código de Ética de Engenharia de Software
Como as demais profissões reconhecidas, a Engenharia de Software também já possui a definição de um Código de Ética, resultante dos esforços de uma equipe de trabalho multinacional liderada pela IEEE/ACM.
Está-se buscando a identificação da Engenharia de Software, e este código confere identidade à profissão.
Não
se pretende que os profissionais apenas o conheçam, mas sim que o
utilizem no sentido de desenvolver a cultura da responsabilidade dos
engenheiros de software em relação à sociedade. A sociedade, por sua
vez, está empenhada em obter qualidade nos produtos e nos serviços, o
que se cristaliza na adoção de leis como o código do consumidor, criando
uma cultura favorável a ética nos negócios.
A cultura ética impõe alto grau de responsabilidade, mas facilita a tomada de decisões, contribuindo para o desenvolvimento de uma sociedade mais humana.
1. A Ética na Engenharia de Software
[GOT99] divide a ética pode em três níveis, onde:
- No Primeiro Nível se encontram todas as obrigações compartilhadas pela humanidade, como integridade, justiça, lealdade, moral;
- No Segundo Nível estariam as preocupações gerais de todas as profissões, como maiores cuidados com o bem-estar social, e
- No Terceiro Nível os padrões inerentes a cada profissão, constantes no seu código de ética.
O Código de Ética e de Práticas Profissionais de Engenharia de Software, proposto como um padrão para ensino e prática de engenharia de software, documenta as obrigações éticas e profissionais para engenheiros de software.
O código deve ensinar sobre que padrões a sociedade espera deles, o que seus pares se esforçam para obter, e sobre o que esperar uns dos outros. Ainda, o código deve informar ao público sobre as responsabilidades que são importantes para a profissão de engenheiro de software.
O Código de Ética para Engenharia de Software se propõe a ser um guia para membros da profissão emergente de engenharia de software. O código foi desenvolvido por uma equipe de trabalho multinacional com apoio de outros profissionais da indústria, governo, milícia e educação.
No código foram tratados todos os aspectos inerentes a área de engenharia de software, considerando a importância do ambiente ético não só durante a fase de desenvolvimento, mas também, com igual responsabilidade, na manutenção do software. A qualidade da manutenção depende do profissionalismo do engenheiro de software, porque a manutenção é normalmente examinada sob um aspecto somente, enquanto um novo desenvolvimento é revisto de modo geral e em um nível corporativo. [ROG99]
2. Razões para adotar o Código de Ética de Engenharia de Software
- Serve de inspiração para o ideal da profissão
- Normaliza os procedimentos, facilitando a tomada de decisões
- Serve para educar engenheiros formados e aspirantes a assumir padrões de qualidade no seu trabalho
- Serve para educar administradores sobre como devam ser as leis e qual o nível de responsabilidade sobre os efeitos e impactos dos produtos desenvolvidos
- Serve para educar o público sobre quais são as práticas aceitáveis na profissão
- Deve suportar profissionais quando precisem se opor contra quem esteja agindo de forma inconsistente com o código
- Incentiva a disciplina e determinação em relação aos quesitos mínimos a serem observados na profissão
- São usados para elevar a imagem da profissão junto ao público.
Os produtos de software estão presentes em toda a sociedade moderna, também no Brasil, e avaliamos que é importante fazer reconhecida a profissão de Engenharia de Software. Podemos adotar também no Brasil este código, desenvolvido por uma equipe de profissionais de diversos ramos e países, aprovado pela IEEE/ACM, com conteúdo universal e bem adaptado às necessidades brasileiras.
3. Código de Ética e Práticas Profissionais de Engenharia de Software
O Código contém oito Princípios relativos ao ambiente e a decisões feitas por profissionais de engenharia de software, incluindo praticantes, educadores, administradores, supervisores e elaboradores e políticas, bem como estagiários e estudantes da profissão. Os Princípios identificam os relacionamentos eticamente responsáveis dos quais os indivíduos, grupos e organizações participam e as obrigações primárias referentes a estes relacionamentos. As Cláusulas de cada Princípio são ilustrações de algumas das obrigações incluídas nestes relacionamentos. Estas obrigações estão fundamentadas na humanidade dos engenheiros de software, especialmente aos cuidados dedicados às pessoas afetadas pelo trabalho de engenheiros de software, e nos únicos elementos da prática de engenharia de software. O Código prescreve estas obrigações de qualquer um que deseja ou aspira ser um engenheiro de software.
Não é sua intenção que as partes individuais do Código sejam usadas isoladamente para justificar erros de omissão ou delegação. A lista de Princípios e cláusulas não é exaustiva. As Cláusulas não devem ser lidas como divisoras do aceitável e inaceitável na conduta profissional em todas as situações práticas. O Código não é um simples algoritmo ético que gera decisões éticas. Em algumas situações, padrões podem gerar tensão entre si ou em relação a outras fontes de padrões. Estas situações requerem que o engenheiro de software use julgamento ético para agir de um modo que seja mais consistente com o espírito do Código de Ética e Práticas Profissionais, dadas as circunstâncias.
Tensões éticas podem ser mais bem dimensionadas pelo uso inteligente de princípios fundamentais, em vez de cegas dependências em regulamentações detalhadas. Estes Princípios devem influenciar engenheiros de software a considerar amplamente que é afetado por seu trabalho; para examinar se os mesmos e seus colegas estão tratando outros seres humanos com respeito; para considerar como o público, se razoavelmente bem informado, pode ver suas decisões; para analisar como o menos favorecido será afetado pelas suas decisões; e para considerar quando seus atos seriam julgados importantes para o ideal profissional trabalhando como um engenheiro de software. Em todos estes julgamentos, é primário levar-se em consideração a saúde, segurança e bem-estar do público; ou seja, o “Interesse Público” é o centro deste Código.
O contexto dinâmico e de demanda de engenharia de software requer um código que seja adaptável e relevante para novas situações na medida em que ocorrem. Entretanto, mesmo nesta generalização, o Código provê suporte para engenheiros de software e administradores de engenheiros de software que necessitem tomar ações positivas num caso específico documentando um caso ético da profissão. O Código auxilia a definir as ações que são eticamente impróprias para serem solicitadas para um engenheiro de software ou um time de engenheiros de software.
O Código não é simplesmente para julgar a natureza de atos questionáveis, também tem uma função educativa muito importante. Como este Código expressa o consenso da profissão em questões éticas, é um meio para educar tanto o público, quanto aspirantes à profissão, sobre as obrigações éticas de todos os engenheiros de software.”
3.1. Resumo dos Princípios
Segundo [ROG99]:
“A versão resumida do código sintetiza aspirações em um nível de abstração muito alto. As cláusulas que estão incluídas na versão completa dão exemplo e detalhes de como estas aspirações mudam o modo como agimos como profissionais de engenharia de software. Se as aspirações, os detalhes podem se tornar legalistas e tediosos; sem os detalhes, as aspirações podem parecer de alta importância, mas vazias de significado real; juntas, as aspirações e os detalhes, forma um código coeso.
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.”
Analisando os princípios, observa-se que logo o primeiro, do público, está de acordo com a aspiração maior do profissional, que não se limita a executar com perfeição o seu trabalho, mas sim, que o seu trabalho sirva para o bem público, de acordo com o pensamento ético universal. Assim também são universais os princípios sexto (profissão), sétimo (coleguismo) e oitavo (identidade).
O segundo princípio, relativo a clientes e empregados, está de acordo com as leis brasileiras de defesa do consumidor e também com os primeiros princípios elaborados para a empresa e seus empregados desde o início do século XX.
Com o terceiro, podemos associar também a lei brasileira de defesa do consumidor, no que se refere à qualidade dos produtos. É muito importante também constar do código de ética o aspecto das modificações, característica própria dos produtos de software, que estão em constante evolução e devem garantir não somente o atendimento de solicitações do cliente, mas a sua satisfação com a qualidade da manutenção.
Buscando os itens do quarto princípio no Anexo I, onde se encontra o código de ética completo, compreende-se melhor o princípio do julgamento, que previne o profissional para assinar somente documentos para os quais esteja habilitado, não participar de práticas financeiras impróprias, subornos, duplo faturamento, manter objetividade profissional com respeito a qualquer software ou documento relacionado que seja chamado a avaliar.
Observamos, porém que o profissional pode ser prejudicado pelas intenções do próprio cliente, que por sua vez pratica irregularidades. Cabe ao profissional de Engenharia de Software manter-se íntegro, e evitar tais práticas. Precisamos de um público melhor informado, precisamos divulgar as experiências em que os princípios éticos se mostrem eficazes para a expansão de negócios que geram retorno de investimentos enquanto proporcionam bem-estar, para o desenvolvimento desta cultura da ética.
Muito importante também o quinto princípio, sobre a administração. O profissional que assume responsabilidades como administrador deve ter em mente que as suas decisões afetam seus subordinados e o destino das empresas. Se o exemplo de administração não observa a ética profissional, o nível de comprometimento dos subordinados decresce, e a credibilidade é afetada no seu todo.
Fases no movimento Fabril
Como mudar
da forma artesanal para uma ciência, conhecida com Engenharia de Software:
- Métodos e ferramentas padrão.
- Apoio para automatização do desenvolvimento.
- Planejamento disciplinado, análise e controle de processos.
- Códigos e componentes reutilizáveis.
A evolução
para Fabrica de Software:
Fase 1 –
Organização Básica e Gerência da Estrutura (meados de 60 e início de 70)
- Objetivos da manufatura de software são estabelecidos.
- Foco no produto é determinado.
- Começa a coleta de dados sobre o processo.
Fase 2 –
Customização da Tecnologia e Padronização (início de 70)
- Objetivos dos sistemas de controle são estabelecidos.
- Métodos padrões são estabelecidos para o desenvolvimento.
- Desenvolvimento em ambiente on-line.
- Treinamento dos recursos para padronizar as habilidades.
- Bibliotecas de código-fonte são introduzidas.
- Começam a ser introduzidas metodologias integradas e ferramentas de desenvolvimento.
Fase 3 –
Mecanização e suporte ao processo (final dos anos 70)
- Introdução de ferramentas para apoio ao controle de projetos
- Introdução de ferramentas para geração de código, teste e documentação.
- Integração de ferramenta com banco de dados e plataformas de desenvolvimento
Fase 4 –
Refinamento do Processo e Extensão
- Revisão dos padrões.
- Introdução de novos métodos e ferramentas.
- Estabelecimento de controle de qualidade e círculos da qualidade.
- Transferências de métodos e ferramentas para as subsidiárias.
Fase 5 –
Automação Flexível
- Aumento da capacidade das ferramentas existentes.
- Introdução de ferramentas apoio à reutilização.
- Introdução de ferramentas de automação e design.
- Introdução de ferramentas de apoio à análise de requisitos.
- Integração de ferramentas em plataforma de desenvolvimento.
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 QA, certificar se a equipe de desenvolvimento
seguiu o prescrito nos processos delineado para a área.
Alguns
princípios como:
- 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.
Devem ser
aplicados no processo de desenvolvimento.
Terceirização de Serviços
Quais
as principais razões para as empresas (de manufatura) utilizarem serviços
terceirizados em tecnologia da informação - TI?
Estudos
realizados em Terceirização em Informática no Brasil e Terceirização em informática
sob a ótica do prestador de serviço, publicado pela revista de Administração de
Empresas, LEITE, J. C., São Paulo, foram abordados diversos aspecto, dos quais
retirei as principais considerações:
- Acesso imediato a novos recursos, necessidade para concentrar-se nas atividades fins, busca por eficácia e redução de custo representam os motivadores principais para o processo de terceirização.
- Excelência e qualidade do parceiro, filosofia de trabalho (processo de operação e serviço), preço, idoneidade, solidez a longo prazo e disponibilidade de serviços diversificados são considerados os itens principais para a tomada de decisão de selecionar os prestadores de serviço.
- Manutenção de equipamentos, treinamento, programação, desenvolvimento e manutenção de sistemas representam os seguimentos mais terceirizados.
- Controle de qualidade, custos, prazos, sigilos, segurança e falta de padrão dos terceiros são algumas das principais preocupações em um processo de terceirização.
No
estudo relacionado às empresas prestadoras de serviço de tecnologia da
informação, com amostragem de 15 empresas líderes de mercado, observou:
- Há uma polarização na oferta de serviços, em termos de diversificação e focalização.
- Os principais mecanismos de acompanhamento dos serviços prestados mais comuns são reuniões periódicas com cliente e relatórios da empresa prestadora de serviço.
- 70% das empresas utilizam metodologias próprias para o controle e qualidade dos serviços.
- Qualidade dos serviços e capacidade de customização são os dois principais fatores críticos de sucesso da operação de prestação de serviço.
A Fábrica de Software de Evans
Outro
conceito que enriquece nosso estudo é o da Fábrica de Software de
Evans, que por sua vez a denomina, Ambiente de Engenharia de Software de
4ª Geração.
Evans
propõe nesse modelo que o ambiente de software enxergue o processo de
engenharia como uma linha de montagem. Essa linha e montagem tem como
objetivo o ciclo de vida do desenvolvimento (o processo produtivos), que
interage com processos de garantia da qualidade do produto, suporte
automatizado para o desenvolvimento e gestão do ambiente e com os
processos de gestão propriamente ditos.
As características básicas desta fábrica são:
- O processo é padronizado, ou seja:
- Documentado
- Praticado
- Medido
- E as pessoas são treinadas para operá-lo.
- A capacidade de atendimento é planejada juntamente com o cliente, considerando um período mínimo de um ano.
- A plataforma de desenvolvimento é totalmente automatizada.
- Há uma sistemática de Planejamento e Controle de Produção, com controle rigoroso da alocação dos recursos.
- Flexibilidade de ambiente.
- Recursos humanos são flexíveis, à medida que cada programador domina pelo menos 3 (três) linguagens de programação.
- Há controle de qualidade e de metas, inclusive controle estatístico de processos e gráficos de Pareto para identificar a maior incidência de defeitos por tipo.
- As versões de programas são controladas por suporte automatizado.
- Os tempos de ciclo de produção da fábrica e o tempo de codificação são padronizados, considerando o tipo de linguagem e a complexidade do programa a ser construído.
- As metas de desempenho em termos de atendimento dos tempos padrões, produtividade individual dos programadores e nível de defeitos são controladas.
- Há projetos de melhoria contínua do processo em função dos resultados das metas de desempenho.
- A Fábrica opera em várias localidades separadas geograficamente, utilizando o mesmo processo padrão.
- O recebimento de especificações do cliente e o envio do programa codificado são feitos por meio eletrônico, inclusive pela internet.
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.
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.
- 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.”
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
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.
Processos da Fábrica
Modelo de Estratégia de Implantação
Considerando os seguintes pontos:
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:
A documentação da estratégia que irá guiar o planejamento do projeto pode conter, pela ordem, os seguintes itens:
Algumas sugestões práticas para a implementação de um projeto de Fábrica de Software são:
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.
- 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.
Processos da Fábrica
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.
A documentação da estratégia que irá guiar o planejamento do projeto pode conter, pela ordem, os seguintes itens:
- Estrutura analítica do projeto – WBS – Work Breakdown Structure.
- Alternativas de aquisição.
- Ciclos de vida selecionados.
- Estratégia de liberação de produtos.
- Requisitos para o plano da qualidade.
- Requisitos para o plano organizacional.
- Requisitos para o plano de riscos.
- Requisitos para o plano de comunicação.
- Critérios para as estimativas.
- Estratégia de envolvimento.
- Necessidades de recursos.
- Plano do planejamento.
- Pontos de revisão do planejamento.
- Estratégia de homologação.
Sugestões Práticas para a Implementação
Algumas sugestões práticas para a implementação de um projeto de Fábrica de Software são:
- Selecionar um gerente de projeto com autoridade (formal e informal) e conhecimento dentro da empresa para ser o responsável pelo projeto.
- Adotar uma abordagem incremental para a implantação da Fábrica (dificilmente se consegue implantar tudo de uma vez só).
- Dar prioridade para:
- • A gestão da operação
- • A gestão de projeto
- • O processo de construção.
- Implementar as ferramentas básicas para a automação da Fábrica, principalmente gestão de demanda.
- Se for fazer o desenvolvimento interno de ferramentas de apoio, alocar recursos dedicados.
- O projeto tem que ter um orçamento específico e deve haver comprometimento da empresa em seguir o planejamento.
Planejamento da Implantação
O
planejamento da implantação da Fábrica deve seguir alguns passos e gerar um Plano
do Projeto. A entrada principal para o planejamento da implementação da
Fábrica de Software é constituída por suas especificações técnicas e pela
estratégia de desenvolvimento.
O planejamento do projeto deve considerar os seguintes passos:
O planejamento do projeto deve considerar os seguintes passos:
- Definição do WBS do projeto.
- Definição das atividades para geração de cada produto previsto para ser entregue pelo projeto (exemplo: instalação dos servidores, procedimento documentado de controle de qualidade etc.).
- Definição sobre precedência entre as atividades.
- Estimativa de prazos e recursos.
- Estimativas de custo.
- Elaboração do plano da qualidade.
- Elaboração do plano organizacional.
- Elaboração do plano de aquisição de recursos.
- Elaboração do plano de riscos.
- Elaboração do plano de comunicação.
- Elaboração do cronograma do projeto.
- Elaboração do orçamento de custo do projeto.
- Elaboração dos critérios de controle do cronograma, custo e escopo.
- Consolidação do Plano do Projeto.
WBS do projeto da Fábrica de Software
O WBS do projeto define os entregáveis do projeto.
O WBS do projeto define os entregáveis do projeto.
Um
projeto de Fábrica de Software geralmente tem os seguintes entregáveis:
- Instalações Físicas
- Imobiliário
- Projeto de Rede
- Servidores
- Softwares
- Cabeamento
- Dispositivo de Rede
- Ferramentas do Processo de Construção
- Processo de Gestão do Projeto
- Ferramentas do Processo de Gestão do Projeto
- Processo de Gestão da Operação
- Ferramentas do Processo de Gestão da Operação
- Processo de Suporte
- Ferramenta de Processo de Suporte
- Processo de Gestão Estratégica
- Ferramentas de Processo de Gestão estratégica
- Organização Funcional
- Organização Matricial
- Organização Projetizada
- Organização Composta
- Gestão de Demanda
- Gestão de Desempenho
- Gestão do Projeto
- Gestão Financeira
- Processos e Ferramentas de Comunicação
- Processos e Ferramentas de Gestão de Projeto
- Processos e Ferramentas de Gestão de Operação
- Processos e Ferramentas de Suporte
- Processos e Ferramentas de Processos Estratégicos
- Plano da Garantia da Qualidade
- Relatórios da Garantia da Qualidade
- Plano do Projeto
- Controle do Cronograma
- Controle do Custo
- Controle da Qualidade
- Controle do Escopo
Definição das Atividades e Precedências
Com base no WBS
definimos as atividades requeridas para a geração de cada fase ou
produto. Por
exemplo, as atividades básicas para elaboração do produto Plano de
Capacitação deve ser elaborado e supervisionado pelos recursos seniores
da empresa:
- Preparação do programa de treinamento
- Validação do programa
- Desenvolvimento do material de treinamento
- Validação do material de treinamento
- Programação do treinamento e sua logística
- Execução do treinamento
- Avaliação do treinamento
É necessário o
estabelecimento de pontos de controle para a avaliação do progresso do projeto.
Geralmente, são atividades de verificação e validação de produtos críticos para
o sucesso do projeto. São produtos que estão no caminho crítico do projeto.
Prazos e Recursos
Prazos e recursos são estimativa interligadas e concorrentes no projeto. O uso de recursos influenciam nos nos prazos estabelecidos para as atividade no planejamento do projeto, assim como restrições relacionado a prazos geralmente influenciam na qualidade de recursos do projeto,
Estima PRAZOS implica em obter informações sobre:
As entradas acima servem de insumos para a elaboração do cronograma.
Estimativa de RECURSOS determina:
A métrica acima é fundamental para o sucesso do projeto.
Como determinar o custo?
Com base no tempo de uso do recurso ou sua quantidade consumida nas atividades do projeto.
Fatores considerados nas estimativas:
Prazos e recursos são estimativa interligadas e concorrentes no projeto. O uso de recursos influenciam nos nos prazos estabelecidos para as atividade no planejamento do projeto, assim como restrições relacionado a prazos geralmente influenciam na qualidade de recursos do projeto,
Estima PRAZOS implica em obter informações sobre:
- Escopo
- Recursos
- Duração das atividades
As entradas acima servem de insumos para a elaboração do cronograma.
Estimativa de RECURSOS determina:
- Pessoas
- Equipamentos
- Materiais
- Serviço
A métrica acima é fundamental para o sucesso do projeto.
Como determinar o custo?
Com base no tempo de uso do recurso ou sua quantidade consumida nas atividades do projeto.
Fatores considerados nas estimativas:
- Envolver a equipe na estimativa projeto, a visão técnica é fundamental.
- Envolver os profissionais seniores nas estimativas é uma boa prática adotada no mercado.
- Envolver especialista no negócio, que conheça de fato o domínio do negócio, para aprimorar as estimativas. Caso a empresa não tenha esse profissional, a prática é buscá-lo no mercado.
- Usar a base de conhecimento da empresa, pois mantém os histórico dos projetos implementados.
- Evitar comprometer-se com pedidos de estimativas fora da realidade.
- Procurar não fazer estimativas sem os subsídios da Especificação Técnica da Fábrica.
- Considerar os riscos pertinentes ao projeto.
- Aplicar a estratégia definida para o desenvolvimento do projeto.
- Planejamento de folgas para que a ocorrência de trabalho não atrase o projeto.
- Definir premissas sobre a qualidade de recursos e fornecedores.
- Analisar os recursos considerando:
- pessoas
- máquinas
- ferramentas
- softwares
- serviços internos
- serviços externos
- instalações físicas
- recursos de comunicação
- Considerar os fatores de produtividade conhecidos para a realizar as estimativas.
- Utilizar uma técnica para a estimativa de prazo.
- Adequar as estimativa de prazo as expectativas do cliente, revisando as atividades, as estratégias de desenvolvimento e ao escopo do projeto, oferecendo propostas alternativas e realistas.
- A base de conhecimento do seu relacionamento profissional é também de grande valia.
Nenhum comentário :
Postar um comentário