Mod.01.MPS Engenharia&QualidadeSoftware v.28.09.06

CURSO DE PS-GRADUAO LATO SENSU (ESPECIALIZAO) DISTNCIA MELHORIA DE PROCESSO DE SOFTWARE

INTRODUO ENGENHARIA DE SOFTWARE E QUALIDADE DE SOFTWARE

Alexandre Marcos Lins de Vasconcelos Ana Cristina Rouiller Cristina ngela Filipak Machado Teresa Maria Maciel de Medeiros

Universidade Federal de Lavras - UFLA Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE Lavras - MG

Parceria Universidade Federal de Lavras - UFLA Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE Reitor Antnio Nazareno Guimares Mendes Vice-Reitor Ricardo Pereira Reis Diretor da Editora Marco Antnio Rezende Alvarenga Pr-Reitor de Ps-Graduao Joel Augusto Muniz Pr-Reitor Adjunto de Ps-Graduao Lato Sensu Marcelo Silva de Oliveira Coordenao do curso Ana Cristina Rouiller Presidente do Conselho Deliberativo da FAEPE Edson Amplio Pozza Editorao Quality Group Impresso Grfica Universitria/UFLA

Ficha Catalogrfica Preparada pela Diviso de Processos Tcnicos da Biblioteca Central da UFLAIntroduo Engenharia de Software e Qualidade de Software / Alexandre Marcos Lins de Vasconcelos, Ana Cristina Rouiller , Cristina ngela Filipak Machado, Teresa Maria Maciel de Medeiros. Lavras: UFLA/FAEPE, 2006. 157 p. :il. (Curso de Ps-graduao Lato Sensu (Especializao) Distncia Melhoria de Processo de Software. Bibliografia. 1. Engenharia de software. 2. Qualidade. 3. Projeto. 4. Gerenciamento. 5. Desenvolvimento. I. Vasconcelos, A. M. L. de. II. Universidade Federal de Lavras. III. Fundao de Apoio ao Ensino, Pesquisa e Extenso. IV Ttulo. CDD-005.1

Nenhuma parte desta publicao pode ser reproduzida, por qualquer meio, sem a prvia autorizao da FAEPE.

SUMRIO1 Introduo .................................................................................................................11 2 O Produto de Software e a Organizao de Desenvolvimento .............................17 2.1 O Produto de Software .........................................................................................17 2.2 A Organizao de Desenvolvimento de Software ................................................19 2.2.1 Ncleo de Processamento de Dados..........................................................19 2.2.2 Pequeno Centro de Desenvolvimento.........................................................21 2.2.3 Fbrica de Software ....................................................................................22 2.3 Os Processos da ODS .........................................................................................23 3 Modelos de Ciclo de Vida do Processo de Software .............................................27 3.1 O Modelo Cascata................................................................................................27 3.2 O Modelo de Desenvolvimento Evolucionrio ......................................................31 3.2.1 O Modelo de Programao Exploratria .....................................................31 3.2.2 O Modelo de Prototipagem Descartvel .....................................................32 3.3 O Modelo de Transformao Formal....................................................................32 3.4 O Modelo de Desenvolvimento Baseado em Reuso ............................................32 3.5 Modelos Iterativos ................................................................................................33 3.5.1 O Modelo de Desenvolvimento Espiral .......................................................34 3.5.2 O Modelo de Desenvolvimento Incremental ...............................................35 3.6 Consideraes Finais ...........................................................................................36 4 Planejamento e Gerenciamento de Projetos de Software.....................................37 4.1 As Dificuldades do Gerenciamento de Projetos de Software ...............................38 4.2 Principais atividades do Gerenciamento de Projetos de Software nas ODSs ......39 4.2.1 O Planejamento do Projeto .........................................................................40 4.2.2 A Seleo de Pessoal .................................................................................41 4.2.3 O Gerenciamento de Riscos.......................................................................41 4.2.4 A Definio das Atividades, Marcos de Referncia e Produtos Entregues ao Usurio ..................................................................................................42 4.2.5 A Definio do Cronograma........................................................................42 4.3 A Gerncia de Projetos sob a tica do PMBOK...................................................43 4.3.1 Gerncia de Integrao de Projetos............................................................45 4.3.2 Gerncia de Escopo de Projetos.................................................................45 4.3.3 Gerncia de Tempo de Projetos .................................................................46 4.3.4 Gerncia de Custo de Projetos ...................................................................46 4.3.5 Gerncia da Qualidade de Projetos ............................................................47 4.3.6 Gerncia de Recursos Humanos de Projetos .............................................47 4.3.7 Gerncia de Comunicao de Projetos.......................................................47 4.3.8 Gerncia de Risco de Projetos....................................................................48 4.3.9 Gerncia de Aquisio de Projetos .............................................................48 4.4 Consideraes Finais ...........................................................................................49

5 O Processo de Desenvolvimento de Software .......................................................51 5.1 Engenharia de Requisitos ....................................................................................51 5.1.1 Caractersticas Especficas da Engenharia de Requisitos ..........................54 5.1.2 Requisitos Funcionais e No-Funcionais ....................................................57 5.1.3 O Processo de Engenharia de Requisitos ..................................................57 Elicitao .......................................................................................................58 Modelagem ....................................................................................................59 Anlise........................................................................................................... 59 Validao .......................................................................................................59 5.1.4 Modelos Conceituais e Linguagens para a Engenharia de Requisitos .......60 Linguagens Naturais ......................................................................................60 Linguagens Rigorosas ...................................................................................61 Linguagens Formais ......................................................................................62 5.1.5 Consideraes ............................................................................................62 5.2 Projeto de Software ..............................................................................................63 5.3 Implementao .....................................................................................................64 5.4 Testes de Software...............................................................................................65 5.4.1 Introduo ...................................................................................................65 5.4.2 Estgios de Teste .......................................................................................66 5.4.3 Abordagens de Teste..................................................................................66 5.4.4 Tipos de Teste ............................................................................................67 5.4.5 Responsabilidade pelos testes....................................................................67 5.4.6 Ferramentas de Teste.................................................................................68 5.5 Gerncia de Configurao....................................................................................68 5.6 Operao e Manuteno de Software ..................................................................69 5.7 Ferramentas CASE ..............................................................................................70 6 Qualidade de Software .............................................................................................73 6.1 Conceituao........................................................................................................73 6.2 Evoluo dos conceitos de qualidade ..................................................................74 6.2.1 Abordagem de W. Edwards Deming ...........................................................75 6.2.2 Abordagem de Armand Feigenbaum ..........................................................76 6.2.3 Abordagem de Joseph M. Juran .................................................................76 6.2.4 Abordagem de Philip Crosby.......................................................................77 6.2.5 Total Quality Control (TQC).........................................................................78 6.2.6 Total Quality Management (TQM)...............................................................80 6.3 Introduo Qualidade de Software ....................................................................81 6.3.1 Preveno X Deteco ...............................................................................81 Tcnicas de Preveno .......................................................................................82 Tcnicas de Deteco .........................................................................................82 6.3.2 Planejamento e Gerncia da Qualidade de Software .................................82 Planejamento da Qualidade de Software.......................................................82 Garantia da Qualidade de Software...............................................................84 Controle da Qualidade de Software...............................................................85

6.3.3 Custos da Qualidade...................................................................................85 6.4 Modelos e Padres de Qualidade de Software ....................................................87 6.4.1 As Normas ISO ...........................................................................................88 ISO12207......................................................................................................90 ISO15504......................................................................................................91 6.4.2 Os Modelos do Software Engineering Institute (SEI) ..................................95 CMMI ............................................................................................................97 6.5 Melhoria do Processo de Software.....................................................................100 6.5.1 O Modelo IDEAL .......................................................................................100 6.6 Auditorias e Avaliaes (Assessments)..............................................................101 6.6.1 Auditorias ..................................................................................................102 Tipos de Auditoria ........................................................................................102 6.6.2 Avaliaes Internas (Assessments) ..........................................................103 6.7 Medio de Software..........................................................................................105 6.7.1 Seleo de Mtricas..................................................................................105 Tcnica Goal/Question/Metric (GQM)..........................................................105 6.7.2 Uso de Mtricas para Suporte a Estimativas ............................................107 6.8 Verificaes e Validaes...................................................................................109 6.8.1 Revises Formais .....................................................................................109 Revises Tcnicas (technical reviews) ........................................................109 Inspees (inspection) .................................................................................110 Wakthroughs................................................................................................110 Revises Gerenciais ....................................................................................110 6.8.2 Inspees de Software..............................................................................111 6.9 Consideraes Finais .........................................................................................112 7 Qualidade de Produto de Software .......................................................................115 7.1 Modelo de qualidade ..........................................................................................115 7.2 Funcionalidade ...................................................................................................116 7.2.1 Adequao ................................................................................................117 7.2.2 Acurcia ....................................................................................................117 7.2.3 Interoperabilidade .....................................................................................117 7.2.4 Segurana de acesso ...............................................................................117 7.2.5 Conformidade............................................................................................118 7.3 Confiabilidade.....................................................................................................118 7.3.1 Maturidade ................................................................................................118 7.3.2 Tolerncia a falhas....................................................................................118 7.3.3 Recuperabilidade ......................................................................................119 7.3.4 Conformidade............................................................................................119 7.4 Usabilidade.........................................................................................................119 7.4.1 Inteligibilidade ...........................................................................................119 7.4.2 Apreensibilidade........................................................................................119 7.4.3 Operacionalidade ......................................................................................120 7.4.4 Atratividade ...............................................................................................120 7.4.5 Conformidade............................................................................................120

7.5 Eficincia ............................................................................................................120 7.5.1 Comportamento em relao ao tempo......................................................121 7.5.2 Utilizao de recursos...............................................................................121 7.5.3 Conformidade............................................................................................121 7.6 Manutenibilidade ................................................................................................121 7.6.1 Analisabilidade ..........................................................................................121 7.6.2 Modificabilidade ........................................................................................121 7.7 Estabilidade ........................................................................................................122 7.7.1 Testabilidade.............................................................................................122 7.7.2 Conformidade............................................................................................122 7.8 Portabilidade.......................................................................................................122 7.8.1 Adaptabilidade ..........................................................................................122 7.8.2 Capacidade para ser instalado.................................................................122 7.8.3 Coexistncia..............................................................................................123 7.8.4 Capacidade para substituir .......................................................................123 7.8.5 Aderncia ..................................................................................................123 7.9 Eficcia ...............................................................................................................124 7.10 Produtividade....................................................................................................124 7.11 Segurana ........................................................................................................124 7.12 Satisfao.........................................................................................................124 8 Concluso ...............................................................................................................126 9 Exerccios de Fixao ............................................................................................129 10 Referncias Bibliogrficas ...................................................................................131 Anexo A Padro de codificao JAVA..................................................................137

LISTA DE FIGURASFigura 1.1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto................................................................. 14 Figura 2.1: Diferenas do produto de software ........................................................... 18 Figura 2.2: Exemplo da estrutura de um NPD ............................................................ 19 Figura 2.3: Pequeno centro de desenvolvimento........................................................ 21 Figura 2.4: Organograma de uma fbrica de software................................................ 22 Figura 2.5: NPDs versus fbricas de software............................................................ 23 Figura 2.6: Estrutura para modelagem do sistema de processo da ODS. .................. 24 Figura 3.1: O modelo cascata..................................................................................... 28 Figura 3.2: O modelo cascata com iteraes.............................................................. 29 Figura 3.3: O modelo de desenvolvimento evolucionrio ........................................... 31 Figura 3.4: O modelo de transformao formal .......................................................... 32 Figura 3.5: Desenvolvimento baseado em reuso........................................................ 33 Figura 3.6: O modelo espiral....................................................................................... 34 Figura 3.7: O modelo incremental............................................................................... 35 Figura 4.1: Estrutura de um plano de projeto.............................................................. 40 Figura 4.2: Processos do gerenciamento de projetos do PMBOK. ............................. 44 Figura 4.3: reas do gerenciamento de projetos do PMBOK. .................................... 45 Figura 5.1: Erros e custo de correo......................................................................... 53 Figura 5.2: Engenheiro de requisitos X engenheiro de software ................................ 54 Figura 5.3: Processo de engenharia de requisitos...................................................... 58 Figura 5.4: Linguagens para especificao de requisitos ........................................... 60 Figura 6.1: Bases do TQC .......................................................................................... 79 Figura 6.2: Ciclo PDCA para melhorias ...................................................................... 79 Figura 6.3: Elementos-chave do TQM ........................................................................ 80 Figura 6.4: Desenvolvimento de produtos de software ............................................... 81 Figura 6.5: Viso geral do planejamento da qualidade ............................................... 83 Figura 6.6: Viso geral da garantia da qualidade ....................................................... 84 Figura 6.7: Balanceamento do custo da qualidade [Kezner1998]............................... 86 Figura 6.8: Requisitos da ISO9001/ISO9000-3........................................................... 89 Figura 6.9: Processos da ISO12207 ........................................................................... 91 Figura 6.10: As dimenses do modelo de referncia da ISO 15504........................... 92 Figura 6.11: Relacionamento entre o modelo de referncia e o modelo de avaliao..................................................................................................... 94 Figura 6.12: Utilizao da ISO15504 .......................................................................... 95 Figura 6.13: Estrutura do Capability Maturity Model for Software............................... 96 Figura 6.14:CMMI: reas de processo em duas representaes: por estgio e contnua ................................................................................................... 98 Figura 6.15: Visualizao grfica do IDEAL [MacFeeley1999] ................................. 101 Figura 6.16: Viso geral do processo de auditoria.................................................... 103 Figura 6.17: Viso geral do processo de avaliao .................................................. 104 Figura 6.18: Viso geral do processo de inspeo ................................................... 112

LISTA DE TABELASTabela 6.1: Iniciativas para melhoria da qualidade do processo de software .............87 Tabela 6.2: Normas ISO9000 para suporte ao desenvolvimento de software ............90

10

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

1INTRODUO

Atualmente, h cada vez mais sistemas controlados por software, fazendo com que a economia de praticamente todos os pases seja muito dependente da qualidade dos softwares por eles usados, justificando um investimento significativo nesse setor. H alguns anos atrs, desenvolvia-se software de uma maneira completamente artesanal. A partir de uma simples definio dos requisitos do software, partia-se imediatamente para a implementao do mesmo. Hoje em dia, ainda h muitas empresas que desenvolvem software dessa maneira, mas vrias outras esto mudando suas formas de trabalho. A forma artesanal de trabalho, geralmente, no traz grandes problemas para o desenvolvimento de software de pequeno porte, o qual no exige um esforo muito grande de implementao. Porm, para softwares de grande porte, srios problemas na implementao podem comprometer todo o projeto. Com o desenvolvimento cada vez maior da tecnologia de hardware e a conseqente disponibilidade de mquinas cada vez mais potentes e baratas, o uso de computadores tem-se tornado cada vez mais difundido em diversas reas. Isso tem feito com que aumente a demanda por software cada vez maior e mais complexo. No entanto, a demanda por software tem-se tornado maior que a capacidade do mercado para atend-la. Muitos projetos so entregues com um grande atraso, custando muito mais que o inicialmente previsto, sendo no confiveis, difceis de manter e/ou no tendo um desempenho satisfatrio. Alm do mais, na tentativa de se consertar os erros, muitas vezes introduzem-se mais erros. Geralmente, a quantidade de problemas diretamente proporcional ao aumento da complexidade do software produzido nos dias de hoje. Esses problemas no desenvolvimento de software so conhecidos mundialmente como a crise de software. Ou seja, a crise de software corresponde incapacidade da indstria de software de atender prontamente demanda do mercado de software, dentro dos custos e dos nveis de qualidade esperados.

12


Desde os anos 1960, quando o termo crise de software foi pronunciado pela primeira vez, muitos problemas desta rea foram identificados e muitos deles ainda persistem at os dias de hoje, tais como [Gibbs1994]: Previso pobre desenvolvedores no prevem adequadamente quanto tempo e esforo sero necessrios para produzir um sistema de software que satisfaa s necessidades (requisitos) dos clientes/usurios. Sistemas de software so geralmente entregues muito tempo depois do que fora planejado; Programas de baixa qualidade programas de software no executam o que o cliente deseja, conseqncia talvez da pressa para se entregar o produto. Os requisitos originais podem no ter sido completamente especificados, ou podem apresentar contradies, e isto pode ser descoberto muito tarde durante o processo de desenvolvimento; Alto custo para manuteno quando o sistema construdo sem uma arquitetura clara e visvel, a sua manuteno pode ser muito custosa; Duplicao de esforos difcil compartilhar solues ou reusar cdigo, em funo das caractersticas de algumas linguagens adotadas, por falta de confiana no cdigo feito por outra pessoa e at mesmo pela ausncia/deficincia de documentao das rotinas e dos procedimentos j construdos. O reconhecimento da existncia da crise de software tem provocado uma forte mudana na forma de como as pessoas desenvolvem software de grande porte, visto que o processo de desenvolvimento atual mais disciplinado do que no passado. Foi proposto que o desenvolvimento de software deixasse de ser puramente artesanal e passasse a ser baseado em princpios de Engenharia, ou seja, seguindo um enfoque estruturado e metdico. Assim, surgiu o termo Engenharia de Software, que se refere ao desenvolvimento de software por grupos de pessoas, usando princpios de engenharia e englobando aspectos tcnicos e no-tcnicos, de modo a produzir software de qualidade, de forma eficaz e dentro de custos aceitveis. Portanto, a Engenharia de Software engloba no apenas o desenvolvimento de programas, mas tambm toda a documentao necessria para o desenvolvimento, instalao, uso e manuteno dos programas. O temo ciclo de vida de software compreende todas as etapas, desde a concepo inicial do software, at a sua implementao, implantao, uso e manuteno, de modo que, ao final de cada uma destas etapas, um ou mais documentos so produzidos. Engenheiros de software devem adotar uma abordagem sistemtica e organizada para seu trabalho e usar ferramentas e tcnicas apropriadas, dependendo do problema a ser solucionado, das restries de desenvolvimento e dos recursos disponveis. Alm das tcnicas de especificao e implementao de software, os engenheiros de software devem ter conhecimento tambm de outras tcnicas como,

Introduo

13

por exemplo, de gerenciamento de software. Dessa forma, aumenta-se a probabilidade de produzir software de grande porte com qualidade, ou seja, software que satisfaa os requisitos do usurio, bem como as expectativas de tempo e de oramento. As ODSs (Organizaes de Desenvolvimento de Software)1, com o intuito de minimizar os problemas do desenvolvimento do software, tm geralmente adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodolgicos para desenvolvimento de software tm sido considerados somente em termos de um mtodo de anlise/projeto/implementao, isto , um conjunto de conceitos, tcnicas e notaes. Essa viso elimina os aspectos tecnolgicos, contextuais e organizacionais que potencialmente existem dentro de um processo de software. Os ambientes tradicionais das ODSs geralmente suportam apenas a engenharia do produto, assumindo um processo implcito e tendo como foco principal o produto. Essa viso tem limitado as ODSs no que diz respeito tomada de decises, ao estabelecimento e arquivamento de metas organizacionais, determinao de pontos para melhoria, estipulao de prazos para entrega de produtos e obteno de uma certificao. O captulo 2 apresenta os aspectos evolutivos das ODSs e seus produtos de software. De forma geral, pode-se dividir as funes de uma ODS em trs grupos principais [Garg1996]2: 1. Definir, analisar, simular, medir e melhorar os processos da organizao; 2. Donstruir o produto de software; 3. Medir, controlar, modificar e gerenciar os projetos de software. Estes trs grupos so abordados, respectivamente, pela Engenharia de Processo, pela Engenharia de Produto e pelo Gerenciamento de Projeto. O relacionamento entre estes grupos mostrado na Figura 1.1.

1

Uma ODS representa uma organizao independente, ou um departamento ou uma unidade dentro de uma organizao, que responsvel por desenvolver, manter, oferecer ou operar um produto ou servio de software ou um sistema de software intensivo [Wang1999]. 2 A Engenharia de Software deve considerar estas funes objetivando a produo de software de maior qualidade e a melhoria do desempenho da ODS, ou seja, torn-la mais produtiva.

14

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de SoftwareExperincias passadas Requisitos do processo Engenharia do processo Modelo do processo Gerenciamento de projeto Processo de desenvolvimento Engenharia do produto Produto de software Requisitos do projeto Requisitos do produto

Figura 1.1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto A engenharia de processo tem como meta a definio e a manuteno dos processos da ODS. Ela deve ser capaz de facilitar a definio, a anlise e a simulao de um processo, assim como estar apta a implant-lo, avali-lo, medi-lo e melhor-lo. A engenharia de processo trata os processos de software de uma forma sistemtica com um ciclo de vida bem definido. O captulo 6 aborda este tema discorrendo sobre qualidade de software, um tema cada vez mais relevante e que engloba avaliao e melhoria contnua dos processos da ODS. O gerenciamento de projeto tem o objetivo de assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessrios para um projeto produzir um produto e/ou servio de acordo com seus requisitos. Todavia, gerenciar projetos de software uma atividade complexa devido a uma srie de fatores, tais como: dinamicidade do processo, grande nmero de variveis envolvidas, exigncia de adaptabilidade ao ambiente de desenvolvimento e constantes alteraes no que foi planejado. Esses fatores dificultam o trabalho das equipes de desenvolvimento na medio do desempenho dos projetos, na verificao de pontos falhos, no registro de problemas, na realizao de estimativas e planejamentos adequados. O captulo 4 aborda esse tema. A engenharia do produto encarregada do desenvolvimento e manuteno dos produtos e servios de software. A principal figura da engenharia do produto a metodologia de desenvolvimento, que engloba uma linguagem de representao, um

Introduo

15

modelo de ciclo de vida e um conjunto de tcnicas. Os ambientes tradicionais de desenvolvimento de software tm se preocupado essencialmente com a engenharia do produto, assumindo um processo implcito e tendo como foco o produto. Todavia, a engenharia do produto por si s insuficiente para suprir as necessidades da ODS e torn-la mais produtiva e adequada s exigncias do mercado. O captulo 3 aborda os modelos de ciclo de vida mais utilizados na engenharia do produto. O captulo 5 descreve as principais atividades da engenharia de produto.

16


2O PRODUTO DE SOFTWARE E A ORGANIZAO DE DESENVOLVIMENTO

Impulsionados pelas mudanas tecnolgicas e pelo amadurecimento das atividades de desenvolvimento de software os produtos, as organizaes de desenvolvimento (ODSs) e seus processos associados mudaram no decorrer das ltimas dcadas. Este captulo faz uma retrospectiva desses elementos. A seo 2.1 e 2.2 abordam, respectivamente, a evoluo dos produtos de software e a evoluo das organizaes de desenvolvimento. A seo 2.3 apresenta os processos existentes em uma ODS, demonstrando modelos e elucidando conceitos. 2.1 O PRODUTO DE SOFTWARE Tem-se observado muitas mudanas nos produtos de software que, nos ltimos anos, surgem em prateleiras de supermercados ou mesmo disponveis gratuitamente na Web. Conseqncia do aperfeioamento tecnolgico e da maturidade no desenvolvimento de software adquiridos no decorrer dos anos. Anterior revoluo gerada pelo surgimento dos PCs (Personal Computers), o software3, geralmente, era confeccionado dentro da empresa que iria utiliz-lo. Os detalhes do negcio ento eram do conhecimento dos desenvolvedores. O software tambm era monoltico e especfico para rodar na plataforma da empresa, considerando o seu ambiente e os seus processos. De responsabilidade organizacional e no contratual, se o software executasse as funes a que se propunha, geralmente, j satisfazia os seus usurios/clientes. O produto de software hoje confeccionado pelas ODSs possui caractersticas diferenciadas, desde a sua especificao at a entrega. Em primeiro lugar, ele deve3

Utilizaremos os termos software e sistema como sinnimos, apesar do ltimo ser mais abrangente.

18


ser o mais geral, flexvel e parametrizvel possvel. Deve estar apto a rodar em empresas diferentes, que possuam inclusive processos de negcio tambm diferentes. O usurio, que determinava os requisitos do software, passou muitas vezes at mesmo a no existir, exigindo que a equipe de desenvolvimento se adaptasse e passasse a buscar o conhecimento de outras formas. Muitas sub-reas da Engenharia de Software surgiram (ou foram reforadas) para satisfazer esses novos quesitos como, por exemplo, Engenharia do Conhecimento, Engenharia de Requisitos, Arquitetura de Software, Sistemas Distribudos. Alguns fatores de qualidade passaram a ser exigidos para o produto de software. Entre esses fatores, podem-se citar os externos como usabilidade, portabilidade, manutenibilidade etc. e fatores de qualidade internos como reusabilidade, modularidade, flexibilidade etc. Uma constante melhoria no processo que desenvolve o produto tambm passou a ter relevncia, pois um processo de software de alta qualidade deve, por conseqncia, gerar um produto de alta qualidade. Pode-se dizer que qualidade uma das palavras chaves na Engenharia de Software e medida atualmente de duas formas: (1) qualidade do produto e (2) qualidade do processo. No captulo 6 sero detalhados os padres que avaliam e propem melhoria da qualidade. Outro aspecto interessante deste novo software que estamos produzindo o fato de gerar uma demanda muitas vezes ainda no existente. Podem-se citar vrios softwares que surgiram desta forma, como: o Windows, o Netscape, o Word, o Yahoo e os RPGs. A Figura 2.1 sintetiza algumas diferenas entre o produto de software que produzamos nos primrdios da computao e os que hoje so desenvolvidos.

Software

1970especializado plataforma especfica responsabilidade organizacional validao do produto monoltico,acopladol e no separvel centralizado satisfaz uma demanda elevado custo para aquisio dificil operao

2000

generalizado portvel reponsabilidade contratual qualidade do produto aberto, reusvel e modular distribudo gera uma demanda baixo custo para aquisio fcil operao

Figura 2.1: Diferenas do produto de software

O Produto de Software e a Organizao de Desenvolvimento

19

2.2 A ORGANIZAO DE DESENVOLVIMENTO DE SOFTWARE natural que um produto confeccionado com caractersticas to diferentes das iniciais tambm fosse gerado por uma ODS diferente. Nesta seo visto o quanto as organizaes mudaram para satisfazer as necessidades da confeco dos produtos de software e se adequarem s novas tecnologias e tendncias mercadolgicas. 2.2.1 Ncleo de Processamento de Dados Os primeiros tipos de computadores produzidos foram os mainframes, equipamentos caros e de difcil manuteno e operao. Uma empresa que resolvesse adquirir um equipamento deste porte sofria a imediata conseqncia de necessitar contratar, tambm, uma grande equipe para produzir e operar os softwares (tanto os desenvolvidos por ela, quanto os de suporte ao desenvolvimento). Os contratos de venda, aluguel e manuteno desses equipamentos ultrapassavam as cifras de milhares de dlares. Somente em grandes empresas, com um bom faturamento e em grandes universidades, observvamos o computador. As equipes dentro dos centros de desenvolvimento de software eram grandes e era requerida muita especializao por parte de quem desenvolvia software. As ODSs (nomeadas de ncleos ou centros de processamento de dados - CPDs ou NPDs) eram compostas, salvo algumas excees, por setores agrupados baseados nas tarefas (funes) que cada um desempenhava em relao ao desenvolvimento e operao do software. A Figura 2.2 mostra um exemplo de um organograma de um NPD.

Empresa

Ncleo de Processamento de Dados

....

....

Desenvolvimento

Suporte

Produo

Anlise

Programao

Digitao

Conferncia

Operao

Figura 2.2: Exemplo da estrutura de um NPD

20


Na diviso de desenvolvimento se concentrava a confeco do produto de software. O setor de anlise levantava informaes junto aos usurios e especificava4 logicamente e fisicamente o software, enquanto o setor de programao codificava as especificaes definidas pelos analistas de sistemas. Dentro do setor de programao poderamos observar duas equipes distintas: equipe de desenvolvimento (encarregada dos novos programas) e a equipe de manuteno (encarregada de manter os programas j desenvolvidos e em produo). A diviso de suporte possua duas caractersticas principais. A primeira era manter em funcionamento os equipamentos e os softwares, instalando e configurando, alm de ter contnua preocupao com o desempenho. A segunda caracterstica era promover a capacitao do pessoal do NPD. Isso implicava em estudo de novas tecnologias e treinamento apropriado. Devido complexidade do gerenciamento dos mainframes, a diviso de suporte requeria pessoal altamente especializado. Dar suporte operao do software e a seu desenvolvimento no era tarefa fcil. A diviso de produo era responsvel por executar, obter os resultados e implantar as informaes. O setor de digitao realizava a digitao dos documentos ou planilhas que vinham do usurio, alm dos programas do setor de programao. Devido ao pouco acesso que as pessoas tinham aos computadores, os usurios preenchiam planilhas com as informaes a serem armazenadas nos computadores para posterior processamento. O setor de conferncia conferia se havia erros nos dados digitados, se os resultados produzidos pelo processamento estavam corretos etc. Muitos artifcios eram utilizados para garantir a digitao correta dos dados, entre eles o total de lote que representava uma totalizao dos valores digitados para posterior conferncia. As execues eram solicitadas pelos usurios ou tinham datas pr-determinadas. Essas execues eram realizadas no setor de operao que tambm administrava o hardware. A documentao de um sistema era um trabalho muito rduo e cansativo. A utilizao de mquinas de datilografia, pastas mantidas manualmente etc., traziam um custo muito elevado para se manter o sistema atualizado. Por isso, alguns NPDs possuam um setor de documentao que era encarregado de realizar todas as alteraes feitas manualmente por analistas, programadores e operadores. A qualidade do produto e do processo que o confeccionava era uma preocupao constante nos NPDs. Todavia, a Engenharia de Software ainda engatinhava em seus conceitos e no havia maturidade em relao a padres de qualidade do produto e do processo de software. O alto custo do homem especializado em computao e de hora mquina obrigava tambm estas organizaes a medirem seu processo. Em4

Especificar um software neste contexto significa criar um modelo computacional, independente da plataforma computacional que ser utilizada.


21

suma, os NPDs primavam por usar uma metodologia de desenvolvimento, documentar os sistemas, medir as atividades pessoais e dar um custo para cada tarefa desenvolvida. Os pontos apontados como falhos para esta estrutura esto mais ligados tecnologia empregada do que estrutura propriamente dita. Com a sada do desenvolvimento dos NPDs para pequenas equipes de desenvolvimento em empresas especficas, houve uma perda da qualidade do processo e do produto. Inclusive tornando a computao desacreditada perante aqueles que necessitavam e/ou pretendiam desenvolver um software. 2.2.2 Pequeno Centro de Desenvolvimento A evoluo do hardware e software mudou significativamente o processo de desenvolvimento e a estrutura das organizaes. Com a chegada e barateamento dos PCs, muitas empresas de pequeno e mdio porte puderam adquirir computadores e contratar pequenas equipes para automatizar seus processos. Assim, as funes realizadas de formas distintas dentro de um NPD comearam a ser fundidas no ambiente de desenvolvimento e produo. Figuras pejorativas (e que posteriormente passaram at mesmo a incorporar carreiras organizacionais) surgiram como o programalista (programador + analista) e o anador (analista + programador). Sistemas como folha de pagamento, contas a pagar, contabilidade, controle de estoque, entre outros, invadiram as pequenas e mdias empresas. A funo supervalorizada de quem produzia software tornou-se algo to comum como um escriturrio ou um contador. A Figura 2.3 ilustra um exemplo de um pequeno centro de desenvolvimento dentro de uma empresa de pequeno ou mdio porte.

Diretoria

Pequeno centro de desenvolvimento

....

....

Figura 2.3: Pequeno centro de desenvolvimento Todavia, qual foi o problema destes pequenos centros de desenvolvimento? Em primeiro lugar tinha-se um cliente (usurio) alheio s dificuldades do desenvolvimento de software, que acreditava que qualquer programador resolveria a automao de sua empresa. E em segundo lugar, um grupo de desenvolvimento imaturo metodologicamente e, em sua maioria, descompromissado com o futuro do produto

22


que confeccionavam. Esses dois pontos trouxeram diversos problemas para a informtica. Muitas empresas, em pouco tempo, se viram merc de um software inopervel ou de difcil/impossvel manuteno. Poucos empresrios passaram a confiar em quem produzia software para solucionar os problemas ou melhorar a produtividade de seu negcio. Criou-se uma lacuna entre quem precisava do software e quem o produzia. 2.2.3 Fbrica de Software Com o intuito de preencher esta lacuna, alguns centros de desenvolvimento de software foram montados como empresas apartadas do cliente/usurio. bom deixar claro que as fbricas de software no surgiram em decorrncia de uma idia, mas sim de bons desenvolvedores que passaram a oferecer sua soluo de software para diversas empresas, assegurando uma continuidade do produto que desenvolviam. Isso possibilitava que o comprador do software tivesse uma garantia contratual de manuteno e evoluo do produto. Apesar dos sistemas perderem em especificidade, comeava a despontar uma soluo de software barato (pois era vendido para diversas empresas) e de melhor qualidade. Atualmente, as fbricas de software so realidades e se tornaram muito mais complexas do que poderamos imaginar. Alm de possurem as funes de desenvolvimento que existiam nos NPDs, somaram a si funes de negcio e administrativas, algumas at possuindo departamentos especializados em pesquisa (ver Figura 2.4). Trabalham, muitas vezes, dispersas em reas geogrficas diferentes e sub-contratam servios. So impulsionadas e avaliadas pelos mesmos quesitos de qualquer outra indstria: qualidade do produto e produtividade.

ODS

Projeto 1

(equipe do

designer, gerncia de marketing, gerncia administrativa, Engenharia

Suporte

Anlise

Figura 2.4: Organograma de uma fbrica de software


23

A Figura 2.5 caracteriza algumas diferenas entre a organizao que produzia software na dcada de 1970 e a organizao que atualmente desenvolve software. lgico que nem todas as organizaes se encaixam em uma ou outra ponta. Quando se fala, por exemplo, que no ano 2000 as organizaes esto fora da empresa que necessita do software, no se est ditando nenhuma regra absurda, apenas trata-se do mais comumente encontrado e de uma tendncia que vislumbrada.

1970

Centro de desenvolvimento de software

2000fora da empresa grandes equipes dispersasl exigencia de qualidadel lida com responsabilidade contratual processos software gerenciado processos de desenvolvimento complexos planejamento baseado em estimativas alto rodzio de pessal produz software barato

dentro da empresa que necessida do software pequenas equipes locais modela funcionalidades e necessidades da empresa processo de software ad-hoc lida com responsabilidade organizacional utilizao de metodologias + ciclo de vida planejamento precrio baixo rodzio de pessoal produz software caro

Figura 2.5: NPDs versus fbricas de software A prxima seo apresenta aspectos referentes aos processos utilizados pelas ODSs para produzir software.

2.3 OS PROCESSOS DA ODS Um processo pode ser definido como um conjunto de atividades interrelacionadas que transformam um conjunto de entradas em resultados [ISO12207:95]. Segundo a ISO15504 [ISO15504:1-9:98] processo de software um conjunto de processos utilizados por uma ODS ou um projeto de software para planejar, gerenciar, executar, monitorar, controlar e melhorar as atividades que esto relacionadas com software. O trabalho de Wang [Wang99] apresenta um framework unificado de um sistema de processo para uma ODS. A Figura 2.6 mostra este modelo, que est dividido em trs agrupamentos principais: o modelo do processo, o modelo de avaliao do processo e o modelo de melhoria do processo.

24


Modelagem do sistema de processo

Modelo do processo

Modelo de avaliao do processo

Modelo de melhoria do processo

Subsistema do processo organizacional

Subsistema do processo de desenvolvimento

Subsistema do processo de gerenciamento

Modelo de capacidade do processo

Mtodo de determinao da capacidade do processo

Modelo de melhoria baseado em avaliao

Modelo de melhoria baseado em Benchmark

Escala do desempenho da pratica

Escala da capacidade do processo

Escopo da capacidade do processo

Determinao da capacidade do processo

Agregao de capacidade do projeto

Agregao da capacidade da organizao

Figura 2.6: Estrutura para modelagem do sistema de processo da ODS O modelo do processo utilizado para descrever a organizao, sua categoria, sua hierarquia, o inter-relacionamento e as instncias dos seus processos. O modelo de processo descrito por [Wang1999] identifica trs conjuntos de subsistemas: processo organizacional, processo de desenvolvimento de software e processo de gerenciamento. Os processos organizacionais regulam as atividades que so geralmente praticadas em uma ODS acima do nvel de projeto. Os processos de desenvolvimento e de gerenciamento so interativos e, em paralelo, atuam sobre o projeto. O modelo de avaliao do processo serve para definir procedimentos para avaliar os pontos fortes e fracos dos processos da ODS, alm de identificar os pontos para melhoria. Atravs do modelo de melhoria do processo podem-se definir procedimentos sistemticos para uma efetiva melhoria do desempenho dos processos da ODS, mudando os processos correntes ou adicionando a eles novos processos para correo ou melhoria de problemas identificados. O processo de melhoria vem a seguir do processo de avaliao e o relacionamento entre eles forma um ciclo repetitivo at o processo de a ODS estar otimizado. Exemplo disso o plan-do-checkact descrito por Campos [Campos1992]. O captulo 6 detalhar os aspectos referentes avaliao e melhoria dos processos de software. Diversos modelos, normas e padres definem certificao, avaliao e melhoria para o processo de software, entre eles, podem-se citar: a ISO9000 [ISO9000-3:1997], CMM [Paulk1993] [Paulk1997], CMMI [CMMI:00], ISO15504 [ISO15504:1-9:98] e


25

BootStrap [Kuvaja1993] [Kuvaja1994]. O captulo 6 detalhar os aspectos referentes a essas normas e padres. Apesar das ODSs durante muito tempo negligenciarem a especificao e o gerenciamento de seus processos, estes sempre existiram. Porm, no h um consenso de que tipo de processo de software deva ser utilizado em uma ODS, pois alguns processos se adequam melhor a certos tipos de aplicaes do que outros. Alm disso, uma ODS pode, inclusive, possuir diversos padres de processos de software sendo utilizados em projetos distintos. O reconhecimento das necessidades dos modelos de processo de software tem deixado um amplo campo de trabalho em muitas direes. As ODSs tm verificado que definindo seus processos pode-se melhorar sua eficcia e a qualidade dos produtos e servios que realiza.

26


3MODELOS DE CICLO DE VIDA DO PROCESSO DE SOFTWARE

A fim de facilitar o entendimento do processo de desenvolvimento de software5, vrios modelos de ciclo de vida tm sido propostos. Estes modelos so descries abstratas do processo de desenvolvimento, tipicamente mostrando as principais atividades e dados usados na produo e manuteno de software, bem como a ordem em que as atividades devem ser executadas. As atividades presentes nos diversos modelos de ciclo de vida de software no so um padro; elas dependem da metodologia6 utilizada no desenvolvimento de um projeto de software. A seguir ser descrito, em detalhes, alguns dos principais modelos de ciclo de vida do processo de software. 3.1 O MODELO CASCATA O modelo de ciclo de vida mais antigo e tambm um dos mais usados o chamado modelo cascata (ou clssico) (vide Figura 3.1). Foi derivado de modelos existentes em outras engenharias e considera que o processo de desenvolvimento de software composto por vrias etapas que so executadas de forma sistemtica e seqencial. Durante a etapa de Definio de Requisitos os servios, as metas e as restries impostas ao sistema so identificados junto aos usurios do software. Nessa etapa, os requisitos identificados tambm so analisados de modo a remover inconsistncias e ambigidades. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.1.

5

Ressaltamos que processo de desenvolvimento de software est intimamente ligado engenharia do produto de software. 6 Uma metodologia um processo concreto que descreve em detalhes as atividades, passos, artefatos e respectivos responsveis envolvidos no desenvolvimento de um projeto de software. Vrias metodologias diferentes podem estar relacionadas a um modelo de ciclo de vida de software especfico.

28


Na etapa de Projeto do Sistema e do Software, os requisitos identificados so mapeados em componentes de hardware e software, de modo que o sistema possa ser posteriormente implementado. Nessa etapa, a arquitetura geral do sistema tambm estabelecida. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.2.

Figura 3.1: O Modelo Cascata Na etapa de Implementao e Testes Unitrios, o projeto de software implementado em unidades de programas, utilizando-se uma linguagem de programao. Nessa etapa, as unidades implementadas tambm so testadas para assegurar conformidade em relao s suas especificaes. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.3. Na etapa de Integrao e Teste do Sistema, as unidades de programas so integradas e testadas como um sistema completo, para assegurar que todos os requisitos do software sejam atendidos. Recomenda-se que os testes sejam feitos medida que as unidades individuais vo sendo integradas (testes de integrao) e que, ao final da integrao, o sistema completo seja testado novamente (teste de sistema). Por esse motivo, muitas vezes a Integrao considerada como parte integrante da Implementao. No captulo 5, seo 5.4, as atividades de Testes sero detalhadas. Na etapa de Operao e Manuteno, o sistema instalado e colocado em Operao. Posteriormente, quando erros forem encontrados no sistema ou quando forem solicitadas mudanas nos requisitos, o sistema entra numa etapa de Manuteno. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.6.

Modelos de Ciclo de Vida do Processo de Software

29

Na sua forma mais simples, o modelo cascata no apresenta iteraes, como visto na Figura 3.1. Na prtica, porm, o processo de desenvolvimento de software pode ter etapas que so desenvolvidas em paralelo e de forma iterativa (vide Figura 3.2), pois durante uma determinada etapa, problemas existentes na etapa anterior podem ser descobertos (ex: novos requisitos podem ser descobertos durante a realizao da etapa de projeto, o que implica uma iterao para a etapa especificao e anlise de requisitos).

Figura 3.2: O Modelo Cascata com Iteraes Outra limitao do modelo cascata que o mesmo no contempla atividades que so executadas antes do incio do ciclo de vida (ex: Estudo de viabilidade), bem como atividades que so executadas durante todo o ciclo de vida do software (ex: Planejamento e Gerenciamento, Verificao e Validao, Gerncia de Configurao e Documentao). O Estudo de viabilidade deve ser executado antes do incio do projeto de software e tem por objetivo: delinear o escopo do problema a ser resolvido; identificar alternativas de soluo; identificar seus custos e tempo para execuo; identificar potenciais benefcios para o usurio. O ideal fazer uma anlise profunda do problema para se produzir um estudo de viabilidade bem fundamentado. Na prtica, porm, tal anlise tem sido superficial devido a limitaes de tempo e de custo. Como no se tem certeza de que a proposta para a execuo do servio ser aceita pelo usurio em potencial, torna-se bastante arriscado investir muitos recursos nessa etapa.

30


O Planejamento de um projeto de software se caracteriza pela definio das tarefas a serem realizadas durante o seu desenvolvimento, bem como pela atribuio de responsabilidades, custos, prazos, marcos de referncia e recursos para a realizao das mesmas. As atividades de planejamento so executadas desde o incio do projeto at a sua finalizao. O Gerenciamento est intimamente relacionado ao planejamento e tem o foco em garantir que o desenvolvimento do projeto est ocorrendo de acordo com o planejado. Assim, o gerenciamento de um projeto de software gera feedbacks para o planejamento e re-planejamento do projeto. Associadas ao gerenciamento do projeto, esto atividades de gerncia de requisitos (gerencia as mudanas de requisitos e seus impactos durante o desenvolvimento do projeto), gerncia de configurao (gerencia verses do software e as interdependncias entre as partes componentes do software ex: documentos e programas) e gerncia da qualidade (dos produtos desenvolvidos e do processo de desenvolvimento). No captulo 4, as atividades de gerenciamento e planejamento so detalhadas; a seo 5.1 apresenta um detalhamento das atividades de gerncia de requisitos; a seo 5.5 apresenta um detalhamento das atividades de gerncia de configurao; e o captulo 6 detalha as atividades de gerncia da qualidade. As atividades de Verificao e Validao esto relacionadas gerncia da qualidade e so responsveis pelos feedbacks durante o desenvolvimento do software para as demais atividades do ciclo de vida. Na Figura 3.2, essas atividades esto relacionadas s iteraes. Basicamente, Verificao investiga, em cada etapa de desenvolvimento, se o software que est sendo construdo atende aos requisitos especificados. Como exemplos de atividades de Verificao, temos os testes unitrios, de integrao e de sistemas, os quais sero detalhados posteriormente na seo 5.4; e as revises e inspees que sero tratadas no captulo 6. A Validao investiga se as funes oferecidas pelo software so as que o usurio realmente quer, pois possvel que os requisitos especificados no atendam s reais necessidades dos usurios. As atividades de Validao caracterizam-se por contarem com a colaborao direta do usurio em suas execues. Como exemplos de atividades de Validao esto os testes de aceitao, que sero tratados na seo 5.4 e a validao de requisitos que ser tratada na seo 5.1. As atividades de Verificao e Validao so executadas durante todo o ciclo de vida do software, a fim de que erros e omisses sejam descobertos antes de serem propagados de uma etapa para outra. Isso necessrio porque quanto mais tarde erros e omisses forem descobertos, mais dispendioso fica para consert-los. A


31

diferena entre os dois conceitos pode ser mais bem entendida atravs da definio dada por Boehm [Boehm1981]: Verificao: Estamos construindo o produto da maneira certa? Validao: Estamos construindo o produto certo? A principal desvantagem do modelo cascata que boa parte do sistema no estar disponvel at um ponto adiantado no cronograma do projeto e, geralmente, difcil convencer o usurio de que preciso pacincia. Alm disso, existe a dificuldade de acomodao das mudanas depois que o processo est em andamento. Portanto, esse modelo mais apropriado quando os requisitos so bem entendidos. No entanto, h tambm algumas vantagens associadas ao modelo, pois ele oferece uma maneira de tornar o processo mais visvel, fixando pontos especficos para a escrita de relatrios e, didaticamente, uma maneira mais fcil de introduzir os principais conceitos de Engenharia de Software. Por esse motivo, as atividades do ciclo de vida do software sero detalhadas nos captulos 4 e 5 com base neste modelo de ciclo de vida. 3.2 O MODELO DE DESENVOLVIMENTO EVOLUCIONRIO O Modelo de Desenvolvimento Evolucionrio (vide Figura 3.3) subdivide-se em dois: Programao Exploratria e Prototipagem Descartvel.

Figura 3.3: O Modelo de Desenvolvimento Evolucionrio 3.2.1 O Modelo de Programao Exploratria O objetivo desse modelo o desenvolvimento da primeira verso do sistema o mais rpido possvel. Os sistemas desenvolvidos com esse modelo caracterizam-se por no terem o escopo claramente definido, ou seja, a especificao do escopo feita de forma intercalada ao desenvolvimento. Aps o desenvolvimento de cada uma das

32


verses do sistema, ele mostrado aos usurios para comentrios. Modificaes sucessivas so feitas no sistema at que o mesmo seja considerado adequado. A principal diferena dos outros modelos a ausncia da noo de programa correto. Esse modelo tem sido usado com sucesso para o desenvolvimento de Sistemas Especialistas, no contexto da Inteligncia Artificial (ex: sistemas de reconhecimento de voz, sistemas de diagnstico mdico etc.). 3.2.2 O Modelo de Prototipagem Descartvel O objetivo principal desse modelo entender os requisitos do sistema. Tem sido usado com sucesso para validar partes do sistema (Interface Grfica e aspectos do sistema relacionados arquitetura ex: performance, portabilidade etc.). Como na programao exploratria, a primeira etapa prev o desenvolvimento de um programa (prottipo) para o usurio experimentar. No entanto, ao contrrio da programao exploratria, o prottipo ento descartado e o software deve ser re-implementado na etapa seguinte, usando qualquer modelo de ciclo de vida (ex: cascata). 3.3 O MODELO DE TRANSFORMAO FORMAL Uma especificao formal (definio matemtica, no ambgua) do software desenvolvida e, posteriormente, transformada em um programa executvel (vide Figura 3.4), atravs de regras que preservam a corretude da especificao (passos de refinamento).

Figura 3.4: O Modelo de Transformao Formal Esse modelo tem sido aplicado ao desenvolvimento de sistemas crticos, especialmente naqueles onde a segurana um fator crtico (ex: sistema de controle de trfego areo). No entanto, a necessidade de habilitaes especializadas para aplicar as tcnicas de transformao e a dificuldade de especificar formalmente alguns aspectos do sistema, tais como a interface com o usurio, so fatores que limitam seu uso. 3.4 O MODELO DE DESENVOLVIMENTO BASEADO EM REUSO Esse modelo baseia-se no reuso sistemtico de componentes existentes ou sistemas COTS (Commercial-Off-The-Shelf). Durante o projeto do sistema, os componentes que podem ser reusados so identificados e a arquitetura do sistema


33

modificada para incorporar esses componentes. O sistema , ento, construdo seguindo essa arquitetura revisada. O processo de desenvolvimento divide-se nas seguintes etapas (vide Figura 3.5): Especificao de requisitos: os requisitos do sistema so especificados; Anlise de componentes: identificam-se componentes que so candidatos a serem reusados no projeto do sistema; Modificao dos requisitos: os requisitos identificados so modificados para se adequarem aos componentes a serem reusados; Projeto do sistema com reuso: o sistema projetado, utilizando-se os componentes a serem reusados; Desenvolvimento e integrao: componentes desenvolvidos e todos os componentes so integrados; Validao: o sistema validado pelo usurio final. no-existentes so

Figura 3.5: Desenvolvimento baseado em reuso Esse modelo de ciclo de vida assume que o sistema , em sua maior parte, formado por componentes pr-existentes. Assim, o processo de desenvolvimento passa a ser similar ao de uma linha de montagem. Essa abordagem de desenvolvimento tem se tornado muito importante, contudo ainda h pouca experincia com ela em larga escala. 3.5 MODELOS ITERATIVOS Os requisitos de um sistema sempre evoluem durante o curso de um projeto. Assim, a iterao do processo sempre faz parte do desenvolvimento de grandes sistemas de software. Iteraes podem ser aplicadas a qualquer modelo do ciclo de vida de software, mesmo no modelo cascata, como vimos anteriormente. Nesse contexto, h duas abordagens relacionadas que so mais adequadas para o tratamento de iteraes:

34


Desenvolvimento Espiral; Desenvolvimento Incremental. 3.5.1 O Modelo de Desenvolvimento Espiral

Acrescenta aspectos gerenciais (planejamento, controle e tomada de deciso) ao processo de desenvolvimento de software, ou seja, anlise de riscos em intervalos regulares. O processo de desenvolvimento representado como uma espiral, ao invs de uma seqncia de atividades (vide Figura 3.6). O modelo define quatro quadrantes, nos quais as atividades (gerenciais ou tcnicas) de um projeto so executadas durante um ciclo na espiral: Determinao dos objetivos, alternativas e restries: os objetivos especficos para a etapa so identificados e alternativas para realizar os objetivos e restries so encontradas; Anlise das alternativas e identificao e/ou resoluo de riscos: os riscos principais so identificados, analisados e buscam-se meios para reduzir esses riscos; Desenvolvimento e validao da verso corrente do produto: um modelo apropriado para o desenvolvimento escolhido, o qual pode ser qualquer um dos modelos de ciclo de vida; Planejamento: o projeto revisto e o prximo ciclo da espiral planejado.

Figura 3.6: O modelo espiral


35

A espiral representa o curso do projeto, onde, a cada volta, um novo produto construdo (ex: documento de requisitos, modelo de projeto, implementao etc.). Cada volta na espiral representa uma etapa no processo de desenvolvimento. No h etapas fixas como especificao ou projeto (o contedo de uma volta na espiral escolhido dependendo do produto requerido pela etapa). Os riscos so avaliados explicitamente e resolvidos ao longo do processo. 3.5.2 O Modelo de Desenvolvimento Incremental Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega so divididos em incrementos, com cada incremento representando parte da funcionalidade requerida (vide Figura 3.7). Os requisitos dos usurios so priorizados e os requisitos de mais alta prioridade so includos nas iteraes iniciais. Uma vez que o desenvolvimento de um incremento iniciado, os requisitos so "congelados", embora os requisitos possam continuar evoluindo para incrementos posteriores. Em certos aspectos similar programao exploratria. No entanto, o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento.

Figura 3.7: O modelo incremental As principais vantagens do modelo incremental so: A funcionalidade do sistema estar disponvel mais cedo, pois ela entregue a partir dos incrementos; Incrementos iniciais agem como um prottipo para ajudar a elicitar requisitos para incrementos finais; Diminuem-se os riscos de falhas no projeto como um todo; Os servios de prioridade mais alta do sistema tendem a receber mais testes.

36


3.6 CONSIDERAES FINAIS Modelos de ciclo de vida de software so descries abstratas do processo de desenvolvimento, tipicamente mostrando a seqncia de execuo das principais atividades envolvidas na produo e evoluo de um sistema de software. Existem vrios modelos de ciclo de vida e todos eles apresentam pontos positivos e negativos. Parte do trabalho do Engenheiro de Software escolher o modelo de ciclo de vida mais adequado s necessidades do cliente/usurio e da empresa que ir desenvolver o software. Nos captulos 4 e 5 as principais atividades envolvidas no processo de desenvolvimento de software, independentemente do modelo de ciclo de vida adotado, sero descritas em detalhes. O foco ser principalmente nas atividades de Gerenciamento, Requisitos e Testes, as quais esto mais intimamente relacionadas com a qualidade do produto de software. A etapa de planejamento e gerenciamento, apresentada no captulo 4, responsvel por garantir que o produto seja entregue no prazo e no custo desejados, bem como por definir critrios de acompanhamento do progresso do projeto. A qualidade do software comea a ser fomentada na etapa de requisitos, pois nessa etapa que so determinados os principais atributos de qualidade relevantes para o usurio do sistema. Finalmente, a etapa de testes um dos principais mecanismos para garantir que o produto final seja entregue com qualidade. No captulo 6 outras atividades ligadas garantia da qualidade sero abordadas.

37

4PLANEJAMENTO E GERENCIAMENTO DE PROJETOS DE SOFTWARE

Alguns estudos e pesquisas que foram realizados nos anos 1990 demonstraram que o gerenciamento de projeto a causa mais evidente das falhas na execuo e entrega de produtos e servios de software. O SEI-Software Engineering Institute constatou, j em 1993, que o principal problema que aflige as organizaes de software gerencial e preconizou que as organizaes precisam vencer o seu buraco negro, que o seu estilo de gerenciar de maneira informal, sem mtodos e sem tcnicas [Paulk1993]. Um estudo conduzido pelo DoD-Department of Defense [Dod1994] indicou que 75% de todos os sistemas de software falham e que a causa principal o pobre gerenciamento por parte do desenvolvedor e adquirente, deixando claro que o problema no de desempenho tcnico. De acordo com um estudo realizado pelo Standish Group [Standish2001], publicado no artigo Extreme CHAOS 2001, no perodo 2000/2001 apenas 28% dos projetos de desenvolvimento pesquisados nos E.U.A. obtiveram sucesso, ou seja, foram completados no tempo e no custo previstos, e possuam todas as funcionalidades inicialmente planejadas. Apesar do aumento de sucesso em relao ao ano de 1994, quando apenas 16% dos projetos conseguiram xito, este ainda um percentual bastante reduzido. Este estudo aponta o gerenciamento de software como sendo a principal razo para o sucesso ou a falha de um projeto de software. Atravs de uma anlise e acompanhamento de cem projetos de software, Jones [Jones1996] relata: os seis primeiros dos dezesseis fatores associados aos desastres do software so falhas especficas no domnio do gerenciamento de projeto, e os trs dos outros dez fatores restantes esto indiretamente associados s praticas de gerenciamento pobre.

38


Walker [Walker1997] conclui que: o desenvolvimento de software ainda imprevisvel; somente 10% dos projetos de software so entregues com sucesso dentro das estimativas de oramento e custo; a disciplina de gerncia , portanto, mais um discriminador de sucesso ou falha dos projetos. Muitas pesquisas enfatizam que o gerenciamento a principal causa do sucesso ou fracasso dos projetos de software. Apesar disso, o gerenciamento de projetos de software ainda pouco abordado e praticado nas ODSs [Machado2001]. Jones [Jones1999] destaca que a ausncia de um processo de gerenciamento apropriado, aliado a estimativas deficientes de custo e de tempo, uma das principais causas das falhas dos projetos de software. Os principais padres e normas para SPA/SPI (Software Process Assessment/ Software Process Improvement) tm colocado o gerenciamento de projetos como um dos requisitos bsicos para que uma empresa inicie a melhoria de seu processo. Contudo, a introduo de padres e normas dentro das ODSs tem se mostrado complexa demais, alm de causar uma sobrecarga de trabalho significativa. Segundo Belloquin [Belloquin1999], esses padres e normas definem prticas que devem ser realizadas, porm no determinam como execut-las. O captulo 6 ir discorrer sobre esses padres. 4.1 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE J em 1989, Humphrey [Humphrey1989] constatou que: a ausncia de prticas administrativas no desenvolvimento de software a principal causa de srios problemas enfrentados pelas organizaes, tais como: atrasos em cronogramas, custo maior do que o esperado e presena de defeitos, ocasionando uma srie de inconvenincias para os usurios e enorme perda de tempo e de recursos. Ainda hoje esta afirmao tem sido confirmada por diversos autores. Na atual cultura das ODSs, o planejamento, quando ocorre, feito de forma superficial [Weber1999] [Sanches2001]. A maioria dos projetos de software realizada sem um planejamento de como a idia modelada, durante o levantamento de requisitos e necessidades dos clientes, pode ser transformada em produto. Os gerentes de projeto esto desacostumados a estimar [Vigder1994]. Quando estimam, costumam basear-se em estimativas passadas, mesmo sabendo que elas podem estar incorretas (no sabem tambm precisar o quanto elas esto incorretas). H gerente que se recusa a estimar somente por julgar perda de tempo, uma vez que se corre o risco de obter resultados incorretos e, portanto, estar desperdiando tempo. Boas estimativas de custo, esforo e prazo de software requerem um processo ordenado que defina a utilizao de mtricas de software, mtodo e ferramenta de

Planejamento e Gerenciamento de Projetos de Software

39

estimativa. As ODSs, de forma geral, no detm conhecimentos e recursos para isso [Vigder1994]. Estimar, medir e controlar um projeto de software tarefa difcil, pois o desenvolvimento de software uma atividade criativa e intelectual, com muitas variveis envolvidas (como metodologias, modelos de ciclo de vida, tcnicas, ferramentas, tecnologia, recursos e atividades diversas). Os gerentes inexperientes tentam cumprir prazos dando a mxima velocidade na fase inicial e esto despreparados para os momentos de impasse, quando os ajustes so inevitveis. A dinamicidade do processo de software dificulta tambm o gerenciamento efetivo de projetos de software, devido s alteraes constantes nos planos de projetos, redistribuio de atividades, incluso/excluso de atividades, adaptao de cronogramas, realocao de recursos, novos acordos com os clientes, entregas intermedirias no previstas etc. Um projeto de software tambm deve adaptar-se ao ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe. 4.2 PRINCIPAIS ATIVIDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE NAS ODSS A gerncia de projetos trata do planejamento e acompanhamento das atividades voltadas a assegurar que o software seja entregue dentro do prazo previsto e de acordo com os requisitos especificados pelas organizaes que esto desenvolvendo e adquirindo o software. O gerenciamento de projeto necessrio porque o desenvolvimento de software est sempre sujeito a restries de oramento e cronograma. Gerentes lutam para cumprir os objetivos dos projetos, os quais tm prazos finais difceis de serem cumpridos. Freqentemente, os sistemas que so entregues no satisfazem aos usurios, os gastos com manuteno so muito grandes e os prazos no so cumpridos. Muitas vezes, esses problemas ocorrem no por incompetncia das pessoas, mas por falha nas tcnicas de gerncia empregadas nos projetos. Nas prximas subsees, sero abordados os aspectos envolvidos com a gerncia de projetos de software. O gerenciamento de um projeto de software difere de outros projetos de engenharia porque, no caso do software, o produto no concreto (a anlise do progresso do projeto depende de sua documentao). No existe um processo padro de gerncia e grandes sistemas de software so normalmente desenvolvidos uma nica vez, o que restringe o reuso de informaes de projetos anteriores. Dependendo da empresa e do projeto, as atividades mais comuns da gerncia so:

40


4.2.1

Escrever a proposta do projeto; Fazer estimativas do projeto (custo, tempo etc.); Definir marcos de referncia; Analisar os riscos; Fazer o planejamento e o cronograma do projeto; Selecionar e avaliar pessoal; Fazer acompanhamento e revises; Escrever os relatrios de acompanhamento; Fazer apresentaes sobre o projeto. O Planejamento do Projeto

uma atividade contnua, desde a concepo inicial do sistema, at a sua entrega. Os planos devem ser revisados regularmente, medida que novas informaes se tornam disponveis. Caso seja necessrio, os planos devem ser atualizados. O plano de projeto um documento que descreve as atividades, os recursos e o cronograma usados para o desenvolvimento do sistema. Uma possvel estrutura para esse documento descrita na Figura 4.1.

Figura 4.1: Estrutura de um plano de projeto


41

4.2.2 A Seleo de Pessoal Nem sempre possvel conseguir as pessoas ideais para trabalharem num projeto devido a limitaes, tais como: Oramento de projeto pode no permitir o uso de pessoal altamente qualificado e, conseqentemente, bem pago; Pessoal com experincia apropriada pode no estar disponvel; Pode fazer parte da poltica da organizao desenvolver as habilidades dos empregados durante um projeto de software. Ou seja, projetos podem ser usados como forma de treinar o pessoal. Assim, gerentes tm de alocar o pessoal disponvel, dentro das restries impostas. Muitas vezes, tambm papel do gerente participar da seleo para a contratao de pessoal para um projeto. 4.2.3 O Gerenciamento de Riscos Um risco uma probabilidade de que alguma circunstncia adversa acontea. O gerenciamento de riscos trata da identificao dos riscos e da preparao de planos para minimizar os seus efeitos no projeto. Riscos podem ser classificados de acordo com vrios critrios. Uma possvel classificao seria: Riscos de projeto: afetam cronogramas ou recursos; Riscos de produto: afetam a qualidade ou desempenho do software que desenvolvido; Riscos de negcio: afetam a organizao que est desenvolvendo ou adquirindo o software. O processo de gerenciamento de riscos pode ser dividido nas seguintes atividades: Identificao dos riscos: identificar os riscos de projeto, produto e negcio. Esses riscos podem estar associados escolha da tecnologia, das pessoas, mudanas de requisitos, estimativas do projeto etc.; Anlise dos riscos: avaliar a probabilidade e as conseqncias dos riscos. Uma possvel classificao para a probabilidade e para as conseqncias pode ser: Probabilidade: muito baixa, baixa, moderada, alta ou muito alta. Conseqncia: catastrfica, sria, tolervel ou insignificante; Planejamento dos riscos: preparar planos, definindo estratgias para gerenciar os riscos. As estratgias podem ser:

42


- Estratgias para evitar o risco: a probabilidade de que o risco surja reduzida. - Estratgias para minimizar o risco: O impacto do risco no projeto ou no produto ser reduzido. - Planos de contingncia: se o risco surgir, os planos de contingncia trataro aquele risco; Monitoramento dos riscos: monitorar os riscos ao longo do projeto. Avalia cada risco identificado regularmente para decidir se ele est se tornando menos ou mais provvel. Tambm avalia se as conseqncias do risco tm se modificado. Cada risco-chave deve ser discutido nas reunies de progresso do gerenciamento. 4.2.4 A Definio das Atividades, Marcos de Referncia e Produtos Entregues ao Usurio Associados s atividades, podem existir marcos de referncia (milestones) ou produtos. Um marco de referncia um ponto final, bem definido, de uma etapa ou atividade. A escolha dos marcos de referncia e das suas freqncias de produo est relacionada ao modelo de ciclo de vida utilizado no projeto. Por exemplo, num projeto desenvolvido utilizando o ciclo de vida em cascata, ao final de cada etapa de desenvolvimento, pode haver um marco de referncia. Nesse caso, um possvel marco de referncia seria o modelo de anlise e projeto, o qual seria produzido ao final da etapa de mesmo nome. Os marcos de referncia podem ser tambm associados concluso de uma atividade. Nesse caso, um marco de referncia associado a uma atividade da etapa de anlise e projeto poderia ser a produo de um diagrama especfico do modelo, como, por exemplo, um diagrama de classes, produzido por uma atividade associada a essa etapa de desenvolvimento. Por outro lado, um produto a ser entregue ao cliente (deliverable) diferencia-se do marco de referncia justamente pelo fato de que nem todos os marcos de referncia so entregues ao cliente. Ou seja, produtos so marcos de referncia, mas marcos de referncia no so necessariamente produtos. 4.2.5 A Definio do Cronograma O cronograma divide o projeto em tarefas e estima o tempo e os recursos requeridos para completar cada tarefa. Sempre que possvel, devem ser definidas tarefas concorrentes de modo a fazer o melhor uso do pessoal. Outra premissa que deve ser levada em conta tentar definir as tarefas que so independentes umas das outras. Isso evita atrasos causados por uma tarefa que est esperando por uma outra


43

ser completada. No entanto, a definio de bons cronogramas depende da intuio e da experincia dos gerentes de projeto. Ou seja, no existe uma cincia exata que determine a melhor forma de se construir um cronograma. Dentre os principais problemas relacionados confeco de um cronograma, pode-se citar: Estimar o esforo associado resoluo dos problemas e, conseqentemente, o custo do desenvolvimento de uma soluo difcil; A produtividade no proporcional ao nmero de pessoas que esto trabalhando numa tarefa; Adicionar pessoas a um projeto atrasado pode fazer com que ele se atrase ainda mais. Isso ocorre devido ao overhead da comunicao; O inesperado sempre acontece. Sempre permita a contingncia no planejamento e uma folga no cronograma; As tarefas no devem ser muito pequenas, de modo que no haja uma interrupo constante dos desenvolvedores pelo gerente do projeto. Assim, recomendado que as tarefas tenham a durao entre uma e duas semanas. 4.3 A GERNCIA DE PROJETOS SOB A TICA DO PMBOK Ao se abordar o planejamento e a gerncia de projeto no se pode deixar de citar o PMBOK Project Management Body of Knowledge, criado pelo PMI Project Management Institute. O PMI (www.pmi.org) uma associao de profissionais de gerenciamento de projetos que existe desde 1969. Essa associao criou em 1986 a primeira verso do PMBOK Project Management Body of Knowledge. O PMBOK um guia que descreve a somatria de conhecimento e as melhores prticas dentro da profisso de gerenciamento de projetos. um material genrico que serve para todas as reas de conhecimento, ou seja, tanto para construo de um edifcio como para a produo de software. A meta do gerenciamento de projetos, segundo o PMBOK conseguir exceder as necessidades e expectativas dos stakeholders7. Todavia, satisfazer ou exceder essas necessidades envolve um balanceamento entre as vrias demandas concorrentes em relao a: Escopo, tempo, custo e qualidade (objetivos do projeto); Stakeholders com necessidades e expectativas diferenciadas;

Requisitos identificados (necessidades) e requisitos no identificados (expectativas).7

O PMBOK [PMBOK2000] define stakeholders como sendo os indivduos ou as organizaes que esto ativamente envolvidos em um projeto, cujos interesses podem afetar positivamente ou negativamente o resultado da execuo do projeto.

44


O PMBOK [PMBOK2000] organiza os processos de gerenciamento de projetos em cinco grupos (Figura 4.2): processos de inicializao, processos de planejamento, processos de execuo, processos de controle e processos de finalizao.

Processos de Inicializao

Processos de Planejamento

Processos de controle

Processos de execuo

Processos de finalizao

Figura 4.2: Processos do gerenciamento de projetos do PMBOK Os processos de inicializao autorizam o incio do projeto ou de uma fase do projeto. Os processos de planejamento definem e refinam os objetivos do projeto selecionando as melhores alternativas para realiz-lo. Os processos de execuo coordenam pessoas e outros recursos para a realizao do projeto, baseando-se no planejamento. Os processos de controle monitoram e medem o progresso do que est sendo executado, com o intuito de tomar aes corretivas, quando necessrias. Os processos de finalizao formalizam o aceite e a finalizao do projeto ou de uma fase do projeto. Os processos do PMBOK esto organizados por reas de conhecimento, que se referem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentro dessas reas de conhecimento os cinco grupos de processos acima descritos podem ocorrer. A Figura 4.3 mostra as 9 reas de conhecimento do PMBOK. A seguir sero descritos os processos de cada rea de conhecimento do PMBOK. Todos os processos das reas abaixo descritos interagem uns com os outros e tambm com os processos das demais reas de conhecimento. Cada processo pode envolver esforo de um ou mais indivduos ou grupos de indivduos dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelo menos uma vez em cada fase do projeto.


45

Gerncia de Projeto

Gerncia de Integrao

Gerncia de Escopo

Gerncia de Tempo

Gerncia de Custo

Gerncia de Qualidade

Gerncia de Recursos Humanos

Gerncia de Comunicao

Gerncia de Risco

Gerncia de Aquisio

Figura 4.3: reas do gerenciamento de projetos do PMBOK 4.3.1 Gerncia de Integrao de Projetos A gerncia de integrao engloba os processos necessrios para garantir que os vrios elementos de um projeto sejam propriamente coordenados. Objetiva realizar as negociaes dos conflitos entre objetivos e alternativas do projeto, com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a execuo do plano de projeto e o controle geral das mudanas. Essa rea de processo incluiu os seguintes processos principais: Desenvolvimento do plano do projeto - agregar os resultados dos outros processos de planejamento construindo um documento coerente e consistente; Execuo do plano do projeto - levar a cabo o projeto atravs da realizao das atividades nele includas; Controle geral de mudanas - coordenar as mudanas atravs do projeto inteiro. 4.3.2 Gerncia de Escopo de Projetos A gerncia do escopo do projeto inclui os processos requeridos para assegurar que o projeto inclua todo o trabalho necessrio, e to somente o trabalho necessrio,

46


para complementar de forma bem sucedida o projeto. A preocupao fundamental compreende definir e controlar o que est ou no includo no projeto. Essa rea de processo incluiu os seguintes processos principais: Iniciao - comprometer a organizao a iniciar a prxima fase do projeto; Planejamento do escopo - desenvolver uma declarao escrita do escopo como base para decises futuras do projeto; Detalhamento do escopo - subdividir os principais subprodutos do projeto em componentes menores e mais manejveis; Verificao do escopo - formalizar a aprovao do escopo do projeto; Controle de mudanas de escopo - controlar as mudanas do escopo do projeto. 4.3.3 Gerncia de Tempo de Projetos A gerncia de tempo do projeto objetiva garantir o trmino do projeto no tempo certo. Consiste da definio, ordenao e estimativa de durao das atividades, e de elaborao e controle de cronogramas. Essa rea incluiu os seguintes processos principais: Definio das atividades - identificar as atividades especficas que devem ser realizadas para produzir os diversos subprodutos do projeto; Seqenciamento das atividades - identificar e documentar as relaes de dependncia entre as atividades; Estimativa da durao das atividades - estimar a quantidade de perodos de trabalho que sero necessrios para a implementao de cada atividade; Desenvolvimento do cronograma - analisar a seqncia e as duraes das atividades e os requisitos de recursos para criar o cronograma do projeto; Controle do cronograma - controlar as mudanas no cronograma do projeto. 4.3.4 Gerncia de Custo de Projetos A gerncia de custo tem por objetivo garantir que o projeto seja executado dentro do oramento aprovado. Consiste no planejamento dos recursos, estimativa, oramento e controle de custos. Essa rea de processo incluiu os seguintes processos principais: Planejamento dos recursos - determinar quais recursos (pessoas, equipamentos, materiais) e que quantidade de cada deve ser usada para executar as atividades do projeto;


47

Estimativa dos custos - desenvolver uma estimativa dos custos dos recursos necessrios implementao das atividades do projeto; Oramento dos custos - alocar as estimativas de custos globais aos itens individuais de trabalho; Controle dos custos - controlar as mudanas no oramento do projeto. 4.3.5 Gerncia da Qualidade de Projetos A gerncia da qualidade objetiva garantir que o projeto satisfar as exigncias para as quais foi contratado. Consiste de planejamento, garantia e controle de qualidade. Essa rea de processo incluiu os seguintes processos principais: Planejamento da qualidade - identificar quais padres de qualidade so relevantes para o projeto e determinar a forma de satisfaz-los; Garantia da qualidade - avaliar periodicamente o desempenho geral do projeto buscando assegurar a satisfao dos padres relevantes de qualidade; Controle da qualidade - monitorar os resultados especficos do projeto para determinar se eles esto de acordo com os padres de qualidade relevantes e identificar as formas para eliminar as causas de desempenhos insatisfatrios. 4.3.6 Gerncia de Recursos Humanos de Projetos A gerncia de recursos humanos objetiva garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento organizacional, alocao de pessoal e definio de equipe. Essa rea de processo incluiu os seguintes processos principais: Planejamento organizacional - identificar, documentar e designar as funes, responsabilidades e relacionamentos de reporte dentro do projeto; Montagem da equipe - conseguir que os recursos humanos necessrios sejam designados e alocados ao projeto; Desenvolvimento da equipe - desenvolver habilidades individuais e do grupo para aumentar o desempenho do projeto. 4.3.7 Gerncia de Comunicao de Projetos A gerncia de comunicao tem por objetivo principal garantir a gerao adequada e apropriada, coleta, disseminao, armazenamento e disponibilizao da informao.

48


Essa rea de processo incluiu os seguintes processos principais: Planejamento das comunicaes - det

Documents

Mod.01.MPS Engenharia&QualidadeSoftware v.28.09.06