PROJETO E DESENVOLVIMENTO DE SISTEMAS DA INFORMAÇÃO EAD MÓDULO 1 O DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 PROJETO E DESENVOLVIMENTO DE SISTEMAS DA INFORMAÇÃO EAD MÓDULO 1 O DESENVOLVIMENTO DE SISTEMAS O desenvolvimento de sistemas tem como característica a complexidade que envolve todos os seus processos, à medida que o tamanho do sistema passa a ser maior, a sua complexidade também aumenta. O tempo e os recursos que são necessários para a construção de um software de controle financeiro são bem menores do que o tempo e os recursos necessários para a construção de um complexo sistema de informação que é responsável pelo controle de várias atividades espalhadas pelos setores de uma empresa. Para a construção de sistemas complexos é necessário que antes seja feito um planejamento completo do que vai ser construído, englobando todas as suas características, desde a mais simples, até a mais complexa. A criação de um modelo pode ser vista como uma representação idealista do sistema que será construído. Existem várias razões para que seja utilizado um modelo no desenvolvimento de um sistema, abaixo citaremos algumas dessas razões. 1.1 Gerenciamento da Complexidade do sistema As pessoas possuem uma dificuldade enorme em lidar com certos tipos de complexidades, e essa é uma das razões para a criação de um modelo para o desenvolvimento dos sistemas. Um mesmo sistema pode ser composto por diversos modelos, onde cada um apresenta uma perspectiva diferente do que será construído. Como exemplo, podemos ter o modelo da estrutura dos dados, o modelo da estrutura das informações, etc. Através dos modelos, os profissionais envolvidos no desenvolvimento do sistema podem analisar o que foi proposto e anteciparem-se a alguns comportamentos do sistema. Outra vantagem é que detalhes irrelevantes que dificultariam o desenvolvimento podem ser ignorados por certo momento estudando-se separadamente cada um dos modelos, sendo reveladas características essenciais de um sistema e detalhes não relevantes que só aumentariam a complexidade do problema. 1.2 Comunicação entre os profissionais envolvidos O desenvolvimento envolve a execução de uma grande quantidade de atividades que se traduzem em informações sobre o sistema em desenvolvimento, e grande parte dessas informações correspondem ao modelo que foi criado para a representação do sistema. Se observarmos bem, o modelo também serve para promover a propagação das informações relativas ao sistema entre os profissionais envolvidos no seu desenvolvimento e como ponto de referência na geração de expectativas. 1.3 Redução dos custos Os erros que são invariavelmente cometidos podem ser a caráter individual ou erros de comunicação entre os membros envolvidos no desenvolvimento. A correção desses erros é bem mais barata quando os erros são detectados no

2 momento em que o modelo do sistema é criado, evitando impactos desastrosos no seu desenvolvimento. 1.4 Comportamentos futuros do sistema Analisando os modelos propostos podemos discutir o comportamento do sistema, onde esses modelos servem como um laboratório utilizado para experimentar diferentes soluções de problemas que estão relacionados ao desenvolvimento do sistema. A melhor forma de representar os modelos de sistemas de softwares é através da utilização de diagramas. Um diagrama é formado por elementos gráficos que possuem um significado predefinido, modelando o sistema e gerando para os desenvolvedores uma representação consistente do sistema. Na disciplina de Modelagem de sistemas de informação, dedicamos um capítulo completo falando sobre UML e todas as suas ferramentas e diagramas. Um bom momento para a utilização da UML é agora, na criação dos modelos do sistema que será desenvolvido. 1.5 O processo de desenvolvimento A dificuldade que envolve o desenvolvimento de um sistema corresponde à junção das complexidades de todos os seus componentes. Esses componentes podem ser tanto de hardwares, softwares, funções, procedimentos, etc. O reflexo de toda essa dificuldade causada pelos componentes envolvidos é um dos principais responsáveis pelo grande número de sistemas que não concluem a sua construção, extrapolando tanto os custos como o tempo alocado. Para lidar com toda essa complexidade e diminuir a quantidade de problemas no desenvolvimento de sistemas, é necessário definir processos para o desenvolvimento de sistemas. Um processo define todas as atividades que visam definir, desenvolver, testar e implantar um sistema. Alguns objetivos são: Definir as atividades a serem executadas; Como e por quem tais atividades serão executadas; Controle e verificação no andamento do desenvolvimento; Padronização e organização do desenvolvimento. As tarefas realizadas durante o desenvolvimento de um sistema são classificadas como atividades. Destacamos vários tipos de processos que são propostos, não existindo aquele que seja o melhor, pois cada processo possui as suas particularidades em relação ao modo de organizar e coordenar as atividades de desenvolvimento. Algumas atividades são comuns na maioria dos processos existentes, são elas:

3 1.5.1.Análise de sistemas - concentra-se em todos os elementos do sistema, não apenas no software; - identifica as necessidades dos usuários, a análise econômica, viabilidades técnica e restrições de prazos e custos Análise de Requisitos - concentra-se apenas no sistema que está sendo desenvolvido; - rever elementos que são problemáticos, refina os dados de entrada e saída e aprimora os modelos Projeto - constroem modelos e representações do sistema que será desenvolvido; Codificação Teste - etapa em que o software é efetivamente construído. - etapa crucial para a garantia da qualidade do sistema que está sendo desenvolvido Manutenção - envolve todas as modificações feitas no software depois dele está pronto. Algumas dessas atividades foram citadas rapidamente na disciplina de Modelagem de sistemas de informação, só que pelo grau de importância de cada uma, nos aprofundaremos em algumas delas no decorrer dessa disciplina. MÓDULO 2 IDENTIFICAÇÃO DAS NECESSIDADES DE INFORMAÇÃO Para que possamos identificar as reais necessidades de informação de uma empresa, devemos criar metodologias e etapas para uma identificação eficiente e objetiva. 2.1 Identificação dos fatores críticos e objetivos

4 Os problemas e objetivos de uma empresa devem ser definidos claramente, levando em consideração que alguns desses problemas podem ser resolvidos sem o auxilio dos recursos da informática. Outros problemas podem ser informatizados, principalmente os que envolvem a manipulação de dados através de papéis, informações importantes que não estão disponíveis, aspectos de produção, cobrança de devedores, controle de estoque, etc. A informatização de todos estes processos conduz a uma melhor eficácia e controle, podendo assim justificar a sua implantação. Todos os fatores analisados são de fundamental importância no sucesso do planejamento estratégico de qualquer empresa. O desempenho de uma empresa pode ser influenciado por um número muito grande de fatores. Como exemplo, temos a contabilidade mensal dentro dos limites estabelecidos, folha de pagamento pronta com antecedência, que são preocupações tanto da área funcional como pessoal de uma empresa. Os fatores citados são básicos, devendo funcionar perfeitamente para um bom desempenho de qualquer empresa, podendo denominá-los de fatores críticos ou fatores chave para o sucesso. Para que uma empresa seja competitiva e garanta a sua sobrevivência, é necessário que ela não esteja vulnerável nestes fatores críticos, por mais eficiente que ela seja em suas diversas áreas operacionais. Características típicas dos fatores críticos de uma empresa: Importância vital para organização; Diferenciadores entre as organizações; Influência nas relações com os mercados atingidos ou pretendidos; Distribuídos pelas diversas atividades operacionais da empresa. Exemplos de fatores críticos em uma empresa comercial: Sua localização; Variedade de produtos e marcas; Conforto; Atendimento; Preços; Facilidades para os clientes. Para que possamos encontrar e identificar os fatores críticos, alguns pontos de pesquisa devem ser observados: Relação empresa X mercado; Tecnologia; Capacidade de produção; Capacidade financeira; Estrutura organizacional; Empresa X ambiente.

5 Os objetivos e fatores críticos devem ser identificados claramente como primeira etapa na identificação. 2.2 Área de aplicação da informática Depois de identificar os objetivos e fatores críticos, deve ser empreendida uma busca das áreas que serão aplicadas à tecnologia da informação, sempre questionando a sua automatização e utilização através dos sistemas de informação. Cada uma das principais áreas da empresa deve contribuir especificamente para os fatores críticos de sucesso que foram citados, identificando as aplicações da informática que dão apoio a essas contribuições. Nesta etapa, é realizado um levantamento junto às áreas funcionais da empresa, identificando os potenciais de informática que possam servir de apoio, avaliando: Contribuição das funções para os fatores críticos apontados; Contribuição das funções para os objetivos básicos e estratégicos da empresa; Tipo de atividades relacionadas à organização do trabalho; Informações utilizadas e geradas por cada função. Além de toda essa análise e identificação, o ponto de vista do usuário também deve ser questionado, sendo englobado o uso potencial da informática e as necessidades individuais, sejam em novas aplicações ou na modificação das já existentes. Por imprimir um levantamento de informações junto às diversas áreas de uma empresa, departamentos e chefia, essa etapa é considerada uma das mais trabalhosas. Depois de tomada todas as decisões em que são escolhidas as prováveis áreas de aplicação, uma lista de necessidades deve ser elaborada. Esta lista deve ser uma descrição simples da empresa e suas principais necessidades de informação, constando: Descrição da empresa; Suas atividades; Funcionalidades; Localização; Lista de aplicações automatizadas; Lista de aplicações a serem automatizadas; Descrição de cada aplicação.

6 MÓDULO 3 IDENTIFICAÇÃO DAS NECESSIDADES DE INFORMAÇÃO 3.3 Solidificação das aplicações identificadas Com a obtenção das informações das áreas em que é necessária a aplicação dos recursos informatizados, é necessária a criação de uma sumarização e agrupamento de todas as informações e com isso, gerar uma relação das necessidades gerais de informação e dos sistemas de informação a serem automatizados. Com um grupo de decisões e atividades, sendo elas relacionadas logicamente, cada área funcional da empresa é responsável pelos seus processos, sendo necessária para a administração dos recursos e operações de sua responsabilidade, sendo que a disponibilidade de informações é um prérequisito básico para a execução dos processos. Esses processos possuem uma grande interdependência entre ambos, pois algumas informações que um processo necessita, são geradas por outros processos. Como resultado de todas essas operações, a consolidação e integração resultante da aplicação da tecnologia da informação são resultado da análise de processos e funções que darão apoio aos dados que serão processados e as informações a serem geradas. É indispensável a identificação de forma precisa de informações que são necessárias para a execução de cada processo. Um sistema de informação tem como função primordial o fornecimento de informações na quantidade certa, prazos oportunos e custo razoável aos participantes da execução de cada processo. É gerada uma necessidade de identificar e classificar os dados criados, sendo eles controlados e utilizados pelos processos criando assim uma classe de dados. Os dados logicamente relacionados são chamados de classe de dados e são necessários para o apoio aos negócios das empresas. Sua classificação e identificação têm como objetivo a determinação: Disponibilidade aos dados normalmente utilizados pelos processos; Dados potenciais e atuais que são compartilhados pelos processos; Dados que são criados e controlados por cada processo; Informações necessárias que não estão disponíveis; Os sistemas de informação de maior necessidade; Os sistemas de informação que precisam ser melhorados; Podemos dividir as classes de dados em:

7 Dados cadastrais: Os dados cadastrais referem-se aos registros e recursos ligados as atividades da empresa. Ex: Fornecedores, funcionários, produtos e clientes. Dados transacionais: Refere-se a todas as transações efetuadas pela empresa. Ex: Compras, vendas, pagamentos e produções. Dados de controle: Permite a análise do desempenho da empresa, sendo extraídos dos dados transacionais e cadastrais. Ex: Volume de compras, vendas, clientes, etc. Dados de planejamento: São estudados através dos três itens anteriores. Ex: Previsão de venda, vendedores ou clientes. Os dados a serem processados e as informações necessárias devem ser considerados e classificados de acordo com os processos e classes de dados a que pertencem. 3.4 Priorização das aplicações Para a priorização das aplicações que devem ser informatizadas, certas atividades levarão mais tempo, pois podem ocorrer vários erros e problemas no decorrer da informatização. Outras atividades são fáceis de serem executadas, sendo sujeitas a poucos erros. Podemos então: Informatizar as áreas administrativas mais difíceis; ou Informatizar as atividades mais fáceis. Se optarmos pelas áreas complexas, é possível obter um ganho na redução de tempo, problemas e execução das atividades. Se optarmos pelas atividades menos complexas, existe uma menor chance de fracasso e a empresa terá maior facilidade em informatizar posteriormente as atividades mais complexas. A opção que seria ideal era a informatização de um meio termo, não sendo nem tão complexo e nem tão simples. MÓDULO 4 SOLICITAÇÕES E VIABILIDADES DO SISTEMA Depois de serem identificadas as necessidades da empresa para se construir um sistema de informação, é necessário que seja criado um documento de solicitação, onde este documento é responsável por descrever todas as razões da empresa para se construir o sistema. 4.1 Solicitação para construção do sistema Como falamos anteriormente, a solicitação para construção do sistema é responsável por descrever as razões da empresa através de um documento. Esse documento é composto pelos seguintes itens:

8 1. Responsável pelo projeto: é onde são descritas as informações sobre a pessoa que será o contato principal do projeto, munido de informações sobre todas as necessidades da empresa. 2. Requisitos de negócios: faz referência aos recursos que existente na empresa que o sistema deverá possuir. 3. Valor agregado: é onde são descritos todos os benefícios que o sistema deverá oferecer a empresa. 4. Casos especiais: contém algumas informações que deverão ser consideradas quando o sistema estiver sendo avaliado. Toda a equipe de desenvolvimento deve estar preparada para qualquer caso especial que possa afetar o sistema. Depois de concluídas todas as solicitações existentes no documento, é necessário que o mesmo seja enviado para aprovação. Sua aprovação será feita através de uma equipe responsável por tomar todas as decisões sobre os sistemas de informação. O quadro abaixo mostra um rápido exemplo sobre o que deve conter no documento de solicitação do sistema. Itens Descrição Exemplo Responsável Pessoa responsável por Gerente de TI todo o projeto de desenvolvimento do sistema. Necessidades Razão pela qual a empresa inicia o desenvolvimento do sistema. - Aumento nas vendas, serviços prestados aos clientes, etc. Requisitos Valor agregado Capacidades que o sistema fornecerá aos negócios. Benefícios que serão criados pelo sistema. Pesquisa de produtos, serviços on-line, etc. Aumento nas vendas, economia nos custos. Casos especiais Questões relevantes no desenvolvimento do sistema. 4.2 Análise das viabilidades do sistema Prazo segurança, etc. estipulado, A análise de viabilidades tem o papel de orientar a empresa na construção do sistema de informação disponibilizando todos os riscos que são importantes e estão totalmente associados ao projeto do sistema. Dividiremos a análise de viabilidades em três tipos, onde nos aprofundaremos em cada uma Viabilidades técnicas

9 É na viabilidade técnica que é feita toda a avaliação técnica do projeto, destacando até em que ponto o sistema deverá ser elaborado, desenvolvido e instalado com total sucesso. Um dos riscos que podem comprometer totalmente a conclusão do sistema é a familiaridade de usuários e analistas com o novo sistema que está sendo desenvolvido. Quando os usuários e analistas não têm total conhecimento do domínio que está sendo erguido, esse desenvolvimento é mais arriscado que as modificações que são feitas em sistemas que já estão prontos. Outro ponto que pode aumentar os riscos no desenvolvimento do novo sistema é com a viabilidade tecnológica. Poderá existir problemas com a nova tecnologia que está sendo implantada na construção do sistema, o que pode proporcionar a existência de problemas e conseqüentemente causar atrasos e riscos. É importante avaliar também o porte do projeto levando em conta o tamanho da equipe de desenvolvimento, o tempo que será necessário para a sua conclusão, o número de recursos distintos. Quanto maior o projeto, maior é a possibilidade de serem apresentados riscos, pois existe um grau de complexidade maior e com isso alguns dos requisitos do sistema podem ser mal compreendidos ou ignorados. A existência de uma integração entre os sistemas já existentes e o sistema novo que está sendo desenvolvido pode ser outra dor de cabeça, devido à necessidade de trabalharem juntos pode ser bastante complicado integrá-los perfeitamente sem a existência de incompatibilidades. As viabilidades técnicas que envolvem a construção de um novo sistema não podem ser consideradas com algo trivial, sendo necessária a análise de várias condições. Seria interessante consultar os profissionais de TI da empresa para que eles verifiquem se o sistema é viável ou não no ponto de vista técnico. MÓDULO 5 SOLICITAÇÕES E VIABILIDADES DO SISTEMA Análise de custo-benefício do sistema A análise de custo benefício tem o papel de identificar os riscos financeiros que estão associados ao sistema que será desenvolvido. Essa análise determina a identificação de custos e benefícios atribuindo valores e calculando o fluxo de caixa e o retorno que será gerado pelo investimento no projeto. O rigor da análise aumenta a medida que o projeto fica mais caro. Existem várias etapas que são necessárias para analisar o custo benefício do projeto. São elas: Identificação de custos e benefícios: lista todos os custos e benefícios que são sensíveis ao projeto do sistema, incluindo os custos investidos e os custos recorrentes.

10 Atribuição de valores a custos e benefícios: é necessário trabalhar em conjuntos com os profissionais de TI da empresa para que sejam criados os valores para cada um dos custos e benefícios existentes, estipulando valores até para os custos intocáveis. Determinação do fluxo de caixa: é feito um planejamento do comportamento dos custos e dos benefícios por um período de tempo. Se necessário, é feita uma aplicação de taxas de crescimento aos valores. Determinar o retorno do investimento: é feito um cálculo das vantagens financeiras que a empresa terá com o investimento que fará. Calculando o ponto de equilíbrio: Aplicando a fórmula do equilíbrio, ajuda a compreender quanto tempo o sistema levará para criar valores reais para a empresa Viabilidades organizacionais do sistema Aplicando a análise das viabilidades organizacionais do sistema, saberemos de que maneira o sistema será aceito ou não pelo usuário e a sua participação nas operações contínuas existentes dentro da empresa. Para a maioria dos desenvolvedores, a análise das viabilidades organizacionais é a mais difícil de ser avaliada devido a enorme quantidade de fatores organizacionais existentes dentro da empresa. Abaixo citaremos algumas maneiras de se avaliar as viabilidades organizacionais: 1. Conformidade estratégica: Quanto maior a conformidade no projeto, menores serão os riscos do projeto no ponto de vista organizacional. 2. Análise das partes interessadas: As partes interessadas no projeto podem ou não afetar o projeto do novo sistema. As partes interessadas mais importantes são os patrocinadores do projeto e os usuários do sistema. No quadro abaixo mostraremos alguns exemplos de partes interessadas para a viabilidade organizacional. Tipo Patrocinador Usuários do sistema Papel - Iniciação do projeto. - Promoção do projeto. - Fornecimento de recursos - Tomam as decisões que influenciam no sistema. - Executam as atividades práticas para o projeto. - Determinam se o sistema foi bem sucedido.

11 MÓDULO 6 GERENCIAMENTO DOS RISCOS É de vital importância o gerenciamento cuidadoso dos riscos que envolvem o projeto e o desenvolvimento de um sistema, pois devido às mudanças em alguma fase no desenvolvimento, a adição de novos requisitos ou eventuais contratempos no desenvolvimento podem aumentar bastante os riscos no desenvolvimento de um sistema. Os riscos devem ser analisados e identificados, projeções devem ser feitas para que todos os riscos que estão na eminência de acontecer sejam avaliados e bem administrados. 6.1 Identificação dos riscos no desenvolvimento de um sistema É importante identificar todos os riscos que envolvem o desenvolvimento de um software, onde esses riscos podem ser divididos em várias categorias que auxiliam no processo de triagem dos riscos. Os riscos que envolvem o projeto de um sistema podem ser identificados nas seguintes categorias: Riscos relacionados ao projeto o Afetam o cronograma ou os recursos do projeto o Problemas orçamentários, cronograma, pessoal, clientes e requisitos. Riscos relacionados ao produto o Afetam a qualidade e o desempenho do sistema que está sendo desenvolvido. o Incluem problemas de implementação, manutenção, obsolência, incertezas técnicas. Riscos para os negócios o Afetam a empresa que está desenvolvendo ou adquirindo os sistemas. Exemplos de riscos: Risco Categoria Descrição Rotatividade de pessoal Projeto Funcionários experientes da equipe de desenvolvimento deixarão o projeto antes do seu termino. Mudança de gerenciamento Projeto Prioridades diferentes serão aplicadas, havendo uma mudança no gerenciamento organizacional. Mudanças tecnológicas Produto A tecnologia que estava sendo utilizada no desenvolvimento do sistema foi superada por uma nova tecnologia.

12 Concorrência Produto Antes que o sistema fosse concluído, um produto concorrente foi lançado no mercado. Alteração nos requisitos Negócio Adição de um número maior de requisitos do que o previsto. Atrasos na especificação Negócio Especificações essenciais não estavam disponíveis no prazo acordado. Todos esses problemas podem causar um impacto negativo enorme no desenvolvimento do sistema. Segundo (Boehm,89), uma das melhores maneiras de identificar os riscos no desenvolvimento de um sistema, é através da criação de um Checklist formado por um conjunto de perguntas que auxiliam a compreensão dos riscos em termos técnicos no planejamento do projeto. Algumas perguntas que a Checklist pode abordar são: 1. As pessoas envolvidas no desenvolvimento são as melhores que estão disponíveis? 2. As pessoas que estão envolvidas no projeto podem combinar suas habilidades? 3. A equipe de desenvolvimento é suficiente? 4. As pessoas envolvidas no projeto estão comprometidas com toda a sua duração? 5. O treinamento aplicado a equipe desenvolvimento foi o suficiente? Com todas essas perguntas, é possível que seja feito um planejamento onde são estimados os prazos e o impacto dos riscos na criação de uma equipe de desenvolvimento de sistemas. MÓDULO 7 GERENCIAMENTO DOS RISCOS 7.2 Estimativas dos riscos no desenvolvimento do sistema A estimativa dos riscos tem o papel de classificar quais as conseqüências que poderão ser causadas pelo problema que está associado aos riscos e à probabilidade que existe para esse problema acontecer. Essa projeção de risco pode ser feita através das seguintes atividades: 1. Estabelecimento de uma escala que tem o papel de refletir a probabilidade percebida. 2. Traçar as conseqüências dos riscos. 3. Construção da estimativa dos impactos que os riscos podem causar ao processo de desenvolvimento ou ao produto final desenvolvido.

13 4. Registro das projeções que foram definidas sobre os riscos, evitando que ocorram maus entendidos. Uma boa estimativa pode ser feita através da criação de escalas probabilísticas que possuíssem valores de análise. Outra alternativa é a implantação de probabilidades matemáticas e estatísticas. 7.3 Avaliação dos riscos Na avaliação dos riscos é possível examinar o grau de precisão e detalhamento de todas as estimativas que foram feitas durante a estimativa dos riscos. Com isso é possível determinar uma ordem de prioridade para os riscos que foram encontrados e pensar em uma maneira para que seja feito um controle para evitar que a probabilidade aconteça. Na maioria dos projetos de desenvolvimento de sistemas, existem três típicos níveis de riscos: Custos envolvidos Prazos Desempenho A análise dos riscos é formada por um ponto de referência chamado BreakPoint que tem o controle sobre a combinação de riscos que envolve o projeto de desenvolvimento. Através do BreakPoint, podem ser tomadas decisões sobre parar ou continuar o desenvolvimento do sistema. Algumas etapas devem ser seguidas durante a avaliação dos riscos no desenvolvimento de um sistema: Definição dos riscos; Desenvolver um relacionamento entre os tipos de níveis de riscos; Definir os pontos de encerramento; Previsão sobre os níveis que serão afetados pelos riscos. 7.4 Monitoramento dos riscos Após a conclusão na identificação dos riscos, verificando quais os mais prováveis para acontecer, é necessário fazer um monitoramento nesses riscos. O monitoramento possui quatro objetivos: Avaliar cada risco individualmente em períodos regulares; Garantir a aplicação dos passos que foram planejados para o controle dos riscos; Rever a análise feita, sempre coletando informações se necessário; Identificar ao longo do processo, quais os ricos que causam problemas. Existem alguns riscos que são comuns:

14 Tipo de Risco Tecnologia Pessoal Organizacional Ferramentas Requisitos Estimativa Potencial Atrasos na entrega de hardwares e softwares Equipe de desenvolvimento desmotivada Falta de iniciativa por parte da gerência Relutância na utilização de certas ferramentas Muitas solicitações de mudanças de requisitos Falta no cumprimento do programa que foi estabelecido. Todos esses pontos podem necessitar de uma grande quantidade de tempo e esforço para o seu planejamento. Mas vale a pena, pois uma boa gerência de riscos de um projeto pode trazer bons frutos e poucas dores de cabeça no desenvolvimento de sistemas. MÓDULO 8 CUSTOS E PRAZOS DO PROJETO O estouro de cronogramas e orçamentos de projetos de desenvolvimento de sistemas de informação, já virou uma rotina para a maioria dos profissionais de desenvolvimento de softwares. Esses atrasos causam enormes prejuízos e desesperos tanto para gerentes do projeto como para os clientes. É bem provável que no próximo contrato seja oferecido um projeto com um menor prazo ou um menor custo, muitas vezes prometendo prazos politicamente agradáveis, embora fora da realidade. A rotina dos desenvolvedores de sistemas é composta por estimativa de prazos e custos, e não basta apenas que esse desenvolvimento atenda a todos os requisitos que são desejados pelos clientes, é necessário também que a sua produção esteja dentro de certos parâmetros de prazos e custos. Uma estimativa de prazos e custos é uma expectativa razoável tanto para os clientes como para os gerentes do projeto, pois se isso não for possível de ser feito, o produto pode tornar-se inviável do ponto de vista do mercado em que ele está sendo aplicado, sendo muitas vezes mais interessante a aquisição de um produto que sacrifique alguns requisitos, mas que esteja dentro dos prazos e custos desejados. O problema na estimativa acontece porque muitos desenvolvedores não conhecem os métodos e técnicas que são necessários para que seja feita uma estimativa de prazos e custos de qualidade. Muitas vezes, até que alguns desenvolvedores sabem fazer uma boa estimativa, mas as organizações onde trabalham não permitem ou não dão muita importância a uma avaliação franca das perspectivas dos projetos, existindo a política de matar os mensageiros de más notícias.

15 Se observarmos bem o triângulo acima, podemos entender que o aumento de requisitos ocasiona o aumento de prazos e custos, e a redução dos requisitos leva a redução dos prazos e dos custos (nem sempre acontece dessa forma). Os requisitos, prazos e custos foram os vértices de um triângulo crítico. 8.1 Planejamento de projetos A cultura do prazo político é ruim para todas as partes envolvidas, pois os gerentes acumulam prejuízos e perdem a credibilidade, os desenvolvedores se estressam e podem produzir sistemas finais de má qualidade, e os clientes recebem produtos caros, de má qualidade e entregues fora do prazo estipulado e acordado. Clientes e gerentes devem cobrar o cumprimento dos prazos prometidos, pressionando para que não sejam feitas promessas que não podem ser cumpridas. Deve ser feita uma checagem no cronograma e orçamento que foi proposto, sempre observando se são realistas ou não e se preciso, recorrer a serviços terceirizados. 8.2 Gerência do custo do projeto Requisitos bem levantados, analisados e documentados podem aumentar em muito a confiabilidade para que os custos sejam cumpridos. Os processos pertencentes à gerência dos custos do projeto devem ser analisados, pois são necessários para assegurar que o projeto será concluído dentro do orçamento aprovado.

16 Planejamento dos Recursos: determina quais os recursos de caráter pessoal, equipamentos e material deve ser utilizado, envolvendo a quantidade, para a execução das atividades do projeto. Estimativas dos custos: determina uma estimativa dos custos dos recursos que são necessários para a implementação das atividades do projeto. Orçamento dos custos: determina as estimativas dos custos globais aos itens individuais de trabalho. Controle dos custos: controla todas as mudanças existentes no orçamento do projeto. Todos os processos citados se integram mutuamente e ocorrem geralmente nas fases de desenvolvimento do projeto. MÓDULO 9 CUSTOS E PRAZOS DO PROJETO 9.3 Gerenciamento dos prazos do projeto O gerenciamento dos prazos do projeto é necessário para assegurar que o projeto será implementado no prazo previsto. Seus processos fornecem uma visão geral do que deve ser feito para assegurar que os prazos serão cumpridos como acordado com os clientes.

17 Definição das atividades: São identificadas as atividades específicas que devem ser realizadas para produzir os diversos subprodutos do sistema. Seqüência das atividades: Identificação da relação de dependência existente entre as atividades que serão executadas. Estimativa de duração das atividades: é estimado um período de trabalho que será necessário para a implementação de cada atividade. Desenvolvimento de cronograma: é analisada a seqüência e a duração das atividades para que seja criado um cronograma do projeto. Controle do cronograma: Todas as mudanças no cronograma do projeto devem ser controladas. Assim como no gerenciamento dos custos, no gerenciamento do tempo todos os processos interagem uns com os outros e em alguns projetos, especialmente os menores, a seqüência das atividades, a estimativa da duração das atividades e o desenvolvimento do cronograma estão tão unidos que podem ser vistos como um único processo. 9.4 Controle do projeto Todo planejamento é composto por incertezas. Como exemplo, a estimativa grosseira de certos requisitos, que podem ser refinadas com um desenho mais detalhado das partes do produto, assim o tamanho e a forma correta dessas partes, só é exatamente conhecido no final do projeto. Ao longo de um projeto, vários problemas devem ser enfrentados, controlando todas as variáveis que

18 vão surgindo para não afetarem no cumprimento das metas estabelecidas. Em alguns casos esses problemas envolvem o remanejamento de pessoal, melhoria de ferramentas, em outros é necessária a renegociação de requisitos, prazos e custos. Para que seja feita uma renegociação, é necessário um replanejamento e atualizar as estimativas, pois novos dados serão incorporados. MÓDULO 10 - PARTICIPANTES DO PROJETO O desenvolvimento de um sistema de informação é uma tarefa altamente colaborativa, pois as tecnologias complexas que compõem a sua estrutura necessitam da demanda de especialistas de várias áreas específicas. Uma equipe típica de desenvolvimento de sistemas é composta por um gerente de projeto, projetistas, analistas, avaliadores, programadores, usuários que utilizarão o sistema e o próprio cliente. Descreveremos cada um desses participantes, onde podemos encontrar uma mesma pessoa desempenhando várias funções e uma mesma função sendo desempenhada por várias pessoas. Para realizar o desenvolvimento de um sistema com qualidade, é necessária a composição de uma equipe de participantes com conhecimentos específicos nas determinadas áreas que formam a sua estrutura, onde essa necessidade é oriunda principalmente do tamanho e complexidade do sistema. O gerente do projeto O gerente do projeto é responsável por toda a gerência e coordenação das atividades que são necessárias para a construção do sistema. Orçamentos, estimativas de tempo, de desenvolvimento, processos de desenvolvimento, cronograma de execução de atividades, escolha de mão-de-obra especializada, escolha de recursos de hardware e software são tarefas

19 designadas pelo gerente do projeto. O acompanhamento das atividades que são realizadas durante todo o desenvolvimento também faz parte do quadro de responsabilidades do gerente do projeto. O gerente também é responsável por verificar os recursos que estão sendo gastos, podendo intervir se necessário para que a adequação dos gastos seja realizada. Além de desempenhar todas essas atividades, o gerente do projeto deve estudar minuciosamente questões como escalonamento de equipe e quais processos de desenvolvimento deverão ser utilizados. Analistas do projeto O conhecimento sobre o domínio do negócio é responsabilidade do analista de sistemas. Ele deve entender o domínio completo do negócio para que possam ser definidos os requisitos necessários a serem desenvolvidos. O analista não precisa ser um especialista do domínio, mas deve ter conhecimento suficiente na área de domínio que o sistema será implantado, para não causar contratempos aos especialistas de domínio tirando dúvidas sobre conceitos básicos do sistema na área que estão sendo desenvolvidos. O analista é tipicamente o profissional responsável por compreender todas as necessidades dos clientes e repassar o que foi entendido aos desenvolvedores do sistema. Ele representa uma ligação na comunicação entre os profissionais de computação e os profissionais do negócio. Na realização de suas funções o analista deve estar por dentro do domínio do negócio e ter conhecimentos de vários aspectos de alto nível do mundo computacional, funcionando como um tradutor que mapeia as informações entre os especialistas de domínio e os profissionais técnicos que fazem parte da equipe de desenvolvimento. A facilidade em se comunicar é imprescindível para um analista, tanto em fala como em escrita, principalmente por ele ser um facilitador entre os clientes e a equipe de desenvolvimento. Com isso, muitas vezes é mais importante para um analista ter um bom relacionamento interpessoal do que um bom conhecimento tecnológico. Por estar em contato muitas vezes com informações sigilosas, a ética profissional é uma característica importante para um analista, pois essas informações são altamente estratégicas na organização em que ele está trabalhando, tendo acesso a margens de lucro e preço de custo de produtos, sendo altamente catastrófico para uma empresa que essas informações vazem e caiam em mãos erradas. Projetistas de sistema O projetista de sistema tem como função a avaliação de alternativas para soluções de problemas que são resultantes da análise, gerando a especificação de uma solução computacional detalhada para o dado problema.

20 Existem diversos tipos de projetistas: Projetistas de Interface Projetista de Redes Projetista de Banco de Dados Um ponto em comum entre todos esses projetistas é que eles trabalham nos modelos que resultam da análise e adicionam aspectos tecnológicos a esses modelos. Arquitetos de sistemas Os arquitetos de sistemas são encontrados principalmente no desenvolvimento de sistemas complexos e de grande porte, tendo como objetivo principal elaborar a arquitetura do sistema como um todo. É o profissional responsável por tomar todas as decisões sobre os subsistemas que fazem parte do sistema e quais as interfaces utilizadas entre esses subsistemas. Trabalha em conjunto com o gerente do projeto organizando todo o plano do projeto. Programadores O programador é o profissional responsável pela implementação do sistema. Em uma equipe de desenvolvimento existem vários programadores, pois o sistema pode ser composto de várias linguagens de programação. Em algumas equipes de desenvolvimento, os analistas realizam algum tipo de programação e os programadores realizam algum tipo de analise, mas, para fins didáticos, algumas diferenças entre ambos são citadas: O analista está envolvido em todas as etapas do desenvolvimento; O programador participa apenas das fases finais do projeto (implementação teste); O analista deve compreender tanto da tecnologia da informação como do modelo de negócio; O programador preocupa-se apenas com os aspectos tecnológicos do desenvolvimento. Bons programadores na maioria das vezes são promovidos a analistas, sendo uma prática muito comum nas empresas de desenvolvimento de sistemas. Os clientes Os clientes também fazem parte da equipe de desenvolvimento do sistema, sendo divididos em clientes usuários e clientes contratantes. O cliente usuário será quem efetivamente utilizará o sistema, sendo um especialista no domínio do negócio. O cliente usuário é quem vai interagir com o analista de sistemas para que sejam levantados todos os requisitos necessários para o desenvolvimento do sistema. O cliente contratante é quem solicitará o