UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU EM ENGENHARIA DE PRODUÇÃO PRODUÇÃO EM ESCALA DE PROGRAMAS DE COMPUTADORES (FÁBRICA DE SOFTWARES) Por: Manoel Carlos Josué de Almeida Orientadora Prof. Ms. Ana Cristina Guimarães Rio de Janeiro 2005
2 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU PROJETO A VEZ DO MESTRE PRODUÇÃO EM ESCALA DE PROGRAMAS DE COMPUTADORES (FÁBRICA DE SOFTWARES) Apresentação de monografia à Universidade Candido Mendes como condição prévia para a conclusão do Curso de Pós-Graduação Lato Sensu em Engenharia de Produção. Por: Manoel Carlos Josué de Almeida
3 AGRADECIMENTOS Agradeço a minha esposa Maria Luiza Matos de Almeida e a minha Mãe Eny Josué de Almeida pelo o apoio e a dedicação, e aos meus filhos Paulo Rafael Matos de Almeida e Rafaele Matos de Almeida pelo carinho e compreensão.
4 DEDICATÓRIA Dedico esse trabalho a Deus, meu Pai e Criador, Onipotente e presente em todos os dias de minha vida e aos meus familiares pela compreensão e carinho. Aos meus professores, orientador e a UCAM.
5 RESUMO O uso crescente de programas e sistemas especialistas tornou claro que o sucesso depende diretamente de sua adequação completa às necessidades particulares de cada negócio. A fim de que as organizações possam extrair o máximo das tecnologias do momento, muitas vezes são necessárias aplicações desenvolvidas sob medida, levando em conta seus processos e seu ambiente tecnológico. A modalidade de Fábrica de Software visa exclusivamente projetar, desenvolver e implantar soluções completas, que vão desde simples sites institucionais até sistemas complexos integrando várias plataformas (sistemas legados, aplicações Java, ambientes Diversos, etc...) e oferecendo acesso por vários canais (browsers, PDA's, terminais de auto-atendimento, integração sistema-a-sistema). Para implementar os processos de manufatura na produção de Software em grande escala, são utilizados os conceitos de engenharia industrial, de operações e da gestão de qualidade total.
6 METODOLOGIA Para a elaboração deste trabalho fora aplicada uma metodologia de pesquisa através de seleção bibliográfica, onde foi consultado: Internet, livros e Revistas Técnicas na qual o tema Fábrica de Software é extremamente abordado.
7 SUMÁRIO INTRODUÇÃO 08 CAPÍTULO I - O que é Software 09 CAPÍTULO II - Construção de uma Fábrica de Software 22 CAPÍTULO III - Implantando a Fábrica de Software 27 CONCLUSÃO 34 REFERÊNCIAS 35 ÍNDICE 36 FOLHA DE AVALIAÇÃO 38
8 INTRODUÇÃO O conceito de Fábrica de Software no cenário brasileiro começou a ser aplicado em escala comercial, a partir de 1993 no mercado de São Paulo. Entre 1960 e 1990, não havia processo disciplinado para o desenvolvimento de Software, o qual era em sua totalidade artesanal. Hoje, o conceito de Fábrica de Software já está totalmente difundido no mercado brasileiro, inclusive com fábricas dispersas geograficamente pelo país e pelo mundo que utilizam o mesmos processos operacionais. Segundo a empresa GSBNET, a Fábrica de Software surgiu para atender a demanda crescente de desenvolvimento de soluções personalizadas. Tal qual uma fábrica convencional, esta possui uma linha de produção altamente especializada da e dinâmica, o que possibilita o desenvolvimento de projetos otimizados e cumprimento dos cronogramas pré-estabelecidos com o cliente. (<http://www.gsbnet.com.br>). A experiência da empresa BMS, através de sua Fábrica de Software, consegue poupar o cliente de todo um ambiente de produção, envolvendo recursos técnicos e humanos. O uso de uma linha de montagem implica numa elaboração mais rápida e disciplinada que, além de promover a redução de custos, aumenta a produtividade, contribuindo para o cumprimento de prazos. A qualidade é um outro benefício inerente a este processo, uma vez que a Fábrica possui todo um controle sobre as atividades e resultados a serem atingidos. (<http://www.bms.com.br>).
9 CAPÍTULO I O QUE É SOFTWARE. De acordo com a Universidade do Paraná, Softwares são programas de computador que explorando os recursos do Hardware, torna a máquina operacional, onde executamos tarefas nas quais são solucionados inúmeros problemas. São sentenças escritas em uma linguagem computável, para a qual existe uma máquina capaz de interpretá-la. A sentença (o software) é composta por uma seqüência de instruções (comandos) e declarações de dados, armazenável em meio digital. Ao interpretar o software, a máquina é direcionada à realização de tarefas especificamente planejadas, para as quais o software foi projetado. (<http://www.inf.ufsc.br/bertoni/intro.htm/>). Algumas funcionalidades que pode-se citar: Criação e Edição de textos; Criação de Planilhas Eletrônicas; Controles Financeiros e de Fluxo de Caixa; Controle de Vendas e Comissões; Controle de Estoque; Planejamento de Custos e Projetos; etc.
10 1.1 - Processo de desenvolvimento de Software Constantemente, no processo de desenvolvimento de softwares, os profissionais envolvidos, acabam comprometidos com múltiplos projetos simultaneamente. Dessa maneira um mesmo desenvolvedor desenvolve dois softwares, bem como corrige bugs de outros dois, fato este que dificulta seu próprio trabalho. As tarefas de desenvolvimento, quer sejam elas de criação de novos softwares ou de manutenção dos softwares existentes, devem ser divididas em projetos e cada projeto deve seguir uma sequencia de execução que garanta a qualidade do software que está sendo gerado. Partilha da mesma opinião a empresa. (<http://www.bufaloinfo.com.br/mds/>). 1.2 - Equipes envolvidas As seguintes equipes devem ser delineadas e envolvidas no processo de desenvolvimento :.Desenvolvimento.Testes.Homologação.Banco de Dados.Suporte.Produção
11 1.3 - Divisões de processos de desenvolvimento..análise.codificação.testes.implantação.produção 1.3.1 - Análise A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade. Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa frequentemente falhas na definição do software, ou seja, descobre-se após o desenvolvimento que o que foi feito não atende a necessidade existente. Divisões da etapa de Análise.Levantamento de informações.desenho de processo (Use Cases).Modelagem de Dados (MER).Modelagem do sistema (DFD/CLASS/SEQUENCE).Prototipação.Definições finais
12 1.3.1.1 - Levantamento de informações Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes. O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando. O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa. Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação. 1.3.1.2 - Desenho de Processo O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário.
13 1.3.1.3 - Modelagem de Dados Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizadas informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento. O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresenta-lo ou não ao usuário pode ser uma decisão do analista. O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados. O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados. Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco Toda futura alteração do modelo de dados deve ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma seqüência histórica de mudanças realizadas no banco de dados.
14 1.3.1.4 - Modelagem de Sistema Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequence, típicos da análise orientada a objetos. Obtem-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto. Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento. É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexível mesmo frente a situações inesperadas. 1.3.1.5 - Prototipação protótipo. Feita a modelagem do sistema parte-se então para a construção do O protótipo é um modelo das telas do sistema que tem por intenção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas.
15 1.3.1.6 - Definições Finais Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo, a fase de análise encontra-se concluída em sua etapa mais formal. Concluído as definições de análise é possível desenvolver um cronograma de execução. A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores), sendo então possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade. 1.3.2 - Codificação Após os levantamentos realizados na etapa da Análise, inicia-se a então a atividade de codificação dos programas que irão compor o sistema de Software.
16 1.3.3 - Testes Os testes se dividem em 5 tipos :.Teste de bancada.teste de qualidade.teste de Stress.Teste de Segurança.Homologação 1.3.3.1 - Teste de bancada Destes tipos, apenas o teste de bancada é realizado em ambiente de desenvolvimento, em geral pelo próprio analista conforme comentado anteriormente. Os demais testes são realizados em um ambiente denominado ambiente de qualidade. 1.3.3.2 - Ambiente de qualidade O ambiente de qualidade é um ambiente o mais similar possível ao ambiente de produção da empresa. Este ambiente é utilizado para a realização de testes de qualidade na aplicação. Raramente, porém, é possível ter um ambiente de qualidade realmente idêntico ao de produção. Cabe à equipe de suporte juntamente com o analista/arquiteto do sistema realizar um relatório de riscos relativo a passagem da aplicação para produção.
17 1.3.3.3 - Teste de Qualidade O teste de qualidade é, de todos, o teste mais detalhado do sistema. É realizado por profissionais especializados na realização de testes da aplicação. Os testes podem fazer uso do plano de testes criado pelo analista, mas não se prendem a ele. O objetivo principal dos testes é fazer o que é chamado de monkey test : Fazer exatamente o contrário do que a aplicação pede em cada tela e verificar como a aplicação reage. Desta forma obtem-se a garantia de que a aplicação funcionará mesmo perante os piores tipos de usuário existentes. Os testes em geral são desenvolvedores, mas não precisam ser tão especializados como os próprios desenvolvedores do projeto. Em alguns casos podem ser outra equipe de desenvolvimento da própria empresa, mas não devem ser os mesmos desenvolvedores do projeto, pois por mais que tentem os desenvolvedores do projeto sempre fazem testes para fazer a aplicação funcionar, ao contrário de testers que devem fazer a aplicação dar erro. Há um trabalho circular entre os testes e o processo de codificação. Os testes devem gerar um relatório de volta para o processo de codificação, gerando uma re-implantação da aplicação em qualidade e novo teste até o momento em que os testes não identifiquem nenhum erro
18 1.3.3.4 - Teste de Stress O teste de stress tem por objetivo testar a aplicação em condições de uso muito maciço, verificando como o hardware e o software respondem em ambiente simulado. O teste envolve tanto o analista/arquiteto, responsável por especificar a simulação de teste, como a equipe de banco, responsável pela análise da resposta do servidor de banco ao teste como a equipe de suporte, responsável pela análise da resposta do hardware e do sistema operacional. 1.3.3.5 - Teste de Segurança Em geral é realizado por uma equipe externa de hackers contratados especialmente para testar a segurança do sistema, este teste tem se tornado comum nas atuais arquiteturas de desenvolvimento para web. 1.3.3.6 - Homologação É o teste realizado pelos usuários finais, que podem ou não seguir o plano de testes preparado pelo analista. O processo de homologação pode gerar um trabalho circular com a etapa de codificação, assim como ocorreu com o teste de qualidade, mas é mais improvável que o processo de homologação encontre muitas falhas no sistema.
19 O usuário vai, como sempre, pedir modificações no sistema. Porém o analista deve ser cuidadoso de direcionar as modificações solicitadas pelo usuário para a próxima versão do sistema. Ao final da homologação o usuário dá sua aprovação final para o sistema. 1.3.4 - Implantação Não existe uma regra específica para o processo de implantação, mas o analista, a equipe de suporte e a de banco de dados devem estar em conjunto solucionando os seguintes problemas :. Treinamento para os usuários.. Trabalho em paralelo com aplicações existentes quando necessário.. Migração de dados de bancos de dados existentes quando necessário.. Observe que tanto o analista, como a equipe de suporte e a equipe de banco de dados devem ter trabalhado deste o término da etapa de análise no planejamento do processo de implantação. Desta forma o trabalho neste etapa torna-se bem planejado e organizado, menos sujeito a falhas 1.3.5 - Produção A partir da implantação da aplicação entra em cena a equipe de produção, que algumas vezes é um sub-conjunto da equipe de suporte. Eis algumas tarefas da equipe de produção :. Fornecer suporte ao uso da aplicação.. Inspecionar logs de eventos gerados pela aplicação identificando possíveis
20 problemas em produção.. Montar uma linha base de performance para a aplicação.. Conhecer as características da aplicação de forma a poder auxiliar a equipe de suporte no planejamento do remanejamento da aplicação em relação aos servidores da empresa.. Apontar para a equipe de desenvolvimento problemas de performance na aplicação.
21 CAPÍTULO II CONSTRUÇÃO DE UMA FÁBRICA DE SOFTWARE Nesta seção, detalham-se as etapas percorridas durante a elaboração de uma fábrica de software e sua conseqüente implantação, exibindo assim, resultados coletados com as experiências práticas vivenciadas. O modelo de fábrica proposto foi aplicado a um projeto piloto com a finalidade de gerar refinamentos e melhorias no processo adotado; em seguida, um projeto mais amplo foi desenvolvido para validar e verificar a viabilidade da estrutura definida. 2.1 - O que é Fábrica de Software? Fernandes e Teixeira (Fábrica de Software Editora Atlas 2004) apresentam o seguinte conceito - fábrica de software está baseado na idéia de ter uma linha de produção de sistemas a partir de requisitos levantados e especificados por um "cliente" da fábrica. Este processo é totalmente direcionado às necessidades do cliente, de acordo com um escopo, cronogramas e padrões pré-estabelecidos de qualidade e de projeto. A Fábrica possibilita que cada integrante do projeto de software tenha uma visão geral do negócio e se especialize em sua área, buscando soluções que atendam aos objetivos globais e específicos.
22 2.2 - Concepção A fábrica foi definida em função do contexto no qual estava inserida. A idéia consistia em adotar um processo de desenvolvimento de software baseado em componentes com métodos para avaliar o progresso, técnicas para Acompanhar andamento das atividades e ferramentas para otimizar a construção dos artefatos, tendo produtos desenvolvidos em um ambiente acadêmico. Devido à necessidade de incrementar a produtividade e a qualidade dos seus processos e produtos, assim como reduzir os custos e o tempo de desenvolvimento, a proposta de solução considerava dois importantes pontos: melhorar a eficiência dos processos e reutilizar os artefatos previamente construídos. Dessa forma, durante esta etapa de concepção, que se estendeu por quatro (4) semanas, atividades relacionadas à forma de organizar a estrutura geral de uma fábrica de software foram consideradas, tendo em vista os objetivos já mencionados. As principais decisões tomadas para possibilitar a construção desse ambiente foram: Perfis funcionais e as respectivas atividades a serem desempenhadas; Metodologia de desenvolvimento de software a ser utilizada incluindo artefatos e métricas; Definir um plano de processos descrevendo as atividades e relacionando-as com os artefatos e perfis funcionais responsáveis pela execução das mesmas; Material de instrumentação necessário.
23 2.2.1 - Perfis Funcionais A classificação estabelecida para os perfis funcionais, juntamente com as responsabilidades de cada cargo: Gerente de Negócios: prospecção do mercado e venda dos serviços. Gerente de Projeto: gerenciamento dos riscos e das atividades em desenvolvimento devendo dimensionar e alocar os recursos necessários para realização das tarefas de forma satisfatória, além de interagir com o cliente e o gerente de negócios. Analista de Sistemas: levantamento de requisitos, análise, definição da arquitetura e documentação do sistema a ser desenvolvido. Analista de Qualidade: revisão dos artefatos gerados, controle de mudanças, bem como a definição e validação da qualidade e acurácia do processo utilizado pela fábrica. Engenheiro de Software: implementação do sistema conforme as especificações de documentação, seguindo o processo de desenvolvimento definido. Engenheiro de Testes: desenvolvimento, validação e execução de testes de software com o intuito de assegurar a qualidade e acurácia do software produzido. Líder de Equipe: coordenação e atribuição de tarefas dentro de um grupo específico, relatando periodicamente ao gerente de projetos o andamento das atividades.
24 2.2.2 Metodologia de Desenvolvimento A metodologia de desenvolvimento baseou-se no Rational Unified Process (RUP) [9] e no Project Management Body of Knowledge (PMBOK) [4]. A essência do RUP consiste em um ciclo de desenvolvimento iterativo e incremental, assim, ao longo do tempo são executadas várias iterações e cada uma delas gera versões contemplando um número maior de funcionalidades. Por sua vez, o PMBOK é aceito como um padrão para gerenciamento de projetos e descreve práticas tradicionais e largamente aplicadas para entendimento e execução das atividades relativas a gestão do projeto, incluindo objetivos, responsáveis e participantes de cada processo. A metodologia de desenvolvimento adotada na fábrica está dividida nas seguintes fases: 2.2.2.1 - Comercial: definição do projeto, de acordo com as necessidades levantadas junto ao cliente, além do levantamento de estimativas de custo e esforço baseando-se na técnica de Pontos de Caso de Uso Ajustados. A intenção é unificar o entendimento do produto a ser desenvolvido e fornecer uma estrutura com previsões razoáveis de recursos, custos e prazos; dados históricos devem ser coletados para utilização em estimativas de projetos futuros, aumentando assim as chances de sucesso. 2.2.2.2 - Planejamento e Gerenciamento: elaboração do plano do projeto (plano de trabalho, riscos, acompanhamento e controle), estimação de prazos e execução das atividades recorrentes para avaliar o progresso coletando as métricas de desempenho (µ concluído, µ atraso médio eµ novas atividades). O gerente de projetos terá atribuições e responsabilidades descritas no PMBOK. A meta é fornecer uma linha básica de estruturação e delimitação do trabalho, devendo produzir ações como: comunicar o escopo
25 e os recursos a todos os envolvidos; definir riscos e sugerir técnicas para evitá-los, ou minimizá-los; elaborar cronograma com divisão de trabalho e dependência entre as atividades; gerenciar mudanças; monitoramento através de relatórios, a fim de checar o planejado com o realizado efetivamente. Enfim, desenvolve-se mecanismos para avaliar o progresso, organizar o pessoal que desenvolverá o produto, além de rastrear e controlar o projeto e mudanças que por ventura apareçam. 2.2.2.3 - Desenvolvimento de Componentes: definição do problema, especificação, projeto e implementação dos componentes. Esta fase segue uma abordagem,considerando a reutilização como fator primordial e, assim, objetivando mais qualidade e redução nos custos de desenvolvimento, testes, documentação e manutenção. Inicialmente, a abordagem parte dos requisitos do domínio do problema e produz os componentes implementados numa linguagem orientada a objetos. Uma vez implementados, o engenheiro de software desenvolve as aplicações reutilizando os componentes previamente construídos. 2.2.2.4 - Testes e Validação: elaboração de testes para validar os artefatos previamente construídos. Representa a última oportunidade de detectar erros antes do software ser distribuído aos usuários e tem como principais objetivos: planejar os testes que devem ser executados em cada iteração; verificar a correta integração entre todos os componentes do software; averiguar se todos os requisitos do sistema foram corretamente implementados; executar vários testes para comparar o resultado dos mesmos com os parâmetros definidos como esperados, a fim de produzir uma indicação da qualidade e da confiabilidade do software; além de realizar os testes de aceitação junto ao cliente.
26 2.2.3 - Definir um Plano de Processos O plano de processos detalha cada fase da metodologia, mostrando o fluxo de atividades a serem executadas, os artefatos que devem ser produzidos e os perfis funcionais encarregados da geração de tal material. 2.2.4 - Material de Instrumentação A fábrica emprega tecnologias que são definidas de acordo com as categorias: Ferramentas de desenvolvimento e modelagem; Ferramentas para relatar bugs durante o desenvolvimento; Ferramentas de gerenciamento de projetos; Ferramentas para comunicação entre os participantes e disseminação do conhecimento; e Sistema gerenciador de banco de dados.
27 CAPÍTULO III IMPLANTANDO A FÁBRICA DE SOFTWARE Fernandes e Teixeira (Fábrica de Software Editora Atlas 2004) demonstram que a implantação da Fábrica de Software parte do princípio de que as questões de sua estrutura e infra-estrutura já estejam decididas. Portanto, a tarefa é planejar o projeto de implementação de Fábrica de Software, Tomando como base sua especificação conceitual. A estratégia de desenvolvimento do projeto de implementação é crucial para seu sucesso. O detalhamento do planejamento do projeto de implementação depende da estratégia. A estratégia de desenvolvimento do projeto de implementação determina o meio pelo qual vamos desenvolver o planejamento e sua execução, considerando alguns aspectos importantes. A estratégia define como vamos estruturar o Work Breakdown Structure (WBS), do projeto (os produtos a serem entregues ao longo do projeto), qual vai ser o ciclo de vida a ser adotado para o projeto, qual a melhor seqüência das atividades em função de prioridades, a 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 muito da complexidade do projeto, considerando seu porte e risco. Quanto maior a complexidade do projeto, mais importante é a definição da estratégia de desenvolvimento do projeto. A estratégia tem como missão principal a redução da complexidade do projeto. A implantação de uma fábrica de Software, pela primeira vez, é um projeto complexo e de risco. A estratégia pode ser formalmente documentada ou não. Sugerimos que a estratégia seja formalmente documentada e colocada sob controle de configuração.
28 3.1 - Pontos Estratégicos como iremos estruturar os deliverables do WBS; a estratégia vai ser o desenvolvimento interno de toda a fábrica? Senão vai ser desenvolvida por terceiros (integralmente ou parte)? Fornecedores de tecnologia e de metodologias participarão ativamente do projeto. qual o ciclo de vida a ser adotado para o projeto? qual a estratégia de entrega dos produtos ao longo do tempo (ou com as funcionalidades requeridas vão ser entregues - tudo de uma vez, por partes etc.)? quais os requerimentos do plano da qualidade do projeto? quais os requerimentos para a estrutura organizacional do projeto? quais os requerimentos para o planejamento de recursos? quais os requerimentos para o plano de riscos? quais os requerimentos para a 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 projeto. Outro aspecto fundamental da Estratégia de Desenvolvimento é que ela também serve para que haja definição sobre como conduzir a execução do planejamento e do projeto.
29 Dependendo do porte, do risco e complexidade do projeto, precisamos alocar recursos humanos especialistas e/ou contratar serviços externos para que possamos gerar um plano coerente e factível. 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 experiências de 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 esperadas para o projeto, que merecem destaque; ao definir as "frentes" de trabalho ou conjunto de deliverables, identificar o conjunto principal de produto (produto final) e os conjuntos de apoio e secundários 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 alternativas 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 deliverable do projeto, considerando as frentes de trabalho definidas pela estrutura do WBS); decidir sobre como os produtos vão ser entregues ao longo do tempo, devido às restrições de prazo e custo (a entrega dos produtos também está muito associada ao ciclo de vida selecionado para o projeto);
30 definir os requisitos do plano da qualidade do projeto, como decidir sobre uso de revisões, ambientes de testes estruturados, papel do quality assurance, uso de padrões etc. (esses requisitos servem de guia para a elaboração do Plano da Qualidade do Projeto); definir os requisitos do Plano Organizacional do Projeto em termos de: 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 requerida etc. (esses requisitos servem de guia para a elaboração do Plano Organizacional do Projeto); definir os requisitos para o Planejamento da Aquisição do Projeto em termos de tipo e qualificação de recursos, parceiros e fornecedores, tipos de equipamentos etc. (também serve de guia para a elaboração do Plano de Aquisição do Projeto); definir os requisitos para o Plano de Riscos em termos de pontos de atenção em função do tipo do 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 meios usuais de comunicação e relatórios já empregados pela empresa ou em função das características da audiência; identificar os meios adequados em vista da cultura da empresa etc; 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 a alocação de recursos para a elaboração do planejamento do projeto; definir as datas-limites de encerramento das atividades previstas no planejamento do projeto;
31 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 básica do WBS; 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.
32 Algumas sugestões práticas para a implementação de um projeto de Fábrica de Software são: selecionar um gerente de projetos com autoridade (formal e informal) 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; dar prioridade para a gestão da operação, gestão do projeto e processo de construção; implementar as ferramentas básicas para a automação da fábrica, principalmente gestão da 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. 3.2 - 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: definição das atividades para a geração de cada produto previsto para ser entregue pelo projeto (exemplo: instalação dos servidores, procedimento documentado de controle da qualidade etc.); definição sobre precedências entre as atividades;
33 estimativa de prazos e recursos; estimativa de custos; 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. 3.3 - Gerenciando e Finalizando a Implantação O gerenciamento da implantação é feito com base no plano do projeto e de seus respectivos planos auxiliares. Em um projeto de implementação de Fábrica de Software, como em qualquer projeto, quatro objetivos devem ser perseguidos, quais sejam: completar o projeto no prazo, no custo, na qualidade e dentro do escopo. Esses quatro objetivos são os indicadores de sucesso de um projeto. Geralmente adicionamos mais um, que é a adoção do resultado do projeto pelo o que foi exigido pela demanda.
34 CONCLUSÃO Neste trabalho, foi apresentado o processo de criação e implantação de uma fábrica de Software, utilizando-se de modelos totalmente consolidados no mercado de TI, demonstrando linhas de produção bastante flexível, com desenvolvedores estrategicamente alocados, atuando sempre dentro de suas especialidades para que se atinja um considerável padrão de qualidade e produtividade. Foram discutidos e demonstrados detalhadamente as etapas mais relevantes nesta tendência mundial de produzir programas de computadores Fábrica de Software, Não perdendo o foco, que é a satisfação total do cliente, que busca sempre além da rapidez, produtos com bons preços e excelentes padrões de Qualidade. A grande contribuição deste trabalho consiste também de como implementar um modelo de Fábrica de Software com baixos recursos Físicos e Financeiros, utilizando o máximo do talento e experiência dos profissionais de Mercado que possuem perfil para atuarem neste modelo de produção de Software.
35 REFERÊNCIAS ASSOCIAÇÃO BRASILEIRA DE CAPITAL DE RISCO ABCR. Disponível em: <http://www.abcr.venture.com.br> Acesso em: 15 mar. 2005 às 21:00 horas. BMS - Disponível em: <http://www.bms.com.br/>. Acesso em: 3 mai. 2005 às 20:00h. CIÊNCIA E CULTURA - Disponível em: <http://cienciaecultura.bvs.br/>. Acesso em: 3 mai. 2005 às 19:30 horas. FERNANDES, Aguinaldo Aragon; TEIXEIRA, Descartes de Sousa: Fábrica de Software - Editora Atlas. GSBNET - Disponível em: <http://www.gsbnet.com.br/>. Acesso em: 3 mai. 2005 às 19:30h. IBM SOLUÇÕES - Disponível em : <http://www.ibm.com/br>. Acesso em: 15 mar. 2005 às 21:00 horas. MENESES, J.B., Moura, H. P. Inspector: Um Processo de avaliação de Progresso para Projetos de Software, Simpósio Brasileiro de Engenharia de Software, Rio de janeiro, 2001. PUC RIO GRANDE DO SUL. Cursos: Graduação Informática. Rio Grande do Sul, 2005. Disponível em : <http://pucrs.campus2.br/>. Acesso em: 15 mar. 2005 às 20:00 horas. UNIVERSIDADE FEDERAL DO PARANÁ. Cursos: Graduação Informática. Paraná, 2005. Disponível em : <http:www.ufpr.br>. Acesso em: 15 mar. 2005 às 19:00 horas.
36 ÍNDICE FOLHA DE ROSTO 02 AGRADECIMENTO 03 DEDICATÓRIA 04 RESUMO 05 METODOLOGIA 06 SUMÁRIO 07 INTRODUÇÃO 08 CAPÍTULO I - O que é Software 09 1.1 - Processo de desenvolvimento de Software 10 1.2 - Equipes envolvidas 10 1.3 - Divisões de processos de desenvolvimento 11 1.3.1 - Análise 11 1.3.1.1 - Levantamento de informações 12 1.3.1.2 - Desenho de Processo 12 1.3.1.3 - Modelagem de Dados 13 1.3.1.4 - Modelagem de Sistema 14 1.3.1.5 - Prototipação 14 1.3.1.6 - Definições Finais 15 1.3.2 - Codificação 15 1.3.3 - Testes 16 1.3.3.1 - Teste de bancada 16 1.3.3.2 - Ambiente de qualidade 16 1.3.3.3 - Teste de Qualidade 17 1.3.3.4 - Teste de Stress 18 1.3.3.5 - Teste de Segurança 18 1.3.3.6 - Homologação 19 1.3.4 - Implantação 19 1.3.5 - Produção 19
37 CAPÍTULO II - Construção de uma Fábrica de Software 21 2.1 - O que é Fábrica de Software 21 2.2 - Concepção 22 2.2.1 - Perfis Funcionais 23 2.2.2 - Metodologia de Desenvolvimento 24 2.2.2.1 - Comercial 24 2.2.2.2 - Planejamento e Gerenciamento 24 2.2.2.3 - Desenvolvimento de Componentes 25 2.2.2.4 - Testes e Validação 25 2.2.3 - Definir um plano de Processos 26 2.2.4 - Material de Instrumentação 26 CAPÍTULO III - Implantando a Fábrica de Software 27 3.1 - Pontos estratégicos 28 3.2 - Planejamento de Implantação 32 3.3 - Gerenciando e Finalizando a Implantação 33 CONCLUSÃO 34 REFERÊNCIAS 35 ÍNDICE 36 FOLHA DE AVALIAÇÃO 38
38 FOLHA DE AVALIAÇÃO UNIVERSIDADE CANDIDO MENDES PRODUÇÃO EM ESCALA DE PROGRAMAS DE COMPUTADORES (FÁBRICA DE SOFTWARES) Manoel Carlos Josué de Almeida Data de Entrega: 11 / 05 / 2005 Avaliado por: Ana Cristina Guimarães Conceito: