1

UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia

CONSULTORIA DA EMPRESA SOFTWARE DEVELOPER PIM VII

Guarulhos/SP 2012

UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia

CONSULTORIA DA EMPRESA SOFTWARE DEVELOPER PIM VII

Nome: Daniel Forli Terra Nova RA: 1100630 Curso: Tecnologia da Informao Semestre: 4 Semestre

Guarulhos/SP 2012

RESUMO Com o avano tecnolgico e cientfico, o ambiente empresarial vem sofrendo vrias transformaes, entre elas, o acirramento competitivo da concorrncia. Surge assim, a necessidade de inovao de servios para a sobrevivncia dessas empresas. No entanto, alguns fatores crticos tendem a se destacar: o poder de inovar de forma rpida e eficiente e o aprimoramento sob grandes restries de recursos no desenvolvimento e desempenho desses projetos. Com base nesta abordagem so apresentadas ferramentas voltadas para a soluo dessas deficincias.

Palavras-chave: Inovao de servios, Transformao, Restrio de recursos.

ABSTRACT Once the sport of chess was reported as the text itself, "A game purely cerebral," ie, the players depend only on their reasoning ability to analyze all possibilities of play. Nowadays it is not the same thing, there are computer programs, such as Sheredder which is one of the most advanced programs for this type of sport that comes to analyze 200 million possible moves per second, and the ability to a professional sport that only come to look into possibilities of on average 50 minutes per move. This has brought many features to these competitors, because they can study these programs and develop plays that would be impossible to do before. However, there are some players who make professional use of such programs to cheat in this sport. Thus we consider that there is always a positive and a negative in this breakthrough technology developed by, because while some use to an improvement in their performance in a responsible manner and the other Indonesian uses recklessly.

Keywords: Innovation of work, Transformation, Restriction of recourse.

SUMRIO
1.INTRODUO....................................................................................................... 6 2.DESENVOLVIMENTO............................................................................................ 6 2.1.4. Objetivo....................................................................................................... 9 2.1.6. Fase do processo de gerncia de risco......................................................10 2.1.7. Fase do ciclo de vida.................................................................................11 O mtodo poder ser aplicado em qualquer fase do ciclo de vida do projeto, do software ou periodicamente. A deciso sobre quando aplicar o mtodo de responsabilidade da organizao ou do gerente de projeto.................................11 2.1.8. Pblico alvo............................................................................................... 11 3. Gerenciamento de risco.................................................................................. 11 5.1. Ferramentas de qualidade............................................................................18 6.CONCLUSO...................................................................................................... 20 7.REFERENCIAS.................................................................................................... 22

1. INTRODUO A empresa Este projeto busca informaes tericas e metodolgicas, aplicando os conhecimentos adquiridos nas matrias estudadas, e com base nos pontos levantados por Gartner, no texto, (Projeto Aplicao Desempenho, no Tempo e no Oramento), onde ele trata da dificuldade de entregar um projeto dentro do prazo e do oramento previamente estabelecido; com a perspectiva de compreender o quanto estes pontos interferem no mercado brasileiro de TI.

2. DESENVOLVIMENTO 2.1. Reviso da Literatura Um projeto um empreendimento temporrio, com data de incio e fim, cujo objetivo criar ou aperfeioar um produto ou servio. Gerenciar um projeto atuar de forma a atingir os objetivos propostos dentro de parmetros de qualidade determinados, obedecendo a um planejamento prvio de prazos (cronograma) e custos (oramento). Ou seja, dadas as metas e as restries de recursos e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos. Este captulo apresenta uma introduo gerncia de risco, a motivao para o estudo do tema, a declarao do escopo e do objetivo e a estrutura geral da dissertao. 2.1.1. Apresentao A rea de engenharia de software tem produzido vrios modelos de melhoria, processos, mtodos e ferramentas para aumentar a probabilidade de que os projetos de software tenham sucesso (PRESSMAN, 1997) (SOMMERVILLE, 1996). Apesar de todos esses esforos, a literatura relata a falha nos projetos como algo comum (WALLACE, 1999) (Defense Science Board, 1994) (STANDISH, 1995) (SOMMERVILLE, 1996) (PRESSMAN, 1997) (ROYCE, 1998). A falha nos projetos vem sendo discutida em algumas pesquisas, como a apresentada por Gartner em fevereiro de 20011 no link http://www.gartner.com/technology/metrics/application-development-projects.jsp, na

qual destacado: Projeto Aplicao Desempenho, no Tempo e no Oramento, onde segundo ele o desempenho do projeto frequentemente medido em termos de oramento ou de tempo, segundo ele com 57 por cento dos projetos de desenvolvimentos de aplicativos concluda no prazo, e 67 por cento dos projetos entregues dentro do oramento, muitas organizaes de TI atribuem a sua incapacidade para cumprir o cronograma do projeto ao escopo inicial pobre, aumento de escopo do projeto e restries de recursos. Em 1992 e 1993, mais de 60% dos projetos pesquisados nos Estados Unidos (EUA) estavam atrasados e mais da metade ultrapassava em 50% o prazo planejado, Curtis e Statz (CURTIS & STATZ, 1996). Um estudo conduzido em 1999 por Gordon (GORDON, 1999) indicou que somente 37% dos Sistemas de Informao (SI) foram finalizados no prazo estipulado. Adicionalmente, dos 63% dos projetos que atrasaram, 42% seriam finalizados acima do oramento. O Standish Group, atravs de um estudo chamado de relatrio do Chaos (STANDISH, 1995), identificou que as empresas dos Estados Unidos gastaram US $81 milhes em projetos de software que foram cancelados em 1995, sendo que 31% dos projetos de software estudados foram cancelados antes de estarem concludos, 53% excederam mais do que 50% a sua estimativa de custo e somente 9% dos projetos, em grandes empresas, foram entregues no tempo e oramento previstos; para empresas de pequeno e mdio porte, os nmeros melhoraram de 50% para 28% e de 9% para 16%. Projetos pesquisados nos Estados Unidos (EUA) estavam atrasados e mais da metade ultrapassava em 50% o prazo planejado, Curtis e Statz [CURTIS & STATZ, 1996]. Um estudo conduzido em 1999 por Gordon [GORDON, 1999] indicou que somente 37% dos Sistemas de Informao (SI) foram finalizados no prazo estipulado. Adicionalmente, dos 63% dos projetos que atrasaram 42% seriam finalizados acima do oramento. O Standish Group, atravs de um estudo chamado de relatrio do Chaos [STANDISH, 1995], identificou que as empresas dos Estados Unidos gastaram US $81 milhes em projetos de software que foram cancelados em 1995, sendo que 31% dos projetos de software estudados foram cancelados antes de estarem concludos, 53% excederam mais do que 50% a sua estimativa de custo e somente 9% dos projetos,

em grandes empresas, foram entregues no tempo e oramento previstos; para empresas de pequeno e mdio porte, os nmeros melhoraram de 50% para 28% e de 9% para 16%. Para o sucesso do desenvolvimento de software. O sucesso do projeto est baseado em oportunidades e benefcios e em riscos. Oportunidades e benefcios tratam o valor do produto a ser entregue; e riscos tratam das incertezas de se obter o produto dentro do custo, tempo, esforo e qualidade estimada. Qualquer deficincia em alguma rea do tringulo (Figura 1-1) se manifestar nos riscos do projeto. Tringulo mgico da fora do desenvolvimento de software

Pelo exposto anteriormente, fica evidente que projetos de software lidam com um alto nvel de incertezas, oriundas das mais diversas fontes, dentre elas, a mudana de tecnologia, a imaturidade nos processos, a adequao do perfil tcnico para exercer uma atividade e a mudana contnua de requisitos. As incertezas so uma fonte de risco em potencial. A gerncia de risco importante principalmente porque ajuda as pessoas a evitar desastres, evitar retrabalho, evitar cancelamento de projetos e estimular uma situao de sucesso nos projetos de software.

2.1.2 . Principais Problemas Um dos principais efeitos negativos dos projetos de software o no atendimento ao seu prazo e custo. Esse fato evidenciado nas pesquisas descritas anteriormente onde Curtis & Statz (CURTIS & STATZ, 1996) focam o prazo ao invs do custo, do esforo e da qualidade. A pesquisa de Gordon (GORDON, 1999) tambm enfatizou a preocupao com o atendimento ao prazo, pois foi a sada de projeto onde o percentual de desvio foi o maior, 63% de atraso. J a matria publicada pelo instituto de Gartner em fevereiro de 2011 destaca o oramento e o prazo de entrega como os dois principais indicadores para medir a eficincia dos projetos. Estes Softwares de baixa qualidade (erros e no conformidade com requisitos) tira a confiana do cliente sobre o produto. 2.1.3. Gerncia de risco Os primeiros passos para a gerncia de risco so a identificao dos riscos e a sua quantificao. A identificao importante porque o conhecimento prcondio para as aes de controle. J a definio quantitativa de risco tende a diminuir a subjetividade na avaliao do risco, mostrando aos gerentes de projeto e aos nveis diretivos da organizao qual a probabilidade do projeto alcanar ou no os seus objetivos. Um mtodo para identificar e quantificar risco utilizar a definio de cenrios para alguns riscos tpicos como, por exemplo, custo, prazo, recurso e qualidade de produto. Cada cenrio possui fatores que podem ser categorizados de vrias formas, tais como, econmico, tcnico e comportamental, esses fatores so comumente chamados de fatores de risco ou indutores de risco porque, se presentes no projeto de software, podem afet-lo tanto positiva quanto negativamente.

2.1.4. Objetivo O objetivo de todo projeto entregar todo o escopo pr-definido, com a qualidade esperada pelo cliente, dentro do prazo e dos custos orados.

10

2.1.5. Escopo O escopo descreve os limites do projeto e define o que o projeto entregar, que dados sero necessrios e como a organizao ser afetada. Dado um conjunto de recursos e o tempo, um nmero infinito de coisas pode ser entregue. Administrao de Mudana de Escopo inicia como o prprio nome revela, quando h uma mudana no escopo do projeto. Se o gerente de projeto no fez um bom trabalho ao definir o escopo, ser difcil de administr-lo durante o projeto. O propsito proteger a viabilidade da Definio de Projeto atual que foi aprovada pelo cliente. No momento em que o projeto foi definido, foram estabelecidas expectativas quanto ao que o projeto iria produzir para certo custo e em certo perodo de tempo. Voc e o patrocinador tinham aquelas expectativas em mente quando a Definio de Projeto foi desenvolvida e aprovada. Durante a vida de um projeto, pode haver uma necessidade de itens que so diferentes ou no includos. No processo de definio do escopo, as habilidades necessrias vo ficando mais claras. Nesse momento, importante formar uma equipe com competncia e com experincia nas reas de atuao do projeto. Em projetos em que h muito conhecimento tcnico envolvido, surge a figura de um profissional com grande conhecimento tcnico e com capacidade de liderana entre os tcnicos. Em geral um profissional com credibilidade junto aos demais tcnicos e com muita bagagem. A experincia desse especialista pode economizar muito tempo e dinheiro no projeto. Em suma: definir o escopo, no fundo saber o que deve ser feito para atender a necessidade do cliente.

2.1.6. Fase do processo de gerncia de risco A Para a definio do escopo da pesquisa e do mtodo de identificao e quantificao de risco foi definida: a fase do processo de gerncia de risco onde ter destaque privilegiado, a fase do ciclo de vida do projeto e do software em que o

11

mtodo ser aplicado, o pblico alvo para o qual o mtodo foi construdo, a origem dos fatores de risco e as limitaes da pesquisa. As fases do processo de gerncia de risco escolhidas e que sero cobertas pelo mtodo a ser desenvolvido so a identificao e a quantificao dos riscos, pois no se pode gerenciar o que no se conhece e no se pode controlar o que no se pode medir (DEMARCO, 1982).

2.1.7. Fase do ciclo de vida

O mtodo poder ser aplicado em qualquer fase do ciclo de vida do projeto, do software ou periodicamente. A deciso sobre quando aplicar o mtodo de responsabilidade da organizao ou do gerente de projeto.

2.1.8. Pblico alvo O mtodo proposto para ser utilizado pelo gerente de projeto da organizao desenvolvedora de software. Entretanto, isso no limita a sua utilizao por todos os envolvidos, como por exemplo: clientes, equipe tcnica e gerentes. 2.1.9. Origem dos fatores de risco As origens dos fatores de risco tratados so relacionadas aos projetos de desenvolvimento, focando-se no prazo do projeto. Esto fora do escopo da pesquisa fatores relacionados a desastres naturais, doenas de funcionrios, epidemias, greves e sabotagem.

3. Gerenciamento de risco
Dentro

do

gerenciamento

de

risco

as

tcnicas

dedutivas

sero

extremamente necessrias, pois iro analisar se os valores lgicos estipulados para as premissas so verdadeiros ou falsos. Na anlise de premissas cada projeto concebido e desenvolvido com base em um conjunto de hipteses ou premissas. Esta uma tcnica que explora as

12

incertezas das verdadeiras. Essas premissas imprecisas, inconsistentes ou incompletas devero ser identificadas e descritas para, posteriormente poderem ser avaliadas. O Microsoft Operations Framework (MOF) e suas SMFs (funes de gerenciamento de servios) oferecem orientaes para operaes de TI eficazes. Os guias das SMFs foram desenvolvidos para proporcionar orientao operacional a organizao que implantaram ou planejam implantar tecnologias Microsoft em um centro de dados ou em outros tipos de ambiente de computao empresarial. Esses guias fornecem tambm informaes conceituais, prticas recomendadas e procedimentos detalhados relacionados aos inmeros processos de SMF. Embora todas as SMFs do MOF desempenhem um papel fundamental na confiabilidade e eficcia do ambiente de produo de uma organizao, algumas so particularmente essenciais para o gerenciamento de patches. So elas:

* Gerenciamento de alteraes * Gerenciamento de configurao * Gerenciamento de verso * Gerenciamento de segurana * Gerenciamento e controle de servio * Administrao de sistema * Gerenciamento de incidentes * Gerenciamento de problemas * Gerenciamento de disponibilidade J o Microsoft Solutions Framework (MSF), foi criado em 1994 para apoiar a execuo dos servios de consultoria a Microsoft. O MSF para a gerncia de risco possui as seguintes atividades:

Identificar riscos: Apresentar os riscos equipe para que possam ser tratados antes de impactarem no projeto.

13

Analisar riscos: Converter dados de risco em informaes para utilizao da equipe de projeto para a tomada de decises. A anlise assegura que a equipe est trabalhando nos riscos corretos. Nessa fase, deve ser gerada a lista dos 10 mais riscos (Top 10). Planejar riscos: Construir planos que suportaro a tomada de deciso e as aes. Planejar envolve gerncia de risco. Acompanhar riscos: Monitorar a situao dos riscos e as aes para reduzi-los. o desenvolvimento de aes para enderear riscos individualmente, priorizar aes para os riscos e criar um plano integrado de

Controlar riscos: Transferir a gerncia de risco para as atividades do dia-adia.diferentes. 3.1. Administrar riscos

O risco se refere a condies ou circunstncias futuras que existem fora do controle da equipe de projeto que tero impacto adverso no projeto. Se um assunto j um problema que deve ser lidado, com o risco um potencial conflito. Gerentes de projetos reativos solucionam os problemas medida que eles surgem. Os gerentes proativos tentam identificar e solucionar problemas potenciais antes que eles ocorram. Isto a cincia e arte da Administrao de Riscos. J nos projetos pequenos que normalmente no tm longa durao, no existe muitas oportunidades para que os problemas se desenvolvam. Projetos maiores sempre tm riscos espreitando no horizonte. A administrao de risco envolve identificar todos os riscos potenciais para o projeto, determinando a probabilidade de que eles venham a ocorrer, e entender o consequente impacto sobre o projeto. Com essas informaes, a equipe de projeto pode determinar que riscos devem ser ativamente administrados. Por exemplo, um risco com uma probabilidade

14

alta de acontecer e um impacto grande no projeto devia ser definitivamente administrado proativamente. Por outro lado, um risco que tem uma probabilidade alta de acontecer, e um impacto imaginrio no projeto, provavelmente pode ser ignorado.

Uma vez que voc identifique quais riscos deseja administrar ativamente, existem cinco atitudes que voc pode adotar:

* Deixar de lado: Voc deixa um risco de lado se voc determinar que seu projeto no seria afetado se o risco ocorrer ou que no h nada que possa ser feito para tratar o risco e voc est disposto a assumir que nada de mau ocorrer.

* Monitorar o risco: Neste caso, o gerente de projeto no faz nada para minimizar o risco, mas o monitora para ver se mais ou menos provvel acontecer com o passar do tempo. Se aparecer mais provvel que acontea mais tarde, a equipe deve trat-lo no tempo certo. * Evitar o risco: Evitar o risco significa eliminar a condio que est causando o problema. Por exemplo, riscos associados com um fornecedor em particular podem ser evitados se outro fornecedor for usado. * Repassar o risco: Em alguns casos, responsabilidade de administrar um risco poder ser removido do projeto e repassada para outra entidade ou para terceiros. * Minimizar o risco: Na maioria dos casos, esta a abordagem a adotar. Se um risco for identificado e se tomar uma preocupao, voc pode desenvolver um planejamento proativo para assegurar-se de que o risco no acontea.Assim como com as mudanas de escopo, no existe nada inerentemente errado em ter riscos em um projeto. Os

15

clientes no esperam que um projeto seja livre de riscos. O que importa a resposta da administrao do projeto. Se riscos so identificados e ativamente administrados, o projeto tem uma chance muito maior de sucesso. Se riscos so ignorados, o projeto ser profundamente afetado quando os riscos se tornarem conflitos. Naquela ocasio, pode haver menos opes para resoluo sem comprometer o projeto. 4. Metodologia Uma metodologia um processo a seguir que d maior controle sobre os recursos que sero utilizados no projeto. Controlando melhor o processo a equipe ser mais eficiente, pois entregar o projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia importante porque permite evitar prticas que levam ao insucesso e com isso produzir o sucesso. A opo pela metodologia deve ser tomada a partir de alguns fatores: as exigncias de cada mercado em que a empresa atua a disponibilidade de mo-deobra e a cultura organizacional necessria para adot-la. 4.1. Principais modelos de metodologia de TI Os principais modelos de metodologia existentes para a rea da Tecnologia da Informao so: COBIT, CMMI, PMBOK, PRINCE2, ITIL, Seis Sigma, Balanced Scorecard, BS 7799 (ISO/IEC 27001 e ISO/IEC 17799), ISO 9001:2000, ISO/IEC 12207, ISO 9126, MR mps, Modelos Fornecedores (Microsoft Operations Framework, Microsoft Solutions Framework, Sun Tone, HP IT SMRM e RUP Rational Unified Process)copiados. 4.2. O Gerenciamento do Nvel de Servios

A NBR ISO 9000 define qualidade como grau no qual um conjunto de caractersticas inerentes satisfaz a requisitos (Associao Brasileira de Normas Tcnicas, 2000:7). A partir dessa definio, pode se resumir gesto da qualidade, portanto, como a forma de gesto de uma organizao, definida pela alta direo, tendo como base as necessidades dos seus clientes, baseada na identificao de requisitos e qualidade do produto ou servio, no estabelecimento de um planejamento para que esse padro seja atingido e na constante busca pela

16

melhoria, em todos os seus aspectos, visando satisfao dos clientes e a eficcia da organizao. Os princpios de gesto da qualidade podem ser utilizados pela alta direo para conduzir a organizao melhoria do seu desempenho. A seguir, esses princpios so apresentados, tendo sido extrados na ntegra da NBR ISO 9000 publicada em dezembro de 2000:

* Foco no cliente: Organizaes dependem de seus clientes, e, portanto recomendvel que atendam s necessidades atuais e futuras do cliente, os seus requisitos e procurem exceder as suas expectativas. * Liderana: Lderes estabelecem a unidade de propsito e o rumo da organizao. Convm que eles criem e mantenham um ambiente interno, no qual as pessoas possam estar totalmente envolvidas no propsito de atingir os objetivos da organizao.

* Envolvimento de pessoas: Pessoas de todos os nveis so a essncia de uma organizao, e seu total envolvimento possibilita que as suas habilidades sejam usadas para o benefcio da organizao. * Abordagem de processo: Um resultado desejado alcanado mais eficientemente quando as atividades e os recursos relacionados so gerenciados como um processo. * Abordagem sistmica para a gesto: Identificar, entender e gerenciar os processos inter-relacionados como um sistema contribui para a eficcia e eficincia da organizao no sentido de esta atingir os seus objetivos. * Melhoria contnua: Convm que a melhoria contnua do desempenho global da organizao seja seu objetivo permanente.

17

* Abordagem factual para tomada de deciso: Decises eficazes so baseadas na anlise de dados e informaes. * Benefcios mtuos nas relaes com os fornecedores: Uma organizao e seus fornecedores so interdependentes, e uma relao de benefcios mtuos aumenta a capacidade de ambos de agregar valor. Uma organizao fundamentada pelos princpios da gesto da qualidade deve estar direcionada holisticamente para a produtividade, qualidade e competitividade de seus produtos e servios. Os benefcios resultantes desse enfoque no so somente os relacionados qualidade intrnseca do produto ou servio, mas tambm os relacionados gesto de custos, riscos e recursos, incluindo a gesto de recursos humanos A qualidade, portanto, precisa ser administrada, ela no acontece sozinha. Efetivamente, deve envolver cada pessoa que atua no processo e ser aplicada atravs de toda a organizao (Oakland, 1994:19). Dessa forma, entende-se que a definio da poltica da qualidade pela alta direo de uma organizao somente ser implantada, de fato, como resultado de um amplo e consistente processo de comunicao, que deve resultar no comprometimento e envolvimento de todos os colaboradores, uma vez que a gesto da qualidade est fundamentada em uma viso integrada dos processos, sistemas e recursos disponveis na organizao. 4.3. Metodologia Cientfica

Foram A Metodologia Cientfica trata de mtodos e cincia. A atividade preponderante da metodologia a pesquisa. O conhecimento humano caracterizase pela relao estabelecida entre o sujeito e o objeto. Qualquer estudo cientfico supe e requer uma prvia pesquisa bibliogrfica, seja para sua necessria fundamentao terica, ou mesmo para justificar seus limites e para os prprios resultados. Cervo e Bervian (1996, p. 48) afirmam que a pesquisa bibliogrfica meio de formao por excelncia. Como trabalho cientfico original, constitui a pesquisa propriamente dita na rea das Cincias Humanas. Como resumo de assunto, constitui geralmente o primeiro passo de qualquer pesquisa cientfica. Todos os trabalhos cientficos podem adotar uma estrutura comum. Apesar de os trabalhos cientficos tratarem de temas diferentes e, com distintos propsitos,

18

variarem materialmente, pode coincidir formalmente numa sequncia comum. Segundo Salvador (1982): (...) a composio de um trabalho cientfico pode ser expressa da seguinte forma: antecipar o que vai transmitir o que se havia proposto e declarar o se sequncia compreende a introduo, o desenvolvimento do trabalho e a concluso. Portanto a pesquisa cientfica desenvolve-se mediante utilizao de conhecimetos disponveis, mtodos, tcnicas e outros procedimentos, que vo desde a adequada formulao do problema at a satisfatria apresentao dos resultados. 5. Ferramentas Em As empresas cada vez mais necessitam certificar atravs de poltica e aes. Fazer qualidade procurar a satisfao dos clientes em primeiro lugar. A verificao deste princpio fez com que muitas empresas de sucesso dominassem o mercado de produto e servio nos ltimos anos. As ferramentas analisadas a seguir so as mais utilizadas no TQC, mas no so as nicas. Essas ferramentas so usadas por todos em uma organizao e so extremamente teis no estudo associado s etapas ao fazer rodar o ciclo. Segundo Yoshinaga (1988:80), "As ferramentas sempre devem ser encaradas como um MEIO para atingir as METAS ou objectivos". Meios so as ferramentas que podem ser usadas para identificar e melhorar a qualidade, enquanto a meta onde queremos chegar (fim). A qualidade no pode estar separada das ferramentas bsicas usadas no controle, melhoria e lanejamento da qualidade, visto estas fornecerem dados que ajudam a compreender a razo dos problemas e determinam solues para elimin-los.

5.1. Ferramentas de qualidade

5.1.1. Diagrama de Pareto

As um grfico de barras que ordena as frequncias das ocorrncias, da maior para a menor, possibilitando a pr-ordenao dos problemas. Indica ainda a curva de percentagens acumuladas, a maior utilidade deste diagrama a de permitir

19

uma fcil visualizao e reconhecimento das causas ou problemas mais relevantes, possibilitando a centralizao de esforos sobre os mesmos. 5.1.2. Histograma O Histograma um grfico formado por retngulos unidos em que a base equivale ao intervalo de classes e a sua altura frequncia. A construo de histogramas tem carter prvio em qualquer estudo e um importante indicador da distribuio de dados. Na qualidade esta ferramenta utilizada para analisar determinados problemas. 5.1.3. Diagrama de causa e efeito Foi desenvolvido por Kaoru Ishikawa em 1953, na Universidade de Tquio, para representar a relao entre alguns efeitos que poderiam ser medidos e o conjunto de possveis causas que produzem o efeito. O diagrama causa e efeito uma representao grfica que permite visualizar facilmente a cadeia de causas e efeitos do problema. O diagrama mostra a relao entre as caractersticas da qualidade e os fatores e representa a relao entre o efeito de todas as possibilidades de causas que contribui ara esse efeito. 5.1.4. Grfico de controle Segundo Rossato (1996) os grficos de controlo servem para examinar se o processo est ou no sob controlo, usando mtodos estatsticos para observar as mudanas dentro do processo, baseado em dados de amostragem. Estes grficos do a informao de como o processo se comporta num determinado tempo, isto , se ele est dentro dos limites pr-estabelecidos, assinalando a necessidade de procurar a causa da variao. Os grficos de controlo so constitudos por trs linhas paralelas em que cada uma delas representa um limite o controlo, assim:

* Linha central representa o valor mdio do caracterstico de qualidade; * Linha superior representa o limite superior do controlo; * Linha inferior representa o limite inferior do controlo fichrio.

20

5.1.5 Fluxograma O fluxograma um tipo de diagrama que pode ser interpretado atravs de uma representao grfica de um processo, normalmente feita com grficos que ilustram e forma simples a transio de informao entre elementos que o compe. O uso do fluxograma possibilita: * Preparar o aperfeioamento de processos empresariais, ou seja, necessrio conhecer para melhorar; * Identificar as atividades crticas para o processo; * Conhecer a sequncia e encadeamento das atividades dando uma viso do fluxo do processo; * Documentao do processo para anlises futuras, adequar a normas e certificaes e esclarecer sobre o funcionamento para pessoas recm-admitidas na organizao; * Fortalecer o trabalho em equipa quando o desenvolvimento dos fluxogramas feito com a participao de todos os envolvidos.

6.

CONCLUSO

A Todo o desenvolvimento desse trabalho um mtodo para identificar e

gerenciar risco de atendimento ao prazo e custo, contribuindo para a indstria de software gerenciar esses riscos de forma eficiente. A definio de escopo de responsabilidade de gerncia de risco e so comparadas para que seja possvel um entendimento dos seus objetivos. Desta forma a proposta dessa dissertao encontrar fatores de riscos componentes do cenrio do projeto para apoiar os gerentes de projeto na identificao e estimativa dos riscos de atendimento ao prazo e oramento em

21

determinados projetos. Isso no quer dizer que o gerente de projeto no poder contar com a ajuda de especialistas na identificao de riscos, principalmente se ele no conhecer o negcio, o cliente, a tecnologia ou for novo na organizao. Ela confirma a importncia da gerncia para a seleo e controle dos prazos e oramentos nos projetos, fornecendo assim, uma visibilidade sobre como tratar projetos dentro da organizao. Fica comprovado que a gerncia de risco importante porque considera no somente o processo, pessoa e tecnologia, que fazem parte do desenvolvimento do software em si, mas tambm aspectos administrativos da empresa, como por exemplo, a influncia poltica da organizao e do cliente no projeto. Com o uso de uma metodologia eficiente evita-se o desperdcio de esforo, custo e prazo. Que so um dos maiores problemas encontrados hoje na rea de TI. Uma metodologia um conjunto de regras de como conduzir um projeto com sucesso, mas importante que j tenha se mostrado eficiente dentro da sua empresa, de preferncia em situao semelhante que voc est vivendo no projeto atual. Desse modo, a metodologia resulta de um conjunto de procedimentos a serem de processos e tcnicas, que garante a legitimidade do saber obtido. A engenharia de software aborda uma srie de prticas e tecnologias, e o seu enfoque seu impacto na produtividade e qualidade de software. Nas ferramentas analisadas pode-se perceber o valor da sua utilizao, elas so baseadas em computadores que auxiliam atividades de engenharia de software, desde a anlise de requisitos e modelagem at programao de testes. Os usos destas ferramentas facilitam a entrega do projeto no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitaes de tempo e oramento.

22

7. REFERENCIAS ASSOCIAAO BRASILEIRA DE NORMAS TCNICAS. Sistemas de gesto e qualidade fundamentos e vocabulrio: NBR ISO 9000. Rio de Janeiro, 2000. CERVO, Amando Luis; BERVIAN, Pedro Alcino. Metodologia Cientfica. So Paulo: Makron Books, 1996. CURTIS, Bill; STATZ, Joyce. Building the case for software process improvemente. In. SEI NATIONAL CONFERENCE SOFTWARE PROCESS GROUP, 1996, Atlanta, Proceending... Atlanta, 1996. DEFENSE SCIENCE BOARD.Report of the defense science board task force on acquiring defense software commercially. Washington, D.C., June 1994. GORDON, Smith A. To error is human, to estimate, divine Information Week, p. 6572, jan. 1999. http://www.cfc.org.br/contedo.aspx?codmenu=283 http://www.dq.fct.unl.p/QOF/chem7.html http://www.microsoft.com/library/media/1046/brasil/corporativo/images/img3.gif http://www.ogerente.com.br/qual/dt/qualidade-dt.diagrama causa efeito.html http://labino.cefetrs.edu.br/professores/johnsoprano/controle%20da %20qualidade/ferramentas%20da%20qualidade.pdf PRESMAN, Roger S. Software engineering-a practitioners approach. 5 ed. New York: McGraw-Hill, 1997. ROYCE, Walker. Software project management-a unified framework.Massacshusetts: Addison Wesley Longman, 1998. OAKLAND, John S. Gerenciamento de Qualidade Total (TQM). So Paulo: Nobel,1994. SALVADOR, ngelo Domingos.Mtodos e tcnicas de pesquisa bibliogrfica. Porto Alegre: Sulina 1998. THE STANDISH GROUP.Chaos.1995. Disponvel em: www.standishgroup.com/visitor/voyahes.html