DIRETRIZES ESTRATÉGICAS PARA EMPRESAS DE SOFTWARE

Transcrição

1 DIRETRIZES ESTRATÉGICAS PARA EMPRESAS DE SOFTWARE Valerio Fernandes (UNIP) Marcelo Pessoa (UNIP) A qualidade em projetos de desenvolvimento de software está relacionada à entrega de um produto que seja adequado ao uso, e que cumpra os objetivos a que se propõe, e esteja alinhado aos objetivos estratégicos das empresas cliente. Em um meercado cada vez mais competitivo, em especial para as pequenas empresas, existe uma necessidade de que estas demonstrem com segurança aos seus futuros clientes que há um entendimento inicial suficiente do problema de negócio. O maior desafio é apresentar de forma consistente uma proposta comercial, com esforço e custos iniciais planejados, e também com uma análise dos riscos da não efetivação do negócio, aumentando desta forma a competitividade. Este artigo propõe um modelo para elaboração e gestão eficaz de propostas comericias para de desenvolvimento de software. Através de pesquisa bibliográfica são levantados conceitos, métodos, técnicas e ferramentas voltados para este fim, garantindo que o investimento inicial nesta fase não seja perdido quando da concretização do negócio. O modelo proposto é aplicado para o desenvolvimento de um pré-projeto de uma pequena empresa. Os resultados desta aplicação são apresentados e discutidos, tendo-se observado um aumento significativo na geração de novos negócios. Desta forma espera-se contribuir para elevar os níveis de qualidade dos projetos e garantir a satisfação dos clientes. Palavras-chaves: requisitos, portfólio de projetos, riscos, gestão de projetos, ciclo de vida, pré-projeto.

2 .1 1. Introdução O entendimento dos requisitos de usuário e de sistema em um projeto de desenvolvimento de software precisa ser expresso de forma clara e objetiva para que a solução sistêmica a ser construída atenda ou supere as expectativas dos usuários. Requisitos mal capturados e mal interpretados podem levar à situações de retrabalho futuro indesejáveis, e conseqüentemente a um desgaste necessário com o cliente. Na grande maioria dos casos, em especial para projetos de novos sistemas, a verificação da exatidão dos requisitos capturados junto aos usuários, nos níveis gerencial e operacional torna-se fundamental e facilitarão a gestão de mudanças (Pádua 2003). Todavia é necessário esclarecer que o detalhamento dos requisitos do projeto irá culminar em um pré-projeto, que na grande maioria dos casos é um investimento absorvido pela empresa proponente. Desta forma é preciso esclarecer que o modelo proposto é para elaboração e apresentação de um pré-projeto, como base para aprovação pelo cliente final de uma proposta comercial. Cabe ainda a empresa proponente, através de sua área comercial, definir a estratégia para formação do preço, que não é abordada neste artigo. Verifica-se a necessidade de um refinamento do pré-projeto quando de sua aprovação, como forma de preservar o investimento nesta fase e também para garantir para as fases seguintes consistência do que deve ser feito. A definição e institucionalização de um modelo para captura e validações de requisitos, com uma análise prévia de seus riscos, e representá-los na forma de um pré-projeto, objetivam a redução de impactos futuros nas linhas base de escopo, prazo e custos dos projetos. Neste contexto acredita-se que uma vantagem estratégica sobre os concorrentes possa ter como foco em toda indústria por diferenciação. A figura 1 ilustra o modelo de Porter para estratégias nos negócios. Vantagem Estratégica Toda Indústria Diferenciação Liderança no Custo Segmento Particular Enfoque 2

3 Figura 1: Modelo para a competitividade. (adaptado de Porter, 1989) Uma das possibilidade do alvo estratégico é a diferenciação, foco deste estudo, que está sendo interpretada pela qualidade dos produtos serem oferecidos pelas empresas de desenvolvimento de software. Desta forma torna-se imperativo que uma fase inicial seja cumprida para diminuir os riscos de se dispender esforço desnecessário na concretizaçào de negócios. Este artigo propõe um modelo para elaboração de propostas comerciais com base em pré-projetos de desenvolvimento de software em seções bem definidas. A seção 2 descreve primeiramente uma visão geral de especificação de requisitos de software, base fundamental para elaboração de um pré-projeto, seguido dos métodos e processos de desenvolvimento de software como RUP (Rational Unified Process), não demonstrados neste documento e MSF (Microsoft Solutions Framework). Na seção 3 são apresentados os conceitos gerais e o modelo para elaboração de pré-projetos que uma pequena empresa de desenvolvimento de software brasileira seguiu para ganhar competitividade, partindo de uma iniciativa de pesquisa e desenvolvimento nos ditos processos, criando e instituindo o modelo proposto além do fluxo para confecção e acompanhamento de resultados de propostas comerciais. A seção 4 apresenta uma proposta de estratégia de elaboração de pré-projetos e os resultados da aplicação do modelo além dos benefícios gerados, mesmo quando da não concretização do negócio. Finalmente na seção 5 é apresentada a conclusão e uma análise crítica do modelo além e descrição para trabalhos futuros. 2.Visão geral de especificação de requisitos de software De acordo com Ian Sommerville (Sommerville, 2003), é difícil estabelecer com exatidão o que o sistema deve fazer. As descrições das funções e das restrições são os requisitos, para o sistema; e o processo de descobrir, analisar, documentar e verificar essas funções e restrições é chamado de engenharia de requisitos. Em alguns casos um requisito é visto como uma declaração abstrata de alto nível, de uma função que o sistema deve fornecer ou de uma restrição dos sistemas. No outro extremo, ele é uma definição detalhada, matematicamente formal, de uma função do sistema. Davis (1993) explica por que essas diferenças existem: Se uma empresa deseja estabelecer um contrato para desenvolvimento de um grande projeto de software, ela tem de definir suas necessidades de maneira suficientemente abstrata para que uma solução não seja predefinida. Os requisitos devem ser redigidos de modo que a empresa desenvolvedora possa atender, talvez de diversas maneiras, às necessidades organizacionais do cliente. Uma vez estabelecido o contrato, deve-se preparar uma definição de sistema para o cliente, com mais detalhes, de modo que o mesmo possa validar o que o software fará. Wilson de Pádua Filho (Pádua, 2003), define que um fluxo de Especificação de Requisitos de Software deve descrever de forma detalhada um conjunto de requisitos que devem ser satisfeitos por uma solução implementável para um problema definido, que é por sua vez descrito em uma Proposta de Especificação de Software. Este fluxo é definido de forma estruturada propondo no caso de algum item constante do roteiro não for utilizado, o mesmo deve conter a expressão não aplicável. Define-se também um roteiro para revisão da ERS Especificação de Requisios de Software, incluindo uma lista de conferência para verificação do Modelo de Análise do Software. 3

4 2.1 Múltiplos stakeholders e requisitos de desempenho Conforme os conceitos de David S.Wile (WILE, 2001), os sistemas são desenhados para satisfazer requisitos de múltiplos stakeholders, sendo que necessariamente nenhum deles compreende o que é mais desejável ou satisfatório. Portanto é necessário unir técnicas que atendam as reais necessidades dos clientes, pois estas freqüentemente não podem ser compreendidas sem uma experiência dos efeitos provocados pelo sistema realmente em uso. Para estudar a relação entre os requisitos dos usuários e a interface usada para monitorar e garantir que eles estão sendo atendidos, é recomendado empregar uma arquitetura formal que permita medir que os requisitos estão realmente sendo atendidos. De acordo com Brian A. Nixon (NIXON, 2000), o gerenciamento de requisitos de desempenho é o maior desafio dos sistemas de informação e outros sistemas de software. Isto ocorre porque requisitos de software podem ter um impacto global nos objetivos do sistema. 2.2 Natureza e Ambiente de Especificação dos Requisitos do Software (ERS) O padrão IEEE (IEEE ), propõe algumas considerações para a natureza e ambiente da especificação de requisitos de software. 2.3 Lidando com obstáculos comportamentais Segundo Axel van Lamsweerde (LAMSWEERDE, 2000), a engenharia de requisitos se preocupa com a elicitação de objetivos de alto nível a serem alcançados pelos sistemas, seu refinamento, assim como a designação de responsabilidades pelos requisitos resultantes para determinados agentes como pessoas, equipamentos e software. Os processos de engenharia de requisitos freqüentemente resultam em objetivos, requisitos e premissas sobre o comportamento destes agentes. A carência na antecipação de comportamentos excepcionais dos requisitos relacionados com os agentes envolvidos, resulta em requisitos irreais, inatingíveis e/ou incompletos. Como conseqüência o desenvolvimento de software a partir destes requisitos não serão robustos o suficiente e inevitavelmente resultarão em baixo desempenho ou falhas, e em algumas situações com conseqüências críticas para o ambiente. O primeiro conjunto de técnicas permite que os obstáculos sejam gerados a partir da formulação dos objetivos. O segundo conjunto de técnicas permite a resolução a ser gerada uma vez que os obstáculos foram identificados. 2.4 Microsoft Solution Framework MSF O Microsoft Solutions Framework (MSF) surgiu a partir da análise de como a Microsoft desenvolveu os seus produtos por mais de 20 anos, reunindo desse modo, as melhores práticas utilizadas pela empresa (HANSEN & THOMSEN, 2004). No entanto, apesar de ser criado pela Microsoft, o MSF aborda basicamente o processo de construção de soluções, não se restringindo unicamente aos seus produtos, sendo então apresentado como independente de tecnologia. O MSF consiste num conjunto de boas práticas sem grandes detalhes, permitindo uma abordagem simples, direta e flexível, independente de linguagem de desenvolvimento. É baseado em um conjunto definido de princípios, modelos, disciplinas, conceitos, diretrizes e práticas comprovadas pela Microsoft, visando obter o sucesso do projeto. O Microsoft Solutions Framework (MSF) surgiu a partir da análise de como a Microsoft desenvolveu os seus produtos por mais de 20 anos, reunindo desse modo, as melhores práticas utilizadas pela empresa (HANSEN & THOMSEN, 2004). No entanto, apesar de ser criado pela Microsoft, o MSF aborda basicamente o processo de construção de soluções, não se restringindo unicamente aos seus produtos, é independente de tecnologia. 4

5 A Microsoft não classifica o MSF como uma metodologia, mas sim como uma disciplina. Serve basicamente como um grande guia e consiste num conjunto de boas práticas sem grandes detalhes, permitindo uma abordagem simples, direta e flexível, independente de linguagem de desenvolvimento. É baseado em um conjunto definido de princípios, modelos, disciplinas, conceitos, diretrizes e práticas comprovadas pela Microsoft, visando obter o sucesso do projeto (MICROSOFT, 2003). Embora a falta de detalhes no MSF possa parecer uma deficiência, foi essa característica que permitiu criar uma abordagem simples e direta, sendo, ainda, bastante flexível e pode ser adaptado para atender as necessidades de qualquer tipo de projeto de desenvolvimento de software e infra-estrutura de TI, independente do tamanho e da complexidade (MICROSOFT, 2003). Um dos modelos sugeridos pelo MSF é o de processos (The MSF Process Model) que prevê o ciclo de vida de um projeto. Todo projeto passa por um ciclo de vida. A função principal de um modelo de ciclo de vida é estabelecer a ordem em que as atividades de projeto são executadas. O modelo de ciclo de vida apropriado pode agilizar um projeto e ajudar assegurar que cada passo aproxime o projeto para uma conclusão bem-sucedida. Uma visão simples do clico de vida do Modelo de Processo do MSF é apresentado na figura 2. Figura 2: Modelo de processos de MSF (Fonte: MICROSOFT, 2003) O modelo de processos do MSF comporta conceitos e vantagens dos modelos cascata e espiral. Combina as vantagens do planejamento baseado em milestones previstas do modelo em cascata com as entregas iterativas e incrementais do modelo espiral. Cada fase é vista como um período de tempo com ênfase em determinado tipo de atividades (MARTINS & SILVA, 2004). O Modelo de Processo é um componente flexível do MSF que foi eficientemente usado para melhorar o controle de projeto, minimizar riscos, melhorar qualidade do produto e diminuir o tempo de desenvolvimento. As cinco fases do Modelo de Processo do MSF fazem isto de forma bastante flexível e pode ser usado para qualquer projeto de tecnologia, desenvolvimento de aplicação, desenvolvimento de infra-estrutura ou uma combinação dos dois. 5

6 O MSF também apresenta o modelo de equipe (The MSF Team Model) que sugere as atribuições, responsabilidades e objetivos de membros da equipe de projeto. A integração do Modelo de Processos com o Modelo de Equipe do MSF faz uma combinação formidável para o sucesso de projeto. Juntos, eles provêem roadmaps flexíveis, porém definido, para entrega de projetos bem-sucedidos que leva em conta a singularidade da cultura de uma organização, tipos de projeto e forças de pessoal. Segundo HANSEN & THOMSEN, 2004, muitos gerentes de projeto tendem a querer ter os melhores colaboradores em suas equipes; entretanto, sem ter um bom processo, é mais provável o projeto falhar do que quando comparado com uma equipe que começa com colaboradores com menos habilidades, mas com um bom processo. 3. Metodologia proposta para elaboração de pré-projetos A metodologia proposta está baseada nas necessidades de uma pequena empresa brasileira de desenvolvimento de software, em especial nos conceitos de engenharia de software preconizados pelo RUP Rational Unified Process, não demonstrados neste artigo e no MSF Microsoft Solution Framework. A metodologia é composta por quatro fases que definem o ciclo de vida dos projetos de desenvolvimento de software. Em cada uma destas fases existe um conjunto de atividades a ser desempenhada e culminam em marcos de aprovação, que fornece subsídios para transpor cada fase. O marco da fase de pré-projeto será a única fase a ser analisada neste documento e pode levar ao cancelamento ou parada temporária do projeto, tendo como principal ferramenta para esta decisão a Gestão de Riscos descrita na seção 4. Figura 3: Ciclo de Vida Proposto A cada ciclo do projeto um novo conjunto de artefatos documentais e de software é entregue ao cliente. As disciplinas, (não descritas neste documento) atuam com maior ou menor intensidade durante todo o ciclo de vida do processo, colaborando no cumprimento das atividades. A fase de pré-projeto provê subsídios técnicos para auxiliar a confecção de propostas comerciais aos possíveis clientes, fazendo todas as análises necessárias. O marco de aprovação da fase de pré-projeto deve conter os artefatos que indicam o problema de negócio entendido, o levantamento das necessidades do cliente e de uma visão da solução tecnológica envolvida. Desta forma o escopo do projeto fica bem estabelecido entre as partes, cliente e empresa de desenvolvimento. Os procedimentos prescritivos do processo proposto, entendidos como disciplinas, devem ser seguidos durante todo o projeto, auxiliando seu andamento conforme a necessidade, independente da fase. Os recursos devem estar sempre 6

7 atentos para as disciplinas às quais estão ligados por meio de papéis, a fim de que possam iniciá-las sempre que seja necessário. As disciplinas estão ocorrendo a qualquer momento dentro do projeto com maior ou menor intensidade, como já dito, não sendo possível descrever o momento exato de sua ocorrência. Existirão momentos que algumas disciplinas não serão utilizadas, seja em fases ou até mesmo nos projetos, cabendo aos recursos envolvidos esse tipo de decisão. As disciplinas devem ser explicadas com relação ao seu conceito e como podem ser empregadas. São seis as disciplinas propostas: Coordenação, Documentação, Solicitação, Ambiente, Risco e Teste e Homologação e como já citado anteriormente não serão tratadas neste documento. Define-se também um fluxo de trabalho que definem a seqüência eventos e agrupam atividades, e são representados por artefatos de entrada e resultantes, assim como os papéis que as executam. Os obstáculos comportamentais citados na seção 2.3 são tratados pelas diversas atividades da fase de pré-projeto, na medida em que se preocupa em capturar as necessidades do cliente entendendo o problema de negócio e fazendo um levantamento prévio da infra-estrutura, levando também em consideração os problemas de múltiplos stakeholders e requisitos de desempenho descritos na seção Fase Pré-Projeto Tem como objeivo prover subsídios técnicos para auxiliar a confecção de propostas, fazendo todas as análises pré-projeto necessárias. Seu escopo consiste em: No caso do uso de listas, deve-se usar o marcador que aparece no início desta frase; As listas devem ser justificadas na direita e na esquerda, da mesma maneira que os trechos de corpo de texto; Após as listas, deixar um espaço simples, como aparece a seguir. O estilo Lista pode ser usado para que a formatação pré-definida seja corretamente empregada. 3.2 Macro Fluxo para elaboração da proposta comercial O fluxo abaixo representa a seqüência de atividades e tomadas de decisão em nível estratégico na elaboração de pré-projetos e propostas comerciais. 7

8 Figura 4: Macro fluxo para elaboração de propostas comerciais. 4. Estratégia de elaboração e gestão de pré-projetos Para operacionalização das atividades propostas na fase de pré-projeto, é utilizada uma estratégia de elaboração de acordo com uma seqüência de passos para que os melhores resultados possíveis possam ser atingidos. Com base nos resultados obtidos o portfólio de préprojetos é gerenciado tendo como principal referência a estratégia adotada pela Superintendência de Produtos de Software, para estimar o esforço que será demandado nesta fase. 8

9 Figura 5: Estratégia para elaboração de pré-projetos 4.1 Passos para a elaboração dos pré-projetos. Estimar o tempo, custo e recursos para entender as necessidades do cliente; Estimativa do número de recursos envolvidos estrategicamente; Monitorar o risco decorrente da necessidade do cliente em obter maior nível de detalhamento X custos envolvidos decorrentes da alocação de recursos acima do planejado. 4.2 Eficiência e eficácia na elaboração de pré-projetos Figura 6: Eficiência e Eficácia na elaboração de pré-projetos (adaptado de Laurindo, 2002) Podemos entender como eficiência, a utilização correta dos procedimentos e artefatos descritos na fase de pré-projeto, ou seja, seguir o fluxo de atividades utilizando-se dos ativos de processo e alocando os melhores recursos disponíveis ao menor custo possível e com uma boa gestão de riscos. Desta forma estaríamos conseguindo um aumento de eficiência e garantindo a qualidade do processo e produto final. A eficácia consiste na geração de pré-projetos que conseguem traduzir efetivamente as necessidades dos clientes futuros na resolução de seus problemas, e não necessariamente no aceite do pré-projeto traduzindo em um negócio concretizado. 4.3 Visão macro da gestão do portfólio de pré-projetos Os resultados da elaboração dos pré-projetos são enviados à SPS que internamente executa um trabalho de análise em conjunto com as áreas envolvidas buscando pontos de melhoria para aplicação futura. A figura 8 demonstra que as metas, disponibilidade de recursos, ativos de processos e resultados dos projetos são as principais informações utilizadas para a gestão do portfólio de pré-projetos. 9

10 Figura 7: Gestão de Portfólio de Pré-Projetos ( adaptado de Kendall, 2003) 4.4 Gestão de Riscos - Estrutura Analítica de Riscos (EAR) e Matriz de Probabilidade e Impacto categorizada A gestão de riscos em pré-projeto consiste na análise da estrutura analítica dos riscos (EAR Estrutura Analítica de Riscos) de forma categorizada, com seus respectivos identificadores (ID) e seus responsáveis, que formam a base para a confecção das Matrizes de Probabilidade e Impacto para cada categoria. Como exemplo a Figura 8 apresenta duas categorias: Organizacional Interno e Externo. Figura 8: EAR Estrutura analítica de Risco 10

11 Tabela 1: Matriz de Probabilidade e impacto categorizada. ID dos Riscos Prob. MA=5 AL=4 MO=3 BA=2 MB=1 Impacto e Probabilidade: MA=Muito Alto, AL=Alto, MO=Moderado, BA=Baixo, MB=Muito Baixo Cada risco da matriz de probabilidade e impacto categorizada de acordo com o EAR.deve ser analisado (vide sub-seções e 4.4.2) pelo seu responsável em conjunto com o gerente de projeto com periodicidade pré-definida. Quando um gatilho para um risco descrito na matriz de probabilidade e impacto ocorrer, o plano de contingência deve ser disparado de acordo com o tempo de resposta. Registra-se então o risco residual após plano de contingência. A matriz de gestão de riscos residuais não é objeto de análise deste documento. Os riscos são priorizados em ordem decrescente de acordo com a coluna prioridade que é o resultado da multiplicação da coluna probabilidade pela coluna impacto. A prioridade é identificada como PR e será utilizada nas seções e Efetuar a análise nas matrizes de probabilidade e impacto categorizadas Os riscos do projeto devem ser analisados de forma global e categorizados. A análise deve seguir os passos conforme abaixo: Calcular o Índice de Criticidade do Risco (ICR e ICR%): Somar os valores da coluna prioridade (PR) para cada Matriz Categorizada dos Riscos (MCR) e dividir pela quantidade de riscos identificados (QRI). O resultado obtido é o índice de criticidade dos riscos (ICR). Para obter o ICR% divide-se o ICR pelo valor máximo possível do PR, que o exemplo é 25, ou seja 5 x 5. ICR = SUM(PR)/QRI ICR% = ICR / Max(PR) Calcular o Índice de Criticidade do Risco do Projeto (ICRP e ICRP%): Somar os valores da coluna prioridade (PR) para cada Matriz Categorizada dos Riscos (MCR) e dividir pela quantidade de riscos identificados (QRI). O resultado obtido é o índice de criticidade dos riscos do projeto ICRP. ICRP = SUM(ICR)/QTDE(MCR) ICRP% = ICRP / Max(ICRP) Impacto MA=5 AL=4 MO=3 BA=2 MB= Elaborar documento final contendo a análise dos riscos do projeto. Prioridade 3 MO AL 12 G a ti l h o Plano de Contingência (ação) Tempo de resposta Risco residual após plano de contingência A análise dos riscos é feita de forma pontual e em percentuais, sendo que a tomada de decisão pela continuidade do projeto depende da tolerância a riscos da organização assim como da importância estratégica e a relevância do projeto para a organização. A Tabela 2 apresenta os Índices de Criticidade em Pré-Projeto, usado para análise de riscos. 11

12 Tabela 2: Índices de criticidade em pré-projeto. Indíce de Criticidade em Pré-Projeto Categoria Organizacional Interno 4.5 Resultados obtidos Total dos riscos identificados: 5 Somatória das prioridades: 48 ICRP 9,6 ICRP % 38,4% Indíce de Criticidade em Pré-Projeto Categoria Organizacional Externo Total dos riscos identificados: 3 Somatória das prioridades: 37 ICRP 12,3 ICRP % 49,3% Indíce de Criticidade em Pré- Projeto - Geral Total dos riscos identificados: 8 Somatória das prioridades: 85 ICRP 10,65 ICRP % 42,5% Abaixo segue o resultado da elaboração de pré-projetos durante os anos de 2005 e 2006, no tocante a geração de negócio efetivamente. Não são abordados o porte e características dos projetos nem sua recursividade no tocante aos clientes. Tabela 4: Resultados obtidos em pré-projetos nos anos de 2006 e Totais Pré-Projetos Elaborados Pré-Projetos Aceitos % de Assertividade 56 % 71 % 66% 64% A análise dos dados no tocante ao percentual de negócios não realizados, (28% do total das propostas somando-se os totais de 2005 a 2007), registram que em 100% dos casos, os prováveis futuros clientes demonstraram interesse em concretizar o negócio em momentos futuros alegando não haver qualquer impedimento do ponto de vista da qualidade do trabalho realizado. Os valores médios de investimento para os pré-projetos aceitos representam de 8 a 16% dos custos totais envolvidos nos projetos. Um dado importante é a diminuição do percentual de assertividade no ano de 2007 se comparado ao ano de 2006, não é suficiente para caractarizar a ineficiência do modelo, pois seria necessário avaliar outras variáveis. A rentabilidade dos projetos não é analisada neste documento. Os 28 pré-projetos elaborados representam 78% do total de solicitações originadas dos possíveis clientes que usaram o modelo proposto, que denota sua utilidade. Todavia não está sendo abordada tolerância a riscos da organização. 12

13 5. Conclusão O estudo demonstrou com base pesquisa bibliográfica realizada e apresentação do modelo implementado, que uma eficiente gestão de riscos na elaboração de propostas comerciais, utilizando os conceitos preconizados pela engenharia de software e gestão eficaz de seu portfólio, é viável com um baixo investimento se comparado ao total do projeto. O enfoque proposto por Porter, quando aplicado a projetos de software mostrou-se eficiente Os resultados no ano de 2006 demonstram um crescimento de 33% na assertividade das propostas. Pode-se ainda garantir a qualidade dos pré-projetos e conseqüente confecção de propostas comerciais, aumentando a competitividade de pequenas empresas desenvolvedoras de software. Os pontos críticos do modelo apresentado residem no fato que a empresa proponente arca com todos os custos do pré-projeto, podendo a futura empresa cliente não fechar negócio, sendo imperativo a adoção de um modelo de competitividade, abordagem foca em projetos em especial no monitoramento de riscos. Embora as formas de entrega dos documentos finais sejam em meio eletrônico, permitindo apenas a impressão, e também em cadernos impressos, não há obrigatoriedade de qualquer pagamento. Esta modalidade acaba configurando os Pré-Projetos, atividades de médui a alto risco. Cabe a alta gerência das pequenas empresas desenvolvedoras de software, para o modelo proposto, a gestão do portfólio de pré-projetos em especial na análise dos custos envolvidos que não se traduzem em negócios efetivamente. Todavia a análise dos resultados dos pré-projetos recusados, demonstram que o cliente sente-se seguro em dar continuidade ao projeto. Neste ponto a gestão do portfólio de pré-projetos é um Fator Crítico de Sucesso, que também deve se preocupar com o seu balanceamento. Trabalhos futuros irão demonstrar em detalhes o monitoramento de riscos adicionais que surgem no desenvolvimento de pré-projetos assim como detalhar a sua gestão de portfólio com objetivo de minimizar os custos envolvidos, sem perder a competitividade e qualidade. Pretende-se demonstrar também a importância do PMO Project Management Office e um mapeamento de interesse e poder das partes interessadas em pré-projeto, e a importância de sua gestão ao longo das atividades dos préprojetos. Referências Bibliográficas DAVIS, A.M. Software requirements: analysis and specification. Englewookd Cliffs, NJ: Prentice Hall, (cap. 5), HANSEN, J. E.; THOMSEN, C. Enterprise Development with Visual Studio.NET, UML, and MSF. Apress, New York, IEEE. IEEE Std IEEE Recommended Practice for Software Requirements Specifications KENDALL, G. I. & ROLLINS, S. C. Advanced Project Portfólio Management and PMO: Multiplying ROI at Warp Speed, EUA: IIL Intenational Institute for Learning, Inc. amd J. Ross Publishing, Inc., 2003 LAMSWEERDE A V Handling Obstacles in Goal-Oriented Requirements Engineering- IEEE Transactions on Software Engineering, vol 26 no. 10 pp , october 2000 LAURINDO, F. J. BARBIN Tecnologia da Informação: Eficácia nas Organizações. 1ª ed. Pp 32 a 33. São Paulo: Futura,

14 MARTINS, P. V.; SILVA, A. R. Comparação de Metamodelos de Processos de Desenvolvimento de Software. In: Actas da 5ª Conferência para a Qualidade nas Tecnologias da Informação e Comunicações, pp , Portugal, Instituto Português de Qualidade MICROSOFT CORPORATION. Microsoft Solutions Framework Version 3.0 Overview, jun Disponível em: < Whitepaper.pdf> Acesso em: 02 jun NIXON, B. A. Management of Performance Requirements for Information Systems. IEEE Transaction on Software Engineering, vol 16 no. 12, pp , Dec PADUA FILHO, W. P. Engenharia de software: Fundamentos, métodos e padrões. 2. ed. Rio de Janeiro, LTC: PORTER, MICHAEL E. Vantagem competitiva: Criando e Sustentando um Desempenho Superior. São Paulo, Campus: SOMMERVILE, IAN. Engenharia de Software. 6. ed. São Paulo: Pearson Addison Wesley, WILE, DAVIS S. Residual Requirementes and Architectural Residues - IEEE International Symphosium x/01 pp ,