CRISTIANO CAMPOS SILVA KLEYTON FARIAS DE SOUSA SAMUEL DIAS DANTAS

METODES METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE

Monografia apresentada como requisito parcial para aprovao na disciplina Trabalho de Concluso de Curso TCC, do Curso de Bacharelado em Sistemas de Informao da Faculdade Cenecista de Braslia, sob orientao do Professor Esp. Andr Gustavo Bastos Lima.

CEILNDIA DF NOVEMBRO DE 2006

FACULDADE CENECISTA DE BRASLIA FACEB

Aprender e Conviver Credenciada pela Portaria MEC n. 998, de 14/07/2000.

CURSO DE SISTEMAS DE INFORMAO

Reconhecido pela Portaria do MEC N.. 591, de 28 de fevereiro de 2005.

Trabalho de Concluso de Curso TCC

rea de Concentrao: Engenharia de Software.

Alunos: Cristiano Campos Silva, Kleyton Farias de Sousa e Samuel Dias Dantas.

Monografia aprovada em: Ceilndia, 11 de dezembro de 2006.

Banca Examinadora

_________________________________________________ Prof. Esp. Andr Gustavo Bastos Lima (Orientador)

_________________________________________________ Prof. Esp. Jos Eduardo Amaral de Oliveira Teixeira

_________________________________________________ Prof. MsC. Cludio da Silva Lobo

_________________________________________________ Prof. Esp. Lus Marcelo Morici Bisinotto

RESUMO Este trabalho visa apresentar a METODES, metodologia de desenvolvimento de software, desenvolvida sob as consideraes e o contexto acadmico da Faculdade Cenecista de Braslia (FACEB). Essa metodologia foi concebida para fornecer aos alunos do curso de Bacharelado em Sistemas de Informao da FACEB, uma opo vivel para auxlio na realizao do Trabalho de Concluso de Curso que envolva o desenvolvimento de software. Tem-se como resultado deste trabalho a descrio da METODES, que apresenta um conjunto de disciplinas e atividades bsicas para o desenvolvimento iterativo e incremental de software, adotando a UML como linguagem para modelagem de sistemas. Alm disso, recomenda um conjunto de ferramentas e modelos de artefatos para ser utilizado no processo de desenvolvimento. Para chegar a esses resultados, realizou-se pesquisa bibliogrfica nas obras dos principais autores da Engenharia de Software. Foi feita, tambm, uma comparao entre processos comerciais para desenvolvimento de software, RUP, XP e PRXIS, alm da observao emprica da realizao trabalhos dos trabalhos dos alunos do segundo semestre de 2006. Palavras-chave: Software. Processo de Desenvolvimento. Metodologia. Engenharia de Software. UML.

ABSTRACT This paper presents METODES, a Softwares Development Methodology, designed to attend the considerations and the academic context of the Faculdade Cenecista de Brasilia (FACEB). This Methodology was conceived to help out the alumni of the Graduation in Informational Systems of FACEB, an option that excells in auxiliaring the Final Work of is course that envolves the development of the Software. Regarding the results of this paper, the description of METODES was obtained as a presentation of disciplines and basic activities to the interative development and advance of this software, adopting an UML as a language to model the systems. Beyond that, it recommends a set of tools and artifact models to be utilized in the process of development. To get to these results, a bibliographic research with a deep look into the authorss approaches in the field of Software Engineering. Also, a comparison was made between the commercial processes of the Softwares Development, RUP, XP and Praxis, moreover, the empiric observation of the alumni of the second semester of 2006. Key words: Software. Development Process. Methodology. Sofware Engineering. UML.

Escrever software como cultivar, caar lobisomem ou abater dinossauros num fosso de piche.
(Fred Brooks, 1995)

SUMRIO
1 INTRODUO ................................................................................................................................................ 12 2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ....................................................................... 15 2.1 Definio .................................................................................................................................................... 15 2.2 Modelos de ciclo de vida........................................................................................................................... 16 2.2.1 Modelo cascata.................................................................................................................................... 16 2.2.2 Modelo iterativo e incremental ........................................................................................................... 18 2.3 Software na viso do usurio ................................................................................................................... 19 2.4 A engenharia de software e sucesso no desenvolvimento ...................................................................... 20 2.5 Qualidade de software.............................................................................................................................. 21 2.6 Norma NBR ISO/IEC 12207.................................................................................................................... 22 2.7 Mtricas e estimativas de software.......................................................................................................... 23 2.8 Processos comerciais de desenvolvimento de software .......................................................................... 25 2.8.1 RUP - Rational Unified Process.......................................................................................................... 25
2.8.1.1 Caractersticas do RUP..................................................................................................................................25 2.8.1.2 Elementos do RUP ........................................................................................................................................26 2.8.1.3 O ciclo de vida RUP......................................................................................................................................26 2.8.1.4 Benefcios......................................................................................................................................................26

2.8.2 XP - Extreme Programming................................................................................................................ 27

2.8.2.1 Processo do XP..............................................................................................................................................27 2.8.2.1.1 Metodologia de desenvolvimento no XP...............................................................................................27 2.8.2.1.2 Programao..........................................................................................................................................28

2.8.3 PRAXIS - Processo para Aplicativos Extensiveis e Interativos.......................................................... 29 2.9 As principais atividades de um processo de desenvolvimento .............................................................. 30 2.9.1 Gerenciamento do processo de desenvolvimento ............................................................................... 30 2.9.2 Levantamento de requisitos ................................................................................................................ 31 2.9.3 Anlise ................................................................................................................................................ 34 2.9.4 Projeto................................................................................................................................................. 37 2.9.5 Implementao.................................................................................................................................... 38 2.9.6 Testes .................................................................................................................................................. 40 2.9.7 Implantao......................................................................................................................................... 41 3 METODES - DISCIPLINAS ........................................................................................................................... 43 3.1 Apresentao da METODES ................................................................................................................... 43 3.1.1 Perspectivas da METODES ................................................................................................................ 44
3.1.1.1 Perspectiva de disciplinas..............................................................................................................................44 3.1.1.2 Perspectiva de blocos ....................................................................................................................................45 3.1.1.3 Perspectiva de papis.....................................................................................................................................46

3.2 Concepo.................................................................................................................................................. 48 3.2.1 Definio............................................................................................................................................. 48 3.2.2 Atividades ........................................................................................................................................... 49

3.2.2.1 Contextualizao do problema ......................................................................................................................50 3.2.2.1.1 Descrio do cliente ..............................................................................................................................50 3.2.2.1.2 Descrio do negcio ............................................................................................................................50 3.2.2.1.3 Descrio do problema..........................................................................................................................51 3.2.2.2 Levantamento de requisitos ...........................................................................................................................52 3.2.2.3 Soluo do problema .....................................................................................................................................55

3.2.3 Resultados da disciplina...................................................................................................................... 56 3.3 Gesto do projeto...................................................................................................................................... 57 3.3.1 Definio............................................................................................................................................. 57 3.3.2 Atividades ........................................................................................................................................... 58
3.3.2.1 Elaborao do plano de projeto .....................................................................................................................58 3.3.2.2 Solicitao de mudanas................................................................................................................................59 3.3.2.3 Controle de artefatos .....................................................................................................................................60 3.3.2.4 Controle de requisitos....................................................................................................................................62 3.3.2.5 Controle de qualidade....................................................................................................................................62

3.3.3 Resultados da disciplina...................................................................................................................... 63 3.4 Detalhamento de requisitos...................................................................................................................... 64 3.4.1 Definio............................................................................................................................................. 64

3.4.2 Atividades ........................................................................................................................................... 67

3.4.2.1 Classificao e priorizao dos requisitos .....................................................................................................67 3.4.2.2 Detalhamento dos requisitos funcionais ........................................................................................................68 3.4.2.3 Prototipao...................................................................................................................................................69 3.4.2.4 Detalhamento dos requisitos no-funcionais .................................................................................................71 3.4.2.5 Documentao dos requisitos ........................................................................................................................71 3.4.2.6 Homologao e validao dos requisitos.......................................................................................................72

3.4.3 Resultados da disciplina...................................................................................................................... 72 3.5 Anlise e projeto ....................................................................................................................................... 73 3.5.1 Definio............................................................................................................................................. 73 3.5.2 Vises de anlise................................................................................................................................. 75
3.5.2.1 Viso da arquitetura.......................................................................................................................................75 3.5.2.2 Viso da infra-estrutura .................................................................................................................................76 3.5.2.3 Viso da segurana........................................................................................................................................76

3.5.3 Atividades ........................................................................................................................................... 76

3.5.3.1 Definio das vises de anlise .....................................................................................................................77 3.5.3.1.1 Arquitetura de software.........................................................................................................................80 3.5.3.1.2 Arquitetura de comunicao..................................................................................................................80 3.5.3.1.3 Ativos fsicos.........................................................................................................................................81 3.5.3.1.4 Softwares...............................................................................................................................................81 3.5.3.1.5 Classificao e proteo dos dados .......................................................................................................81 3.5.3.1.6 Trfego seguro das informaes............................................................................................................82 3.5.3.1.7 Persistncia e recuperao dos dados ....................................................................................................82 3.5.3.1.8 Segurana fsica ....................................................................................................................................83 3.5.3.2 Detalhamento do modelo de classe................................................................................................................83 3.5.3.3 Projeto de interfaces grficas.........................................................................................................................84 3.5.3.4 Realizao de casos de usos ..........................................................................................................................85 3.5.3.5 Projeto de banco de dados .............................................................................................................................86 3.5.3.6 Projeto de interfaces com sistemas ................................................................................................................86

3.5.4 Resultados da disciplina...................................................................................................................... 86 3.6 Construo ................................................................................................................................................ 87 3.6.1 Definio............................................................................................................................................. 87 3.6.2 Atividades ........................................................................................................................................... 89
3.6.2.1 Construo da interface grfica .....................................................................................................................89 3.6.2.2 Codificao do elemento de software............................................................................................................90 3.6.2.3 Teste do elemento de software ......................................................................................................................90 3.6.2.4 Documentao do elemento de software .......................................................................................................91 3.6.2.4.1 Documento de cdigo de componente ..................................................................................................92 3.6.2.4.2 Manual do usurio.................................................................................................................................92 3.6.2.4.3 Manual de instalao do software .........................................................................................................93

3.6.3 Resultados da disciplina...................................................................................................................... 93 3.7 Teste Funcional ......................................................................................................................................... 94 3.7.1 Definio............................................................................................................................................. 94 3.7.2 Atividades ........................................................................................................................................... 95
3.7.2.1 Elaborao do Plano de Realizao do Teste Funcional................................................................................96 3.7.2.2 Definio de ambiente operacional para teste ...............................................................................................96 3.7.2.3 Executar Plano de Realizao do Teste Funcional ........................................................................................96 3.7.2.4 Avaliao de resultados.................................................................................................................................97

3.7.3 Resultados da disciplina...................................................................................................................... 97 3.8 Implantao............................................................................................................................................... 98 3.8.1 Apresentao....................................................................................................................................... 98 3.8.2 Atividades ......................................................................................................................................... 100
3.8.2.1 Plano de implantao...................................................................................................................................100 3.8.2.2 Documentao do usurio ...........................................................................................................................101 3.8.2.3 Implementao de arquitetura e segurana ..................................................................................................101 3.8.2.4 Implementao de infra-estrutura ................................................................................................................102 3.8.2.5 Instalao do software .................................................................................................................................102 3.8.2.6 Treinamento do usurio...............................................................................................................................103 3.8.2.7 Formalizao do aceite do software ............................................................................................................104

3.8.3 Resultados da disciplina.................................................................................................................... 104 4 METODES - ARTEFATOS .......................................................................................................................... 106 5 METODES - PAPIS..................................................................................................................................... 107

5.1 Descrio dos Papis............................................................................................................................... 107 5.1.1 Gerente de relacionamento................................................................................................................ 107 5.1.2 Gerente de projeto............................................................................................................................. 108 5.1.3 Gerente de artefato ............................................................................................................................ 109 5.1.4 Gerente de mudanas ........................................................................................................................ 109 5.1.5 Gerente de qualidade......................................................................................................................... 111 5.1.6 Gerente de requisitos......................................................................................................................... 111 5.1.7 Analista de requisitos ........................................................................................................................ 111 5.1.8 Prototipador ...................................................................................................................................... 112 5.1.9 Projetista ........................................................................................................................................... 112 5.1.10 Construtor ....................................................................................................................................... 113 5.1.11 Documentador................................................................................................................................. 113 5.1.12 Analista de testes............................................................................................................................. 114 5.1.13 Analista de implantao .................................................................................................................. 114 6 METODES - FERRAMENTAS .................................................................................................................... 116 6.1 Recomendaes da METODES ............................................................................................................. 116 6.2 Modelagem de banco de dados .............................................................................................................. 116 6.2.1 Dbdesigner 4 ..................................................................................................................................... 116 6.2.2 Mogwai ER-Designer ....................................................................................................................... 117 6.3 Administrao de banco de dados ......................................................................................................... 117 6.3.1 MySQL Administrator ...................................................................................................................... 117 6.3.2 MySQL Query Browser .................................................................................................................... 118 6.3.3 PgAdmin ........................................................................................................................................... 118 6.3.4 SQL Lite ........................................................................................................................................... 118 6.4 IDE (Integrated Development Environment) e Linguagens ............................................................... 119 6.4.1 Eclipse............................................................................................................................................... 119 6.4.2 NetBeans........................................................................................................................................... 119 6.4.3 PHP 5 ................................................................................................................................................ 119 6.4.4 J2SE .................................................................................................................................................. 120 6.4.5 J2EE.................................................................................................................................................. 120 6.5 Servidores Web ....................................................................................................................................... 121 6.5.1 Apache .............................................................................................................................................. 121 6.5.2 Tomcat .............................................................................................................................................. 121 6.5.3 IIS - Internet Information Services ................................................................................................... 121 6.6 Controle de Verso ................................................................................................................................. 122 6.6.1 CVS................................................................................................................................................... 122 6.7 Gesto de projeto .................................................................................................................................... 122 6.7.1 DotProject ......................................................................................................................................... 122 6.8 Modelagem visual (UML) ...................................................................................................................... 122 6.8.1 Jude Community ............................................................................................................................... 122 6.9 SGBD - Sistema gerenciador de banco de dados ................................................................................. 123 6.9.1 Mysql 5 ............................................................................................................................................. 123 6.9.2 Oracle Express Edition 10g............................................................................................................... 123 6.9.3 PostgreeSQL ..................................................................................................................................... 123 6.9.4 SQL Server 2005 Express Edition .................................................................................................... 124 6.10 Documentao ....................................................................................................................................... 124 6.10.1 BrOffice .......................................................................................................................................... 124 7 GUIA WEB METODES ................................................................................................................................ 125 8 CONSIDERAES FINAIS......................................................................................................................... 129 9 REFERNCIAS ............................................................................................................................................. 131 10 GLOSSRIO ................................................................................................................................................ 132 11 APNDICE A DVE DOCUMENTO DE VISO E ESCOPO ........................................................... 134 12 APNDICE B - PRP - PLANILHA DE RESULTADOS DE PROJETO................................................ 137

13 APNDICE C - PCR - PLANILHA I DE CONTROLE DE REQUISITOS........................................... 138 14 APNDICE D - PCR - PLANILHA II DE CONTROLE DE REQUISITOS ......................................... 139 15 APNDICE E - PCR PLANILHA III DE CONTROLE DE REQUISITOS ....................................... 140 16 APNDICE F - PCR - PLANILHA IV DE CONTROLE DE REQUISITOS ........................................ 141 17 APNDICE G - CUF CASO DE USO FUNCIONAL............................................................................ 142 18 ANEXO A TEXTO SOBRE ANLISE DE PONTO DE FUNO..................................................... 143 19 ANEXO B METODES ORIGINAL ........................................................................................................ 156

LISTA DE FIGURAS
2.1 CICLO DE VIDA CASCATA ...................................................................................................................... 17 3.1 PERSPECTIVAS DE DISCIPLINAS DA METODES .............................................................................. 45 3.2 DIAGRAMA DE BLOCOS DA METODES............................................................................................... 46 3.3 PERSPECTIVAS DE PAPIS ESQUEMA DE INTERAO DOS PAPIS DA METODES ......... 47 3.4 FLUXO DE ATIVIDADES DA DISCIPLINA CONCEPO................................................................. 49 3.5 FLUXO DE ATIVIDADES DA DISCIPLINA GESTO DE PROJETO................................................ 58 3.6 FLUXO DE ATIVIDADES DA DISCIPLINA DETALHAMENTO DE REQUISITOS........................ 66 3.7 FLUXO DE ATIVIDADES DA DISCIPLINA ANLISE E PROJETO ................................................. 77 3.8 FLUXO DE ATIVIDADES DA DISCIPLINA CONSTRUO .............................................................. 89 3.9 FLUXO DE ATIVIDADES DA DISCIPLINA TESTE FUNCIONAL..................................................... 95 3.10 FLUXO DE ATIVIDADES DA DISCIPLINA IMPLANTAO .......................................................... 99 5.1 FLUXO DO TRATAMENTO DE SOLICITAO DE MUDANA .................................................... 110 7.1 PGINA INICIAL DO GUIA WEB DA METODES .............................................................................. 125 7.2 OPO DE MENU VISES DA METODOLOGIA METODES....................................................... 126 7.3 OPO DE MENU DISCIPLINAS........................................................................................................ 127 7.4 OPO DE MENU PAPIS ................................................................................................................... 128

LISTA DE TABELAS
4.1 TABELA DE ARTEFATOS....................................................................................................................... 106

12

1 INTRODUO

Ao final do segundo semestre de 2005, surgiu a idia deste trabalho - uma metodologia de desenvolvimento de software sob o paradigma da orientao a objetos - como tema para a realizao do Trabalho de Concluso de Curso (TCC). Naquela poca, em conversa com a nova coordenao do curso de Bacharelado em Sistemas de Informao, que assumiria o prximo semestre, houve a sinalizao de que a criao de uma metodologia de desenvolvimento de software j figurava entre as propostas para o curso de Sistemas de Informao. Nasce, ento, a METODES, concebida a partir do esforo de um grupo de professores da Faculdade Cenecista de Braslia (FACEB), inicialmente como um roteiro metodolgico estruturado que auxiliaria os alunos do curso de Sistemas de Informao na realizao dos projetos que envolveriam o desenvolvimento de software. Sob essas circunstncias, configurava-se a oportunidade de negcio que justificaria o incio do desenvolvimento da METODES. Esse desenvolvimento abordaria os principais aspectos de uma metodologia propriamente dita, com a indicao de mtodos, tcnicas e ferramentas adequadas para a realizao de um projeto de software. A METODES foi baseada em processos comerciais para desenvolvimento de software, utilizados amplamente no mercado e fundamentada luz dos conhecimentos da Engenharia de Software. Alm disso, a estrutura dessa metodologia foi adequada realidade acadmica da FACEB e contextualizada levando em considerao as necessidades enfrentadas pelos alunos do curso de Sistemas de Informao. O curso de Sistemas de Informao da FACEB traz, em seu currculo, uma gama de disciplinas voltadas para gesto e administrao, que capacitam o aluno gerncia de ambientes de TI (Tecnologias da Informao), bem como gesto e empreendimento de

13

negcios. Oferece ainda um slido conhecimento dos fundamentos da computao e das tecnologias atuais de mercado. So metas do curso de Sistemas de Informao da FACEB:
Estimular a criao e o aprimoramento da empregabilidade, luz das demandas de mercado; Desenvolver habilidades para aquisio e gerenciamento de servios e recursos relacionados tecnologia de informao; Capacitar para o desenvolvimento e evoluo de sistemas informatizados, e infraestrutura para uso em processos organizacionais, usando metodologias e tcnicas consagradas e de ltima gerao.
(http://www.vqv.com.br/FACEB_j2ee14a/principal/cursos.jsp?idCurso=1&id=2)

Considerando as metas supracitadas e a oportunidade de negcio apresentada, este trabalho aborda como tema o processo de desenvolvimento de software. O principal objetivo disponibilizar aos alunos da FACEB uma metodologia de desenvolvimento de software com o intuito de facilitar o entendimento das atividades envolvidas no desenvolvimento de projetos de software. Os objetivos especficos deste trabalho so: Desenvolver uma metodologia personalizada para desenvolvimento e gesto de projetos de softwares que contemple:

modelos para documentao do produto e do projeto de software; indicao de ferramentas para desenvolvimento do projeto.

Desenvolver o guia da metodologia em forma de pginas WEB.

A questo que propulsiona este trabalho descobrir qual a importncia da utilizao de uma metodologia de desenvolvimento aplicada execuo de um projeto de software em ambiente acadmico. A justificativa dessa questo a nfase cada vez mais acentuada nos princpios e tcnicas da Engenharia de Software empregadas em projetos de desenvolvimento, face demanda por softwares de qualidade dentro de um quadro tecnolgico cada vez mais complexo e dinmico.

14

Para alcanar os objetivos traados por este trabalho foi feita uma pesquisa bibliogrfica com fim descritivo acerca dos conceitos envolvidos no tema deste trabalho e, utilizou-se o curso de Sistemas de Informao da FACEB como referencial para fundamentao do desenvolvimento da METODES. Aps a introduo, primeiro captulo deste trabalho, apresenta-se o segundo captulo, a reviso da bibliografia que cerca a Engenharia de Software, incluindo as normas que visam orientar de forma genrica, processos de desenvolvimento de produto de software. A inteno desse captulo oferecer uma referncia bsica sobre os conceitos abordados neste trabalho, oferecendo ao leitor contedo suficiente para a compreenso e anlise do tema, alm de trazer tambm um comparativo das principais metodologias de desenvolvimento utilizadas no mercado. O terceiro captulo apresenta a metodologia proposta, suas caractersticas e particularidades. Especifica as disciplinas, atividades e tarefas que a compe, interrelacionando-as dentro do seu fluxo de atividades. O quarto captulo mostra os artefatos, modelos de documentos gerados durante o processo de desenvolvimento. O quinto e o sexto captulos so, respectivamente, a descrio dos papis que atuam no desenvolvimento do software e a indicao de um conjunto de ferramentas que pode ser utilizado no projeto de software. O sexto captulo apresenta a estrutura do guia da metodologia em forma de pginas WEB. Alm da apresentao do guia, abordam-se nesse captulo detalhes de sua construo, requisitos para seu funcionamento e operao.

15

2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

2.1 Definio

Um processo de desenvolvimento de software, ou simplesmente processo de software, pode ser definido como um conjunto de disciplinas, atividades e tarefas necessrias para a gerao de um produto de software, abordando desde sua concepo at o seu estado operacional entregue ao usurio. Alm do processo produtivo em si, um processo de desenvolvimento deve contemplar todo o acompanhamento e controle da produo do software, abordando os aspectos gerenciais que se fazem necessrios no transcorrer do desenvolvimento. As atividades de gerncia de um projeto de software rezam pelo correto andamento das atividades e tarefas executadas, bem como pela administrao de falhas, imprevistos e mudanas que possam ocorrer em qualquer uma das disciplinas do processo. Pfleeger (2004) define processo como sendo um srie de etapas que envolvem atividades, restries e recursos para alcanar a sada desejada. Sua abordagem sobre o significado de processo ampla e cita algumas caractersticas que, segundo ele, esto presentes em todos os processos.
O processo prescreve todas as suas principais atividades; O processo utiliza recursos, est sujeito a um conjunto de restries (como um cronograma) e gera produtos intermedirios e finais; O processo pode ser composto de subprocessos de algum modo relacionados. Ele pode ser definido como uma hierarquia de processos, organizados de tal maneira que cada subprocesso tenha seu prprio modelo de processo; Cada atividade do processo tem critrios de entrada e sada, de modo que seja possvel saber quando o processo comea e quando termina; As atividades so organizadas em uma seqncia, para que a ordem de execuo de uma atividade em relao s outras seja clara; Todo processo tem um conjunto de diretrizes que explicam os objetivos de cada atividade. (PFLEEGER, 2004, pg. 36)

16

A forma como se encadeiam as etapas em um processo de desenvolvimento conhecida como modelo de processo ou modelo de ciclo de vida. Existe, porm, o ciclo de vida do projeto de software e o ciclo de vida do produto de software. Este ltimo estende-se alm do projeto e acompanha o produto de software da sua operao inicial, passando por possveis manutenes at quando o software entra em obsolescncia. O ciclo de vida do processo, por sua vez, temporrio e acaba ao final do projeto de desenvolvimento. H diversos modelos de ciclo de vida, no entanto, consenso que no existe um modelo nico que atenda a todos os projetos. O ciclo de vida deve ser escolhido de acordo com a natureza e caractersticas do projeto.

2.2 Modelos de ciclo de vida

Os modelos de ciclo de vida diferem um do outro na forma em que as diversas etapas de processo de software se relacionam entre si.

2.2.1 Modelo cascata

Um dos modelos mais utilizados o Cascata. Esse modelo se caracteriza por seu encadeamento linear de suas etapas, de forma que, uma fase s tem incio somente com o trmino da anterior. Eventualmente pode-se haver retro alimentao etapa anterior, no entanto, esse modelo mantm sua linearidade de aes do incio ao fim.

17

2.1 CICLO DE VIDA CASCATA

Dentre as diversas razes que levam crtica do modelo cascata citamos: O modelo se aplica ao desenvolvimento de sistemas onde se tm os requisitos bem definidos e estveis, o que no corresponde realidade prtica de desenvolver sistemas; O modelo em cascata prescinde de artefatos ou produtos de uma fase anterior para se dar incio fase posterior. Dessa forma, uma verso operacional do software pode demorar muito. Eduardo Bezerra (2002) alerta que esse detalhe pode ser um fator de perda de competitividade das empresas que utilizam o modelo em cascata, pois o cliente pode no ter a pacincia suficiente para esperar uma primeira verso operacional do software. Alm disso, pode haver inevitveis mudanas de requisito entre a solicitao do cliente at a primeira verso do software, recaindo sobre o gerente de projeto uma carga de trabalho maior. No livro de Shari Lawrence Pfleeger (2004) diz que o modelo impe uma estrutura de gerncia de projeto ao desenvolvimento do sistema (PFLEEGER apud MCCRACKEN, JACKSON, 2004);

18

Nesse mesmo livro h referncias de Curtis, Kranser, Shen e Iscoe (1987) que dizem que o principal defeito do modelo cascata a falha em tratar o desenvolvimento de software como um processo de soluo de problemas. Pfleeger argumenta que o modelo derivado de um processo de fabricao de hardware onde uma vez fabricado o produto ele reproduzido vrias vezes e, segundo o autor, o desenvolvimento de software um processo de criao, no de fabricao, e evolui medida que o problema melhor compreendido (iteraes).

Em um artigo no stio http://www.internativa.com.br/artigo_gestao.html, Marcelo Jacintho explica:

O ciclo de vida a ser adotado ser uma das tnicas agora, pois dependendo das caractersticas do projeto, do cliente e da prpria equipe, alguns modelos de ciclo de vida no so recomendveis. Ainda, o famigerado e to perseguido ciclo de vida Cascata, se estiver com grandes chances de ser escolhido, precisar sempre passar por uma crtica muito severa, haja vista que as estatsticas de desempenho da indstria mundial de T.I., largamente divulgadas pelo Standish Group, apontam para um sucesso menor que 30% no resultado dos projetos, e, pesquisas correlatas apontam que a utilizao de um ciclo de vida que no permite uma antecipao de riscos, nem testes de parciais do sistema em desenvolvimento, e que ignora a natureza mutvel dos requisitos, est ligada a este ciclo e a este resultado. claro que no podemos esquecer que possvel ser bem sucedido utilizando o Cascata, porm o mercado vem sinalizando muito forte para a utilizao de modelos diferentes.

2.2.2 Modelo iterativo e incremental

O modelo iterativo e incremental uma alternativa para soluo de problemas enfrentado no modelo cascata. Nesse modelo, considera-se o desenvolvimento do software em ciclos iterativos onde uma pequena poro dos requisitos passa por todas as etapas de desenvolvimento como em um modelo cascata. Ao final de cada ciclo de iterao tm-se uma nova verso do software, a qual ser incrementada a cada novo ciclo que ocorrer. Ao final de cada ciclo de iterao pode-se ter uma verso do software. Isso reduz a ansiedade e a expectativa do usurio em relao ao software. Alm disso, o modelo

19

possibilita que o software seja desenvolvido em mdulos de acordo com a necessidade e caractersticas do projeto. Embora parea que o modelo imprima uma forma mais gil de desenvolvimento, um planejamento formal no desprezado. A idia das iteraes desse modelo permitir que o sistema seja melhor compreendido e refinado a cada etapa. Dessa forma, a qualidade do software pode ser provida gradualmente medida que seu desenvolvimento evolui.

2.3 Software na viso do usurio

Segundo o Dicionrio Aurlio Eletrnico, 1999, software o conjunto dos componentes que no fazem parte do equipamento fsico propriamente dito e que incluem as instrues e programas (e os dados a eles associados) empregados durante a utilizao do sistema.. Do ponto de vista da Engenharia de Software, o conceito de software compreende todo o conjunto de programas, procedimentos, dados e documentao associados a um sistema de computador, e no somente ao programa em si. (PFLEEGER, 2004). No obstante aos conceitos aqui apresentados, o software popularmente conhecido como os programas que utilizamos em um computador e que nos ajuda a realizar de forma mais fcil e produtiva nosso trabalho. Acontece que o software tambm visto, muitas vezes, como empecilho produtividade por trazer mais problemas do que soluo ao usurio. Geralmente, isso fruto da m qualidade do software ou, simplesmente, pelo fato de o software no estar atendendo ao usurio de forma satisfatria. O importante em tudo isso que a satisfao do usurio do software um fator crtico para o seu sucesso, alm do atendimento eficaz ao propsito essencial para o qual ele foi criado, sem isso no haveria razo para a sua existncia. Neste ltimo pensamento estamos

20

elevando o conceito de software a um nvel superior, que o de sistema, algo mais complexo e que pode ser composto de vrios softwares. Bezerra (2002) salienta o surgimento dos chamados sistemas de informao, adventos da crescente importncia dada informao, destacada por muitos como o bem mais valioso da humanidade atualmente. Ele afirma que um sistema de informao muito mais que programas de computador, o conjunto das pessoas, das tecnologias, dos sistemas e dados, todos, integrados de forma intrnseca para auxiliar a inteligncia das organizaes nas tomadas de decises estratgicas. Diz ainda que, em um sistema de informao, um dos seus componentes o sistema de software, que compreende os mdulos funcionais computadorizados que interagem entre si para proporcionar ao(s) usurio(s) do sistema a automatizao de diversas tarefas (op. cit.). Na viso da maioria dos usurios no h distino entre sistemas de informao, sistemas de software ou programas de computadores. Sua viso condicionada s experincias e resultados que obtm com a utilizao do software. Pare ele importante que o software atenda as suas necessidades e, por conseqncia, a necessidade da organizao que tem o software ou sistema implantado. Isso uma das premissas de qualidade de software, que ser discutida nesse captulo mais adiante, e onde podemos contextualizar a Engenharia de Software como fator crtico de sucesso do produto de software.

2.4 A engenharia de software e sucesso no desenvolvimento

A engenharia de software a criao e a utilizao de slidos princpios de engenharia a fim de obter software de maneira econmica, que seja confivel e que trabalhe eficientemente em mquinas reais. (PRESSMAN, 2002)

21

De acordo com Peters e Pedrycz (2001), uma abordagem de engenharia engenharia de software caracteriza-se por um desenvolvimento de software prtico, ordenado e medido. Essa afirmativa ressalta a importncia que os mtodos, processos, tcnicas e ferramentas da engenharia de software tm no desenvolvimento de software. A utilizao de uma sistemtica consistente para conduzir esse desenvolvimento faz com que tenhamos resultados prticos e plausveis, do ponto de vista de custos e prazos, bastantes positivos de projetos de software. A importncia, ento, da engenharia de software para o sucesso no desenvolvimento de sistemas est na aplicao das prticas da engenharia para garantir que um projeto de software seja executado de acordo com alguns princpios bsicos que levam qualidade final do produto. Pfleeger (2002) afirma que escrever software uma arte e uma cincia, ressaltando a racionalidade dos mecanismos computacionais e suas teorias e, por outro lado, a necessidade do envolvimento de arte, originalidade e tcnica para escrever programas.

2.5 Qualidade de software

Qualidade de Software: A totalidade das caractersticas de um produto de software, que lhe confere a capacidade de satisfazer s necessidades explcitas e implcitas (NBR 13596, 1996). Avaliar produtos de software constitui uma atividade bastante complexa em que a demanda est crescendo significativamente devido fatores externos como a globalizao que afeta diretamente grandes empresas e futuras empresas que pensam em crescer, sendo assim os usurios exigem cada vez mais qualidade, eficincia, eficcia, dentre outros requisitos que podem influenciar na aquisio de software. Por um lado, surge a oportunidade de se

22

desenvolver metodologia para avaliar a qualidade de produto de software com base em requisitos de qualidade reconhecidos internacionalmente, dando subsdios para os clientes (compradores de tecnologia) que adquirirem produtos com qualidade. Por outro lado, os produtores de software tm a possibilidade de fornecer produtos de maior qualidade e podendo crescer no mercado competitivo. A avaliao de produto de software tem sido uma das formas empregadas por organizaes que produzem ou adquirem software para obteno de maior qualidade nesses produtos, sejam esses softwares completos, ou mdulos a serem integrados a um sistema computacional mais amplo. Os benefcios de avaliao de software servem para:

o desenvolvedor utilizar os resultados da avaliao de seu produto para identificar aes no desejadas como os bugs, com o objetivo de melhor-lo, ou de tomar decises sobre a estratgia de evoluo do produto podendo tomar como parmetros para outras reas em que esse software poder atuar;

o fornecedor de software demonstrar confiabilidade no seu produto, sob tudo agregar valores em relatrio de Avaliao com finalidades comerciais;

no futuro cliente poder conhecer o nvel de qualidade do software para ajudlo na tomada de deciso de aquisio deste produto.

2.6 Norma NBR ISO/IEC 12207

Advindo do fato de que a qualidade do produto de software est diretamente relacionada qualidade do processo de software, diversos modelos e normas para a definio e melhoria de processos de software tm sido desenvolvidos. Modelos como o CMM

23

(Capability Maturity Model for Software) so cada vez mais reconhecidos e utilizados, tanto no Brasil como em todo o mundo, destacando-se na fabricao de software de qualidade. As normas estabelecem o que deve ser feito e no como deve ser implementado. Ou seja, estabelecem quais so os processos que devem estar presentes para garantir o sucesso dos projetos, mas no oferecem orientaes sobre qual modelo de ciclo de vida, ferramenta, linguagem ou ambiente deve ser utilizado para o desenvolvimento do software. Percebemos que na elaborao de um software a equipe desenvolvimento se depara com diversos paradigmas, mtodos e ferramentas de desenvolvimento pregando ser a soluo definitiva para os problemas dos projetos de software. No decorrer dos anos 90, estiveram em pauta as metodologias orientadas a objetos introduzidas isoladamente por cada um de seus autores. No final dos anos 90, trs deles (Jacobson, Booch e Rumbaugh) se reuniram para desenvolver o Unified Software Development Process (UP). Posteriormente, o UP foi instanciado e especificado pela Rational Software Corporation, resultando no Rational Unified Process (RUP).

2.7 Mtricas e estimativas de software

Segundo Ian Sommerville (2003), mtricas so as medies que precisam ser coletadas para ajudar a responder as questes e para confirmar se as melhorias de processo alcanaram a meta desejada ou no. Mtricas de software referem-se a uma ampla variedade de medidas de software de computador, ou seja, medidas do resultado do desenvolvimento de software, medidas de tamanho do software so frequentemente utilizadas tanto na concepo de projetistas quanto na de usurios, pois essa medida um bom indicador de grandeza de um sistema de software,

24

envolvendo recursos como os requisitos de memria, o esforo de manuteno e o tempo de desenvolvimento.

O software medido por muitas razes: (1) indicar a qualidade do produto; (2) avaliar a produtividade das pessoas que produzem o produto; (3) avaliar os benefcios (em termo de produtividade e qualidade) derivados de novos mtodos e ferramentas de software; (4) formar uma linha bsica para estimativas; (5) ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional (PRESSMAN, 1995, pg. 60.).

As medidas de software so mapeamentos dos objetos nas entidades de software, na forma de nmeros ou smbolos, que servem para quantificar um atributo de software (PETERS, PEDRYCZ, 2001). H dois tipos de medidas que so bastante utilizadas para a realizao de estimativas de software:
Medidas relacionadas a tamanho: essas medidas so relacionadas ao tamanho de alguma sada de uma atividade. Dessas, a mais comum o nmero de linhas de cdigo-fonte fornecidas. Outras medidas que podem ser utilizadas so o nmero de instrues de cdigo-objeto entregues ou o nmero de pginas de documentao do sistema; Medidas relacionadas a funes: essas medidas so relacionadas funcionalidade geral do software entregue. A produtividade expressa em termos da funcionalidade til produzida em um tempo determinado. Os pontos de funo e os pontos de objeto so as melhores medidas conhecidas desse tipo. (SOMMERVILLE, 2003).

As estimativas de software so feitas para definir o valor total a ser gasto no desenvolvimento de um software e para passar o oramento ao cliente, sendo que essas estimativas podem ser reajustadas no decorrer do desenvolvimento do software permitindo o uso eficaz dos recursos disponibilizados. Nenhuma estimativa exata, no entanto elas so bastante consistentes e combinam dados sobre o usurio, sobre o desenvolvedor e sobre o plano de desenvolvimento do projeto a ser implantado com os dados do domnio de informao exigidos para a contagem de pontos - por - funo. A estimativa oferece ao planejador as informaes necessrias para concluir as atividades de planejamento do software (PRESSMAN, 1995).

25

2.8 Processos comerciais de desenvolvimento de software

2.8.1 RUP - Rational Unified Process

O RUP um processo de engenharia de software bem definido e bem estruturado que define claramente quem responsvel pelo que, como as coisas devem ser feitas e quando faz-las. O RUP tambm prov uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de deciso; tornando-se uma maneira de desenvolvimento de software que iterativa, centrada arquitetura e guiada por casos de uso. O RUP utiliza a Linguagem Unificada de Modelagem (UML) para especificar, modelar e documentar artefatos. A UML um padro definido pelo OMG (Object Management Group) e ter se tornado o padro empresarial para a modelagem orientada a objetos.

2.8.1.1 Caractersticas do RUP

Existem alguns princpios que podem caracterizar e diferenciar o RUP de outros mtodos iterativos: Atacar os riscos cedo e continuamente; Certificar-se de entregar algo de valor ao cliente; Focar no software executvel; Acomodar mudanas cedo; Liberar um executvel da arquitetura cedo; Construir o sistema com componentes;

26

Trabalhar junto como um time; Fazer da qualidade um estilo de vida, no algo para depois.

2.8.1.2 Elementos do RUP

O RUP possui cinco elementos principais: Papis Atividades Artefatos Fluxos de trabalho Disciplinas

2.8.1.3 O ciclo de vida RUP

O ciclo de desenvolvimento no RUP possui quatro fases: Concepo Elaborao Construo Transio.

2.8.1.4 Benefcios

Com a utilizao de uma metodologia de desenvolvimento de software como o RUP, possvel obter: Qualidade de software;

27

Produtividade no desenvolvimento, operao e manuteno de software; Controle sobre desenvolvimento dentro de custos, prazos e nveis de qualidade desejados;

Estimativa de prazos e custos com maior preciso.

2.8.2 XP - Extreme Programming

Extreme Programming usa times integrados de programadores, clientes, e gerentes para desenvolver software de alta qualidade em velocidade alta. Rene tambm um conjunto de prticas de desenvolvimento de software j testadas, que estimuladas a sinergia entre elas geraro vastas melhorias em produtividade global e satisfao do cliente. Cada prtica tem sua funo para manter o custo de mudana baixo e esto divididas nas categorias da seguinte forma: Programming Simple design (projeto simples), testing (testes), refactoring (reconstruo), coding standars (cdigo padro); Team Collective ownership (cdigo coletivo), continuous integration (integrao continua), metaphor (metfora), pair programming (programao em par), small releases (verses pequenas); Process On-site customer (no local do cliente), testing (testes), small releases (verses pequenas), planning game (planejamento do jogo).

2.8.2.1 Processo do XP

2.8.2.1.1 Metodologia de desenvolvimento no XP

28

Planning game - Define incrementalmente os requisitos do sistema e a produz a criao das user stories (estorias de uso)

Client on-site atravs do analista de negocio faze-se a interao junto ao cliente

Small realeases so realeases para avaliao e aprovao junto cliente

2.8.2.1.2 Programao

Algumas tcnicas aplicadas na metodologia XP:

Pair programming onde a codificao efetuada em dupla Coding standards - padronizao do cdigo se torna necessria, pois ocorre o revezamento dos desenvolvedores do cdigo. Ou seja, se escrito por um, esse cdigo dever est claro suficiente para a perfeita compreenso dos demais desenvolvedores. Outro ponto marcante quando o desenvolvimento dos scripts de testes ou testes de unidade so alterados e executados, uma nova implementao colocada em prtica.

Simple design a codificao apenas das funcionalidades essenciais ao sistema, desta forma foi agregado simplicidade ao projeto do sistema, agilidade e um maior custo/benefcio, tendo como base que os esforos de tempo necessrio para o desenvolvimento e teste foram praticamente os mesmos e que produziram um resultado final.

29

2.8.3 PRAXIS - Processo para Aplicativos Extensiveis e Interativos

O PRAXIS um processo que foi desenvolvido por Wilson de Pdua Paula Filho e publicado no livro Engenharia de Software: Fundamentos, Mtodos e Padres. O PRAXIS, que j est em sua segunda verso, possui um ciclo de vida composto por fases, dividida em iteraes. Cada iterao produz um conjunto precisamente definido de documentos, modelos e relatrios, que so os artefatos do processo: Documentos so os artefatos produzidos por ferramentas de processamento de texto ou hipertexto, para fins de documentao dos principais aspectos de engenharia de um projeto, incluindo aspectos selecionados dos modelos e aspectos no modelveis. So, tipicamente, os artefatos entregues aos clientes; Modelos so os artefatos de uma ferramenta tcnica especfica (tais como planilhas, ferramentas de modelagem orientada a objetos e de

desenvolvimento), produzido e usado nas atividades de um dos fluxos do processo; Relatrios so artefatos que relatam as concluses de determinadas atividades do projeto; Na construo desses artefatos, o usurio do processo guiado por padres e auxiliado pelos gabaritos de documentos e por exemplos, constantes do material de apoio. O PRAXIS inclui um conjunto de conceitos, tcnicas, fluxos de trabalho e subprocessos que cobrem todos os aspectos dos projetos tpicos de software e so baseados em mtodos de aceitao consagrados pela indstria de software. O PRAXIS baseado na tecnologia orientada a objetos; sua notao de anlise e desenho a UML (Unified Modeling Language), adotada como padro pelo consrcio OMG,

30

que rene centenas dos principais produtores mundiais de software. Os padres do PRAXIS esto em conformidade com os padres de engenharia de software do IEEE, os mais abrangentes e respeitados da rea.

2.9 As principais atividades de um processo de desenvolvimento

2.9.1 Gerenciamento do processo de desenvolvimento

O gerenciamento do processo de desenvolvimento de software bem amplo, pois diz respeito a toda a parte de planejamento e programao do projeto, gerenciamento de riscos, gesto de pessoal, estimativa de custos de software e gerenciamento de qualidade de software. Essa atividade, durante todo o desenvolvimento do software, estar em execuo, analisando e revisando os processos e as etapas desenvolvidas e comparando o tempo e o custo do desenvolvimento real do projeto de acordo com que foi planejado. O desenvolvedor de software deve se reunir com o cliente para a definio do escopo do projeto para juntos chegarem a um consenso sobre o que ser desenvolvido. A partir desse escopo sero definidas diretrizes e os requisitos do projeto. Ambos podem sofrer alterao ao longo do projeto, pois podem tornar-se inadequados ou ficarem fora de contexto original definido. A gerncia de projetos a primeira camada do processo de engenharia de software, ns a chamamos camada, em vez de etapa ou atividade, porque ela abrange todo o processo de desenvolvimento, do comeo ao fim (PRESSMAN, 1995). Para que um projeto de software seja bem desenvolvido, torna-se necessrio compreender todo o escopo do projeto, analisando as tarefas a serem executadas, as referncias a serem seguidas e os custos

31

liberados para cada etapa do projeto, destinando um tempo necessrio para o desenvolvimento do projeto.
O gerente de projeto geralmente o responsvel pela preparao dos relatrios sobre o projeto, tanto para a organizao do cliente como para as organizaes dos fornecedores. Os gerentes de projeto devem redigir documentos concisos e coerentes, que resumam as informaes fundamentais a partir de relatrios de projeto detalhados. Eles devem ser capazes de apresentar essas informaes durante as revises de andamento. Consequentemente, a capacidade de se comunicar de modo eficaz, tanto verbalmente como por escrito, uma habilidade essencial para o gerente de projeto (SOMMERVILLE, 2003).

Segundo Pfleeger (2004) importante que a gerncia do projeto desenvolva um cronograma que descreva o ciclo de desenvolvimento de software para um projeto especfico, enumerando as etapas ou estgios, dividindo cada um deles em tarefas ou atividades a serem realizadas. Assim o desenvolvimento e o acompanhamento das atividades ficam facilitados para os gerentes do projeto, fornecendo diretrizes e metas para a equipe de desenvolvimento de software, que por sua vez buscar cumprir as estimativas de custo e prazo definidos durante o desenvolvimento do planejamento do software. Vale lembrar que muito importante que os gerentes do projeto se renam com a equipe de desenvolvimento para discutirem e avaliarem o do andamento geral do projeto.

2.9.2 Levantamento de requisitos

A atividade de levantamento de requisitos corresponde etapa de compreenso do problema aplicada ao desenvolvimento de software (BEZERRA, 2002). Nessa atividade feito o levantamento de requisitos de software a serem desenvolvidos, a equipe de desenvolvimento de software levantara e analisara esses requisitos compreendendo as necessidades dos clientes com a inteno de solucionar os problemas por eles descritos. Nessa atividade importante que tanto a equipe de desenvolvimento quanto os clientes tenham uma

32

mesma viso dos problemas constatados, pois isso ajudar bastante no desenvolvimento do software. O levantamento e a anlise dos requisitos envolve muito mais do que apenas descrever e registrar os requisitos descritos pelo cliente, significa dizer que se deve identificar requisitos, nos quais os desenvolvedores e o cliente possam concordar e nos quais possam ser testados (PFLEEGER, 2004). O fluxo de Requisitos rene as atividades que visam a obter o enunciado completo, claro e preciso dos requisitos de um produto de software (PDUA, 2003). Isso significa dizer que os requisitos a serem desenvolvidos devem ser os mais explcitos possveis e no podem ser ambguos, alm disso, precisam ser passveis de implementao, seguros, confiveis, e fceis de serem testados, tudo isso para que eles sejam requisitos de alta qualidade para o projeto de software. Tanto Wilson de Pdua quanto Pfleeger do nfase maior a soluo do problema do cliente e a implementao dos requisitos levantados, sugerindo que todos os requisitos atendam a uma determinada funcionalidade, atentando para as reais necessidades encontradas. importante lembrar que necessrio fazer uma triagem entre esses requisitos, priorizando aqueles que so importantes, pois alguns so essenciais, outros desejveis e outros no sero contemplados para a implementao. Dentro da atividade de requisitos sero gerados dois documentos: o documento de definio dos requisitos, que gera uma listagem completa de tudo que o cliente espera que o sistema proposto faa; e o documento de especificao dos requisitos, que descreve os requisitos em uma linguagem mais tcnica apropriada para o desenvolvimento do sistema. Esses documentos representaro os desejos do cliente em relao quilo que o software deve possuir como funcionalidades. Os requisitos levantados podem ser divididos basicamente em trs tipos:

33

Requisitos funcionais: definem as funcionalidades do sistema, descrevendo uma interao entre o sistema e o seu ambiente verificando o seu funcionamento. Os requisitos funcionais descrevem detalhadamente as funes do sistema, suas entradas, sadas, e excees, possibilitando que eles possam ser escritos em diferentes nveis de detalhes do sistema;

Requisitos no-funcionais: so aqueles que declaram as caractersticas de qualidade que o sistema deve possuir e que esto relacionadas as suas funcionalidades. (BEZERRA, 2002). Requisitos no-funcionais so aqueles que no dizem respeito diretamente s funcionalidades fornecidas pelo sistema, mas dizem respeito ao sistema como um todo, de acordo com as necessidades do cliente e conforme as restries de oramento, polticas organizacionais, ou devido a fatores externos;

Restries: segundo Bezerra (2002) as restries definem a adequao a custos e prazos, a plataforma tecnolgica, aspectos, licenciamento, limitaes sobre a interface com o usurio, componentes de hardware e software a serem adquiridos.

Depois de todos os requisitos serem avaliados, analisados e tratados, eles estaro prontos para serem utilizados ao longo do desenvolvimento do sistema, servindo como fundamento a todas as etapas do processo de desenvolvimento. Todos os requisitos representaro o entendimento entre os desenvolvedores e o cliente, sendo que esses requisitos devem ser descritos de forma clara para que todos possam entender, tanto os desenvolvedores quanto pessoas leigas no assunto. Sempre que houver a necessidade de alterao em algum requisito faz-se necessrio reavaliar todos os processos do sistema e verificar se a alterao vivel ou onerosa ao sistema, tanto em servio quanto em finanas, e se o cliente aprovar determinadas mudanas. Em um estudo baseado em 6.700 sistemas feito e 1997, Carper Jones

34

mostrou que os custos resultantes de m realizao desta etapa de entendimento podem ser duzentas vezes maiores que o realmente necessrio (BEZERRA apud JONES, 2005). Isso mostra porque esta atividade do processo de software se torna a mais importante, pois aqui se cria uma base solidificada estabelecendo o escopo do sistema a ser desenvolvido. Dessa forma, em caso de mudana de escopo, tanto o cliente quanto os desenvolvedores tm um parmetro para decidirem o quanto de tempo e de recursos sero utilizados.

2.9.3 Anlise

Na anlise de desenvolvimento de um software busca atingir uma transformao de todo os conceitos que foram expostos para uma viso mais ampla, Wilson de Pdua de Paula Filho (2003), ressalta-se a importncia de modelar os conceitos presentes no domnio do problema, sendo assim consegue-se verificar a qualidade dos requisitos e juntamente com os seus respectivos fluxos e os projetistas atingem com maior exatido o detalhamento de cada requisito visto na fase de levantamento de requisito e sua real finalidade a que foi proposto. O autor cita a importncia em detalhar o modelo de anlise para servir como base para a fase de projeto que a disciplina posterior. Anlise e projeto de software poderiam se restringir a uma nica fase, j que a diferena visvel o nvel de detalhamento que se estabelece entre as duas etapas do processo de desenvolvimento. Pfleeger (2004) esclarece os conceitos relativos a um projeto orientado a objetos como classes, instncias, comportamentos, herana, polimorfismo, entre outros, estabelecendo uma base de como o desenvolvimento de um projeto orientado a objeto. Indiferente do ciclo de vida utilizado requer-se etapas bem planejadas e estruturadas para cada atividade abordada,

35

como descrever os requisitos, projetar o sistema, projetar os programas, codificar e realizar testes. Pfleeger ressalta a possibilidade de a anlise dos requisitos serem quase sempre realizada na linguagem do usurio, no estudo de conceitos e situaes do domnio do problema. Para isso a tcnica de casos de usos torna-se extremamente importante, por descrever as funcionalidades especificas do sistema e modelar de forma apropriada para o entendimento de ambas as partes. Os casos de uso auxiliam a comunicao entre o cliente e a equipe de desenvolvimento de software, certificando-se que as funes desejadas pelo cliente sero realizadas. Os casos de usos descrevem um cenrio de como os atores (usurio, dispositivos e sistemas externos) iro interagir com o sistema, identificando cada evento de um respectivo cenrio. Por essa razo, os casos de usos tm sido adotados por grande parte da comunidade de adeptos da orientao a objetos, como suplemento dos meios mais formais de modelagem de objetos, durante a anlise do sistema. Ian Sommerville (2003) descreve que anlise orientada a objetos se dedica a desenvolver um modelo orientado a objetos do domnio da aplicao e os objetos identificados refletem entidades e operaes que esto associadas com o problema. Essa abordagem visa aproveitar algumas aplicaes e experincias em projetos de sistemas desenvolvidos e os tipos de mtodos utilizados, demonstrando uma forma de extrair os dados que serviro para um projeto orientado a objetos, necessitando uma viso abrangente de como as atividades so executadas pela equipe de projeto. Alguns pontos importantes a observar para identificar as classes de objetos so os seguintes: Utilizar uma anlise gramatical facilita descrio, conseguindo agir de forma clara e natural sem dificultar o entendimento do sistema projetado onde os

36

objetos e atributos so nomes e operaes de servios so verbos (SOMMERVILLE, 2003). Demonstrar as entidades tangveis que faro parte do domnio da aplicao, como exemplo, as funes exercidas por funcionrios: gerente, administrador, encarregado; e os eventos: solicitaes ou requisies. (SOMMERVILLE, 2003). Buscar o aprimoramento do projetista para que compreenda a viso geral do sistema, podendo assim atingir o entendimento das operaes executadas pelo sistema. Os participantes que desempenham papis significativos so reconhecidos como objetos (SOMMERVILLE, 2003). Dividir os cenrios em pedaos menores para proceder a anlise mais apurada, facilitando a absoro do problema. medida que se procede a buscar a diminuir o escopo, consegue-se estudar cada cenrio e a equipe responsvel pela anlise visualiza com maior facilidade os objetos, conseguindo identificar os atributos e operaes que so necessrias por esses objetos. Exemplo o mtodo de anlise, chamado de cartes CRC, em que analistas e projetistas assume o papel de objetos eficaz no apoio a essa abordagem baseada em cenrios (SOMMERVILLE apud BECK, CUNNINGHAM, 2003). Um artifcio bastante usado por diversos autores a UML, principalmente em projetos orientados a objetos. A UML uma linguagem de modelagem unificada para a elaborao da estrutura de projetos de software. empregada na visualizao, na especificao, na construo e na documentao de artefatos que faam uso de sistemas complexos de software. Entretanto a UML poder ser aplicada em outros projetos, independente serem projetos para desenvolvimento de software.

37

2.9.4 Projeto

Segundo Wilson de Pdua Paula Filho (2003), projeto tem como objetivo definir uma estrutura implementvel para um produto de software que atenda os requisitos especificados para ele. Pdua descreve alguns objetivos que essa disciplina tem que obedecer como:

Os aspectos relativos anlise de um projeto e seus requisitos abordados: em especial observa-se um destaque aos atendimentos de casos de usos, atravs das classes as quais foram definidas pelos analistas, sendo que no projeto o detalhamento superior ao da anlise, que apenas visualiza as provveis classes e o projeto descreve a composio das classes, facilitando para os construtores dos cdigos, onde abranger um nvel mais tcnico torna-se necessrio.

Os requisitos no funcionais captados e verificados: esses mantero a exigncia na qualidade para o bom desenvolvimento do projeto de software.

Definio clara e fiel das interfaces dos componentes do produto: visa caracterizar o ambiente de implementao e um estudo da usabilidade, isso claro diante das ferramentas propostas para a soluo.

Documentar todas as alteraes efetuadas de maneira que as informaes fluam sem dvidas para os responsveis pela implementao e

manutenibilidade do produto, facilitando a continuidade do negcio quando houver uma solicitao de mudana em uma funcionalidade do sistema ou de um mdulo especfico.

Reutilizao de componentes, estruturas, mecanismos e demais artefatos que possam aumentar a produtividade e confiabilidade da equipe desenvolvedora.

38

Pfleeger (2004) define o projeto do sistema como uma abstrao de alto nvel do que eventualmente ser o projeto do programa, estabelece dados essenciais para a implementao que os projetistas devem abranger:

Inserir aspectos computacionais nos modelos; Inserir alguns detalhes da biblioteca de classes, geralmente, utilizando uma abordagem bottom-up;

Considerar os requisitos no-funcionais, como desempenho e a segurana, e aprimoram o projeto de maneira adequada a estes requisitos.

Pleeger utiliza amplamente a UML, fazendo uma diviso de como encaixar os diagramas em nvel de viso que so as seguintes:

Dinmica representada pelos os casos de usos, listas de atividades, diagrama de interao mostrando seqncia e colaborao, e as mquinas de estado, a fim de ilustrar os estados e suas mudanas;

Esttica retratada pelos diagramas de classes, que mostram as relaes (associao, generalizao, dependncia e realizao) e a extensibilidade (restries, valores identificados por tags e esteretipos). Alm disso a viso esttica mostra os pacotes e a implementao.

As restries e a fomalizao so expressas com a OCL (Object Constraint Language).

2.9.5 Implementao

Transformar a extrao da anlise e projeto do sistema em plataforma implementvel, com a estrutura de interfaces e a persistncia dos dados. Para obter a viso geral das funcionalidades a UML disponibiliza o diagrama de atividades que retrata como as

39

atividades interagem entre si, atravs de condies que so satisfeitas ou no, e so executadas atravs de um fluxo de informaes. O fluxo de implementao realiza um desenho em termos de diversos tipos de componentes de cdigo fonte e cdigo binrio conforme as tecnologias escolhidas (PDUA, 2003). Admite-se critrios para a implementao, sendo assim, verifica-se as hierarquias de implementao das unidades de acordo com o planejamento efetuado para a disciplina, com suas definies, tarefas, de modo gerar um produto executvel, analisando seus comportamentos de acordo com as interaes. Isso tudo aliado com as devidas entradas, processamento para as funcionalidades e suas sadas respectivas, definindo, assim, os componentes que podem ser reutilizveis, por meio das ligaes efetuadas. Paralelo a isso, gera-se a documentao que compete ao usurio do software. Por meio do diagrama de componentes e diagrama de implantao da UML, consegue-se verificar as ligaes e seus respectivos pacotes lgicos. Esse modelo esttico como o autor o representa uma espcie de viso para orientar onde cada pacote est implementado. Ressalta-se a necessidade de acompanhamento para apurar aspectos discordantes. Wilson de Pdua Paula Filho apresenta dados significativos quanto superioridade das revises e inspees em relao aos testes na remoo de defeitos. O principal argumento que inspees localizam diretamente o defeito, enquanto os testes apenas mostram sintomas; a partir desses, a identificao do defeito pode ser bastante demorada. Aplica-se uma espcie de checklist do processo para validar o cdigo. Entretanto, se forem bem planejados e executados, os testes de unidade podero detectar cerca de 70% dos defeitos que seriam encontrados pelos usurios (PDUA, 2003). Para isso, estabelecem-se os testes de unidades, citando os testes de interfaces, os quais validam as passagens de parmetros (entradas) garantindo a que as informaes sero fidedignas, os testes de estruturas de dados que

40

verificam a integridade de dados armazenados temporariamente em instrues especficas ou do tipo de dados que esperam uma requisio.

2.9.6 Testes

Segundo o autor Wilson de Pdua os testes so executados para detectar aqueles defeitos que no so detectados durante as revises e para avaliar o grau de qualidade de um produto e de seus componentes. Assim que os desenvolvedores terminam suas atividades comeam a criar vrios casos de teste com a inteno de forar o software at aparecerem os erros. Esses casos de teste, quando bem desenvolvidos, tm grande probabilidade de mostrar erros ainda no descobertos, facilitando assim a correo do software, proporcionando uma boa indicao da confiabilidade e da qualidade do software desenvolvido. A atividade de teste de software um elemento crtico da garantia de qualidade de software e representa a ltima reviso de especificao, projeto e codificao (PRESSMAN, 1995). Quando os testes so implantados eles verificam se os requisitos de desempenho criados nas disciplinas de anlise e projeto esto de acordo com o especificado, nessa disciplina torna-se necessrio fazer um bom procedimento de teste para identificar as etapas necessrias para operar o sistema e exercitar os procedimentos dos casos de testes para implementar o projeto de teste do software. O teste de software determina quando um sistema de software pode ser liberado e prev um desempenho futuro. O teste uma fonte importante de feedback e fornece uma base para a interao com os participantes no projeto (PETERS, PEDRYCZ, 2001).

41

2.9.7 Implantao

Nesta disciplina chegamos etapa final do processo de desenvolvimento do software, que a sua implantao. Nessa etapa aumentar a interao entre o responsvel pela implantao e os clientes. Esse um momento importante do desenvolvimento, onde se torna necessrio dar uma ateno maior aos clientes para que eles possam aprender corretamente a operar o sistema e a se familiarizarem com o produto entregue, se essa implantao no for bem sucedida podero surgir problemas posteriores para a equipe de desenvolvimento. O treinamento dos usurios tem como base, principalmente, as principais funes do sistema e a necessidade do usurio de poder acess-las (PFLEEGER, 2004). Cada usurio receber acesso s funcionalidades do software de acordo com as permisses designadas a ele, para que assim ele tenha um completo domnio das funes do sistema aplicando as funcionalidades desenvolvidas para desempenhar o seu trabalho. Sero entregues nessa etapa os manuais do usurio e um guia de alto ajuda que proporcionar uma facilidade maior ao entendimento e ao manuseio do sistema. Segundo Pfleeger (2004), o treinamento pode ser feito de vrias maneiras. No importa por quanto tempo o treinamento realizado, ele deve oferecer informaes para os usurios e operadores em todos os momentos, e no apenas quando o sistema entregue. Algumas vezes, se o usurio se esquecer de como acessar um arquivo ou executar uma funo, o treinamento deve incluir mtodos para que o usurio possa encontrar e aprender essa informao. Alguns outros documentos tambm podem ser entregues nessa fase do projeto, como por exemplo, os documentos de requisitos, os documentos de projeto de programas e o documento de projeto do software.

42

Efetuada toda essa parte de implantao do produto, com os devidos cuidados tomados e com todos os treinamentos efetuados, encerra-se todo o desenvolvimento do software, finalizando o projeto de software.

43

3 METODES - DISCIPLINAS

3.1 Apresentao da METODES

O princpio fundamental da METODES sua utilizao contextualizada em meio acadmico, embora apresente aspectos tcnicos e conceituais que possibilitam sua utilizao em projetos de desenvolvimento de softwares para fins comerciais. Seu objetivo fornecer infra-estrutura metodolgica para auxiliar a conduo e execuo desses projetos. Neste trabalho o contexto utilizado como fundamento para desenvolvimento da Metodologia o ambiente acadmico da FACEB. A idia da METODES fornecer um meio de trabalho que propicie ao aluno saber quando, o qu e por quem devem ser realizadas determinadas tarefas para que um software seja desenvolvido atendendo a um conjunto de requisitos de qualidade, controle e produtividade. No propsito da METODES ensinar ao aluno como executar procedimentos tcnicos. Assume-se que o aluno utilizar o conhecimento adquirido ao longo do seu curso de graduao para realizar as tarefas determinadas pela metodologia, embora ela indique, em alguns casos, um conjunto de condies desejveis para a realizao dessas tarefas. A forma com que a METODES prope a conduo de um projeto de desenvolvimento de software faz com que ela possa ser utilizada para desenvolvimento iterativo e incremental. Essa possibilidade se deve pela forma com que so tratados os requisitos de software. Estes podem ser considerados individual e gradualmente, ou seja, possvel que um nico requisito seja detalhado, analisado, projetado e construdo de forma independente no projeto, fazendo com que haja releases funcionais do software antes do trmino do projeto.

44

A METODES foi criada para ser utilizada, preferencialmente, em projetos de desenvolvimento de software sob o paradigma da orientao a objeto, tendo como linguagem de modelagem a UML. Essa recomendao foi adotada pela FACEB devido ascenso da utilizao desse paradigma no atual mercado de software. A diviso da METODES feita por disciplinas, atividades e tarefas. As disciplinas representam um conjunto de atividades inter-relacionadas a fim de alcanar um objetivo especfico, um resultado parcial do processo de desenvolvimento. As atividades contm uma ou mais tarefas que devem ser executadas para que o resultado da disciplina seja alcanado. Todas as disciplinas da METODES apresentam estrutura funcional comum. Elas apresentam pr-requisitos (insumos), processamento desses insumos e artefatos do processo. Os artefatos da METODES so documentos especficos de cada disciplina que contm os resultados do projeto de software. Esses artefatos podem ser, em momentos distintos, tanto resultados como insumos para as disciplinas da metodologia. A METODES oferece trs perspectivas de funcionamento, denominadas vises da metodologia. So elas: perspectiva de disciplinas, perspectiva de blocos e perspectiva de papis.

3.1.1 Perspectivas da METODES

3.1.1.1 Perspectiva de disciplinas

A Perspectiva de Disciplinas apresenta a metodologia sob o aspecto do fluxo de atividades que so realizadas ao longo do processo de desenvolvimento. Esse fluxo de atividade representado com o diagrama de atividades da UML e considera os fluxos condicionais e as ocorrncias de execues em paralelo de algumas atividades.

45

A figura 3.1 representa a viso geral de como se d o processo de desenvolvimento da METODES e apresenta apenas a viso dos relacionamentos entre as disciplinas da metodologia.

3.1 PERSPECTIVAS DE DISCIPLINAS DA METODES

3.1.1.2 Perspectiva de blocos

A Perspectiva de Blocos mostra as disciplinas da METODES disponveis como blocos independentes do processo de desenvolvimento. Essa viso permite ao Gerente de

46

Projeto utilizar cada bloco separadamente, ao invs de utilizar toda a metodologia. Ou seja, ele pode resolver utilizar, por exemplo, somente a disciplina Concepo da METODES e continuar o desenvolvimento do software utilizando uma outra metodologia. Cabe ao Gerente de Projeto optar pela utilizao dessa perspectiva, dependendo das caractersticas e particularidades do projeto de software. Cada disciplina (bloco) continuar exigindo os mesmos insumos e produzindo os mesmos resultados. Portanto, cabe ao Gerente de Projeto adequar os insumos (ou artefatos), provindos de outra metodologia, para o padro exigido pela METODES. A figura 3.2 representa a idia da perspectiva de blocos da METODES.
3.2 DIAGRAMA DE BLOCOS DA METODES

3.1.1.3 Perspectiva de papis

A Perspectiva de Papis apresenta a viso de interao dos papis com o processo de desenvolvimento. Dependendo da disponibilidade de recursos humanos e outras limitaes que pode haver em um projeto, pode ser interessante visualizar a metodologia sob o aspecto

47

de quem trabalha nela. Assim, uma pessoa, ao assumir determinado papel, saber onde atuar no projeto. Isso pode facilitar a distribuio e entendimento das responsabilidades dos recursos humanos por todo o processo. A figura 3.3 uma representao da perspectiva de papis da METODES.

3.3 PERSPECTIVAS DE PAPIS ESQUEMA DE INTERAO DOS PAPIS DA METODES

48

3.2 Concepo

3.2.1 Definio

A disciplina Concepo da METODES foi desenvolvida para permitir o entendimento global do projeto a que est sendo aplicada, possibilitando melhor entendimento de pontos estratgicos para o sucesso do projeto, tais como compreenso do cliente, do negcio do cliente e do problema a ser solucionado. Para isso, a disciplina o marco inicial para qualquer projeto de software. Ao trmino de sua execuo, ter-se- artefatos suficientes para a avaliao da viabilidade do projeto, tendo-se determinado seu escopo, as necessidades fundamentais do usurio e as estimativas de prazo e custo. As estimativas apresentadas na disciplina Concepo da METODES so extradas a partir da Anlise de Pontos-de-Funo1 (APF) do software proposto. Para essa anlise, utiliza-se o prottipo visual apresentado ao cliente. importante que fique documentado que ocorrero revises nessas estimativas. Isso porque o software ser mais detalhado nas etapas subseqentes do processo, possibilitando a apurao com maior preciso, dos reais dispndios para execuo do projeto do software. Neste trabalho h, em anexo, um guia de referncia sobre contagem de pontos de funo e, tambm, uma planilha eletrnica que auxilia a implementao dessa contagem. O objetivo principal da disciplina fornecer um conjunto de informaes suficientes, tanto para o cliente como para a equipe de projeto, para que possam decidir sobre a viabilidade do desenvolvimento de determinada soluo sem que seja necessrio iniciar a construo da soluo. Ou seja, ao final dessa disciplina existir um estudo contextualizado e
1

A anlise de pontos de funo (APF) uma tcnica empregada para medir as funes fornecidas por um software ao usurio, independente da tecnologia utilizada na sua implementao.

49

uma demanda formal para o produto de software, que caracterizaro insumos fundamentais para a criao de um projeto de software METODES. O artefato que ser produzido nessa disciplina o Documento de Viso e Escopo de Projeto (DVE). Nesse artefato existe um termo de aceite do projeto, o qual a condio necessria para o desenvolvimento da soluo proposta no DVE. Os papis envolvidos nessa disciplina so: Analistas de Requisitos, Gerente de Relacionamento e o Gerente de Projetos.

3.4 FLUXO DE ATIVIDADES DA DISCIPLINA CONCEPO

3.2.2 Atividades

So trs as atividades bsicas da disciplina Concepo da METODES, de acordo com a figura 3.4: Contextualizao do Problema, Levantamento dos Requisitos e Soluo do Problema. Cada atividade dessa disciplina fornece parte dos artefatos que comporo o conjunto final dos artefatos da disciplina.

50

3.2.2.1 Contextualizao do problema

Essa atividade est dividida em trs tarefas essenciais: descrever o cliente, o negcio do cliente e o problema que o cliente est enfrentando. Nenhum artefato especfico do processo, nessa etapa, ser produzido. Ainda sim, as informaes coletadas nas tarefas subseqentes dessa atividade produziro parte de um artefato.

3.2.2.1.1 Descrio do cliente

A descrio do cliente deve conter informaes suficientes para suprir o projeto de software. Isso significa dizer que no deve haver falta dessas informaes que comprometam o andamento ou a execuo do projeto. No entanto, no h a necessidade de se alongar nessa descrio. Por exemplo, no caso de uma empresa, detalhar seus scios ou a sua hierarquia interna pode no interessar ao projeto. O objetivo dessa descrio no a apresentao da empresa, mas sim, responder para a METODES quem o cliente e o que dele se precisa saber para no comprometer o projeto do software.

3.2.2.1.2 Descrio do negcio

O negcio do cliente precisa ser descrito sob o aspecto funcional, portanto, descreve como acontecem as operaes da empresa, suas inter-relaes e suas relaes externas com parceiros e fornecedores, tudo isso para extrair informaes para auxiliar a compreenso e anlise do problema.

51

Na descrio do negcio do cliente devem ser identificadas as regras de negcio que existem nos processos da empresa, bem como o contexto onde essas regras so identificadas, com a explicao, sempre que possvel, de situaes hipotticas. Isso torna o trabalho de anlise e detalhamento de requisitos mais fcil e mais preciso. A METODES admite que a empresa tenha seu negcio bem compreendido e consolidado. No entanto, caso no seja essa a realidade, faz-se necessrio submeter a empresa a um trabalho profissional de modelagem de negcio. A falha ou inexistncia de processos de negcio bem definidos compromete a qualidade do produto de software a ser desenvolvido, visto que nem sempre cliente tem clareza de suas reais necessidades.

3.2.2.1.3 Descrio do problema

Estando o cliente e o seu negcio bem definido, passa-se ao entendimento do problema enfrentado pelo cliente. O principal objetivo dessa tarefa captar do cliente qual ou quais so as suas reais necessidades. Muitas vezes o cliente pensa que um sistema de computador ir resolver todos os seus problemas e acaba inserindo problemas muito maiores em seus processos, tornando-os mais lentos e onerosos para empresa. Nem sempre um sistema computacional a melhor soluo para a resoluo de um problema. Em muitos casos seria suficiente um pouco de organizao e ajustes de procedimentos operacionais internos empresa, aliados a algum software de prateleira para se chegar a uma soluo vivel e satisfatria. A disciplina Concepo da METODES pode chegar concluso, considerando as caractersticas do negcio do cliente, que no vivel o desenvolvimento de um software especfico, seja por questes financeiras ou mesmo questes funcionais. A verdade que a filosofia da disciplina contextualizar o cliente, o negcio e o problema dentro de um espao

52

definido, levando em conta a disponibilidade de investimento financeiro e humano, e chegar a uma proposta de soluo para o problema que seja satisfatoriamente compreendida e aceita pelo cliente.

3.2.2.2 Levantamento de requisitos

Nota-se que na atividade anterior ao levantamento de requisitos, a tarefa de descrio do problema alerta para a possibilidade de o desenvolvimento de um software no ser a melhor soluo a se adotar para a resoluo do problema do cliente. Portanto, no haveria sentido em se falar de levantamento de requisitos de sistema caso a soluo do problema estivesse inclinada para esse ponto. No transcorrer de toda a disciplina Concepo os profissionais envolvidos devem ser capazes de perceber a tendncia da proposta de soluo para no incorrerem em trabalho desnecessrio. Aplicando-se essa disciplina em um projeto acadmico, a probabilidade que essa situao ocorra praticamente nula, mas, como a METODES tem um propsito mais abrangente, podendo ser utilizada para a produo de softwares para clientes comerciais, por exemplo, faz-se necessrio deixar um alerta para que os profissionais que estiverem desempenhando os papis envolvidos nessa disciplina saibam como atuar. O objetivo dessa atividade listar e entender as funcionalidades que um software precisar fornecer como resultados a seus usurios. A maneira como o software realizar esses resultados, ser detalhado nas disciplinas de Detalhamento de Requisitos e Anlise e Projeto. O levantamento de requisitos de fundamental importncia para todo o projeto do software, pois seu resultado servir de base para a definio de pontos importantes como a delimitao de escopo, alm de nortear todo o desenvolvimento atravs da metodologia.

53

Os requisitos levantados nessa atividade devem tambm sofrer uma classificao para possibilitar maior clareza do que se pretende atingir como objetivos de projeto. Em um projeto METODES na disciplina Concepo, classifica-se os requisitos como:

Requisitos essenciais: aqueles que compem a parte fundamental do software e devem ser implementados dentro das limitaes e restries do projeto;

Requisitos desejveis: so aqueles que, dependendo do andamento do projeto, podem ser reclassificados como requisitos essenciais e serem implementados, mediante acordo formal entre o cliente e a equipe de projeto. Esses so os requisitos que no inviabilizam a soluo proposta ou que o cliente considera como no-essenciais para resolver seu problema. Eles podem agregar maior valor ao software, mas, geralmente por restries financeiras, deixa-se para implementaes de futuro aprimoramento do software;

No-requisitos: so os requisitos que a equipe de projeto e o cliente acordaram para no fazerem parte do escopo do projeto. Portanto, esses requisitos no sero implementados no software, a no ser que haja um novo acordo para sofrerem reclassificao. A ao de reclassificar no-requisitos dever ser tratada como uma solicitao de mudana de escopo de projeto, seguindo assim, os trmites que a disciplina Gesto de Mudanas da METODES define.

A equipe de projeto envolvida nessa atividade tem de realizar reunies, quantas forem necessrias, a fim de captar coma mxima preciso possvel os requisitos essenciais e

54

demais requisitos para o projeto com intuito de solucionar o problema apresentado pelo cliente. Alm de captar as funcionalidades que o sistema deve atender preciso extrair informaes sobre:

Infra-estrutura de fsica: verificar a disponibilidade ou necessidades de itens de infra-estrutura fsica que sero importantes para o projeto, tais como computadores e perifricos, instalaes de rede de dados (cabeamento e ativos de rede), condies de suficincia da rede eltrica e outros itens que o Gerente de Projeto julgar importante.

Infra-estrutura de servios: levantar necessidades de contratao de servios de comunicao (acesso Internet ou links dedicados) e hospedagem de stios WEB, alm de outros servios necessrios ao projeto.

Licenciamento de softwares: estimar o tipo e a quantidade de licenciamentos necessrios para o software, incluindo licenas de sistema operacional, de banco de dados e de qualquer outro software que o cliente precisar para que o software seja construdo sem restries legais.

Ainda no levantamento de requisitos, a equipe de projeto deve captar o mximo de requisitos no-funcionais para o software, atentando para as expectativas implcitas do cliente. Essas expectativas devem ser captadas e registradas no Documento de Viso e Escopo, e as expectativas inviveis ou julgadas no-importantes devem ser tambm registradas como itens fora do escopo de projeto.

55

Feita a considerao dos requisitos funcionais e no-funcionais para o projeto, recomenda-se equipe de projeto que avalie, nesse momento, as restries e ou limitaes que o cliente apresente e que possam influenciar na anlise do projeto. Por exemplo:

O cliente pode ter em sua empresa uma infra-estrutura de rede montada e definir que esta tem de ser mantida, nesse caso a anlise do software fica restrita a infra-estrutura existente;

Pode haver licenas de softwares j adquiridas pela empresa e isso passa a ser fator limitante da tecnologia a ser utilizada.

Existem muitas outras hipteses que podem ser consideradas. O importante entender e registrar as que podem causar impacto na concepo do projeto de software.

3.2.2.3 Soluo do problema

Solucionar o problema, para a METODES, significa propor uma soluo tecnicamente vivel para resolver o problema apresentado pelo cliente, considerando todo o contexto de seu negcio e as restries e limitaes impostas. A soluo apresentada nessa atividade no representa com detalhes nenhum modelo do que ser o software a se desenvolver no projeto, mas delimita as expectativas percebidas pelo cliente e serve como base norteadora para o trabalho de toda a equipe do projeto. A equipe de projeto deve consolidar nessa atividade todas as informaes extradas do cliente nas atividades anteriores em um documento que ser o primeiro artefato do processo de desenvolvimento, o Documento de Viso e Escopo. Nesse documento devem

56

estar contidas as informaes do cliente, descrio do negcio, descrio do problema, requisitos essenciais, requisitos desejveis, no-requisitos, limitaes impostas e suas conseqncias, e a sntese da soluo. Por exemplo, uma sntese da soluo, considerando todos os itens que compe a viso e o escopo do projeto, seria assim:

Desenvolver um sistema de computador que funcione na atual infra-estrutura de rede da empresa Annimos Instrumentos Musicais LTDA, para permitir que as vendas de balco sejam registradas, mantidas e posteriormente verificadas para fins de consultas, gerao de relatrios de venda e estatsticas de venda, sendo estas ltimas dirias, semanais, mensais e anuais. O sistema deve fazer parte da Intranet da empresa, seguindo o mesmo padro de layout grfico atual.

O entendimento da proposta de soluo depende muito dos outros itens inseridos na viso e escopo do sistema, portanto ela no deve nunca ser apresentada fora do contexto analisado por meio das informaes que se obtm durante toda a disciplina Concepo da METODES.

3.2.3 Resultados da disciplina

Dois importantes artefatos de projeto so gerados nessa disciplina. Alm do Documento de Viso e Escopo, tambm gerado o Aceite Formal de Projeto. Esse documento deve ser assinado ao cliente para ratificar a soluo apresentada pela equipe de projeto, concordando, dessa forma, com todo o teor e condies contidos no documento. Os artefatos detalhados posteriormente neste trabalho.

57

Uma boa execuo da disciplina Concepo da METODES garante a compreenso precisa da essncia do projeto, tanto por parte do cliente quanto da equipe de projeto. importante que ambos, aps o trmino da disciplina, no estejam preenchidos com dvidas ou falsas expectativas em relao a nenhum ponto do projeto, pois s assim o resultado final do projeto pode ficar livre de surpresas, e, geralmente, em um projeto de desenvolvimento de software as surpresas so geralmente desagradveis.

3.3 Gesto do projeto

3.3.1 Definio

na disciplina Gesto de Projeto que se figura um Projeto METODES. Um projeto METODES qualquer projeto de desenvolvimento de software que seja desenvolvido utilizando a metodologia por completo. Dessa forma, quando citado o termo Projeto METODES, quer-se dizer que o projeto citado foi concebido e executado sendo fidedigno ao que METODES define. A gesto de projeto da METODES acompanha todo o processo de desenvolvimento, do seu incio at o momento em que o produto de software implantado e entregue ao cliente. Cinco atividades dividem o trabalho de gerncia e controle de um Projeto METODES, todas elas sendo apresentadas e realizadas de forma quase simultnea. Isso porque as atividades da Gesto de Projeto podem ser requeridas a qualquer momento em qualquer momento da metodologia, seja para o controle de um resultado ou para uma solicitao de mudana de projeto.

58

3.5 FLUXO DE ATIVIDADES DA DISCIPLINA GESTO DE PROJETO

3.3.2 Atividades

As atividades da disciplina tm como objetivos acompanhar e controlar a execuo do projeto de software. Todas essas atividades se iniciam aps a finalizao da disciplina Concepo da METODES, quando de fato se tem o incio de um Projeto METODES. A figura 3.5 mostra o fluxo de atividades dessa disciplina.

3.3.2.1 Elaborao do plano de projeto

Um Projeto METODES tem incio a partir da assinatura do Documento de Viso e Escopo pelo cliente do software. Uma vez aprovado o projeto, ele precisa ser planejado e detalhado para o cliente de forma que ele possa saber qual ser o andamento almejado at o fim dos trabalhos.

59

Trata-se da elaborao do Plano de Projeto, que dever conter informaes do cronograma de atividades, cronograma financeiro, gesto de riscos, enfim, tudo que est envolvido em um projeto de software e que poder influenciar os resultados daquele projeto. A METODES fornece um artefato prprio e especfico para esse fim, porm, necessrio ressaltar que esse artefato no ser a realidade para todos os projetos. preciso que o Gerente de Projeto esteja atento s particularidades do seu projeto e proceda com as devidas adequaes no artefato. Esse plano de projeto ser identificado na metodologia como Plano de Projeto de Software (PPS), e ser descrito e detalhado em um captulo posterior deste trabalho. Essa atividade de elaborao do PPS acontece logo no incio do projeto do software, porm tem seu condicionado somente ao final de todo o projeto, isso significa que o PPS poder, e fatalmente, sofrer, alteraes ao longo da execuo do projeto. Por exemplo, quando surgir uma solicitao do cliente que se caracterize como uma alterao de escopo, prazos e custos do projeto podero sofrer alteraes. Em um caso desses necessrio que o Gerente de Projeto avalie o impacto nesses cronogramas e os custos de projeto, comunique ao Gerente de Relacionamento, para que este remeta ao cliente os ajustes necessrios no projeto e obtenha dele a aprovao formal para proceder com tais ajustes. Sob o contexto citado, necessria uma alterao no PPS e esta dever ser realizada no Controle de Artefatos, atividade responsvel por esse fim.

3.3.2.2 Solicitao de mudanas

Na METODES h a figura do Gerente de Mudanas, responsvel pelo recebimento e envio de solicitaes de mudanas.

60

A disciplina Gesto de Projeto recebe, basicamente, durante o processo de desenvolvimento do software, resultados do projeto e solicitaes de mudanas. Os resultados de projeto so, na prtica, os artefatos gerados em cada disciplina da METODES. Esses artefatos sero controlados na atividade de Controle de Artefatos. Os requisitos de software que foram definidos no Documento de Viso e Escopo tero um controle diferenciado na atividade de Controle de Requisitos. Essa atividade no controlara os artefatos de fato que se referem documentao dos requisitos, mas sim a rastreabilidade e as relaes dos requisitos de software com som seus artefatos, alm de outras informaes importantes para controle dos requisitos dentro do projeto do software. As solicitaes de mudanas podem ser de requisitos, de artefatos, de correo, de reviso, enfim, qualquer coisa que remeta alterao de um artefato da metodologia que j tenha sido produzido ou a qualquer item do PPS e caracterizado como uma solicitao de mudana. Todas as solicitaes de mudana sero enviadas ao Controle de Qualidade e, aps serem analisadas pelo gerente responsvel, sero deferidas ou indeferidas e remetidas novamente disciplina da METODES que fez a solicitao. Assim como as solicitaes de mudanas, os resultados do Controle de Artefatos e do Controle de Requisitos sero enviados, tambm, ao Controle de Qualidade.

3.3.2.3 Controle de artefatos

O controle dos artefatos dar-se- por meio de um documento especfico que ser identificado como Controle de Artefatos do Projeto (CAP). Alm do CAP a METODES sugere uma estrutura para guardar os arquivos eletrnicos que representam os artefatos de projeto. Esses arquivos so documentos de texto,

61

planilhas eletrnicas, cdigos do software, imagens, tudo o que representar um artefato em forma eletrnica. As ferramentas recomendadas para a utilizao em um Projeto METODES produzem esses arquivos e para padronizao e organizao desses a metodologia recomenda que seja criada uma estrutura de pastas essas arquivos. A estrutura de pastas proposta independente de sistema operacional e est representada de forma genrica, devendo ser adequada para a verso especfica do sistema operacional onde esto sendo executados os softwares que produziro os artefatos.

<<raiz>> |__<<nome_do_projeto>> |__<<Artefatos>> |__<<Gestao_Projeto>> |__<<Concepcao>> |__<<Det_Requisitos>> |__<<Analise_Projeto>> |__<<Construcao>> |__<<Teste_Funcional>> |__<<Implementacao>> |__<<Requisitos>> |__<<Outros>>

Os nomes indicados que esto em negrito recomenda-se que sejam mantidos e os outros substitudos de acordo com o projeto. Alm da estrutura de pastas sugerida, recomenda-se que os nomes dos arquivos recebam o sufixo _v.1.x, onde x um nmero seqencial para cada nova release do artefato em questo, sendo 0 para a verso inicial e (1, 2, 3,... ) para cada vez que o artefato for atualizado. Dessa forma teramos a verso v.1.0, v.1.1, v.1.2, e assim por diante. Caso o artefato sofra uma alterao que caracterize uma mudana grande para a verso anterior, ento haver a necessidade de mudana de verso do artefato, passando para v.2.0, v.2.1, v.2.2, assim seqencialmente.

62

O aluno poder tambm utilizar uma ferramenta CASE para realizar o trabalho de controle de verses, mas mesmo nessa hiptese, recomenda-se que a planilha de Controle de Artefatos de Projeto da METODES seja preenchida.

3.3.2.4 Controle de requisitos

A METODES comea o controle de requisitos a partir da disciplina Detalhamento de Requisitos, onde sero especificados, detalhados e documentados. Desse ponto em diante, toda e qualquer ao que envolva os requisitos deve passar por essa atividade de controle. Nessa atividade h uma Planilha de Controle de Requisitos (PCR) que constitui o artefato principal dessa atividade. Tem por objetivo documentar a vida do requisito durante a execuo do projeto de software. Portanto, informaes como: data de aprovao, registros de alterao, relacionamentos com as funcionalidades do software e outras coisas mais sero encontradas nessa planilha. Os resultados dessa atividade tambm sero acompanhados pelo Controle de Qualidade e, portanto, devem ser encaminhados a ela.

3.3.2.5 Controle de qualidade

O Gerente de Qualidade o papel responsvel por conferir o andamento do projeto de acordo com o que foi planejado. Alm disso, nessa atividade que so colhidos os resultados do projeto e lanados na Planilha de Resultados de Projeto (PRP), que servir a futuros Projetos METODES como medida de comparao de fator de qualidade. O objetivo do Controle de Qualidade colher resultados e compar-los ao que era esperado pelo cliente do software e pela equipe de projeto. Dessa forma, tem-se uma

63

perspectiva de avaliao no s do ponto de vista do produto, mas tambm do processo de desenvolvimento. A METODES define um produto de software de qualidade como aquele que atendeu explicitamente ao que foi especificado no Documento de Viso e Escopo e que seu desenvolvimento tenha ocorrido dentro do prazo e custo previsto no Plano de Projeto de Software, j considerando quaisquer ajustes que tenham ocorrido independente por qual motivo, durante a realizao do projeto. Acredita-se que a Planilha de Resultados de Software ser um instrumento a ser utilizado para Projetos METODES como fonte para estimativas de prazos e custos, alm de fonte comparativa de fator de qualidade.

3.3.3 Resultados da disciplina

O principal resultado da disciplina de Gesto de Projeto possibilitar que o plano de projeto possa ser cumprido como definido, isso j admitindo possveis ajustes de prazos e custos de projeto. Alm disso, espera-se que os resultados obtidos nessa disciplina possam contribuir para uma melhoria contnua da METODES, avaliando e comparando o resultado de outros projetos realizados coma metodologia. Um bom acompanhamento de um projeto de software pode trazer maior qualidade no produto final, j que as questes que envolvem riscos no projeto podem ser melhor dirimidas.

64

3.4 Detalhamento de requisitos

3.4.1 Definio

Na METODES a disciplina que trata do levantamento de requisitos, como j visto, a Concepo, entretanto, sem entrar em detalhes e pormenores de cada requisito. Acreditase que para os alunos de Sistema de Informao da FACEB, essa a forma mais eficaz para trabalhar com os requisitos, visto que as iteraes com o cliente nem sempre so fceis, por diversos motivos, principalmente disponibilidade e choque de agenda ou tempo insuficiente. Sendo assim, a utilizao da METODES pode simplificar o trabalho dos alunos, pois o maior contato com o cliente pode ser feito durante a execuo da Concepo. Apesar disso, as interaes com o cliente no acabam na Concepo, mas com o escopo do projeto definido e os requisitos levantados (essenciais, desejveis e no-requisitos), torna-se mais fcil detalhar os requisitos definidos. Detalhar os requisitos o objetivo principal dessa disciplina e para isso ser necessria a compreenso total dos fluxos de trabalho e tambm dos processos de negcio em que esto inseridos. Sommerville (2003) faz uma classificao de requisitos segundo seus nveis de descrio, sendo requisitos de usurio as declaraes, em linguagem natural e tambm em diagramas sobre as funes que o sistema deve fornecer e as restries sobre as quais deve operar e, requisitos de sistemas, como as descries detalhadas das funes e restries do sistema. A partir dessa classificao o autor define os requisitos funcionais e no-funcionais. Para Sommerville (2003), requisitos funcionais so declaraes de funes que o sistema deve fornecer como o sistema deve reagir a entradas especficas e como deve se comportar em

65

determinadas situaes e os requisitos no-funcionais so as restries sobre os servios ou as funes oferecidos pelo sistema. Na disciplina Concepo da METODES os requisitos so classificados como essenciais, desejveis e no-contemplados. Esses requisitos sofrero nova classificao na disciplina Detalhamento de Requisitos. Agora, dentre cada conjunto anteriormente classificado, sero classificados como requisitos funcionais e no-funcionais. Os requisitos funcionais compreendem todas as funcionalidades que o sistema deve apresentar, considerando aquelas funcionalidades que esto alheias interveno ou interao do usurio com o software. Por exemplo, funes internas que realizam procedimentos essenciais para o funcionamento do software, mas no foram citadas pelo usurio. Os requisitos no-funcionais so aqueles que se referem ao atendimento de uma demanda no diretamente relacionada s funes do software. Por exemplo, o padro esttico das interfaces grficas do software, o tempo mximo de resposta de determinada requisio, ou ainda, tipo de linguagem de programao a ser utilizado para o desenvolvimento. A METODES especifica e documenta os requisitos funcionais definidos na Concepo por meio do Caso de Uso de Funcional (CUF), que se configura como mais um artefato da metodologia. Para a modelagem de um CUF deve ser utilizado o diagrama de caso de uso da UML. Dentro do Detalhamento de Requisitos h uma outra disciplina, a Prototipao, onde seus resultados, os prottipos de interfaces grficas, apresentam-se como condies precpuas para a validao dos requisitos. A prototipao de interfaces grficas na METODES tem como objetivo apresentar ao cliente uma idia de como o usurio interagir com as diversas interfaces que o software lhe apresentar. No inteno dos prottipos demonstrarem funcionalidades do sistema, ou seja, o prottipo totalmente passivo e tambm

66

no representa as interfaces finais do software, pois s depois da disciplina de Anlise e Projeto que as interfaces sero totalmente definidas. Nessa disciplina de detalhamento de requisitos o Analista de Requisitos o nico papel envolvido diretamente, mas como seu trabalho tem de ser feito com os usurios do software o Gerente de Relacionamento pode ser envolvido.

3.6 FLUXO DE ATIVIDADES DA DISCIPLINA DETALHAMENTO DE REQUISITOS

67

3.4.2 Atividades

Nessa disciplina so consolidados os Casos de Uso Funcionais da METODES. A correlao preliminar e padro que cada funcionalidade listada como requisito na Concepo, e que for um requisito funcional, tornar-se- um CUF. Dessa forma, a primeira atividade a ser realizada a Classificao dos Requisitos. Nessa atividade que os requisitos da METODES sero classificados como requisitos funcionais e no-funcionais, alm disso, ainda durante a classificao, ocorrer tambm a priorizao deles.

3.4.2.1 Classificao e priorizao dos requisitos

A partir do conjunto de requisitos classificados na Concepo, o Analista de Requisitos deve classific-los como requisitos funcionais e no-funcionais. Cada requisito funcional seguir pela METODES como um CUF. Um CUF um documento que contm a descrio e o detalhamento de um requisito funcional do software. Ele deve ser modelado utilizando o diagrama de caso de uso da UML alm das descries textuais necessrias para tornar claro o entendimento do requisito. Os requisitos no-funcionais sero documentados individualmente por meio do Documento de Requisito No-Funcional (DRNF). Cada DRNF fornecer uma descrio detalhada do que , e como aquele requisito no-funcional ser atendido ou tratado, informando, tambm, os objetivos e conseqncias do tratamento desse requisito. Dependendo do requisito no-funcional, pode no haver modelos ou diagramas especficos da UML para serem utilizados na descrio desses requisitos. Porm, a equipe de

68

projeto pode convencionar um diagrama qualquer para ser utilizado nessa descrio, levando em considerao as caractersticas do requisito no-funcional que estiver sendo tratado. Depois de os requisitos serem classificados, eles devem ser priorizados para as disciplinas subseqentes da METODES. A priorizao ser um tipo de ordenao dos requisitos segundo o grau de essencialidade, ou seja, o Gerente de Projeto, com a aquiescncia do cliente do software, dever estabelecer quais sero os primeiros requisitos a serem desenvolvidos, aqueles fundamentais para o cumprimento das metas do projeto. Os critrios utilizados para estabelecer as prioridades dos requisitos podem ser os mais diversos em um projeto de software, desde questes financeiras at a escassez de pessoal, portanto, essa priorizao precisar ter o acorde formal do cliente. Como a METODES admite o desenvolvimento de forma iterativa e incremental a classificao dos requisitos poder ser realizada ainda na disciplina Concepo, no entanto, essa classificao e priorizao deve ser documentada segundo as determinaes da atividade Classificao e Priorizao dos Requisitos.

3.4.2.2 Detalhamento dos requisitos funcionais

Essa atividade acontecer paralela atividade de prototipao. Nela sero considerados apenas os requisitos funcionais do software, ou seja, os CUF. Para a anlise de um CUF devero ser consideradas as interaes com o usurio que so produzidas, as interaes com outros sistemas, pr-condies que devem existir para que o CUF se realize e tambm as situaes posteriores realizao dele. Os diagramas de caso de uso da UML sero utilizados para modelar os CUF. Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e uma descrio de um conjunto de seqncias de aes, incluindo variantes realizadas pelo sistema para produzir um

69

resultado observvel do valor de um ator. (BOOCH, RUMBAUGH, JACOBSON, 2005). As variantes realizadas pelo sistema so fluxos secundrios ou alternativos que podem ocorrer durante a execuo de uma funcionalidade do software. Na METODES essas variantes so tratadas como fluxos alternativos de um CUF e no h a obrigatoriedade de serem documentadas pelo Analista de Requisitos, desde que no haja comprometimento do entendimento do CUF pelo Projetista do sistema. Na modelagem de um caso de uso, um ator representa qualquer elemento que interaja com o sistema, seja um usurio, um hardware ou mesmo um outro sistema. Dessa forma os atores precisam ser descritos e contextualizados naquele CUF. Tudo isso para tornar mais clara a descrio do caso de uso.

3.4.2.3 Prototipao

Paralelo atividade de detalhamento dos requisitos funcionais, um prottipo visual do software deve ser criado para facilitar o entendimento do comportamento da funcionalidade. O prottipo de software tem como nico e exclusivo objetivo criar uma viso grfica representativa do CUF, portanto, no h nenhuma funo implementada. Acredita-se que uma interface grfica ajuda na compreenso e validao de um requisito apresentado ao usurio, e tambm auxilia na transmisso do entendimento entre Analista de Requisitos e Projetista, pois uma viso grfica de um CUF restringe as dvidas levadas ao Projetista. A prototipao deve ser realizada por especialista em design grfico. Na METODES esse papel ser do Prototipador. Os prottipos criados nessa etapa do processo de desenvolvimento podem ou no gerar as interfaces grficas definitivas. Para tanto, a METODES tem como diretriz que os prottipos de software devem ser construdos

70

utilizando-se de linguagens visuais que possam ser implementadas no futuro. Por exemplo, se h clareza na Concepo que o sistema a ser desenvolvido ser em formato Web, os prottipos devem ser feitos, portanto, em HTML. O ideal que os prottipos sejam sempre construdos na linguagem em que o sistema ser desenvolvido. Embora a definio da linguagem de construo a ser utilizada no projeto acontecer formalmente na disciplina de Anlise e Projeto, geralmente essa definio se d nas disciplinas anteriores, seja por questes de restrio de projeto ou outra questo qualquer. As tarefas da Prototipao so:

Definir linguagem de construo: considerar uma linguagem visual para construo do prottipo, se possvel, utilizar a mesma linguagem de construo do projeto;

Levantar requisitos de interface do Caso de Uso Funcional: identificar elementos grficos necessrios como botes, nome e metforas para os elementos grficos, campos de texto, figuras e desenhos para afforadance objeto, tamanho dos objetos e cores; Requisitos de interface podem ser considerados requisitos no-funcionais de um software, porm, para a METODES, o prottipo algo puramente visual e no interfere na anlise e projeto do sistema como um todo, dessa forma o projeto de interface grfica do sistema segue sendo tratado de forma integrada ao processo, porm em paralelo a outras atividades da metodologia;

Construir prottipo: Construir o prottipo segundo os requisitos de interface levantados;

71

Validar prottipo: o prottipo ser um fundamento para a validao do requisito pelo usurio, entretanto o prottipo em si deve ser validado pelo Analista de Requisitos para corrigir no-conformidades entre o seu entendimento e o do Prototipador.

3.4.2.4 Detalhamento dos requisitos no-funcionais

Cada requisito no-funcional na METODES documentado como DRNF (Documento de Requisito No-Funcional). O DRNF o artefato onde estaro as informaes e condies necessrias para que esses requisitos sejam atendidos. Ou seja, tudo o que precisa ser realizado ou adquirido para que o projeto atenda aos requisitos no-funcionais especificados para o software. Sendo assim, o DRNF deve conter a descrio do requisito no-funcional, os objetivos desse requisito, as conseqncias de no atendimento, os CUF relacionados e a soluo proposta para o atendimento do requisito no-funcional. Caso seja necessrio, devero ser inseridos diagramas, preferencialmente da UML, que exemplifiquem a soluo proposta para o atendimento do requisito no-funcional. O DRNF constitui um artefato da metodologia e ser descrito e detalhado com os outros artefatos em um captulo posterior.

3.4.2.5 Documentao dos requisitos

Documentar os requisitos significa criar os artefatos especficos para cada tipo de requisito, funcional e no-funcional. No caso da METODES esses artefatos so o CUF e o DRNF.

72

3.4.2.6 Homologao e validao dos requisitos

A homologao e validao dos requisitos acontecem assim que for possvel demonstrar ao usurio do software como a equipe de projeto entendeu o comportamento de uma funcionalidade. Na METODES isso se d quando um CUF totalmente detalhado, inclusive com os DRNF a que se relacionam e, tambm, os prottipos de interfaces grficas que se ligam a ele. Os resultados do detalhamento dos requisitos so demonstrados ao usurio e, ento, para cada CUF, gerado um Termo de Aceite de Requisito (TAR). Esse aceite um termo que o cliente dever assinar, ratificando as informaes nele contidas e aceitando as condies de realizao do CUF.

3.4.3 Resultados da disciplina

Espera-se que ao final dessa disciplina todos os requisitos estejam completamente compreendidos pela equipe de projeto. Alm disso, fundamental que usurio do software esteja de pleno acordo com o entendimento que o Analista de Requisitos teve de sua declarao de requisitos, ou seja, no basta que o cliente assine um documento ratificando o trabalho do Analista, essencial que usurio e o Analista entendam, ao final da disciplina, o requisito da mesma forma. Formalmente os resultados dessa disciplina so: CUF e o DRNF.

73

3.5 Anlise e projeto

3.5.1 Definio

Como j dito, a METODES oferece a possibilidade do desenvolvimento do software de forma iterativa e incremental. Conceitualmente, isso significa que a cada nova iterao todas as disciplinas da metodologia seriam realizadas, entretanto, na METODES, as iteraes acontecem a partir da disciplina Detalhamento de Requisitos. Isso porque na disciplina Concepo so realizadas as atividades que definem o escopo do projeto, portanto s realizada uma nica vez. Desse ponto em diante as necessidades de alterao so tratadas como solicitaes de mudana de escopo de projeto. Em Anlise e Projeto, o Projetista, papel responsvel por essa disciplina, realizar as suas atividades tendo como base os requisitos definidos na Concepo. nessa etapa da metodologia que a soluo do problema, indicada no Documento de Viso e Escopo, comear a receber um tratamento tcnico para viabiliz-la. O Projetista deve se ater a todo o conjunto de requisitos especificados para projetar uma soluo que atenda aos anseios dos usurios do software em todos os aspectos. Isso significa que, alm de prover soluo s funcionalidades que o software deve apresentar, ou seja, os requisitos funcionais, a soluo projetada deve, tambm, atender aos requisitos no-funcionais. importante salientar a semntica do termo projeto para essa disciplina. Do ingls temos project e sua traduo literal que projeto. Nessa forma o termo significa projeto, se referindo a um plano de realizao de algo, um procedimento estruturado e organizado com um desgnio especfico. Porm, no contexto da engenharia de software, esse termo pode estar se referindo traduo de design, que tambm traduzido do ingls como projeto, que nesse caso se refere forma com que o software ser modelado. Normalmente

74

essa semntica aparece nas disciplinas de anlise e projeto, ou anlise e desenho, dos processos comerciais de desenvolvimento. A anlise e o projeto de um software podem aparecer como disciplinas distintas em uma metodologia por apresentarem sutis diferenas para alguns e bastantes relevantes para outros. Pfleeger (2002) traz o conceito de projeto conceitual (anlise) e projeto tcnico (projeto). O primeiro o projeto do sistema na viso do cliente e se prope a responder o qu o sistema far. O outro o projeto tcnico do sistema que responder aos construtores do software como o sistema far o que props fazer ao cliente. Pdua (2003) diz que na anlise o foco a modelagem dos conceitos presentes no domnio do problema, porm os detalhes tcnicos que pertenam construo devem ser evitados. Na METODES a anlise e o projeto do sistema so realizados como uma s disciplina para facilitar o trabalho e a compreenso do aluno na hora de projetar um sistema, j que, na prtica a anlise e projeto se diferenciam no nvel de detalhamento dos dois modelos. Acredita-se que para o aluno, diante de um problema que ele precise resolver, seja mais fcil considerar todos os aspectos que envolvem aquela soluo e criar um s modelo a ser detalhado de forma gradual na disciplina a tentar criar dois modelos iguais com detalhamento diferenciado. Considerar a totalidade dos aspectos envolvidos na soluo pode parecer ser mais trabalhoso, mas na verdade pode se tornar a maneira mais prtica e objetiva de resolver um problema. A reviso e o detalhamento dos aspectos considerados no projeto acontecero medida que o domnio do problema analisado pelo Projetista. A METODES define em sua disciplina Anlise e Projeto algumas linhas de ao que o Projetista deve executar para contemplar os aspectos tcnicos e no-tcnicos envolvidos na soluo. Os aspectos que a metodologia sugere serem tratados so apresentados de forma generalizada e abrangente. Isso significa que no so os nicos aspectos que devem ser

75

considerados e nem que esto apresentados da forma mais adequada para qualquer projeto de software. Os aspectos que a metodologia prope serem tratados so aqueles que podem aparecer na maioria dos projetos de software, porm, no h garantias de que sejam ao menos suficientes para contemplar essa maioria de projetos. Os aspectos definidos pela METODES tambm podem ser entendidos como vises de anlise. As vises propostas para um projeto de software so trs: viso de arquitetura, viso de infra-estrutura e viso de segurana. Essas trs vises abrangem os aspectos essenciais que devero ser tratados em um projeto de software realizado com a METODES.

3.5.2 Vises de anlise

3.5.2.1 Viso da arquitetura

Os aspectos arquiteturais que a metodologia considera tm como objetivo eleger a arquitetura de software e arquitetura de comunicao que servir ao sistema. sabido que a escolha dessas duas arquiteturas depender das caractersticas do software que se desenvolver e seu conjunto de requisitos, contudo os pontos aqui descritos servem a apenas como orientao para a definio dessas arquiteturas. Na disciplina Concepo da METODES alguns itens podem j ter sido definidos. Por exemplo, o cliente poderia j ter montada sua infra-estrutura de rede, portanto, cabe ao Projetista adequar a seu projeto, tudo aquilo que tenha de ser aproveitado. Cabe aqui tambm a considerao dos softwares que j estejam instalados ou adquiridos pelo cliente, ento, o projeto fica condicionado a esses itens j definidos. O trabalho do Projetista ser desenvolver

76

uma soluo que contemple o que j existe e que promova os resultados esperados do software pelo cliente.

3.5.2.2 Viso da infra-estrutura

Os aspectos de infra-estrutura que devem ser tratados se referem a todos os elementos necessrios para viabilizar a implementao das arquiteturas de software e comunicao definidas anteriormente. O recomendado a ser tratado pela METODES a infraestrutura de ativos fsicos e a infra-estrutura de software.

3.5.2.3 Viso da segurana

A METODES trata nessa viso as questes de segurana que permeiam o desenvolvimento do software. Cada projeto de software pode exigir um conjunto especfico de requisitos de segurana que devem ser tratados, porm, na maioria dos casos as questes que a METODES sugere que sejam tratadas, mostram-se relevantes e pertinentes. Os quatro pontos essenciais que so tratados pela METODES so: Classificao e Proteo dos Dados, Trfego Seguro das Informaes, Persistncia e Recuperao dos Dados e Segurana Fsica.

3.5.3 Atividades

A figura 3.7 apresenta o fluxo geral de atividades que o Projetista deve excetuar na disciplina Anlise e Projeto da METODES. Logo aps, tm-se as descries das atividades dessa disciplina.

77

3.7 FLUXO DE ATIVIDADES DA DISCIPLINA ANLISE E PROJETO

3.5.3.1 Definio das vises de anlise

O trabalho que realizado nessa atividade acontecer intensamente durante toda a disciplina de anlise, pois nessa atividade que decises importantes sobre o projeto precisaro ser tomadas. Muitas dessas decises podero no tero um carter definitivo logo no incio do projeto do software, a avaliao deve ser considerada ao longo do desenvolvimento de toda a disciplina Anlise e Projeto. Algumas questes como a definio da arquitetura de software a ser utilizada, podem no sofrer grandes alteraes ao longo do projeto, outras, porm, como arquitetura de comunicao e a infra-estrutura de software podem se mostrar bastantes dinmicas e instveis. No entanto, essas so apenas especulaes que se faz para demonstrar a necessidade da constante reviso do projeto e da modelagem das vises de anlise, termo

78

utilizado pela METODES para definir o tratamento das questes de arquitetura, infraestrutura e segurana do projeto. O Projetista deve considerar o conjunto de requisitos definidos no Documento de Viso e Escopo para avaliar e projetar cada uma das vises de anlise que a METODES define. A partir das avaliaes dessas vises de anlise sero gerados artefatos especficos para document-las:

Modelagem da Viso de Arquitetura de Software (MVAS): documento que apresenta a arquitetura de software escolhida para o software, contendo a sua descrio completa, os motivos que levaram sua escolha, o detalhamento de camadas, caso existam naquela arquitetura, e a todas as demais descries necessrias para que o apreciador desse documento entenda a arquitetura exposta.

Modelagem da Viso de Arquitetura de Comunicao (MVAC): apresentao da topologia fsica e lgica de rede, demonstrando, em um nvel baixo de detalhamento tcnico, as ligaes dos componentes envolvidos e dos links de comunicao. Esse documento tem por objetivo identificar o esquema de comunicao lgico que utiliza.

Documentao da Infra-estrutura de Ativos Fsicos (DIAF): simplesmente a descrio de todos os ativos fsicos utilizados. Hubs, switches, roteadores, modems, servidores (computadores). Ou seja, todo ativo que direta ou indiretamente tem um papel no funcionamento do software deve ser caracterizado e descrito nesse documento. A descrio dever ser completa e conter a especificao tcnica de cada um deles. Por exemplo, qual o processador do

79

servidor de banco de dados? Qual a quantidade de memria RAM? Qual a capacidade de armazenamento? Que sistema de disco foi utilizado? Qual o sistema de arquivos dos discos? Enfim, todos os detalhes que permita conhecer bem a infra-estrutura sob o ponto de vista fsico e tcnico.

Documentao da Infra-estrutura de Software (DIS): muito parecido com o DIAF, porm, trata especificamente dos softwares utilizados. Nesse caso so descritos todos os softwares que compe a soluo, mas no o software que est sendo desenvolvido. Por exemplo, o sistema operacional que roda no servidor de banco de dados, a verso que foi instalada, se for um Linux qual a verso do kernel, qual a distribuio, enfim, detalhes que explicitam bem o ambiente do software.

Modelagem da Viso de Segurana (MVS): a viso de anlise de segurana da define quatro pontos essenciais que devem ser observados nessa viso. So eles: Classificao e Proteo dos Dados, Trfego Seguro das Informaes, Persistncia e Recuperao dos Dados e Segurana Fsica. Nesse documento dever ser feita a considerao para cada um desses pontos, apontando a soluo adotada para cada ponto quando for o caso. Recomenda-se que as solues sejam tambm demonstradas utilizando alguma linguagem visual para facilitar o entendimento, por exemplo, diagramas, esquemas, grficos, enfim, qualquer elemento que se mostre adequado para representar a soluo escolhida. Caso algum diagrama da UML possa ser utilizado dar preferncia a ele.

80

O trabalho do Projetista bastante intenso e poder refletir diretamente na qualidade do produto de software desenvolvido, pois ele atua como arquiteto, consultor tcnico e analista de sistemas quase que ao mesmo tempo. A seguir tm-se as especificaes de cada tpico que as vises de anlise tratam para um projeto METODES.

3.5.3.1.1 Arquitetura de software

Nessa etapa da metodologia o Projetista deve considerar os padres de projeto (design patterns) que podem ser utilizados para, ento, eleger o melhor tipo de arquitetura de software que atenda aos requisitos do software, tanto os requisitos funcionais como os nofuncionais. Recomenda-se que, na avaliao da arquitetura de software, seja definida tambm a plataforma de desenvolvimento, j que a deciso da arquitetura pode influenciar na escolha da linguagem de programao, frameworks e vice-versa.

3.5.3.1.2 Arquitetura de comunicao

Mais uma vez, devem-se considerar as caractersticas do projeto de software para a definio da arquitetura de comunicao que atender aos propsitos do software. Aqui devem ser tratadas as questes das tecnologias de rede, topologia fsica, topologia lgica, qualidade de servio (QoS Quality of Service), links de comunicao, redundncia desses links, enfim, todos os aspectos necessrios para atender os requisitos de comunicao entre os diversos elementos ou componentes do sistema.

81

3.5.3.1.3 Ativos fsicos

Trata-se dos componentes que daro suporte s arquiteturas definidas. Todo e qualquer hardware necessrio para promover a implantao do software de acordo com as definies do projeto. Componentes de rede (cabeamento, switchs, routers, modems), bem como, os computadores e perifricos (impressoras, plotters, scanners) devem ser especificados para atender arquitetura de comunicao definida.

3.5.3.1.4 Softwares

Todos os softwares que precisaro ser adquiridos e licenciados para suportar a arquitetura definida. Inclui-se nesse caso a definio da plataforma de sistema operacional, frameworks, definio do SGBD e qualquer outro componente que seja essencial para o funcionamento do software.

3.5.3.1.5 Classificao e proteo dos dados

Caso seja necessrio ao projeto, a METODES recomenda que os dados que so manipulados pelo software estejam classificados como pblicos, restritos ou privados. Cada um desses tipos de dados requer um cuidado especial para armazenamento. O Projetista deve considerar as questes de criptografia e demais questes de segurana no desenho do modelo do banco de dados, no permitindo, por exemplo, que dados restritos ou privados se apresentem acessveis para usurios no autorizados, ou que, o acesso a eles seja disponibilizado diretamente ao usurio. sempre recomendado que haja uma

82

camada de software que sirva como elo entre o usurio (apresentao) e os dados (persistncia).

3.5.3.1.6 Trfego seguro das informaes

Esse aspecto deve ser tratado quando h troca de informaes em um meio hostil, como a Internet, por exemplo. Isso significa dizer que se deve ter o cuidado de no trafegar informaes sigilosas como senhas e dados pessoais pela rede, sem que estejam criptografadas. Sempre que houver a necessidade de trafegar esse tipo de informao recomendado que se trafegue por canal de comunicao criptografado.

3.5.3.1.7 Persistncia e recuperao dos dados

O tratamento da persistncia e recuperao de dados extremamente importante que se tenha clareza de como, onde, e por quanto tempo os dados devem persistir para o sistema. Alm disso, necessrio estar documentado com clareza a forma com que os dados mais antigos podem ser recuperados, para o caso de sistemas que precisem manter algum tipo de histrico. Na METODES o Projetista deve elaborar os processos operacionais que tratam da manuteno da persistncia desses dados. Processos documentados que dizem como, quando, onde, e quem so os responsveis por manter a base de dados persistente pelo tempo necessrio. So esses processos que definem como so executados os procedimentos de backup e restore dos dados do sistema. Esses procedimentos podem ser automatizados, mas em alguns casos as infra-estruturas podem depender da interveno humana para que se finalizem por completo.

83

3.5.3.1.8 Segurana fsica

A segurana fsica se refere ao ambiente interno onde esto os ativos fsicos da infra-estrutura que servem ao sistema. Servidores e ativos de rede no devem ficar expostos a qualquer usurio ou pessoas externas no autorizadas. Somente usurios que tenham privilgios administrativos devem executar tarefas nesses equipamentos. Idealmente, a infraestrutura deve estar isolada o mximo possvel do ambiente operacional do sistema para evitar que ataques fsicos aos equipamentos comprometam a integridade e o sigilo das informaes. O nvel de segurana fsica aplicada a um sistema est diretamente ligado criticidade do sistema. Por exemplo, um sistema que tenha que estar disponvel vinte e quatro horas por dia, sete dias por semana, no pode estar a merc de uma simples tomada de fora ou um cabo de rede que, se arrancados, pe abaixo todo o funcionamento do sistema. A disponibilidade de um sistema apenas um exemplo, o qual poderia ser tratado com a adoo de mecanismos de redundncia, mas vrios outros aspectos podem ser comprometidos com a falta de segurana fsica, roubo de informaes, comprometimento da integridade dos dados e outros aspectos que podem ser violados. Cabe ao Projetista analisar os requisitos do software (ou sistema), a poltica da empresa e os riscos do produto para definir os mecanismos de segurana fsica necessrios.

3.5.3.2 Detalhamento do modelo de classe

Utilizar-se- nessa atividade o diagrama de classes da UML para se realizar a modelagem de classes do software.

84

O diagrama de classe do software integra mais um artefato da metodologia e ser identificado por Modelo de Anlise de Projeto (MAP). Dependendo do tamanho do software, diagramas de classes podem ser muito extensos, o que dificulta sua leitura e interpretao. Assim sendo, o Gerente do Projeto pode optar por fazer um diagrama de classes para caso de uso funcional (CUF). A METODES recomenda que seja feito um diagrama de classe para cada CUF. Alm disso, ao final da anlise de todo o sistema, recomenda-se que haja, tambm, um nico diagrama de classe que represente todo o sistema. O diagrama de classes oferece ao projeto de software uma abstrao dos objetos, identificando os componentes que fazem parte da classe, os atributos e mtodos, criando um modelo com uma melhor viso mais prxima do mundo real para criar programas executveis facilitando o entendimento do que ser desenvolvido. Para isso o aluno deve, nessa tarefa, tentar identificar as classes, os relacionamentos entre as classes e analisar o comportamento delas, abstraindo o problema em nvel de objetos. A atividade deve ocorrer quantas vezes necessrias at termos um diagrama com detalhamento tcnico suficiente para seguir para a disciplina Construo. O fluxo de atividades da disciplina Anlise e Projeto da METODES pem um fluxo paralelo de execuo das atividades que se seguem neste texto, com o fim de promover uma seqncia ordenada e prtica de aes que precisaro ser tomadas para dar prosseguimento a anlise e projeto do software.

3.5.3.3 Projeto de interfaces grficas

O projeto de interfaces grficas atende principalmente ao usurio do software. Essas interfaces precisam ser construdas de forma que qualquer pessoa, sem conhecimentos tcnicos aprofundados, consiga manusear o software.

85

Na METODES as interfaces grficas so construdas de fato pelo Construtor, mas essas interfaces, ou telas do sistema, so especificadas durante a anlise e projeto do software. Isso significa que o Projetista deve considerar, durante a realizao dessa atividade, os aspectos que podem refletir diretamente nas telas do software. Por exemplo, os atributos visveis em uma determinada tela, a exigncia de um boto ou qualquer outro elemento da tela necessrio para a chamada de um mtodo, ou elementos para a definio de parmetros para uma consulta, ou seja, aquilo que o Projetista perceber que esteja faltando nos prottipos iniciais construdos.

3.5.3.4 Realizao de casos de usos

A METODES adotou o diagrama de seqncia da UML para realizar os modelos de caso de uso. Esse diagrama far parte do Modelo de Anlise e Projeto (MAP) e representar a realizao de um Caso de Uso Funcional (CUF). Um diagrama de seqncia da UML o aperfeioamento do modelo de caso de uso. Fazendo uso das informaes do modelo de classes, ele mostra a troca de mensagens entre objetos ao longo do tempo na realizao de uma operao. No ser possvel realizar um caso de uso sem as informaes obtidas no diagrama de classes. Os diagramas de seqncia na METODES integram a documentao do modelo de anlise de projeto (MAP). Dever ser realizado, obrigatoriamente, um diagrama de seqncia para cada caso de uso funcional (CUF). Os fluxos alternativos de operao podem ser omitidos, desde que no comprometam o entendimento do Construtor para a traduo desses diagramas para a linguagem de programao definida para o projeto.

86

3.5.3.5 Projeto de banco de dados

Aps a atividade de Detalhamento do Modelo de Classe ocorrer o Projeto de Banco de Dados. Essa atividade nada mais que a traduo de um modelo de classes para a linguagem de banco de dados definida para o projeto. Em caso de uso de uma linguagem de banco de dados relacional, dever ser produzido modelo entidade-relacionamento (MER), juntamente com o modelo fsico, ou seja, os scripts do banco de dados. Estes ltimos tambm integraro o Modelo de Anlise de Projeto (MAP).

3.5.3.6 Projeto de interfaces com sistemas

Nessa atividade devero ser consideradas as interaes do software em desenvolvimento com outras aplicaes, hardwares ou outras camadas de software. Essas interaes so consideradas interfaces externas ao sistema e so tratadas no projeto de interfaces com sistema. Essas interfaces externas podem ser outros sistemas ou consultas base de dados. Estando fora do escopo de atuao do software, em princpio pode ser considerada uma interface externa.

3.5.4 Resultados da disciplina

Espera-se como resultados da disciplina Anlise e Projeto da METODES, as definies de projeto, arquiteturas e infra-estruturas, que possibilitaro a realizao das funcionalidades requisitadas pelo cliente do software. Alm disso, nessa disciplina que so

87

produzidos os artefatos que serviro como base para a construo dos cdigos do software e dos scripts do banco de dados.

3.6 Construo

3.6.1 Definio

A disciplina Construo da METODES tem como principal objetivo transformar em cdigos, na linguagem de programao definida na disciplina anterior, as classes de objetos projetadas pelo Projetista. O Construtor, papel que realiza essa transformao, recebe da disciplina Anlise Projeto os Modelos de Anlise de Projeto (MAP) juntamente com os CUF relacionados para realizar sua traduo em cdigos de linguagem. O banco de dados, projetado em Anlise e Projeto, tambm construdo nessa disciplina, sendo o Construtor a pessoa responsvel por construir os scripts de gerao do banco, bem como implement-los. Na verdade, o Construtor o papel que efetivar a soluo tcnica proposta. Portanto, nessa fase da metodologia mais correto se referir ao banco de dados como Sistema Gerenciador de Banco de Dados (SGBD), pois as questes tcnicas j foram definidas, ento, o banco de dados a ser utilizado, a plataforma de sistema operacional, o hardware, enfim, toda a infra-estrutura j conhecida. Os resultados da codificao do CUF e do MAP, incluindo as interfaces grficas que os atendem, so definidos na disciplina Construo da METODES como elementos de software. O elemento de software o conjunto de resultados produzidos por meio da transformao, em linguagem de programao, dos CUF e MAP. Ou seja, telas do software, classes codificadas, script do SGBD mesmo que apenas parte desse script - e demais componentes de software que tenham sido escritos pelo Construtor.

88

O fluxo de atividades da Construo constitudo por quatro atividades interdependentes entre si. O fluxo de codificao de um requisito na METODES comea pela construo da interface grfica, seguindo adiante com a construo do elemento de software e o teste desse elemento. Paralelo a isso realizada a atividade Documentao, onde se inclui a produo dos documentos dos cdigos da classes, a documentao do usurio e a documentao de instalao do software. Devido ao grande nmero de documentos que devem ser gerados nessa disciplina, outros papis atuaro nessa atividade especfica de documentao, o Documentador, que ficar responsvel pela documentao do usurio e trabalhar em conjunto com o Projetista nessa disciplina na confeco dessa documentao. O Construtor ficar responsvel pela documentao dos cdigos de unidades e pela finalizao da documentao do banco de dados, iniciada na disciplina Anlise e Projeto. Em um primeiro momento, pode parecer que h uma sobrecarga de trabalho de documentao para os papis envolvidos nessa etapa da METODES, contudo, considerando o contexto acadmico que a metodologia aplicada, pode acontecer de um nico aluno ficar responsvel por vrios papis distintos durante todo o processo de desenvolvimento. Sendo assim, a sobrecarga de trabalho gerada naturalmente devido a isso. Portanto, no haveria efeitos prticos se a METODES adotasse vrios papis distintos para ficarem responsveis por cada tipo de documentao.

89

3.8 FLUXO DE ATIVIDADES DA DISCIPLINA CONSTRUO

3.6.2 Atividades

3.6.2.1 Construo da interface grfica

Aqui devem ser geradas as interfaces grficas do CUF que est sendo tratado de acordo com a sua documentao e com as especificaes do prottipo criado no detalhamento de requisitos. A tarefa principal do Construtor nessa atividade adequar os prottipos s especificaes tcnicas e funcionais definidas na disciplina de anlise, ou seja, aqui ele deve rever os prottipos criados e verificar se a forma como foram construdos est de acordo com

90

o esperado pelo usurio do software. Na Concepo h uma diretriz para se tentar identificar, se possvel, j nas definies de requisitos qual a provvel linguagem de programao a ser utilizada para que os prottipos iniciais sejam criados utilizando a mesma linguagem. A METODES tambm define que os prottipos de interfaces devem ser construdos em uma linguagem visual funcional para poder ser aproveitado na etapa de construo. Se essas diretrizes foram seguidas o trabalho do Construtor restringir adequao das interfaces grficas, caso contrrio ele dever construir as interfaces grficas seguindo os modelos apresentados ao usurio no momento da validao dos requisitos.

3.6.2.2 Codificao do elemento de software

O Construtor recebe como insumo os artefatos produzidos na disciplina Detalhamento de Requisitos e Anlise e Projeto da METODES. Os artefatos necessrios para o trabalho de construo so os CUF e os MAP. Aps a construo da interface de um CUF, o Construtor codificar as funcionalidades envolvidas naquele CUF, seguindo as especificaes do diagrama de caso de uso que documenta o CUF e dos diagramas contidos nos MAP.

3.6.2.3 Teste do elemento de software

Testar a unidade significa simplesmente eliminar bugs e certificar-se que as entradas de dados esto todas tratadas adequadamente. Alm disso, quando for o caso, verificar se os dados so gravados e recuperados com integridade no banco de dados. O teste de unidade se limita s classes ou unidade que est sendo tratada. A tarefa de teste de conformidade com os requisitos definidos ser realizada aps a construo

91

de todas as classes que realizam um CUF. Por exemplo: considerando uma tela de cadastro de fornecedores que utilize trs classes distintas para que ela funcione. Quando essas trs classes estiverem construdas presume-se que todas foram testadas logo aps a sua codificao, nesse caso, esse primeiro teste realizado individualmente s foi considerado o funcionamento daquela classe em questo. Depois disso h que se considerar se aquelas trs classes esto funcionando adequadamente para realizar o cadastro de fornecedores segundo os requisitos e regras de negcio definidas pelo cliente. O teste que verifica as conformidades com os requisitos e regras de negcio definidas denominado na METODES de Teste Funcional. uma disciplina que ocorre logo aps a disciplina Construo. Para isso necessrio que o CUF esteja completamente implementado, com sua interface grfica e as possveis interfaces com outros sistemas, alm das bases de dados implementadas e em funcionamento.

3.6.2.4 Documentao do elemento de software

Nessa atividade gerada a documentao que a METODES considera essencial para um projeto de software: o Manual do Usurio, o Manual de Instalao do Sistema e a Documentao dos Cdigos de Componente, alm dos scripts de criao do banco de dados que integraro o Modelo de Anlise de Projeto (MAP) de cada funcionalidade do sistema. As interfaces grficas tambm necessitam ser documentadas, porm essa documentao ocorrer fatidicamente quando for gerado o Manual do Usurio, pois esse documento deve conter as telas do software impressas para melhor compreenso do usurio.

92

3.6.2.4.1 Documento de cdigo de componente

Esse documento se configura como mais um artefato da disciplina Construo da METODES. Basicamente, nele deve conter a descrio da classe, a descrio dos atributos e mtodos enfatizando os argumentos de entrada e sada dos mtodos, alm do cdigo da classe. Assim como os outros, esse artefato ser descrito e detalhado em um captulo posterior.

3.6.2.4.2 Manual do usurio

Esse manual de operao do software para o usurio final. Ele deve conter as telas que fazem a interface com o usurio com a indicao de como deve ser feita as entradas de dados, os fatores que condicionam essa entrada, as mensagens de alerta previstas pelo software, a descrio dos campos e demais elementos da interface, como caixas de texto e botes. O Manual do Usurio deve ser claro o suficiente para que o usurio compreenda qual o propsito de cada tela do software, suas entradas e os resultados que dela ele pode esperar. Nessa atividade o Documentador e o Projetista trabalharo em conjunto para produzir a documentao do usurio. O Documentador fica responsvel por criar o texto e diagramar os documentos. O Projetista fica responsvel por fornecer o suporte necessrio ao Documentador, por conhecer em detalhes como realizada cada funcionalidade do sistema. O Construtor tambm pode auxiliar nessa atividade, sendo o Projetista o papel mais indicado para essa funo.

93

3.6.2.4.3 Manual de instalao do software

Dependendo das caractersticas do software desenvolvido, esse manual de instalao pode se tornar um documento bastante extenso e por demais tcnico. No se trata da instalao de um componente do software, mas sim de toda a soluo tcnica empregada para resolver um problema. Dessa forma, os procedimentos para instalao e configurao do ambiente de banco de dados, servios empregados na soluo, como Web Server, FTP, servidores de arquivos, enfim, todo o conjunto de servios que so essenciais para que o sistema funcione com todas as funcionalidades definidas no escopo do projeto. O Construtor o papel mais indicado para essa funo. Porm, dependendo do projeto, o Analista de Implantao pode tambm exercer essa funo. Tudo depender do nvel de detalhamento tcnico que a documentao exigir. O manual de instalao do sistema precisa estar escrito de tal forma que uma pessoa que no tenha participado do processo de desenvolvimento, mas que tenha conhecimentos tcnicos suficientes e adequados, consiga instalar o sistema e deix-lo em sua forma operacional.

3.6.3 Resultados da disciplina

Ao final da disciplina Construo da METODES espera-se, como resultados, as classes implementadas e documentadas, incluindo os manuais de operao para o usurio e os procedimentos para a instalao do sistema.

94

3.7 Teste Funcional

3.7.1 Definio

A METODES define dois objetivos para os testes funcionais: O primeiro a verificao de conformidade entre requisitos definidos e caso de uso funcional (CUF) construdos, ou seja, trata-se de uma avaliao dos resultados obtidos at a disciplina Construo em relao ao que foi definido como requisitos essenciais e desejveis pelo cliente na disciplina Concepo. O segundo objetivos avaliao das solues definidas para os requisitos nofuncionais. Para cada requisito no-funcional em questo, essa avaliao deve ser realizada em conjunto com o demandante do software, usurios e o Gerente de Relacionamento. Uma vez obtida a satisfao do usurio, considerar-se- os requisitos no-funcionais atendidos. Os testes funcionais devero ser planejados e adequados para cada tipo de software de pelo Analista de Testes, tendo este que analisar o software de maneira imparcial, considerando apenas o que est definido como requisito e o CUF que ele est analisando. O Analista de Teste pode, a qualquer momento, convocar qualquer outro papel da METODES para compor equipe ir executar o Plano de Realizao do Teste Funcional.

95

3.9 FLUXO DE ATIVIDADES DA DISCIPLINA TESTE FUNCIONAL

3.7.2 Atividades

Na primeira iterao de um projeto METODES as atividades dessa disciplina devero ser iniciadas. Se possvel algumas delas devem ser realizadas por completo visando aperfeioar a realizao dos testes funcionais para as demais iteraes. Um exemplo a atividade de Elaborao do Plano de Realizao do Teste Funcional e a Definio do Ambiente Operacional para Testes, duas atividades que estar definidas j na primeira iterao do projeto do software.

96

3.7.2.1 Elaborao do Plano de Realizao do Teste Funcional

Essa atividade visa definir as aes e papis necessrios para a realizao e avaliao dos da disciplina Testes Funcionais. O Plano de Realizao do Teste Funcional um artefato da metodologia que define um plano de trabalho para realizao das aes essenciais que devem ocorrer para que os objetivos dos testes funcionais sejam cumpridos. Esse e os outros artefatos sero tratados em um captulo posterior.

3.7.2.2 Definio de ambiente operacional para teste

Definir um ambiente operacional montar um ambiente mnimo que seja suficiente para executar o Plano de Realizao do Teste Funcional. Para os requisitos funcionais no so necessrios que todos os componentes da infra-estrutura, como servidores de rede e topologia fsica da rede, sejam considerados exatamente como definidos no projeto, sobretudo na Anlise e Projeto, para os testes, desde que isso no comprometa os resultados. Porm, para testes dos requisitos no-funcionais que dependem de alguma forma das definies da disciplina Anlise e Projeto, devem ser fidedignas em relao ao que foi definido e projetado. Como nem sempre isso ser possvel, admite-se que alguns testes funcionais possam ser realizados em paralelo disciplina Implantao.

3.7.2.3 Executar Plano de Realizao do Teste Funcional

Por em prtica o que foi definido no Plano de Realizao do Teste Funcional, documentando todos os resultados para posterior avaliao.

97

O Analista de Teste convocar os papis definidos para a execuo do plano para que executem as aes definidas e as documentem o que foi previsto pela equipe de Anlise e Projeto e o que foi observado por eles.

3.7.2.4 Avaliao de resultados

Aps a execuo do Plano de Realizao do Teste Funcional, consegue-se extrair as no-conformidades encontradas no desenvolvimento do software, podendo assim submetlas disciplina de Gesto de Projeto para tratamento adequado. Na Gesto de Projeto o Gerente de Mudana recebe e trata a solicitao como uma Solicitao de Mudana de Projeto. Nessa atividade da Gesto de Projeto o Gerente de Projeto identificar, quando possvel, aonde a no-conformidade dever ser tratada. No sendo possvel ele encaminhar o tratamento para disciplina Detalhamento dos Requisitos, passando subsequentemente por todas as disciplinas da METODES. Uma vez dado seguimento ao tratamento da no-conformidade a disciplina responsvel deve analisar e corrigir a no-conformidade encontrada. No havendo no-conformidades nos casos de uso funcional (CUF) testados, passa-se para a disciplina Implantao.

3.7.3 Resultados da disciplina

A disciplina Testes Funcionais da METODES prev como resultado a deteco e, quando possvel, dentro do prazo para execuo da disciplina, estabelecido na elaborao do Plano de Realizao do Teste Funcional, a correo de no-conformidades do software como um todo do CUF desenvolvido.

98

Se as no-conformidades detectadas no puderem ser resolvidas dentro do prazo de execuo dos testes funcionais, ser necessria uma avaliao do impacto que a resoluo dessas no-conformidades causar no cronograma do projeto. Assim o Gerente de Relacionamento pode tratar como com o demandante do software os ajustes necessrios nos prazos do projeto. Nem sempre sero necessrios ajustes nos prazos do projeto devido s noconformidades encontradas. Elas podem, por exemplo, ser tratadas durante novas iteraes do processo de desenvolvimento. O importante que a resoluo de no-conformidades no comprometa o prazo final do projeto.

3.8 Implantao

3.8.1 Apresentao

Implantar um sistema significa torn-lo operacional para o cliente. Portanto, quando um sistema est pronto para ser utilizado pelo usurio, com dados e situaes reais, considera-se que ele esteja implantado. A implantao de um sistema pode ocorrer de uma s vez, ou seja, depois dele todo construdo que se inicia o processo de implantao. Outra opo implantar o sistema medida que releases funcionais do sistema so disponibilizadas. Na METODES isso significa desenvolver um caso de uso funcional (CUF) por completo, ou seja, aps ter passado pelo detalhamento do requisito, anlise e projeto, construo e testes e chegado a uma situao que se possa utilizar a funcionalidade que o caso de uso funcional representa.

99

Aps passar por todas essas disciplinas citadas, a infra-estrutura necessria para o software j teria sido concebida, definida e instalada, pelo menos o mnimo necessrio para fazer funcionar o primeiro release de software disponibilizado. Preferencialmente, recomenda-se que a implantao do software na METODES seja realizada de forma gradual para que se possa usufruir de fato das vantagens de se desenvolver um software de forma iterativa e incremental, alm de permitir nessa forma de implantao uma avaliao mais precisa da infra-estrutura projetada.

3.10 FLUXO DE ATIVIDADES DA DISCIPLINA IMPLANTAO

100

3.8.2 Atividades

As atividades da disciplina Implantao da METODES visam colocar em prtica todos os aspetos de arquitetura, infra-estrutura e segurana que foram definidos em Anlise e Projeto. Como esses aspectos dependem diretamente das caractersticas e particularidades do software e tambm podem envolver procedimentos tcnicos para serem implementados participaro dessa disciplina o Analista de Implantao, responsvel pela coordenao e execuo de um plano de implantao, o Construtor e o Projetista. O treinamento do usurio no software tambm acontece nessa disciplina, portanto, o manual de instalao, manual de operao do software fazem parte da implantao e devem ser entregues formalmente aos usurios do sistema. Caso sejam necessrios ajustes, que no impliquem em grandes alteraes de formato ou contedo dos manuais entregues, estes devem ser realizados nessa mesma disciplina junto com o usurio. Porm, se os ajustes necessrios implicarem em alteraes que comprometam muito a forma ou o contedo desses manuais devem ser submetidos Gesto do Projeto e ser tratado como uma solicitao de mudana.

3.8.2.1 Plano de implantao

Elaborar e obter a aprovao do demandante do software so as principais tarefas nessa atividade. O plano de implantao dever conter as aes detalhadas para tornar o software operacional para o usurio. Para isso deve-se elaborar um cronograma de trabalho, acordado

101

com o cliente, alm de definir metas e objetivos que devem ser alcanados durante o processo de implantao.

3.8.2.2 Documentao do usurio

Nessa atividade a documentao do usurio produzida na disciplina Construo ser formalmente entregue ao cliente e validada por ele. As documentaes pertinentes ao usurio do software so: o manual de instalao e o manual de operao do software. O manual de instalao contm os procedimentos e demais condies necessrias para a instalao do software. Nesses procedimentos so citados somente os detalhes procedimentais de instalao que um usurio comum possa executar, como por exemplo, a instalao de um front-end, a configurao de um navegador Web, instalao de um setup, enfim, procedimentos nfimos que sejam necessrios para que o usurio consiga acesso s interfaces do software. O manual de operao apresenta os aspectos prticos para operao do software, com demonstraes das interfaces que os usurios interagiro e demais processos que fazem parte das interaes que a interface promove.

3.8.2.3 Implementao de arquitetura e segurana

Aqui devem ser implementados todos os aspectos de arquitetura e segurana considerados na disciplina Anlise e Projeto que ainda no tenham sido implementados nas disciplinas anteriores. O primeiro passo do Analista de Implantao verificar as solues definidas nos documentos produzidos na disciplina Anlise e Projeto e providenciar que as solues sejam

102

implementadas. Normalmente, o que se deixa para implementar dessas solues definidas so aquelas que esto alm dos aspectos tcnicos da soluo ou que dependiam de todo o sistema construdo para implement-las, como, por exemplo, as questes de segurana fsica de ambiente.

3.8.2.4 Implementao de infra-estrutura

Basicamente as mesmas consideraes que faz na atividade anterior devem ser feitas nessa tambm. A nica diferena o foco e os documentos analisados, pois aqui devem ser considerados os aspectos de infra-estrutura que ainda no tenham sido implementados nas disciplinas anteriores da METODES.

3.8.2.5 Instalao do software

Aps terem sido revistos os aspectos de arquitetura, segurana e infra-estrutura, passa-se a instalao de fato do software. Isso compreende toda e qualquer instalao necessria para que o software funcione como projetado. Portanto, formalmente, a instalao do SGBD, dos sistemas operacionais dos servidores, servidores Web, frameworks, enfim, todos os softwares que d suporte ao software, so instalados nessa atividade, considerando que o software no esteja sendo desenvolvido no mesmo ambiente onde funcionar. Na hiptese de o software estar sendo desenvolvido no mesmo ambiente onde funcionar, essas instalaes podem ser realizadas aps a disciplina Anlise e Projeto, para que o Construtor escreva e teste os cdigos do software j no ambiente operacional do software. Considerando essa hiptese, as instalaes mencionadas nessa atividade devem ser revisadas e adequadas segundo as definies do projeto.

103

3.8.2.6 Treinamento do usurio

O foco dessa atividade a elaborao de um treinamento que aborde os aspectos funcionais do software, ou seja, no necessrio que o usurio qual SGBD que est sendo utilizado e nem por que ele foi escolhido. Deve ser transmitido ao usurio como utilizar o sistema para que se tire o maior proveito possvel e em que o software afetar em sua rotina normal de trabalho. A METODES sugere uma ementa bsica para o treinamento. Essa ementa deve ser apresentada, adequada e validade junto ao demandante do software. Alm disso, devem ser acordados o local e carga horria do treinamento de acordo com a disposio do cliente e com as condies iniciais indicadas no Plano de Projeto do projeto METODES. A ementa bsica contempla os seguintes itens:

1. Apresentao do Software 1.1. Pblico alvo 1.2. Descrio 1.3. Objetivos 1.4. Alinhamento com o negcio da empresa 2. As Funes do Software 2.1. Descrio bsica da infra-estrutura 2.2. Cadastro e autenticao de usurios do software 2.3. Descrio de perfis de usurios 2.4. Descrio das funcionalidades 3. Outras opes 3.1. Descrio e tratamento de erros conhecidos 3.2. Procedimentos de backup e restore 3.3. Manuteno e Suporte Tcnico

A ementa proposta apresenta apenas alguns tpicos que so importantes para o treinamento de um software, porm, no significa que seja suficiente e nem mesmo adequado para ser aplicado em um projeto de software. Cada tipo de software exige uma ementa

104

especfica para treinamento que deve ser elaborada com o demandante e os usurios do software.

3.8.2.7 Formalizao do aceite do software

Ao final de todos os procedimentos o Analista de Implantao deve apresentar ao demandante do software um documento que contenha explicitamente a conivncia com a forma e o resultado de todos os procedimentos realizados para a implantao do software, bem como, a concordncia com todas as funcionalidades do software fornecidas no estado como se apresentarem aps a completa implantao. Esse documento deve ser apresentado somente aps todas as iteraes da METODES que forem necessrias para a completa implantao do software. Isso significa que todos os casos de uso funcional e todas as questes de arquitetura, infra-estrutura e segurana tenham sido resolvidas.

3.8.3 Resultados da disciplina

Considerando que o desenvolvimento do software esteja sendo realizado de forma iterativa e incremental, a implantao dele se dar, tambm, dessa forma. Assim sendo, espera-se que ao final de todas as iteraes necessrias se tenha o software implantado por completo. Mais uma vez importante ressaltar que para a METODES, um software implantado significa que todos os requisitos funcionais e no-funcionais definidos no Documento de Viso e Escopo foram atendidos, considerando nesse atendimento as questes de arquitetura, infra-estrutura e segurana. Um software implantado pela METODES tambm

105

contempla o treinamento do usurio e, principalmente, o documento de aceite formal do software assinado pelo demandante do software.

106

4 METODES - ARTEFATOS

Cada disciplina da METODES tem como resultado um conjunto de artefatos do projeto, cada qual com sua finalidade e objetivo. O modelo de cada artefato produzido na METODES est presente, sob a forma eletrnica, no guia em formato WEB da metodologia. A tabela 4.1 uma sntese dos artefatos produzidos na METOODES. Neste trabalho, alguns dos artefatos foram anexados para fins de demonstrao.

4.1 TABELA DE ARTEFATOS

Disciplina Concepo

Gesto do Projeto

Detalhamento de Requisitos

Anlise e Projeto

Construo Teste Funcional Implantao

Artefato DVE - Documento de Viso e Escopo PPS - Plano de Projeto de Software DSM - Documento de Solicitao de Mudana CAP - Controle de Artefatos do Projeto PRP - Planilha de Resultados de Projeto PCR - Planilha de Controle de Requisitos CUF - Caso de Uso Funcional DRNF - Documentao do Requisito No-funcional TAR - Termo de Aceite do Requisito MVAS - Modelagem da Viso de Arquitetura de Software MVAC - Modelagem da Viso de Arquitetura de Comunicao DIAF - Documentao da Infra-estrutura de Ativos Fsicos DIS - Documentao da Infra-estrutura de Software MVS - Modelagem da Viso de Segurana MAP - Modelo de Anlise de Projeto DCC - Documentao de Cdigo de Componente MOU - Manual de Operao do Usurio MIS Manual de Instalao do Software PRTF - Plano de Teste PRT - Planilha de Resultados de Testes PI - Plano de Implantao PT - Plano de Treinamento TAS - Termo de Aceite do Software

107

5 METODES - PAPIS

Os papis da METODES so funes a serem representada, com perfis profissionais especficos, que interagem no processo de desenvolvimento do software. A maioria dos papis pode ser representada por um ou mais membros da equipe de projeto. Do mesmo modo, um membro dessa equipe tambm pode representar mais de um papel durante a realizao do projeto. Os perfis profissionais dos papis sugeridos pelo METODES esto descritos sob forma de recomendaes, e no caracterizam uma condio sine qua non para que um membro da equipe do projeto exera algum papel. Alm disso, alguns papis podem no exigir requisitos profissionais especficos. Porm, necessrio que todos os membros da equipe de projeto tenham conhecimentos a cerca das atividades de para todos os papis ser necessrio o conhecimento geral dos fundamentos da informtica.

5.1 Descrio dos Papis

5.1.1 Gerente de relacionamento

O Gerente de Relacionamento o papel responsvel pela intermediao do contato entre a equipe de projeto e o cliente, e dever ser representado, preferencialmente, por uma nica pessoa, para simplificar e facilitar a comunicao entre as partes. Entretanto, dependendo do tamanho e das caractersticas do projeto, mais de uma pessoa pode assumir o papel. desejvel para a pessoa que exercer esse papel ter em seu perfil profissional requisitos como boa fluncia na comunicao, noes de gesto de projetos e conhecimentos

108

dos fundamentos da computao. No so necessrios conhecimentos tcnicos profundos, no entanto, imprescindvel ter uma fundamentao tcnica global para melhor compreenso e anlise do problema. As responsabilidades do Gerente de Relacionamento so: Agendar reunies e entrevistas com os usurios; Negociar ajustes de prazos, custos e escopo do projeto; Obter aprovao formal do cliente dos documentos Apresentar ao cliente as releases do software produzido; Comunicar ao cliente sobre o andamento e resultados do projeto.

5.1.2 Gerente de projeto

O Gerente de Projeto o responsvel pela coordenao e controle das atividades necessrias para o desenvolvimento do software. ele quem elabora e pe em prtica a execuo do Plano de Projeto, verificando o cronograma, ajustes de oramento, mitigando riscos, enfim, cumprindo o planejamento definido no incio do projeto METODES. Dentre os requisitos desejveis para o perfil profissional que representar esse pape esto: domnio de tcnicas de gerenciamento de projeto, conhecimento de tcnicas de estimativa de prazo e custos de projeto, liderana, alm dos conhecimentos tcnicos gerais a cerca das tecnologias de informtica. As responsabilidades do Gerente de Relacionamento so: Elaborar Plano de Projeto; Estimar prazos e custos do projeto; Formar equipe e distribuir papis; Coordenar as atividades dos outros gerentes da METODES;

109

Alocar recursos ao projeto e verificar como esto sendo consumidos ao logo do processo de desenvolvimento do software;

Avaliar qual ser o impacto causado no projeto devido s solicitaes de mudana.

5.1.3 Gerente de artefato

O Gerente de Artefatos o papel responsvel por manter a atualizao dos artefatos da METODES. Isso significa que quando houver qualquer mudana que reflita em uma alterao de artefatos, estes devem ser atualizados e suas verses antigas guardadas para a formao de um histrico de controle de artefatos. Basicamente, responsabilidade do Gerente de Relacionamento manter o histrico e controle dos artefatos da METODES, por meio da Planilha de Controle de Artefatos.

5.1.4 Gerente de mudanas

O Gerente de Mudanas da METODES o responsvel por receber e encaminhar as solicitaes de mudana de projeto e manter atualizada a Planilha de Alterao de Escopo de Projeto (PAEP). Ou seja, qualquer solicitao de alterao, seja por parte do cliente ou dos analistas da equipe, no escopo do projeto ou nos resultados j produzidos (artefatos), o Gerente de Mudanas quem receber essas solicitaes e enviar os resultados delas a que as solicitou. O trabalho do gerente de mudanas pode em alguns casos se limitar a simplesmente encaminhar as solicitaes de mudanas para os responsveis que iro trat-las,

110

como no caso de alterao de artefatos. Quando se tratar de alterao do escopo do projeto, estas devero ser analisadas pelo Gerente de Projeto que ir deferir ou indeferir as mudanas solicitadas. Ento, o Gerente de Mudanas atualiza a PAEP e devolve o resultado do julgamento do Gerente de Projeto aos que solicitaram a mudana para que, em caso de deferimento, tomem as providncias necessrias. A figura 5.1 representa o fluxo de tratamento de solicitao de mudana. As setas vermelhas indicam o fluxo para alterao de artefatos, onde no h a necessidade de apreciao do Gerente de Projeto por se tratar de casos em que a solicitao partiu dos analistas da equipe do projeto.

5.1 FLUXO DO TRATAMENTO DE SOLICITAO DE MUDANA

4. Necessidades de ajustes de prazos e custos do Projeto. 6. Ajustes aprovados / reprovados pelo Cliente Gerente de Relacionamento 1. Solicitao de mudana de escopo 5. Comunicar os ajustes de prazos e custos e obter aprovao do Cliente. Cliente

2. Encaminhamento da solicitao para tratamento

3. Encaminhamento da solicitao para avaliao de impacto 7. Deferimento / indeferimento da solicitao. Informaes para atualizao do PAEP

Solicitao de mudana 8. Defereimento / indeferimento das solicitaes

Gerente de Projeto

Gerente de Mudanas

Analistas da Equipe de Projeto

Alterao de artefatos

Gerente de Artefato

111

5.1.5 Gerente de qualidade

O Gerente de Qualidade o papel responsvel por conferir o andamento do projeto observando o que foi especificado no Plano de Projeto. O Gerente de Qualidade mantm a Planilha de Resultado de Projeto (PRP), que servir de instrumento para que se possa aferir a qualidade do Software desenvolvido segundo os padres de qualidade definidos na METODES.

5.1.6 Gerente de requisitos

O controle de requisitos realizado pelo Gerente de Requisitos, que atuar constantemente durante todo o ciclo de vida do requisito. Esse ciclo de vida compreende desde o momento em que o requisito definido na disciplina Concepo, passando pela disciplina de Detalhamento de Requisitos, at sua construo, considerando nesse fluxo as possveis revises e alteraes que podem ocorrer. As responsabilidades do Gerente de Requisitos so: Manter atualizada a Planilha de Controle de Requisitos; Requisitar agendamento de reunies com o cliente/usurios; Coordenar as reunies entre usurios Analistas de Requisitos; Providenciar homologao e aprovao dos requisitos junto ao cliente.

5.1.7 Analista de requisitos

O Analista de Requisitos o responsvel por interpretar e detalhar e documentar os requisitos apresentados pelo cliente.

112

O profissional que exercer o papel de Analista de Requisitos deve ter o domnio pleno do negcio, por isso ele participa da disciplina Concepo da METODES.

5.1.8 Prototipador

O Prototipador trabalhar em conjunto com o Analista de Requisitos na construo de prottipos visuais do software que correspondam aos requisitos apresentados pelo cliente. Esse prottipo tem o objetivo de demonstrar uma interface grfica no-funcional para facilitar a interpretao dos requisitos expostos pelo cliente. Para o profissional que exercer esse papel bastante recomendvel que tenha conhecimentos especficos na construo de interfaces homem-mquina, conhecimentos de designer grfico, alm dos conhecimentos gerais da anlise de sistemas.

5.1.9 Projetista

O Projetista um dos principais papis a serem exercidos em um projeto METODES. Esse papel o responsvel por projetar a arquitetura e a infra-estrutura que suportaro a soluo apresentada ao cliente no Documento de Viso e Escopo. A METODES considera vrios aspectos de arquitetura e infra-estrutura a serem considerados pelo Projetista. Cada um desses aspectos, citados na descrio da disciplina Anlise e Projeto, responsabilidade do Projetista. Para perfil profissional da pessoa que exercer o papel de Projetista extremamente recomendado que se tenha domnio do problema, conhecimentos slidos de padres de projeto e arquitetura de software e domnio da linguagem da UML. Esses so

113

apenas requisitos especficos de conhecimento, sendo, portanto, tambm necessrios conhecimentos dos fundamentos gerais da informtica. As principais responsabilidades do Projetista so: Desenhar o modelo de classes dos Casos de Uso Funcionais; Especificar e descrever os requisitos no-funcionais; Desenvolver e realizar os Casos de Uso Funcionais; Desenvolver o modelo entidade-relacionamento.

5.1.10 Construtor

O Construtor o papel responsvel por implementar os modelos criados pelo Projetista. Isso significa transformar a modelagem dos requisitos em cdigos de linguagem de programao. Entre as responsabilidades do Construtor esto a instalao e configurao do SGBD e a implementao dos scripts do banco de dados. O perfil desejvel para o profissional que exercer o papel de Construtor na METODES de uma pessoa com domnio na linguagem de programao definida para o projeto e conhecimentos slidos no SGBD escolhido.

5.1.11 Documentador

O Documentador papel responsvel por coordenar a elaborao da documentao do software que cabe ao usurio. Para a METODES essa documentao compreende o Manual do Usurio (Manual de Operao do Software) e o Manual de Instalao do Sistema.

114

O Documentador atuar em conjunto com o Projetista e o Construtor na elaborao dos manuais citados. Os requisitos para o perfil profissional da pessoa que exercer esse papel so: Possuir boa redao; Facilidade na interpretao Noes de diagramao de documentos.

5.1.12 Analista de testes

O Analista de Testes o papel responsvel por elaborar, coordenar e executar as atividades dos Testes Funcionais da METODES. Esse papel tem tambm a responsabilidade de providenciar a infra-estrutura de testes necessria para que estes aconteam. Alm disso, o Analista de Testes que avaliar os resultados dos testes e tomar as providncias cabveis quanto aos resultados. As responsabilidades principais do Analista de Teste so: Elaborar Plano de Realizao do Teste Funcional; Providenciar infra-estrutura para testes; Executar Plano de Realizao do Teste Funcional; Avaliar resultados dos testes.

5.1.13 Analista de implantao

O Analista de Implantao o papel responsvel por coordenar os trabalhos de implantao do software desenvolvido.

115

As principais responsabilidades desse papel so as atividades descritas na disciplina Implantao da METODES. O profissional que exercer esse papel poder realizar procedimentos tcnicos de instalao e configurao de softwares nas atividades da Implantao, portanto, essa pessoa precisa ter conhecimentos tcnicos suficientes para realizar esses procedimentos. O Analista de Implantao trabalhar em conjunto com o Gerente de Relacionamento por haver bastante interao com cliente na disciplina Implantao.

116

6 METODES - FERRAMENTAS

6.1 Recomendaes da METODES

A METODES recomenda um conjunto de softwares e ferramentas, entre elas as do tipo CASE (Computer Aided Software Engineering), para auxiliar a realizao das atividades das disciplinas da METODES. A utilizao dessas ferramentas no arbitrria e nem mesmo obrigatria, apresenta-se apenas como uma opo para auxlio na execuo de um Projeto METODES. As ferramentas apresentadas so apenas algumas opes dentre as muitas disponveis no mercado para os mesmos fins. Outras ferramentas podem ser necessrias para um projeto de software, ou simplesmente adotadas para maior conforto e produtividade das pessoas que as utilizaro diretamente.

6.2 Modelagem de banco de dados

6.2.1 Dbdesigner 4

Uma ferramenta de modelagem de banco de dados desenvolvida e otimizada para utilizao com o MySQL, provendo aos seus usurios uma forma simples e centralizada para a definio dos seus modelos de dados. O cdigo do DBDesigner 4 OpenSource distribudo sob a licena GPL (General Public License) e tem compilaes disponveis para Windows e Linux.

117

6.2.2 Mogwai ER-Designer

Mogwai ER-Designer uma ferramenta visual de modelagem de banco de dados parecida com o ERWin, porm com cdigo OpenSource e licena GPL. Construdo em Java independente de plataforma de sistema operacional, tendo como requisito apenas uma mquina virtual Java. Essa ferramenta trabalha com MySQL , PostgreSQL and Oracle e foi projetada para permitir que suas funcionalidades sejam estendidas com a simples instalao de plug-ins. O Mogwai ER-Designer tem um interessante recurso, o IVT (Intelligent version tracking) que mantm um histrico de mudanas do esquema do banco de dados. Ele tambm possibilita a engenharia reversa de bancos de dados.

6.3 Administrao de banco de dados

6.3.1 MySQL Administrator

O MySQL Administrator um console de administrao visual que o permite facilmente administrar o ambiente MySQL, com possibilidades de verificar visualmente o estado das bases de dados em operao. O MySQL Administrator agora integra a gerncia e a manuteno da base de dados em um nico ambiente, com uma interface grfica leve e intuitiva. Disponvel tambm para Windows, MacOSX e Linux sob a licena GPL e licenas comerciais.

118

6.3.2 MySQL Query Browser

Ferramenta visual utilizada para criar, otimizar e executar queries para bancos de dados MySQL. Alm disso, oferece suporte para criao e modificao de tabelas e um editor de sentenas SQL. Est disponvel para Windows, MacOSX e Linux sob a licena GPL (para uso em sistemas no-comerciais) e tambm sob licenas comerciais.

6.3.3 PgAdmin

O PgAdmin III o software de administrao do PostgreSQL desenvolvido para ajudar os usurios a construir cdigo extremamente complexos. Trabalha com as plataformas Windows, 2GNU/Linux e FreeBSD. Inclui uma interface administrativa grfica, ferramentas de SQL e editor de cdigo.

6.3.4 SQL Lite

Trata-se de gerenciador gratuito para banco de dados SQL Server, MSDE (Microsoft SQL Server Desktop Engine) e Microsoft Access. possvel criar, excluir e alterar tabelas e campos, definir chaves e tipos de dados. Possui sistema de consulta com suporte a TSQL, podendo apenas digitar comandos manualmente e executar as instrues com suporte para Views, Procedures, Triggers, Functions, etc. Programa escrito em Visual Basic 6 e disponvel apenas para a plataforma Windows.

GNU um acrnimo recursivo para GNU No UNIX e pronunciado como guh-noo. Fonte: http://www.gnu.org/home.pt.html.

119

6.4 IDE (Integrated Development Environment) e Linguagens

6.4.1 Eclipse

O Eclipse uma das IDEs mais populares, atualmente para desenvolvimento em plataforma Java e considerado uma das ferramentas chaves em se tratando de iniciativas OpenSource. A IDE eclipse possui facilidades para os desenvolvedores como a visualizao de todos os arquivos contidos no projeto de forma clara e ferramentas de gerenciamento de trabalho coletivo.

6.4.2 NetBeans

Uma IDE que rene caractersticas especificas e ferramentas de apoio ao desenvolvimento de software, com o objetivo de agilizar este processo, permitindo que os desenvolvedores obtenham um aproveitamento maior e desenvolvendo cdigos com maior rapidez.

6.4.3 PHP 5

uma linguagem muito interessante, de sintaxe cmoda e similar a outras linguagens como o C e o C++. rpido para ser interpretado e dispe de uma grande biblioteca que facilita muitssimo o desenvolvimento de suas aplicaes. PHP uma linguagem ideal tanto para quem comea a desenvolver aplicaes para a web ou para quem um desenvolvedor experiente.

120

6.4.4 J2SE

O J2SE (Java 2 Standard Edition) o ambiente de desenvolvimento mais utilizado. Isso porque seu uso voltado a PCs e servidores, onde h bem mais necessidade de aplicaes. Alm disso, pode-se dizer que essa a plataforma principal, j que, de uma forma ou de outra, o J2EE e o J2ME tem sua base aqui. Pode-se dizer que esses ambientes de desenvolvimento so verses aprimoradas do J2SE para as aplicaes a que se propem.

6.4.5 J2EE

O J2EE (Java 2 Enterprise Edition) a plataforma Java voltada para redes, Internet, Intranets e afins. Assim, ela contm bibliotecas especialmente desenvolvidas para o acesso a servidores, a sistemas de e-mail, a banco de dados, etc. Por essas caractersticas, o J2EE foi desenvolvido para suportar uma grande quantidade de usurios simultneos. A plataforma J2EE contm uma srie de especificaes, cada uma com funcionalidades distintas. Entre elas, tem-se:

JDBC (Java Database Connectivity), utilizado no acesso a banco de dados; JSP (Java Server Pages), um tipo de servidor Web. Grossamente falando, servidores Web so as aplicaes que permitem a voc acessar um stio na internet;

Servlets, para o desenvolvimento de aplicaes Web, isto , esse recurso "estende" o funcionamento dos servidores Web, permitindo a gerao de contedo dinmico nos stios Internet.

121

6.5 Servidores Web

6.5.1 Apache

O servidor Apache (Apache Server) servidor Web de cdigo livre que roda sobre as plataformas Windows e Linux. Oferece suporte instalao de componentes extras para suporte de linguagens como PHP e Pearl. Possui licena GPL e tambm licena para uso comercial.

6.5.2 Tomcat

um servidor de aplicaes Java para Web que se integra ao servidor Apache. Roda em Windows, Solaris e Linux, alm de Mac OS X, HP-UX e FreeBSD. O Tomcat distribudo e licenciado sob as mesmas condies do servidor Apache.

6.5.3 IIS - Internet Information Services

Servidor proprietrio da Microsoft que permite a utilizao de sistemas Web desenvolvidos nas linguagens, tambm proprietrias, da empresa: ASP (Active Server Pages) e .Net. Sua licena est condicionada ao licenciamento da verso do sistema operacional Windows Server 2003.

122

6.6 Controle de Verso

6.6.1 CVS

um sistema de controle de verso que permite que se trabalhe com diversas verses de arquivos, organizando-os em diretrios e sendo localizados local ou remotamente, mantendo-se suas verses antigas e os logs de quem e quando manipulou esses arquivos. especialmente til para se controlar verses de um software durante seu desenvolvimento, ou para composio colaborativa de um documento.

6.7 Gesto de projeto

6.7.1 DotProject

uma ferramenta Opensource desenvolvida em PHP para gerncia de projetos de fcil utilizao, com um bom conjunto de funcionalidades e caractersticas que o tornam interessante para utilizao em ambientes de corporativos.

6.8 Modelagem visual (UML)

6.8.1 Jude Community

Uma das ferramentas gratuitas para UML mais poderosas disponveis. Com caractersticas que no so encontradas nas outras ferramentas grtis, como adicionar mtodos no diagrama de seqncia e a alterao se refletirem no diagrama de classes.

123

Seu desempenho impressiona principalmente tratando-se de uma ferramenta 100% Java/Swing, desmistificado que Swing lento.

6.9 SGBD - Sistema gerenciador de banco de dados

6.9.1 Mysql 5

O MySQL um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL(Structured Query Language) como interface. atualmente um dos bancos de dados mais populares, com mais de 4 milhes de instalaes pelo mundo e com a verso 5.0. O MySQL incorporou mais recursos avanados ao sistema, incluindo views , triggers, storage procedures e suporte a transaes.

6.9.2 Oracle Express Edition 10g

Banco de dados Oracle, em uma verso mais leve para estudantes e desenvolvedores. Essa verso light do Oracle uma tentativa da Oracle de popularizar seu banco de dados para pequenos desenvolvedores, assim como o MySQL vem fazendo h muito tempo. Sua limitao a utilizao de apenas 1 processador, 4Gb de espao em disco e 1Gb de memria RAM. Possui suporte para SQL, PL/SQL e linguagens como PHP, .Net e Java.

6.9.3 PostgreeSQL

O PostgreSQL um SGBD objeto-relacional de cdigo aberto, com mais de 15 anos de desenvolvimento. extremamente robusto e confivel, alm de ser extremamente

124

flexvel e rico em recursos. Ele considerado objeto-relacional por implementar, alm das caractersticas de um SGBD relacional, algumas caractersticas de orientao a objetos, como herana e tipos personalizados. A equipe de desenvolvimento do PostgreSQL sempre teve uma grande preocupao em manter a compatibilidade com os padres SQL92/SQL99.

6.9.4 SQL Server 2005 Express Edition

Uma verso gratuita e limitada do SGBD da Microsoft SQL Server 2005. Entre as limitaes que possui est o fato de suportar apenas 1 CPU, apenas 1 GB de memria RAM para buffer pool, que usado para o armazenamento de pginas de dados e outras informaes e arquivos de dados at 4GB. O SQL Server 2005 Express Edition substitui o MSDE (Microsoft SQL Desktop Engine), porm no apresenta limitaes de acesso concorrente de usurio e ainda traz consigo uma ferramenta grfica para administrao e gerenciamento, o SQL Server Express Manager (XM).

6.10 Documentao

6.10.1 BrOffice

um conjunto de aplicativos em Opensource disponvel para plataforma Windows e Linux que oferece opes de editor de texto, planilha eletrnica, desenho grfico, editor de apresentaes e outros. similar a famosa sute de aplicativos da Microsoft, o Office, oferecendo aos usurios quase todas as funcionalidades que o Microsoft Office oferece.

125

7 GUIA WEB METODES

O guia Web METODES um stio Web que apresenta a infra-estrutura metodolgica que a metodologia prope para auxiliar os alunos nas disciplinas e atividades da METODES. A figura 7.1 mostra a pgina inicial do guia METODES. A estrutura do guia METODES baseada em quadros (frames). H um menu nico de opes que possibilita acesso a todas as etapas do processo de desenvolvimento da metodologia.

7.1 PGINA INICIAL DO GUIA WEB DA METODES

A partir do menu de opes o usurio do guia pode, por exemplo, navegar sobre as vises da metodologia. A figura 7.2 mostra a opo do item de menu Vises da Metodologia:

126

7.2 OPO DE MENU VISES DA METODOLOGIA METODES

127

A figura 7.3 mostra a opo de menu Disciplinas:

7.3 OPO DE MENU DISCIPLINAS

128

7.3 Opo do menu Papis da METODES:

7.4 OPO DE MENU PAPIS

129

8 CONSIDERAES FINAIS

Este trabalho apresentou o desenvolvimento, sob a forma descritiva, da metodologia de desenvolvimento de software, METODES. A METODES uma metodologia unificada que permite desenvolvimento iterativo e incremental baseado em casos de uso, apesar de apresentar um ciclo de vida de projeto em cascata. O que parece ser uma contradio conceitual na verdade uma adaptao da metodologia s necessidades e realidade acadmica em que ela est inserida. A simplicidade da METODES se destaca por ter sido desenvolvida para atender especificamente o pblico acadmico da Faculdade Cenecista de Braslia (FACEB), porm, nada impede que ela seja adotada fora desse contexto, pois apresenta aspectos tcnicos e conceituais suficientes para contemplar o desenvolvimento de projetos de software diversos, comerciais ou acadmicos. Pode-se considerar que os objetivos deste trabalho foram alcanados, uma vez que ele descreve o conjunto de disciplinas, artefatos e papis, base da infra-estrutura metodolgica que a METODES oferece aos alunos do curso de Bacharelado em Sistemas de Informao da FACEB, para desenvolvimento dos seus trabalhos de concluso de curso. A partir da anlise da infra-estrutura que a METODES prope, chega-se a concluso que a utilizao de uma metodologia para o desenvolvimento de software, em ambiente acadmico, alerta os alunos para questes importantes que devem ser consideradas em um projeto. Alm de conferir aos alunos, maior clareza de conceitos tericos envolvidos no processo de desenvolvimento de software. Portanto, fica caracterizada a importncia da utilizao da metodologia no contexto apresentado. Por no haver resultados prticos de projetos reais realizados com a METODES, as afirmaes feitas no trabalho sobre s gesto do processo e qualidade do produto de

130

software, so fundamentadas apenas na perspectiva ideal de funcionamento da metodologia. Dessa forma, faz-se necessrio a ponderao das questes que devem ser tratadas no futuro. Estabelece-se, ento, lista de sugestes para futuras revises da METODES: Desenvolver um processo contnuo de avaliao do processo de

desenvolvimento da METODES, que aponte as falhas e sugira correes; Desenvolver um mtodo eficaz de anlise de resultados de projetos, de forma que essa anlise sirva como parmetro para mensurar a qualidade do produto de software; Detalhar em linguagem mais prxima do aluno, todos os diagramas da UML utilizados no processo de desenvolvimento, de forma que o aluno possa ter uma referncia prtica para construo desses diagramas; Desenvolver um banco de dados de padres de projeto utilizados por todos os projetos METODES, possibilitando que o aluno publique, consulte e utilize esses padres em seu prprio projeto, imprimindo, assim, maior agilidade e produtividade no desenvolvimento do software. Por fim, a METODES pode ser uma opo plausvel para ser adotada como metodologia padro de desenvolvimento de software da FACEB. Bastando para isso, que sua implantao seja encarada como a constante reviso e adequao da infra-estrutura proposta pela METODES, ou seja, suas disciplinas, os artefatos e papis que compem a essencialidade do processo de desenvolvimento da METODES.

131

9 REFERNCIAS

ABNT - Associao Brasileira de Normas Tcnicas. NBR 13596 - Tecnologia de informao avaliao de produto de software - caractersticas de qualidade e diretrizes para o seu uso: Rio de Janeiro, 1996. ABNT Associao Brasileira de Normas Tcnicas. NBR ISO/IEC 12207. Tecnologia de Informao: Processos de Ciclo de Vida de Software: Rio de Janeiro, 1998. BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML: 8. ed. Rio de Janeiro: Elsevier, 2002. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar, Traduo de Fbio Freitas da Silva e Cristina de Amorim Machado. UML Guia do Usurio: 2. ed. Rio de Janeiro: Elsevier, 2005. PDUA, Wilson de. Engenharia de Software: Fundamentos, Mtodos e Padres: 2. ed. Rio de Janeiro: LTC, 2003. PETER, James; PEDRYCZ, Witold. Engenharia de Software: Teoria e Prtica: Rio de Janeiro: Campus, 2001. PFLEEGER, Shari Lawrence. Engenharia de Software: teoria e prtica. 2. ed. So Paulo: Prentice Hall, 2004. PRESSMAN, Roger S. Engenharia de Software. 5. ed. Rio de Janeiro: MacGraw-Hill, 2002. ______. Engenharia de Software: So Paulo: 3. ed. So Paulo: Makron Books, 1995. SOMMERVILLE, Ian. Engenharia de Software: 6. ed. So Paulo: Addison Wesley, 2003.

<http://www.internativa.com.br/artigo_gestao.html>. Acessado em 23/05/2006.

<www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf>. Acessado em 14/08/2006.

132

10 GLOSSRIO

Afforadance .......Refere-se s propriedades percebidas e as propriedades reais de um objeto, que deveriam determinar como ele pode ser usado. Esse conceito aplicado na construo de interfaces dos softwares. APF .....................Anlise de Ponto de Funo CAP .....................Controle de Artefatos do Projeto CASE ..................Computer Aided Software Engineering CMM...................Capability Maturity Model CUF .....................Caso de Uso Funcional DCC ....................Documentao de Cdigo de Componente DIAF ...................Documentao da Infra-estrutura de Ativos Fsicos DIS ......................Documentao da Infra-estrutura de Software DRNF ..................Documentao do Requisito No-funcional DSM ....................Documento de Solicitao de Mudana DVE.....................Documento de Viso e Escopo GNU ....................Acrnimo recursivo para GNU No UNIX GPL .....................General Publica License IEEE....................Institute of Electrical and Electronics Engineers MAP ....................Modelo de Anlise de Projeto MIS......................Manual de Instalao do Software MOU ...................Manual de Operao do Usurio MVAC.................Modelagem da Viso de Arquitetura de Comunicao MVAS .................Modelagem da Viso de Arquitetura de Software MVS ....................Modelagem da Viso de Segurana OCL ....................Object Constraint Language

133

OMG ...................Objetct Management Group PAEP...................Planilha de Alterao de Escopo PCR .....................Planilha de Controle de Requisitos PI .........................Plano de Implantao PRTF...................Plano de Realizao do Teste Funcional PPS ......................Plano de Projeto de Software PRAXIS ..............Processo para Aplicativos Extensveis e Interativos, Wilson de Pdua, muito utilizado no meio acadmico. PRP .....................Planilha de Resultados de Projeto PRT .....................Planilha de Resultados de Testes PT ........................Plano de Treinamento QoS......................Quality of service RUP .....................Rational Unified Process SGBD ..................Sistema Gerenciador de Banco de Dados SQL .....................Structured Query Language TAR.....................Termo de Aceite do Requisito TAS .....................Termo de Aceite do Software TI .........................Tecnologia da informao UML....................Unified Modeling Language UP........................Unified Process XP........................Extreme Programming desenvolvido por

134

11 APNDICE A DVE DOCUMENTO DE VISO E ESCOPO

135

136

137

12 APNDICE B - PRP - PLANILHA DE RESULTADOS DE PROJETO

138

13 APNDICE C - PCR - PLANILHA I DE CONTROLE DE REQUISITOS

139

14 APNDICE D - PCR - PLANILHA II DE CONTROLE DE REQUISITOS

140

15 APNDICE E - PCR PLANILHA III DE CONTROLE DE REQUISITOS

141

16 APNDICE F - PCR - PLANILHA IV DE CONTROLE DE REQUISITOS

142

17 APNDICE G - CUF CASO DE USO FUNCIONAL

143

18 ANEXO A TEXTO SOBRE ANLISE DE PONTO DE FUNO

144

145

146

147

148

149

150

151

152

153

154

155

156

19 ANEXO B METODES ORIGINAL

Metodologia de Desenvolvimento de Software MetoDeS Faceb

Roteiro Metodolgico Preliminar 1. Modelo de gesto de desenvolvimento do software 1.1 Metodologias [Relacionar as metodologias que sero utilizadas no trabalho.] 1.2 Contagem de pontos de funo 1.3 Anlise da regio impossvel - clculo onde 1.4 Cronograma [Descrio das tarefas com durao, data incio, data fim, precedncia e responsvel. Considerar o previsto e o realizado.] 1.5 Composio da equipe do projeto de software [Nome do papel e da(s) pessoa(s) que o exercero.] 1.6 Oramento do projeto [Considerar itens de receita, itens de custo e cronograma de desembolso.] 1.7 Necessidade de aquisies [Considerar itens a serem adquiridos, quantidade, data prevista, data realizada, responsvel e fornecedor.] 1.8 Plano de resposta aos riscos [Considerar ID do risco, risco, prioridade, ao, responsvel e prazo.] 1.9 Procedimentos de comunicao [Indicar cronograma de reunies, formas de registro das informaes, meios de comunicao das informaes, receptores e emissores.] 2. Modelo de Requisitos 2.1 Viso e escopo da aplicao 2.1.1 Apresentao do cliente [Eempresa, suas caractersticas, rea de atuao, misso, viso, objetivos estratgicos, organograma e outras informaes que forem relevantes] 2.1.2 Descrio da situao atual [Descrever em forma textual qual a situao atual do(s) processo(s) de negcio em que se pretende atuar, enfatizando o escopo de negcio (domnio do problema), os recursos atuais, reas e sistemas envolvidos e outras informaes relevantes. Quando necessrio, descrever, aqui, o sistema atual.] 2.1.3 Problemas diagnosticados 2.1.4 Oportunidade de negcio [Descrever a oportunidade de negcio abstrada a partir dos problemas diagnosticados, alinhando-a a um ou mais objetivos estratgicos] 2.1.5 Descrio da Soluo Proposta 2.1.5.1 Objetivos da soluo proposta [Descrever o objetivo geral, os objetivos especficos e no objetivos] 2.1.5.2 Envolvidos

157

[Descrever quem ser envolvido ou afetado com o desenvolvimento e implantao da soluo proposta, enfatizando como sero afetados, ou envolvidos.] 2.1.5.3 Necessidades e funcionalidades [Apontar as necessidades dos usurios e as funcionalidades do sistema para atend-las, fazendo a rastreabilidade (correlao) entre as mesmas] 2.1.5.4 Itens fora do escopo 2.2 Documentao dos Requisitos 2.2.1 Diagrama de casos de uso 2.2.2 Descrio dos casos de uso 2.2.3 Descrio dos atores 2.2.4 Lista de regras de negcio 2.2.5 Lista de requisitos no-funcionais 2.2.6 Dicionrio de termos tcnicos 2.2.7 Rastreabilidade entre requisitos [Documentar a rastreabilidade entre requisitos usando matrizes de rastreabilidade entre funcionalidades e casos de uso e entre casos de uso e regras de negcio] 3. Modelo de Anlise 3.1 Modelo de anlise 3.1.1 Diagrama de Classe 3.1.2 Realizao de casos de uso 3.1.2.1 Diagrama de seqncia [Um para cada cenrio do caso de uso, quando o sistema for pequeno. Um para cada fluxo principal, quando o sistema for grande] 3.1.2.2 Diagrama de colaborao (opcional) [Seguir a regra do diagrama de seqncia] 3.1.2.3 Rastreabilidade entre requisitos e elementos de software 3.1.3 Diagrama de Atividades (opcional) 3.1.4 Diagrama de Transio de Estado (opcional) 3.2 Descrio da Arquitetura da Soluo 3.2.1 Representao da arquitetura lgica 3.2.2 Representao da arquitetura fsica [Usar diagrama de implantao da UML] 3.2.3 Configurao de hardware necessrio 3.2.3.1 Hardware para desenvolvimento 3.2.3.2 Hardware para produo do software desenvolvido 3.2.4 Descrio de software necessrio 3.2.4.1 Software para desenvolvimento 3.2.4.2 Software para produo do software desenvolvido 4. Modelo de Projeto 4.1 Diagrama de Classe [Diagrama de classe com o formalismo de projeto, organizado conforme a arquitetura lgica. Obrigatrio apenas quando a implementao usar orientao a objetos, podendo ser mesclado.] 4.2 Descrio dos padres e frameworks utilizados [Obrigatrio apenas quando a implementao usar tais elementos.] 4.3 Modelo fsico do banco de dados

158

4.4 Projeto de interface 4.4.1 Interface homem-mquina

159

Interface entre sistemas [Obrigatrio quando houver integrao entre sistemas.] 5. Modelo de Implementao 5.1 Diagrama de componentes 5.2 Descrio dos componentes externos 5.3 Descrio dos pacotes de implementao 5.4 Unidades de implementao 5.5 Interfaces da aplicao 5.6 Script do banco de dados 5.7 Estruturas de dados 6. Modelo de Implantao 6.1 Procedimentos de instalao e configurao 6.2 Manual do usurio 6.3 Representao da distribuio de pacotes [Obrigatrio para sistemas distribudos.]

4.4.2