Home

TCC - Maxwell Anderson

Contents

1. 291 8 FLUXO DE TRABALHO DE TESTE aa 292 9 NECESSIDADES AMBIENTAIS J 293 9 1 HARDWARE B SICO DO SISTEMA es 293 9 2 ELEMENTOS DE SOFTWARE B SICOS DO AMBIENTE DE TESTE 293 9 3 FERRAMENTAS DE PRODUTIVIDADE E DE SUPORTE 294 9 4 CONFIGURA ES DO AMBIENTE DE 294 10 MARCOS DA ITERACAQO U u u 296 11 PROCEDIMENTOS E PROCESSOS DE GERENCIAMENTO 297 11 1 MEDI O E AVALIA O DA EXTENS O DO TESTE 297 11 2 GERA O DE RELAT RIOS SOBRE COBERTURA DE TESTE 297 11 3 APROVA O E ENCERRAMENTO pp 297 1 PLANO DE TESTE 1 1 INTRODU O 1 2 FINALIDADE A finalidade do Plano de Teste de Itera o reunir todas as informa es necess rias para planejar e controlar o esfor o de teste referente a uma itera o espec fica Ele descreve a abordagem dada ao teste do software e o plano de n vel superior gerado e usado pelos gerentes para coordenar o esfor o de teste Assim ele e Identifica os itens que devem ser inspecionados pelos testes e Identifica a motiva o e as id ias subjacentes s reas de teste a serem abrangidas e Descreve a abordagem de teste que ser usada e Identifica os recursos necess rios e fornece uma estim
2. 63 APENDICE 69 AP NDICE B 1 CLIENTE 4 71 AP NDICE B 2 ANALISTA DE REQUISITOS 15 AP NDICE GERENTE DE 79 AP NDICE B 4 ARQUITETO DE SOFTWARE 83 AP NDICE B 5 87 AP NDICE B 6 ANALISTA DE 91 AP NDICE B 7 ANALISTA DE SUPORTE 95 AP NDICE B 8 ANALISTA DE QUALIDADE 99 AP NDICE C ARTEFATOS I U nora 103 AP NDICE C 1 105 AP NDICE C 2 DOCUMENTO DE VISAQO I u u u 109 AP NDICE GLOSS RIO isentas 135 AP NDICE C 4 REGRAS DE NEG CIO RN 147 AP NDICE C 5 ATA DE REUNI O iii 159 AP NDICE C 6 DOCUMENTO DE ESPECIFICA O DE REQUISITOS 163 AP NDICE C 7 DOCUMENTO DE ESPECIFICA O DE CASO DE USO 179 AP NDICE C 8 PROT TIPO DA INTERFACE O USU RIO 195 AP NDICE C 9 MATRIZ DE 205 AP NDICE C 10 LISTA DE RISCOS aaa 209 AP NDICE C 11 PLANO DE PROJETO eee 213 AP NDICE C 12 DOC
3. 227 5 1 PLANO DE GER NCIA DE CONFIGURA O 227 5 2 DE AVALIA O Ne 227 5 3 PLANO DE DOCUMENTA O pp 227 5 4 PLANO DE GARANTIA DE QUALIDADE anne 227 5 5 PLANO DE SOLU O DE 227 5 6 PLANO DE MELHORIA DO PROCESSO ni 227 1 PLANO DE PROJETO DE SOFTWARE 1 1 INTRODU O A introdu o ao plano deve mostrar uma vis o geral de todo o documento Ele deve incluir o prop sito escopo defini es acr nimos abrevia es referencias e uma vis o geral deste plano 1 2 PROP SITO Especifique aqui o prop sito deste documento 1 3 ESCOPO Uma breve descri o do escopo quais as pessoas ou empresas que s o afetadas ou influenciadas por este plano 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Consultar o documento Gloss rio de Neg cios 1 5 REFER NCIAS Essa sub se o deve mostrar uma lista completa de todos os documentos referenciados ao longo desse plano Cada documento dever ser identificado por t tulo n mero do relat rio se aplic vel data e organiza o de publica o 1 6 VIS O GERAL Essa sub se o deve mostrar como o restante desse plano est organizado 2 VIS O DO PROJETO 2 1 PROP SITO DO PROJETO ESCOPO E OBJETIVOS Uma breve descri o do prop sito e objetivos do projeto 2 2 PREMISSAS E RESTRI ES Uma lista das premissas do proj
4. Considera es Especiais O acesso ao sistema dever ser revisto ou discutido com o administrador de sistemas ou de rede adequado Talvez esse teste n o seja necess rio j que poder ser uma das fun es da administra o de sistemas ou de rede 6 CRIT RIOS DE ENTRADA E DE SA DA 6 1 PLANO DE TESTE 6 1 1 Crit rios de Entrada de Plano de Teste Especifique os crit rios que ser o usados para determinar se a execu o do Plano de Teste poder ser iniciada 6 1 2 Crit rios de Sa da de Plano de Teste Especifique os crit rios que ser o usados para determinar se a execu o do Plano de Teste foi conclu da ou se a continua o da execu o n o ser vantajosa 6 1 3 Crit rios de Suspens o e de Rein cio Especifique os crit rios que ser o usados para determinar se os testes dever o ser prematuramente suspensos ou conclu dos antes que o plano tenha sido totalmente executado Especifique tamb m segundo que crit rios os testes poder o ser reiniciados 6 2 CICLOS DE TESTE 6 2 1 Crit rios de Entrada de Ciclo de Teste Especifique os crit rios que ser o usados para determinar se o esfor o do pr ximo Ciclo de Teste deste Plano de Teste poder ser iniciado 6 2 2 Crit rios de Sa da de Ciclo de Teste Especifique os crit rios que ser o usados para determinar se o esfor o de teste do Ciclo de Teste atual deste Plano de Teste considerado suficiente 6 2 3 T rmino Anorma
5. assunto ou tema a ser trabalhado METODOLOGIA DE ENSINO Descreva de que forma ser o ministradas as aulas quais as t cnicas empregadas e os recursos SISTEMA DE AVALIA O Descreva detalhadamente como ser avaliado o conhecimento dos alunos REFER NCIAS BIBLIOGR FICAS Liste aqui as refer ncias bibliogr ficas no padr o ABNT usadas como referencial te rico e pr tico para a disciplina 6 RELAT RIO DO TREINAMENTO Um relat rio de treinamento especifica os resultados obtidos de um treinamento realizado Atrav s os gestores da empresa e ou o cliente podem avaliar se os resultados foram satisfat rios Portanto abaixo est expresso um modelo desse relat rio recomend vel cri lo fora deste documento e anex lo ao final do treinamento proposto por este plano RELAT RIO DE TREINAMENTO Este documento tem como intuito relatar as atividades realizadas durante o treinamento ocorrido no per odo de data inicial lt dd mm aaaa gt a data final lt dd mm aaaa gt na cidade de Nome da cidade UF para os funcion rios e contratados da nome da entidade que contratou o treinamento listados abaixo Foram feitas atividades praticas e te ricas sobre liste todas as atividades realizadas durante o treinamento Em seguida s o relacionadas as atividades realizadas no decorrer do curso Atividade Aproveitamento Primeira atividade Bom Aceit vel Insuficiente Segunda atividade
6. importante ter um bom conhecimento sobre o ambiente do cliente por exemplo se o cliente for um supermercado que deseja automatizar as opera es no caixa importante que a implanta o seja executada fora do hor rio de atendimento para n o atrapalhar o atendimento ao cliente ou possa vir a gerar uma situa o que venha a causar transtornos ao cliente No caso do suporte as op es disponibilizadas pela empresa ser o oferecidas ao cliente e inclu das no contrato antes do in cio das atividades de especifica o da solu o Assim o cliente poder ter v rias op es de suporte dispon veis de acordo com os seus interesses Alguns exemplos s o e Suporte via telefone e Suporte online mensagem instant nea e mail etc e Suporte presencial envio de um profissional at o cliente e Manual de usu rio impresso ou em m dia eletr nica e Assist ncia remota As possibilidades de suporte ao usu rio s o in meras Nesse momento uma empresa deve oferecer o melhor servi o poss vel de forma a minimizar os esfor os do cliente na busca de esclarecimentos sobre d vidas 4 6 PROCESSOS DE APOIO 4 6 1 Gerenciamento das Mudan as GMD A fase de mudan a corresponde as atividades referentes altera o exclus o ou inser o de requisitos de projeto durante o desenvolvimento Podemos dizer que as atividades que compreendem essa fase est o relacionadas a eventos que fa am com que o processo tome uma cam
7. O Seesen 117 12 SEINAEDADE nes aan 117 TS ESOPO ni as 117 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 117 1 5 TBEFERENEIRS masse aaa 117 1 6 MSAO GE BA ee Da 118 2 POSICIONAMENTO nahe 119 2 1 OPORTUNIDADE DE NEG CIOS RN 119 22 DESCRI O DO PROBLEMA SECR eu 119 2 3 SENTEN A DE POSI O DO PRODUTO 119 3 DESCRI ES DOS ENVOLVIDOS E USUARIOS 121 3 1 DEMOGRAFIA DO MERCADO eterna 121 3 2 RESUMO DOS ENVOLVIDOS erra 121 3 3 RESUMO DOS USU RIOS I aasan 122 34 AMBIENTE DO USUARIO eae 122 3 5 PERFIS DOS ENVOLVIDOS een 123 3 6 lt NOME DO ENVOLVIDO gt 123 87 PERRIS DE USUARIOS pole aaa E sae 123 371 NOME DO USU RIOS iuris 124 3 8 RINCIPAIS NECESSIDADES DOS USU RIOS OU DOS ENVOLVIDOS 124 3 9 ALTERNATIVAS E CONCORRENCIA 125 3 9 1 lt UMCOMPETIDOR gt ee 125 3 9 2 x lt OUTROCONMPETIDOR U u uuu uuu 125 4 VIS O GERAL DO PRODUTO I uu uuu 126 4 1 PERSPECTIVA DO PRODUTO 126 4 2 RESUMO DOS RECURSOS ccccoccccincnccncnininoncnanononnnnnoncnnncnnnno nano rn cn anna 126 4 3 SUPOSICOES E DEPEND NCIAS RN 126 5 RECURSOS DO PRODUTO I uu uuu 127 5 1 lt UM RECURSO gt 127 5
8. e Meta de mercado visando dissemina o e ado o do modelo MPS em todas as regi es do pa s em um intervalo de tempo justo a um custo razo vel tanto em PME foco principal quanto em grandes organiza es p blicas e privadas com resultados esperados tais como o Cria o e aprimoramento do modelo de neg cio MN MPS 26 Cursos provas e workshops Organiza es que implementaram o modelo MPS Organiza es com avalia o MPS publicadas prazo de validade de tr s anos 27 4 O PRUMO Como amp parte dos objetivos desse trabalho esta sec o pretende apresentar uma proposta de processo de desenvolvimento de softwares para utiliza o em micro e pequenas empresas tecnologia da informa o Antes que seus detalhes sejam citados uma forma de visualiza o do processo apresentada com o intuito de deixar o leitor bem posicionado em termos de qual caracter stica e n vel de detalhamento ele est observando al m de proporcionar um panorama completo da organiza o do Prumo Outra estrat gia adotada para melhorar o entendimento do conte do apresentado aqui foi a defini o dos pap is antes que as atividades sejam apresentadas e detalhadas Assim o leitor compreender melhor o objetivo de cada uma delas e entender a escolha dos pap is dos artefatos necess rios para a realiza o da atividade e dos artefatos gerados como sa da 4 1 NIVEIS DE DETALHAMENTO DO PROCESSO Um processo de desenvolvimento
9. es de Neg cios Seguran a no n vel do sistema incluindo efetuar login ou acessar remotamente o sistema Com base no n vel de seguran a desejado a seguran a no n vel do aplicativo assegura que os atores estejam restritos a fun es ou casos de uso espec ficos ou que tenham acesso limitado aos dados dispon veis Por exemplo todos t m permiss o para inserir dados e criar novas contas mas apenas os gerentes poder o exclu los Se houver seguran a no n vel dos dados o teste assegurar que o tipo de usu rio um possa ver todas as informa es de um cliente incluindo dados financeiros No entanto o tipo de usu rio dois somente ver os dados demogr ficos referentes ao mesmo cliente A seguran a no n vel do sistema assegura que somente os usu rios a que tenha sido concedido acesso ao sistema ser o capazes de acessar os aplicativos e somente atrav s dos gateways apropriados Objetivo da Experimentar o objetivo do teste nas seguintes condi es para observar e registrar o comportamento alvo e Seguran a no n vel do aplicativo um ator poder acessar somente as fun es ou os dados para o quais seu tipo de usu rio tenha recebido permiss o e Seguran a no n vel do sistema somente os atores com acesso ao sistema e aos aplicativos t m permiss o para acess los T cnica Seguran a no n vel do aplicativo Identifique e liste cada tipo de usu rio e as fun es ou os T cnica dados para os qu
10. o com outros sistemas ou dispositivos como por exemplo redes locais dispositivos seriais remotos etc 4 NEGATIVO Aqui ser descrito todos os requisitos ou caracter sticas que o produto do projeto n o ter Ser o definidas suas caracter sticas e o reflexo das mesmas no produto final AP NDICE C 7 DOCUMENTO DE ESPECIFICA O DE CASO DE USO lt Nome da Empresa gt a lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt DOCUMENTO DE ESPECIFICA O DO CASO DE USO lt NOME DO CASO DE USO gt VERS O 1 183 Hist rico de revis o Data Vers o Descri o Autor 185 SUM RIO ESPECIFICA O DE CASO DE USO lt NOME DO CASO DE USO gt 187 1 NOME DO CASO DE USO ee 188 1 1 BREVE DESCRI O u ccccessscssssesesssssssceseusssssssevessussseseveususssesesevsususnseveves 188 2 FLUXO DE EVENTOS I u u 189 OA ED EE AAA ee 189 22 FLUXOS ALTERNATIVOS innen 189 2 2 1 lt Primeiro fluxo alternativo gt 189 2 2 2 lt Um subfluxo alternativo gt 189 2 2 3 lt Segundo fluxo alternativo gt serenas 190 3 REQUISITOS ESPECIAIS I u u u 191 34 lt PRIMEIRO REQUISITO ESPECIAL gt aasan 19
11. 5 1 1 Teste de Integridade de Dados e de Banco de Dados Os bancos de dados e os processos de banco de dados dever o ser testados como um subsistema independente Esse teste deve testar os subsistemas sem que a Interface do Usu rio do objetivo do teste fa a interface com os dados Objetivo da Experimentar processos e m todos de acesso a banco de dados independentes da UI para que voc possa observar e registrar comportamentos alvo incorretos ou a exist ncia de dados corrompidos t cnica T cnica Dispare cada processo e m todo de acesso a banco de dados propagando dados v lidos e inv lidos ou solicita es de dados em cada um deles Inspecione o banco de dados para assegurar que os dados foram distribu dos conforme o planejado e que todos os eventos de banco de dados ocorreram de forma adequada ou revise os dados retornados para assegurar que os dados corretos foram recuperados pelas raz es corretas Estrat gias Descreva uma ou mais estrat gias que podem ser usadas pela t cnica para observar de forma precisa os resultados do teste A estrat gia combina elementos do m todo atrav s do qual a observa o pode ser feita e das caracter sticas dos resultados espec ficos que indicam um prov vel xito ou falha do teste O ideal que as estrat gias sejam autoverificadas permitindo que os testes automatizados fa am uma avalia o inicial do xito ou falha do teste No entanto tenha aten o para re
12. es necess rias para testar e implantar o software As instala es podem incluir constru es especiais ou salas com piso elevado requisitos de energia el trica e recursos especiais de suporte aos requisitos de privacidade e seguran a 3 2 HARDWARE Identifique o hardware necess rio para execu o e suporte ao software se aplic vel Especifique modelo vers es e configura es Forne a informa es sobre suporte do fabricante e licencas 4 3 UNIDADE DE IMPLANTA O Liste o software e a documenta o fornecida como parte do produto liberado 3 2 1 Software de suporte Conforme aplic vel descreva todo o software necess rio para suporte ao produto liberado como ferramentas compiladores ferramentas de teste dados de teste utilit rios ferramentas de CM bancos de dados arquivos de dados e assim por diante 3 2 2 Documenta o de suporte Conforme aplic vel descreva a documenta o necess ria para suporte ao produto liberado como descri es de design casos e procedimentos de teste manuais do usu rio etc 3 2 3 Pessoal de suporte Conforme aplic vel descreva o pessoal e os respectivos n veis de habilidades necess rios para suporte ao produto liberado 4 TREINAMENTO Descreva o plano e as informa es para treinamento dos usu rios de forma que eles possam utilizar e adaptar o produto de acordo com suas necessidades Caso possua um artefato Plano de Treinamento referencie o AP NDI
13. ndice o uso de um gloss rio de termos estrat gia de tutorial versus de manual de refer ncia etc As restri es de formata o e de impress o tamb m dever o ser identificadas 10 2 AJUDA ON LINE Muitos aplicativos fornecem um sistema de ajuda on line para auxiliar o usu rio A natureza desses sistemas exclusiva do desenvolvimento do aplicativo j que eles combinam aspectos de programa o hyperlinks etc com aspectos de escrita t cnica como por exemplo organiza o e apresenta o Muitos perceberam que o desenvolvimento de um sistema de ajuda on line um projeto que est contido em outro projeto beneficiando se do gerenciamento adiantado do escopo e da atividade de planejamento 10 3 GUIAS DE INSTALA O E DE CONFIGURA O E ARQUIVO LEIAME Um documento que inclua instru es de instala o e diretrizes de configura o importante para se oferecer uma solu o completa Al m disso um arquivo Leiame normalmente inclu do como um componente padr o O arquivo Leiame poder incluir uma se o O Que H de Novo Neste Release e uma discuss o dos problemas de compatibilidade em rela o aos releases anteriores A maior parte dos usu rios tamb m considera desej vel que o arquivo Leiame documente erros e solu es conhecidos 10 4 ROTULAC O E EMBALAGEM Os aplicativos modernos atuais apresentam uma apar ncia consistente que percebida inicialmente na embalagem do produto e se propaga pe
14. o de n vel suficientemente elevado de modo a resultar em 25 a 99 recursos Esses recursos ser o a base fundamental do gerenciamento do projeto do gerenciamento do escopo e da defini o do produto Cada recurso ser descrito mais detalhadamente no modelo de casos de uso Em toda esta se o cada recurso ser percebido externamente por usu rios operadores ou outros sistemas externos Esses recursos dever o incluir uma descri o da funcionalidade e de todas as quest es de usabilidade relevantes que dever o ser abordadas As seguintes diretrizes se aplicam 5 1 lt UM RECURSO gt 5 2 lt OUTRO RECURSO gt 6 RESTRI ES Mencione quaisquer restri es de design restri es externas ou outras depend ncias 7 FAIXAS DE QUALIDADE Defina as faixas de qualidade para desempenho robustez toler ncia a erros usabilidade e caracter sticas semelhantes que n o s o capturadas no Conjunto de Recursos 8 PRECED NCIA E PRIORIDADE Defina a prioridade dos diferentes recursos do sistema 9 OUTROS REQUISITOS DO PRODUTO Em um n vel alto liste os padr es aplic veis os requisitos de hardware ou de plataforma os requisitos de desempenho e os requisitos de ambiente 9 1 PADR ES APLIC VEIS Liste todos os padr es com os quais o produto dever estar em conformidade Entre eles poder o estar inclu dos padr es legais e reguladores FDA UCC padr es de comunica es TCP IP ISDN padr es de conformidade
15. poss vel que os elementos espec ficos do sistema de teste n o sejam totalmente compreendidos nas itera es iniciais sendo assim espera se que esta se o seja preenchida ao logo do tempo recomend vel que o sistema simule o ambiente de produ o reduzindo o acesso concorrente e o tamanho do banco de dados se e quando for necess rio Observa o Adicione ou exclua itens conforme o necess rio Recurso Quantidade Nome e Tipo Servidor de Banco de Dados Rede ou Sub rede Nome do Servidor Nome do Banco de Dados PCs de Teste Cliente Inclua requisitos de configura o especiais Reposit rio de Teste Rede ou Sub rede Nome do Servidor PCs de Desenvolvimento de Teste 9 2 ELEMENTOS DE SOFTWARE B SICOS DO AMBIENTE DE TESTE S o necess rios os seguintes elementos de software b sicos no ambiente de teste deste Plano de Teste Observa o Adicione ou exclua itens conforme o necess rio Nome do Elemento de Software Tipo e Outras Observa es NT Workstation Sistema Operacional Windows 2000 Internet Explorer Sistema Operacional Navegador da Internet Netscape Navigator Microsoft Outlook Network Associates McAffee Virus Checker Navegador da Internet Software Cliente de E Mail Software de Detec o e Recupera o de V rus 9 3 FERRAMENTAS DE PRODUTIVIDADE E DE SUPORTE Ser o utilizadas as seguintes ferramentas para suportar o processo de teste deste Plano de Teste Observa o A
16. 2009 p 2 6 24 3 4 1 Rational Unified Process RUP O Rational Unified Process um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organiza o de desenvolvimento Sua meta garantir a produ o de software de alta qualidade que atenda s necessidades dos usu rios dentro de um cronograma e de um or amento previs vel Disciplinas in Elabora Modelagem de Neg cios Requisitos An lise e Design Implementa o Teste Implanta o Geren de Configura o e Mudan a Gerenciamento de Projeto Ambiente Itera es Figura 3 4 Arquitetura organizacional do RUP A Figura 3 1 mostra como a nfase varia atrav s do tempo Por exemplo nas itera es iniciais dedicado mais tempo aos requisitos J nas itera es posteriores gasto mais tempo com a implementa o Assim pode se observar que o RUP tem duas dimens es e O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo medida que se desenvolve Ele tamb m representa o aspecto din mico do processo quando ele aprovado e expressa em termos de fases itera es e marcos e O eixo vertical representa as disciplinas que agrupam as atividades de maneira l gica por natureza Representa o aspecto est tico do processo 25 como ele descrito em termos de componentes disciplinas ativ
17. FERRAMENTAS NECESS RIAS I u 286 CONSIDERA ES ESPECIAIS I u uuu 287 5 1 2 Teste de Funcionamento 287 5 1 3 Teste de Interface do USUARIO a en 287 5 1 4 Teste de Seguran a e de Controle de 288 6 CRIT RIOS DE ENTRADA E DE SA DA u uuu 289 6 1 PLANO DE TESTE e 289 6 1 1 Crit rios de Entrada de Plano de 289 6 1 2 Crit rios de Sa da de Plano de 289 6 1 3 Crit rios de Suspens o de Rein cio 289 6 2 CICLOS DE TESTE us tas a pira Age Ge dis 290 6 2 1 Crit rios de Entrada de Ciclo de Teste 290 6 2 2 Crit rios de Sa da de Ciclo de 290 6 2 3 T rmino Anormal do Ciclo de Teste 290 7 PRODUTOS LIBERADOS U 291 7 1 SUM RIOS DE AVALIA O DE 291 7 1 1 Resultados Detalhados dos Testes 291 7 1 2 Matrizes de Rastreabilidade
18. INTRODU O FPN 307 1 2 FINALIDADE aan 307 E O aa AAN AAA ANGE 307 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 307 dab VISAO GERAL esses o e de 307 1 6 REFER NCIAS 307 2 PLANEJAMENTO DE IMPLANTACAQ u uu 308 2 1 RESPONSABILIDADES cococccncononoconcnnonnonencnnoninenenonnoronanononroranenennnerinineneos 308 22 PROGRAMA O a 308 9 RECURSOS taa 309 3 4 INSTALA ES bien 309 3 22 HARDWARE u a een 309 43 UNIDADE DE IMPLANTAGAO 2 ee 309 3 2 1 Software de suporte nannten 309 3 2 2 Documenta o de suporte 309 3 2 3 Pessoal de Suporte 1 U J 309 4 TREINAMENTO Es 310 1 PLANO DE IMPLANTA O 1 1 INTRODU O Forne a uma vis o geral do documento inteiro 1 2 FINALIDADE Descreva a finalidade deste documento 1 3 ESCOPO Identifique os destinat rios dos itens identificados no Plano de Implantac o 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Consultar o documento Gloss rio de Neg cios 1 5 VIS O GERAL Explique como este documento est organizado 1 6 REFER NCIAS Esta subse o fornece uma lista completa dos documentos Identifique cada documento por t tulo n mero do relat rio se aplic vel e organiza o de publica o Especifique as fontes a partir das quais a
19. Projeto s ao s qual is ele est associado e tudo o que afetado ou influenciado por este documento 2 4 REFER NCIAS Esta subse o apresenta uma lista completa de todos os documentos mencionados no documento Regras de Neg cios Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 2 5 VIS O GERAL Esta subse o descreve o conte do restante do documento Regras de Neg cios e explica como ele est organizado 26 DEFINI ES Os termos definidos aqui formam a parte essencial do documento Eles podem ser definidos na ordem desejada mas geralmente a ordem alfab tica proporciona maior acessibilidade 156 3 REGRAS 3 1 RN001 lt REGRAS DE NEGOCIO gt A defini o de lt regras de neg cio gt apresentada aqui com todas as informa es necess rias para que o leitor entenda o conceito 3 2 RN002 lt OUTRAS REGRAS DE NEGOCIO gt A defini o de lt Outras regras de neg cio gt apresentada aqui com todas as informa es necess rias para que o leitor entenda o conceito 3 3 GRN001 lt UM GRUPO DE REGRAS DE NEG CIO gt As vezes til organizar as Regras de Neg cios em grupos para melhorar a leitura Por exemplo se o dom nio de problema cont m Regras de Neg cios relacionad
20. aterrar 269 24 SUBSISTEMA Sada 270 B BUILDS anne enden 271 1 PLANO DE INTEGRA O DO BUILD 1 1 INTRODU O A introdu o do Plano de integra o do build oferece uma vis o geral de todo o documento Ela inclui a finalidade o escopo as defini es os acr nimos as abrevia es as refer ncias e uma vis o geral deste Plano de integra o do build 1 2 FINALIDADE Especifique a finalidade deste Plano de integra o do build 1 3 ESCOPO Uma breve descri o do escopo deste Plano de integra o do build os modelos aos quais ele est associado e tudo o que afetado ou influenciado por este documento 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Consultar o documento de Gloss rio de neg cios 1 5 REFER NCIAS Esta subse o apresenta uma lista completa de todos os documentos mencionados no Plano de integra o do build Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 1 6 VIS O GERAL Esta subse o descreve o conte do restante do Plano de integra o do build e explica como o documento est organizado 2 SUBSISTEMAS Especifique os subsistemas que dever o ser implementados nesta itera o Especifique tamb m a ordem preferencial na qual os subsistemas ser o implement
21. es suplementares e de caso de uso A introdu o do documento de Vis o oferece uma vis o geral de todo o documento Ela cont m a finalidade o escopo as defini es os acr nimos as abrevia es as refer ncias e a vis o geral deste documento Vis o 1 2 FINALIDADE Especifique a finalidade deste documento Vis o 1 3 ESCOPO Uma breve descri o do escopo deste documento Vis o a que Projeto s ele est associado e tudo o mais que seja afetado ou influenciado por este documento 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Esta subse o fornece as defini es de todos os termos acr nimos e abrevia es necess rias adequada interpreta o do documento Vis o Essas informa es podem ser fornecidas mediante refer ncia ao Gloss rio do projeto 1 5 REFER NCIAS Esta subse o apresenta uma lista completa de todos os documentos mencionados no documento de Vis o Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 1 6 VIS O GERAL Esta subse o descreve o que o restante do documento Vis o cont m e explica como o documento est organizado 2 POSICIONAMENTO 2 1 OPORTUNIDADE DE NEG CIOS Fa a uma breve descri o da oportunidade de neg cios atendida por este projeto
22. o Este papel representa a pessoa capaz de traduzir problemas do mundo humano para o mundo computacional atrav s de linguagens O desenvolvedor deve conhecer os princ pios b sicos da computa o como algoritmos e estruturas de dados al m de saber aplic los em uma ou mais linguagens de programa o O desenvolvedor dever saber trabalhar em equipe dividir o conhecimento com os demais colegas de trabalho 4 Atribui es A Artefatos do papel gt Codificar e documentar solu es de software w Plano de integra o x Criar mecanismos para uma melhor implementa o das Y Componente de Software solu es Y Utilizar os padr es de codifica o estabelecidos pela empresa w Mensurar requisitos de software x Avaliar riscos de codifica o Fornecer feedback das atividades para o l der da equipe 4 T tulos Caracter sticas Exigidos Y Compet ncia w Curso t cnico na rea de desenvolvimento de sistemas Agilidade para codificar solu es w Facilidade de perceber de problemas Desejados Y Saber trabalhar em equipe w Curso superior na rea de com foco em desenvolvimento de software AP NDICE B 6 ANALISTA DE TESTE 93 Processo de desenvolvimento d 5 Detalhamento Papel Analista de testes Descri o Este papel representa a pessoa habilitada para desenvolver testes de software Ele deve atuar na fase de An lise onde cria as propostas de testes esperadas
23. rio GUI e analisar a sa da ou os resultados A tabela a seguir identifica um resumo do teste recomendado para cada aplicativo Objetivo da Experimentar a funcionalidade do objetivo do teste incluindo a navega o a entrada o processamento e a recupera o de dados a fim de observar e registrar o comportamento alvo T cnica T cnica Experimentar os recursos e fluxos ou fun es de cada um dos cen rios de caso de uso utilizando dados v lidos e inv lidos para verificar se e 05 resultados esperados ocorrer o quando forem usados dados v lidos e As mensagens de erro ou de aviso apropriadas ser o exibidas quando forem usados dados inv lidos e Cada regra de neg cio ser aplicada de forma adequada Estrat gias Descreva uma ou mais estrat gias que podem ser usadas pela t cnica para observar de forma precisa os resultados do teste A estrat gia combina elementos do m todo atrav s do qual a observa o pode ser feita e das caracter sticas dos resultados espec ficos que indicam um prov vel xito ou falha do teste O ideal que as estrat gias sejam autoverificadas permitindo que os testes automatizados fa am uma avalia o inicial do xito ou falha do teste No entanto tenha aten o para reduzir os riscos inerentes determina o autom tica dos resultados Ferramentas A t cnica exige as seguintes ferramentas e Ferramenta de Automa o de Scripts de Teste e Restaurador e repr
24. rios aspectos O principal deles a organiza o dos recursos humanos e dependendo de como acontece na pr tica pode trazer s rios problemas que influenciam diretamente nas atividades Esta se o far uma explana o sobre como esses aspectos acontecem no dia a dia 15 2 3 1 Colaboradores Segundo o SEBRAE 2005 desde 1999 o crit rio adotado para conceituar micro e pequena empresa de com rcio ou servi o a receita bruta anual ou o n mero de funcion rios cujos valores foram atualizados pelo Decreto n 5 028 2004 de 31 de mar o de 2004 segundo descrito na Tabela 2 1 Ela n o um padr o nacional serve apenas como refer ncia para as economias locais Unidades da Federa o Classifica o Renda bruta anual N mero de funcion rios Microempresa Menor que 433 755 14 Menor ou igual a 9 Pequena empresa Entre 433 755 14 e Entre 10 e 49 2 133 222 00 Tabela 2 1 Classifica o das micro e pequenas empresas de software brasileiras segundo o SEBRAE Observando o mercado local muito dif cil para uma microempresa tendo um quadro reduzido de pessoal adotar a um processo de desenvolvimento de software sem que uma pessoa n o acumule pap is Isso comum no mercado A maioria das empresas prefere dar mais pap is para os colaboradores do que contratar novos funcion rios Isso uma caracter stica observada e tratada pelo Prumo Ele prop e a distribui o de pap is entre um n mero m nimo de
25. 2 2 DESCRI O DO PROBLEMA Forne a uma descri o resumindo o problema que est sendo resolvido pelo projeto Pode ser utilizado o seguinte formato O problema Que afeta Cujo impacto Uma boa solu o seria 2 3 SENTEN A DE POSI O DO PRODUTO Forne a uma senten a geral resumindo no n vel mais alto a posi o exclusiva que o produto pretende ocupar no mercado Pode ser utilizado o seguinte formato Para cliente alvo Que indique a necessidade ou oportunidade O lt Nome do produto gt categoria do produto um a Que indique o principal benef cio ou seja o motivo que leva a comprar Diferente de principal alternativa da concorr ncia Nosso produto indique a principal diferen a Uma senten a de posi o do produto comunica o objetivo do aplicativo e a import ncia do projeto para todo o pessoal envolvido 3 DESCRI ES DOS ENVOLVIDOS E USUARIOS Para fornecer de maneira eficiente produtos e servi os que atendam s reais necessidades dos usu rios e dos envolvidos necess rio identificar e considerar todos os envolvidos como parte do processo de Modelagem de Requisitos necess rio tamb m identificar os usu rios do sistema e assegurar que a comunidade de envolvidos os represente adequadamente Esta se o fornece um perfil dos envolvidos e dos usu rios que integram o projeto e dos principais problemas que de acordo com o ponto de vista deles poder o ser aborda
26. 4 Atribui es A Artefatos do papel Comunicar se com o cliente w Plano de Treinamento j V Desenvolver e executar treinamento de usu rios Y Plano de Implanta o Desenvolver e executar implanta o da solu o Solicita o de Treinamento Dar suporte ao usu rio w Comprovante de Implanta o da Funcionalidade 4 T tulos Caracter sticas Exigidos relacionamento interpessoal w Curso superior em tecnologia da informa o Comunicativo w Experi ncia em ministrar aulas e ou cursos Saber ouvir as opini es do cliente Clareza de id ias Desejados Cursos que envolvam instala o e manuten o de aplicativos e sistemas operacionais Y Cursos que envolvam instala o e manuten o de servidores AP NDICE B 8 ANALISTA DE QUALIDADE 101 Processo de desenvolvimento 1 E Detalhamento do Papel Analista de qualidade Descri o Este papel representado pela pessoa que realizar as auditorias sobre os artefatos produzidos durante o ciclo de vida do processo Ele observa os artefatos examinando os segundo os padr es estabelecidos pela empresa de desenvolvimento 4 Atribui es A Artefatos do papel gt Realizar auditorias no decorrer do processo lista de verifica o de qualidade w Zelar pelo alto n vel de qualidade do software w Todos os documentos das fases anteriores Y Verificar a conformidade das atividade realizadas Y Verificar a confor
27. DE PROCESSOS a ds ale 18 3 3 1 Modelo em Cascata 18 3 3 2 Modelo iterativo e incremental 19 3 3 3 Diferenciando os modelos em cascata iterativo e incremental 20 3 3 4 Modelo em eSPl 5 21 338 Modelo Adi 22 3 4 PADR ES POR EXCELENCIAL een 23 3 4 1 Rational Unified Process RUP 24 3 4 2 25 4 ER RR ER 27 4 1 N VEIS DE DETALHAMENTO DO 0 27 42 N VEL DO CICLO DE VIDA oc 29 4 2 1 Fase de Solicita O nico he 31 4 2 2 Fase de an lise ee 31 4 2 3 Fase de planejamento iia 31 4 2 4 Fase de Desenvolvimento 32 4 2 5 4 2 6 4 2 7 4 2 8 4 3 4 3 1 4 3 2 4 3 3 4 3 4 4 3 5 4 3 6 4 3 7 4 3 8 4 4 4 4 1 4 5 4 5 1 4 5 1 1 4 5 1 2 4 5 1 3 4 5 2 4 5 2 1 4 5 2 2 4 5 2 3 4 5 2 4 4 5 2 5 4 5 2 6 4 5 3 4 5 3 1 4 5 3 2 4 5 4 4 5 4 1 4 5 4 2 4 5 5 4 5 5 1 Fase de A cess 33 Fase de Entregas 33 Verifica o da qualidades 34 Gerenci
28. Esta subse o fornece uma lista completa de todos os documentos mencionados em qualquer outra parte do Gloss rio Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 1 5 VIS O GERAL Esta subse o descreve o que o restante do Gloss rio cont m e explica como o documento est organizado Defini es 144 Os termos definidos aqui s o a ess ncia do documento Eles poder o ser definidos na ordem desejada mas geralmente a ordem alfab tica propicia maior acessibilidade 1 6 lt UM TERMO gt A defini o de lt Um termo gt apresentada aqui Voc dever apresentar quantas informa es forem necess rias para que o leitor compreenda o conceito 1 7 lt OUTRO TERMO gt A defini o de lt Outro termo gt apresentada aqui Voc dever apresentar quantas informa es forem necess rias para que o leitor compreenda o conceito 1 8 lt UM GRUPO DE TERMOS gt As vezes til organizar os termos em grupos para aprimorar a legibilidade Por exemplo se o dom nio do problema contiver termos relacionados a contabilidade e a constru o de pr dios como seria o caso se estiv ssemos desenvolvendo um sistema para gerenciar projetos de constru o apresentar os termos dos dois subdom nios diferentes
29. INTRODU O Su u qa S A sua aura 237 1 2 n RAS 237 ESCORO e 237 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 237 ES REFERENCIAS a iA 237 or VIS O GERAL PRN GU COPE ET CIR PEL CRP REN 238 2 REPRESENTA O ARQUITETURAL s s s sssssssssssssssessssssssssssssesssetesenenees 239 3 METAS E RESTRI ES DA ARQUITETURA 240 4 VIS O DE CASOS DE USO na na De Qasa 241 1 7 REALIZA ES DE CASOS DE USO serranas 241 2 VISAO I LOGIGA ce acesas A nee nena 242 VISADO GERAL sss 242 2 2 PACOTES DE DESIGN SIGNIFICATIVOS DO PONTO DE VISTA DA ARQUITETURA A 242 3 VIS O DE PROCESSOS I U U u u uu uu 243 4 VIS O DE IMPLANTACAQO 244 5 VIS O DA IMPLEMENTA O I u uu 245 BA VISAO GER aa sn Annan nadas 245 52 Lu aan a da a a da ara 245 6 VIS O DE DADOS OPCIONALL I u uu 246 7 TAMANHO E DESENPENHQO I u uu 247 8 QUALIDADE corona A AAA AAA 248 1 DOCUMENTO DE ARQUITETURA DE SOFTWARE Este documento oferece uma vis o geral arquitetural abrangente do sistema usando diversas vis es arquiteturais para representar diferentes aspectos do siste
30. PROJETO sn eine 224 4 2 PEANO DE PROJETO Ce TQ T he A a 224 4 2 1 PIANO de dass 2 2 224 4 2 2 Objetivos das itera es J 224 4 2 3 Releases E 224 4 2 4 Cronograma do projeto uoconia a 224 4 2 5 Recursos do 224 4 2 5 1 Plano de saias 224 4 2 5 2 Plano de aquisi o de recursos 224 42 097 Plano de heimamento NANA 225 4 2 6 Ann 225 4 3 PLANOS DAS ITERA ES tear 225 4 4 CONTROLE E ACOMPANHAMENTO DO PROJETO pp 225 4 4 1 Plano de ger ncia de requisitos 225 4 4 2 Plano de controle do cronograma 225 4 4 3 Plano de controle do or amento 225 4 4 4 Plano do controle de qualidade 225 4 4 5 Plano de comunicacao 225 4 4 6 Plano de M trica ui 226 4 5 DE GER NCIA DE 226 4 6 PLANO DE ENCERRAMENTO rn tata da a 226 5 PLANOS DE APOIO AO PROCESSOQ
31. Por exemplo este envolvido garante que o sistema ter manuten o garante que haver uma demanda do mercado para as caracter sticas do produto monitora o andamento do projeto 3 3 RESUMO DOS USU RIOS Apresente uma lista resumida de todos os usu rios identificados Nome Descri o Responsabilidades Envolvidos 3 4 AMBIENTE DO USU RIO Detalhe o ambiente de trabalho do usu rio alvo A seguir s o apresentadas algumas sugest es N mero de pessoas envolvidas na execu o da tarefa Isso est mudando Qual a dura o de um ciclo de tarefas Qual o tempo gasto em cada atividade Isso est mudando Existem restri es ambientais exclusivas telefone celular ambientes ao ar livre uso em aeronaves e outros Quais plataformas de sistema est o sendo utilizadas atualmente Quais s o as futuras plataformas Que outros aplicativos est o em uso necess rio que o seu aplicativo interaja com eles Este local em que podem ser inclu dos os extratos do Modelo de Neg cios para descrever a tarefa e os pap is envolvidos etc 3 5 PERFIS DOS ENVOLVIDOS Descreva aqui cada envolvido no sistema preenchendo a tabela abaixo para cada um deles Lembre se de que os tipos de envolvidos poder o ser os mais diversos como por exemplo usu rios departamentos e desenvolvedores t cnicos Um perfil completo deve abranger os t picos abaixo para cada tipo de envolvido 3 6 lt NOME DO ENVOLVIDO gt Repre
32. a complexidade do caso de uso sob controle poder ser conveniente definir termos como por exemplo informa es do cliente neste gloss rio a fim de evitar que o caso de uso fique repleto de detalhes As alternativas simples poder o ser apresentadas no texto do caso de uso Se forem necess rias apenas algumas frases para descrever o que acontece quando h uma alternativa fa a essa descri o diretamente na se o fluxo de eventos Se o fluxo alternativo for mais complexo use uma se o separada para descrev lo Por exemplo uma subse o fluxo alternativo explica como descrever alternativas mais complexas s vezes uma figura vale por mil palavras embora n o haja nada que possa substituir uma reda o clara e organizada Se for mais esclarecedor sinta se vontade para colar representa es gr ficas de interfaces do usu rio fluxos de processo ou outras imagens no caso de uso Se um fluxograma for til para apresentar um processo complexo de decis es utilize o sem d vida nenhuma Assim como no caso de comportamentos dependentes de estado um diagrama de transi o de estado geralmente esclarece o comportamento de um sistema muito mais do que p ginas e p ginas de texto Use o meio de apresenta o certo para o problema mas procure evitar o uso de terminologia nota es ou imagens que o p blico possa n o entender Lembre se de que sua finalidade esclarecer e n o obscurecer 2 2 FLUXOS ALTERNATIVOS 2 2 1 l
33. a equipe tamb m ter melhores condi es de gerenciar a qualidade dos artefatos produzidos A quarta forma de agrupamento proposta neste trabalho une dois pap is o Analista de Testes e o Analista de Suporte ou seja agora o primeiro papel far n o s o planejamento defini o de diretrizes de testes e execu o como tamb m passar a realizar o planejamento e execu o dos treinamentos e implanta o da solu o Qualquer outra forma de combina o entre pap is deve ser avaliada por exemplo os pap is de Desenvolvedor e Testador n o devem ser atribu dos a uma mesma pessoa devido ao risco de o Desenvolvedor criar testes ineficientes para os componentes de software que ele mesmo desenvolveu entre outros casos 4 5 N VEL DAS ATIVIDADES As atividades dentro de um processo de desenvolvimento de software fazem parte do segundo n vel de detalhamento de um processo Elas s o importantes para especificar em que momento ser trabalhado qual aspecto da solu o 45 Uma caracter stica importante de uma atividade o que ela expressa ou seja ela define quem participa da atividade quando ela deve ser realizada quais os artefatos de entrada e quais os artefatos de sa da A Figura 4 3 mostra um exemplo de atividade No canto superior esquerdo encontra se o s participante s ou seja quem realiza participa ou acompanha a atividade No canto inferior esquerdo est o as siglas dos artefatos de entrada o
34. cada problema esclare a os seguintes pontos Quais s o as causas do problema Como ele est sendo resolvido agora Que solu es o envolvido ou usu rio deseja essencial entender a import ncia relativa atribu da pelo envolvido ou usu rio resolu o de cada problema A s t cnicas de ordena o e de vota o cumulativa indicam os problemas que devem ser resolvidos versus os problemas que eles gostariam que fossem resolvidos Preencha a tabela a seguir se estiver usando o Rational RequisitePro para capturar as Necessidades pode ser um fragmento ou relat rio dessa ferramenta Necessidade Prioridade Preocupa es Solu o atual Solu es propostas 3 9 ALTERNATIVAS E CONCORR NCIA Identifique as alternativas que o envolvido considera dispon veis Isso inclui adquirir um produto do concorrente desenvolver uma solu o pr pria ou simplesmente manter o estado atual Liste as op es conhecidas que a concorr ncia oferece ou que podem se tornar dispon veis Inclua os principais pontos fortes e pontos fracos de cada concorrente segundo o ponto de vista do envolvido ou do usu rio final 3 9 1 lt UMCOMPETIDOR gt 3 9 2 lt OUTROCOMPETIDOR gt 4 VIS O GERAL DO PRODUTO Esta se o oferece uma vis o de n vel superior dos recursos do produto interfaces com outros aplicativos e configura es de sistema Ela geralmente constitu da destas tr s subse es Perspectiva do produto Fun es do produ
35. da quantidade de n o conformidades em compara o com o cumprimento dos prazos estabelecidos para o projeto Logo ap s as devidas corre es s o apresentadas aos respons veis e a atividade segue o curso normal Os pap is respons veis pelas atividades durante esta fase s o o Gerente de Projeto e Analista de Qualidade O primeiro ir avaliar como esta o andamento do projeto se est em dia se os ricos est o sendo controlados devidamente etc O segundo ir avaliar os artefatos gerados durante a fase de forma a solicitar altera es nos mesmos caso eles n o estejam no padr o estabelecido pela empresa Em seguida haver uma reuni o entre os dois onde o Analista de Qualidade passar ao Gerente a sua avalia o para que ele possa ter um maior controle do andamento do projeto j que pode haver a necessidade de corre o de alguns documentos 4 2 8 Gerenciamento de mudan a Este um processo de apoio que ser realizado quando qualquer envolvido solicitar uma mudan a no projeto uma vez que esta mudan a envolva uma especifica o que j tenha passado pela Fase de An lise O comportamento dessa atividade foi 35 definido dessa forma devido ao impacto que uma mudan a pode provocar em um item em desenvolvimento Na primeira atividade ser analisada a influ ncia que a mudan a solicitada ir gerar no projeto analisando se algum requisito ser invalidado ou adicionado ao projeto pela solicita o ou aind
36. de uso mas que n o especificado de maneira f cil ou natural no texto do fluxo de eventos do caso de uso Entre os exemplos de requisitos especiais est o inclu dos requisitos legais e reguladores padr es de aplicativos e atributos de qualidade do sistema a ser criado incluindo requisitos de usabilidade confiabilidade desempenho ou suportabilidade Al m disso outros requisitos como ambientes e sistemas operacionais requisitos de compatibilidade e restri es de design dever o ser capturados nesta se o 3 1 lt PRIMEIRO REQUISITO ESPECIAL gt 192 4 PRECONDICOES Uma precondi o de um caso de uso o estado do sistema que deve estar presente antes de um caso de uso ser realizado 4 1 lt PRECONDI O UM gt 193 5 POS CONDICOES Uma p s condi o de um caso de uso uma lista dos poss veis estados em que o sistema poder se encontrar imediatamente depois do t rmino de um caso de uso 5 1 lt P S CONDI O UM gt 194 6 PONTOS DE EXTENS O Pontos de extens o do caso de uso 6 1 lt NOME DO PONTO DE EXTENS O gt Defini o da localiza o do ponto de extens o no fluxo de eventos AP NDICE C 8 PROT TIPO DA INTERFACE COM O USU RIO lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt PROTOTIPO DA INTERFACE COM O USUARIO VERSAO 1 199 Hist rico de
37. de Teste estima os resultados gerados pelo sistema como solu o satisfat ria para os problemas do Cliente Dessa forma um Plano de Testes definido para dar suporte realiza o fiel dos testes nas fases posteriores do processo de desenvolvimento Nessa atividade o Analista de Testes ir analisar o Documento de Elicita o de Requisitos e definir as diretrizes dos testes que ser o aplicadas Uma vez definidas as entradas sa das e as condi es de execu o de cada teste o Analista de Testes ir elaborar o Plano de Testes que formalizar todo o procedimento de teste que ser realizado sobre o sistema 4 5 2 6 Negociar requisitos Aqui est o definidas as atividades necess rias para a negocia o de requisitos entre o Gerente de Projetos e o Cliente Eles se reunir o para definir prioridades de 50 requisitos estabelecer prazos e estipular metas O Analista de Requisitos participa esclarecendo e apresentando os requisitos elicitados e definidos Finalizando com um contrato firmado entre o Cliente e a empresa de desenvolvimento 4 5 3 Atividades da fase de planejamento Este t pico mostra como s o realizadas as atividades necess rias para a realiza o do planejamento para o desenvolvimento do projeto 4 5 3 1 Planejar desenvolvimento Nesta atividade est o descritos os passos necess rios para que o planejamento do projeto seja realizado de forma satisfat ria O Gerente de Projetos ao iniciar esta atividade
38. de software pode ser observado sobre diversos aspectos Uma forma de abord lo a fim de entender a sua organiza o buscando uma vis o em n veis de detalhamento Pensando nisso esse t pico tenta explicar o Prumo em tr s n veis Ciclo de vida Atividades e Detalhamento mostrados na Figura 4 1 28 Planeja ento NIVEL 1 Cicio de Vida N VEL 2 Atividades Atividades Pap is Artefatos a NIVEL 3 Detalhamento Figura 4 1 Visualiza o do Prumo em n veis No nivel mais alto de abstra o dos detalhes est o Ciclo de Vida do processo onde se especifica como est o organizadas as fases Durante a defini o deste n vel pensou se como seriam melhor utilizados dos modelos de processos definidos pela Engenharia de Software Note que foram aplicados aspectos do modelo iterativo e incremental ao Prumo ou seja no ciclo podem ser lan ados pacotes de funcionalidades que ap s serem desenvolvidos e integrados representam uma solu o O seguindo n vel possui a representa o das atividades compostas de nome da atividade participantes artefatos de entrada e artefatos de sa da Outra caracter stica importante expressa nesse n vel o relacionamento entre as atividades Assim os integrantes da equipe sabem exatamente em que atividades eles possuem participa o quais artefatos necess rios para iniciar a atividade e quais artefatos gerados como sa da Por fim no terceiro n ve
39. degrada o o modo aceit vel de opera o quando o sistema tiver sido degradado de alguma maneira A utiliza o de recursos como por exemplo mem ria disco comunica es etc 3 3 1 RNF005 Primeiro requisito n o funcional de desempenho Uma descri o detalhada do requisito RNFOO5 3 3 2 RNF006 Segundo requisito n o funcional de desempenho Uma descri o detalhada do requisito RNFOO6 3 4 INTERFACES Esta se o define as interfaces que devem ser suportadas pelo aplicativo Ela deve conter especificidades protocolos portas e endere os l gicos adequados entre outros para que o software possa ser desenvolvido e verificado em rela o aos requisitos de interface 3 4 1 Interfaces do Usuario Descreva as interfaces de usudrio que deverdo ser implementadas pelo software 3 4 2 Interfaces de Hardware Esta secdo define todas as interfaces de hardware que devem ser suportadas pelo software incluindo a estrutura l gica os endere os f sicos o comportamento esperado etc 3 4 3 Interfaces de Software Esta se o descreve as interfaces de software para outros componentes do sistema de software Poder o ser componentes comprados componentes reutilizados de outro aplicativo ou componentes que estejam sendo desenvolvidos para subsistemas fora do escopo desta SRS mas com os quais esse aplicativo de software deve interagir 3 4 4 Interfaces de Comunica o Descreva todas as interfaces de comunica
40. desenvolvimento 50 Atividades da fase de desenvolvimento 51 Definir arquitetura pe 51 ONGEN 51 Atividades da fase de test 51 MOST ea e Aan eae Ahan Gea PCE 51 4 5 6 Atividades da fase de entrega J 53 4 5 6 1 Planejar treinamento e 53 4 5 6 2 Treinar usu rios 53 4 5 6 3 Implantar solu o e dar suporte eee 54 4 6 PROCESSOS DE APOIO Seen 54 4 6 1 Gerenciamento das Mudan as GMD 54 Analisar solicita o sacas ao o 55 4 6 1 2 Negociar solu o com o cliente 55 4 6 1 3 Executar mudan a planejada 55 4 6 2 Verifica o da qualidade VQA J 56 4 6 2 1 Levantamento do projeto vcs ana eles ete eee lea 56 46 22 Avalia o da qualidade van 56 1 622 REUNI O NE 57 bad COMO lts ii 57 5 CONSIDERA ES FINAIS I u uuu 58 REFERENCIAS aa a ata a 59 AP NDICE A CICLO DE VIDA E MAPA DE
41. do software implementa o e teste de unidade integra o e teste do sistema opera o e manuten o 19 Defini o dos requisitos A Design do software A Y Implementa o e teste de unidade A Y Integra o e teste do sistema a Operacao e manuten o Figura 3 1 Ciclo de vida do modelo sequencial cascata A origem do termo cascata frequentemente citado como sendo um artigo publicado em 1970 por W W Royce lronicamente Royce defendia uma abordagem iterativa para o desenvolvimento de software e nem mesmo usou o termo cascata Ele originalmente descreve o que hoje conhecido como o modelo em cascata como um exemplo de um m todo que ele argumentava ser um risco e um convite para falhas Wikip dia A enciclop dia livre 2009 3 3 2 Modelo iterativo e incremental Desenvolvimento incremental uma estrat gia de planejamento em que v rias partes do sistema s o desenvolvidas em vers es como na Figura 3 2 ou em paralelo sendo integradas quando completas N o implica requer ou pressup e desenvolvimento iterativo ou em cascata ambos s o estrat gias de retrabalho A alternativa ao desenvolvimento incremental desenvolver todo o sistema com uma integra o nica Desenvolvimento iterativo uma estrat gia de planejamento de retrabalho em que o tempo de revis o e melhorias de partes do sistema pr definido Isto n o pressup e desenvolvimento incremental mas funciona mu
42. em lt http video globo com Videos Player Noticias 0 GIM965786 7823 SETOR DE TECNOLOGIA DA INFORMACAO CRESCE COM A CRISE 00 htm I gt Acesso em 26 de Outubro de 2009 DESENVOLVIMENTO Iterativo e Incremental Wikip dia a enciclop dia livre 17 Outubro 2009 Disponivel em lt http pt wikipedia org wiki Desenvolvimento iterativo e incremental gt Acesso em 26 de Outubro de 2009 DUTRA L R Paradigmas de Engenharia de Software Site da Universidade de Bras lia 2008 Disponivel em lt http www redes unb br material Metodologia 20de 20Desenvolvimento 20de 20Software aula3 pdf gt Acesso em 8 de Novembro de 2009 FILHO E M G et al Tributagao e Desenvolvimento no Setor de Software Brasileiro Site da Abes Associacao Brasileira das Empresas de Software Dezembro 2006 Disponivel em lt http www faltaesselink com br gt Acesso em 15 de Outubro de 2009 60 INTERNATIONAL BUSINESS MACHINES IBM IBM Rational Unified Process IBM International Business Machines 2009 Disponivel lt http www 01 ibm com software awdtools rup gt Acesso em 14 de Novembro de 2009 ISO IEC 12207 12207 2008 E Systems and software engineering Software life cycle processes Site da ISO International Organization for Standardization 2008 Disponivel em lt http www iso org iso iso_catalogue catalogue_tc catalogue_detail htm csnumber 43447 gt Acesso em 4 de Novembro de 2009 A MACHADO C A F WEBER K C
43. empresas Site do SEBRAE Jo o Pessoa 19 de Maio de 2005 Disponivel em lt http www sebrae com br customizado estudos e pesquisas integra_bia ident_unico 97 gt Acesso em 06 de Outubro de 2009 SIM O 1 VARELA P A Engenharia de Requisitos como processo inovador nas organiza es Site da RUN Reposit rio Universidade Nova Monte de Caparica Julho 2009 Disponivel em lt http dspace fct unl pt bitstream 10362 1972 1 WPSeries 08 2009ISimao_PVarela B pdf gt Acesso em 26 de Outubro de 2009 SOFTEX MPS BR capacita o e empreendedorismo Guia de Implementa o Parte 9 Implementa o do MR MPS em organiza es do tipo F brica de Software 02 Outubro 2009 ISSN ISBN 978 85 99334 16 4 Disponivel em lt http www softex br mpsbr guias guias MPS BR Guia de Implementacao Parte 209 pdf gt Acesso em 12 de Outubro de 2009 SOMMERVILLE Engenharia de Software 6 ed S l Addison Wesley 2001 42 54 p UENO M www assespro org br Site da ASSESPRO Associa o das Empresas de Tecnologia da Informa o Software e Internet Abril 2007 Disponivel em lt http www assespro org br images pati pdf gt Acesso em 12 de Outubro de 2009 WIKIP DIA A ENCICLOP DIA LIVRE IBM Rational Unified Process Site Wikip dia a enciclop dia livre 2009 Disponivel em lt http pt wikipedia org wikiIBM Rational Unified Process gt Acesso em 2009 de Novembro de 14 WIKIP DIA A ENCICLOP DIA LIVRE Modelo Casc
44. imagem e um texto que dar uma breve explica o do que se trata este modelo junto com os requisitos e os modelos de caso de uso relacionados 2 3 lt UM GRUPO DE MODELOS gt Conforme necessidade os modelos podem ser agrupado de forma a garantir o melhor entendimento do leitor 2 3 1 lt Um modelo do grupo gt O modelo apresentados aqui ter suas caracter sticas que o identificar o com o grupo que est inserido Os modelos seguir o o padr o de descri o dos modelos anteriores 2 3 2 lt Outro modelo do grupo gt O modelo apresentados aqui ter suas caracter sticas que o identificar o com o grupo que est inserido Os modelos seguir o o padr o de descri o dos modelos anteriores AP NDICE C 9 MATRIZ DE RASTREABILIDADE 207 lt Nome do projeto gt lt Nome da Empresa gt _ Hist rico de Revis es lt Slogan gt Vers o lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt Data Vers o Descri o Autor dd mm aaaa M N Descreva as altera es feitas no documento Nome da pessoa que realizou a altera o no documento AP NDICE C 10 LISTA DE RISCOS lt Nome do projeto gt Lista de Riscos 211 lt Nome da Empres lt Slogan gt Vers o lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt N Descri o Probabilidade 2 Data do Risco de Ocorr ncia Impacto Status Respons vel dd mm aaaa Descreva Atla M dia Atla
45. incerteza intervalo da estimativa de programa o da equipe dos projetos 11 5 RELEASE ALVO Registra a vers o planejada do produto em que o recurso aparecer pela primeira vez Este campo pode ser usado para alocar recursos de um documento de vis o em um release de baseline espec fico Quando for usado em conjunto com o campo de status sua equipe poder propor registrar e discutir v rios recursos do release sem que tenham que ser necessariamente desenvolvidos Somente ser o implementados os recursos cujo Status estiver definido como Incorporado e cujo Release alvo estiver definido Quando ocorrer o gerenciamento do escopo o N mero da Vers o do Release alvo poder ser aumentado de modo que o item permane a no documento Vis o mas seja programado para um release posterior AP NDICE C 3 GLOSS RIO lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt GLOSS RIO VERS O 1 139 Hist rico de revis o Data Vers o Descri o Autor 141 SUM RIO 1 GLOSSARIO dd 143 A Eee see ernten 143 1 2 FINA DAD aid ri 143 1 3 Xu u 143 1 4 REFERENCIAS A 143 1 5 MISA A 143 2 DEEINICOESE 2 143 2 1 lt UM 144 2 2 lt OUTRO TERMO gt een 144 2 3 lt UM GRU
46. interactive incremental spiral agile and frameworks RUP on the subject today so that the reader will have a greater intimacy with the terms and techniques that will be used throughout the text At the end the reader will have acquired a load of knowledge that will provide you understand the goals and methods used in the process comprehensively They will also have a hand in the process of developing software that will show ways of how to best leverage their resources by providing an increase in service quality and productivity of the company as a whole SUM RIO 1 INTRODU O uns EE iaa 5 1 1 SITUA O ENCONTRADA ess ee 7 1 2 JUSTIFICATIVA 8 1 3 OBJETIVOS GERAIS a scenes neueren 8 1 4 OBJETIVOS ESPEC FICOS io 9 1 5 FUNDAMENTA O TE RICA cocoococccccccccocncncnncncncnnononnn nono no nonnnn rn nono nnncncncnns 9 2 MICRO E PEQUENAS EMPRESAS DE SOFTWARE 13 2 1 MERCADO cia 13 2 2 PEAFIL DAS EMPRESAS 14 23 ORGANIZA O at 14 2 3 1 Colaboradores incio rana 15 2 4 PROBLEMAS DA EMPRESA DE DESENVOLVIMENTO 15 3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 17 3 1 DEFINI O DE 2 17 3 2 DEFINI O DE PROCESSO DE 17 3 3 MODELOS
47. isso desenvolvidos Diagramas Endidade Relacionamento DER em seguida os Diagramas Entidades Relacionais ER e por Consulte o Ap ndice C para saber os detalhes o Plano de Projeto e outros artefatos 33 fim defini o de um dicion rio de dados Estes podem fazer parte de um novo banco de dados ou serem integrados a outro A terceira e ltima atividade desta fase a codifica o nesse passo que s o traduzidas todas as especifica es arquiteturais e de banco de dados para uma linguagem de programa o resultando no c digo fonte ou build da solu o 4 2 5 Fase de Teste Esta fase respons vel por definir como ser o realizados todos os testes necess rios para garantir o bom funcionamento e aceita o da nova solu o de software que poder ser integrada a outra solu o existente ou um novo software Alguns dos testes propostos s o descritos abaixo e Teste de integridades dos dados e Teste de interface com o usu rio e Teste de seguran a e Teste de funcionamento e Teste de aceita o e Teste de integra o De forma geral ap s a realiza o de todos os testes sobre as funcionalidades ou solu es em caso de aprova o elas devem seguir para a pr xima fase caso sejam identificadas irregularidades ser o encaminhadas juntamente com relat rio de irregularidades para a fase e atividade respons vel por corrigir o erro detectado Para complementar o entendimento sobre as ati
48. j deve possuir conhecimento sobre os requisitos sobre o ambiente onde a solu o ser desenvolvida testada e utilizada sobre os recursos necess rios para a execu o do projeto or amento prazos sobre como se pretende desenvolver os requisitos etc Assim ele tem embasamento suficiente para criar um bom Plano de Projeto que seja satisfat rio em prazo e vi vel em termos de custo O respons vel por essa atividade o Gerente de Projetos que ir desenvolver o Plano de Projeto de Software Esse documento ir reunir informa es referentes recursos f sicos e humanos a serem utilizados no decorrer do desenvolvimento do projeto bem como os prazos e metas a serem atingidas pela equipe 4 5 3 2 Preparar ambiente de desenvolvimento Esta atividade descreve como deve ser feita a prepara o do ambiente de desenvolvimento de um software A prepara o que ser realizada pelo Gerente de Projetos envolve tanto recursos humanos como materiais Os recursos humanos s o a aloca o de funcion rios para determinadas atividades e ou a contrata o de novos ou capacita o Os recursos materiais s o todos os equipamentos de hardware computacional e escrit rio incluindo se tamb m as ferramentas de software ou qualquer outro recurso necess rio para o desenvolvimento adequado do processo 51 4 5 4 Atividades da fase de desenvolvimento Nesta fase s o descritas todas as atividades necess rias para o desenvolvimento t cnic
49. mensura o de requisitos Aqui o Analista de Requisitos deve 49 identificar os riscos de implementa o observando aspectos de tempo possibilidade de desenvolvimento no cen rio atual e viabilidade Um ou mais desenvolvedores devem participar da mensura o dando para todos os requisitos um n mero de pontos horas de trabalho A ideia de mensurar os requisitos em pontos funciona da seguinte maneira apresentada a especifica o de um requisito caso de uso para um desenvolvedor atrav s de leitura ou apresenta o gr fica Em seguida de acordo com o entendimento dele em rela o ao desenvolvimento ser o atribu das tr s notas i a quantidade de pontos necess rias no pior caso de desenvolvimento do requisito ou seja quando o desenvolvedor n o tem experi ncia e o problema pode ser mais complicado do que o que parece ii a quantidade normal de pontos para ele desenvolver os requisitos e iii no melhor caso a quantidade de pontos necess rias para ele desenvolver os requisitos tendo em vista que tudo ocorrer sem interfer ncias e ele j tenha experi ncia em uma solu o id ntica ou bem parecida com a apresentada Vale ressaltar que esse tipo de mensura o apenas uma sugest o Na pr tica podem ser adotadas v rias outras formas de mensurar os requisitos 4 5 2 5 Definir diretrizes de teste Aqui est o definidas as formas de realiza o dos testes sobre os requisitos da solu o Assim o Analista
50. para as funcionalidades elicitadas e principalmente na fase de teste de software elaborando o plano de teste de software e solicitando mudan as Ele executar os testes definidos no plano de testes e agrupara os resultados no plano de testes onde ser o analisados e processados conforme descrito no plano de testes 4 Atribui es A Artefatos do papel gt Definir diretrizes de teste w Plano de teste v Elaborar plano de teste Y Solicita es de mudan a Criar solicita es de mudan as v Analisar relat rios de teste Realizar testes 4 T tulos Caracter sticas Exigidos w Saber trabalhar em equipe w Curso superior em tecnologia da informa o Compet ncia Y Experi ncia de um ano como analista de teste w Boa comunica o interpessoal Facilidade para identificar solu es Capacidade para sugerir boas solu es Desejados Especializa o em teste de software Y Especializa o em qualidade de software AP NDICE B 7 ANALISTA DE SUPORTE 97 Processo de desenvolvimento 1 E Detalhamento do Papel Analista de Suporte Descri o O papel de analista de suporte deve ser atribu do a uma pessoa capaz de realizar treinamento sobre sistemas computacionais ou empresariais Ele deve ser comunicativos e ter boa rela o com clientes O analista de suporte desenvolve e realiza todos os treinamentos necess rios para a utiliza o correta da solu o de software
51. pessoas julgado atrav s do interesse artefatos e responsabilidades do papel nas atividades do processo 2 4 PROBLEMAS DA EMPRESA DE DESENVOLVIMENTO O principal problema enfrentado pela empresa ainda n o aberta oficialmente que desenvolve o Sistema para Gerenciamento de Credi rios a organiza o das atividades para o desenvolvimento e um bom produto de software Assim como nas empresas brasileiras de software ela possui conhecimento t cnico sobre v rias tecnologias Dessa forma a equipe de desenvolvimento corre o risco de se confundir Cada um dos estados brasileiros reajusta a sua tabela de acordo com as caracter sticas do mercado local 16 na hora de desenvolver as atividades de produ o do software por que os integrantes dela n o sabem em que momento deve se especificar qual parte do software produzido e que atividade deve ser mais intensa para garantir que o problema do cliente ser resolvido de fato Assim observa se que o principal problema n o est no conhecimento ou aprendizado da equipe e sim na sistematiza o das atividades que levam a constru o de um produto de software vi vel para as duas pontas empresa e cliente 17 3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Esta se o mostrar em mais detalhes uma proposta para defini o nesse contexto de processo gen rico de software Em seguida complementa se a ideia mostrando os modelos mais citados pelas bibliografias consultadas e a
52. poder gerar confus o para o leitor Para resolver o problema utilizamos agrupamentos de termos Ao apresentar os agrupamentos de termos forne a uma breve descri o que ajude o leitor a compreender o que lt Um grupo de termos gt representa Os termos apresentados no grupo dever o ser organizados alfabeticamente para possibilitar um f cil acesso 1 8 1 lt Um sub grupo de termo gt A defini o de lt Um sub grupo de termo gt apresentada aqui Apresente quantas informa es forem necess rias para que o leitor compreenda o conceito 1 8 2 lt Outro sub grupo de termo gt A defini o de lt Outro sub grupo de termo gt apresentada aqui Apresente quantas informa es forem necess rias para que o leitor compreenda o conceito 145 1 9 lt UM SEGUNDO GRUPO DE TERMOS gt 1 9 1 lt Mais um sub grupo de termos gt A defini o do termo apresentada aqui Apresente quantas informa es forem necess rias para que o leitor compreenda o conceito 1 9 2 lt Outro sub grupo de termo gt A defini o do termo apresentada aqui Apresente quantas informa es forem necess rias para que o leitor compreenda o conceito AP NDICE C 4 REGRAS DE NEG CIO lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt REGRAS DE NEG CIO VERS O 1 151 Hist rico de revis o Data Vers o D
53. possua uma organiza o de atividades eficiente ela precisa definir quem faz o que Por isso antes da apresenta o das atividades todos os pap is ser o definidos expondo suas responsabilidades atribui es e apontando suas caracter sticas mais importantes 36 importante frisar nesse momento sobre a terminologia utilizada nas pr ximas se es para denominar os pap is e artefatos definidos aqui Assim quando forem citados nomes de pap is ou artefatos eles ter o a primeira letra escrita em mai sculo por exemplo a diferen a entre Cliente e cliente que o primeiro faz refer ncia o papel definido no Prumo e o segundo representa uma pessoa qualquer que procura uma empresa em busca de solu es produtos ou servi os 4 3 1 Cliente Este papel representa a pessoa que entende a regra de neg cio da empresa a qual se destina a solu o podendo ser representado por uma ou mais pessoas dependendo do projeto e da necessidade Nesse caso ele pode ser dividido em dois perfis Cliente Interno e Cliente Externo onde cada uma das pessoas apresentar caracter sticas e responsabilidades pertencentes a um ou outro perfil Em todos os casos eles possuir o as mesmas atribui es O primeiro perfil analisado o Cliente Interno representado por um colaborador da empresa de desenvolvimento Geralmente este perfil pode possuir poucos conhecimentos t cnicos em inform tica por m possui boas habilidades para e
54. possuir uma lista de poss veis riscos e junto a eles um plano de a o preventiva ou corretiva caso um deles venha a se concretizar chamado plano de conting ncia Esta lista de riscos pode ser organizada da forma mais conveniente poss vel de acordo com as considera es do Gerente de Projetos Um exemplo seria organiz la em um nico documento denominado Lista de Riscos contendo os riscos e suas principais caracter sticas O documento Gest o de A es Corretivas ajuda no controle e nas medidas a serem tomadas nos desvios que acontecem durante o projeto al m de possibilitar que tais desvios possam ser evitados nas itera es futuras Outro artefato que tamb m de responsabilidade deste papel s o os Contratos Assim um Gerente de Projetos tamb m interage com o Cliente realizando negocia es e firmando os contratos O Prumo n o define nenhum modelo de contrato Portanto devem ser definidos contratos de acordo com o servi o a ser prestado ao cliente Em se tratando de experi ncia n o necess rio que ele possua conhecimento t cnico na tecnologia trabalhada embora isto adicione certa import ncia Ele deve ser l der realizar planejamentos concretos e acompanhar o trabalho e o projeto 4 3 4 Arquiteto de Software Ao papel Arquiteto de Software s o atribu das a lideran a e a coordena o das atividades t cnicas no decorrer do projeto O Arquiteto de Software tamb m estabelece a estrutura geral de cada
55. rias adequada interpreta o da SRS Essas informa es podem ser fornecidas mediante refer ncia ao Gloss rio do projeto 1 5 REFER NCIAS Esta subse o fornece uma lista completa de todos os documentos mencionados em qualquer outra parte da SRS Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 1 6 VIS O GERAL Esta subse o descreve o que o restante da SRS cont m e explica como o documento est organizado 2 REQUISITOS FUNCIONAIS Requisitos funcionais de um software indicam as funcionalidades desenvolvidas visando a resolu o de um problema Neste documento eles s o identificados pelo prefixo RF seguido de um numero seg encial entre colchetes como por exemplo RF0001 Os identificadores dos requisitos n o devem ser reiniciados a cada subse o Este n mero sequencial n o deve ser modificado ou reaproveitado para n o invalidar refer ncias externas feitas a eles 2 1 RF001 NOME DO PRIMEIRO REQUISITO Uma descri o detalhada do requisito 1 Tamanho Pior caso Caso normal Melhor caso Prioridad Essencial O Importante O Desej vel 2 2 RF002 NOME OUTRO REQUISITO Uma descri o detalhada do requisito RFOO2 Tamanho Pior caso Caso normal Melho
56. 1 A PRECONDICOES nennen a ad 192 4 1 lt PRECONDICAO UM gt HE ee 192 5 POS CONDICOES ta dado ee a it it dE 193 5 1 lt P S CONDICAO UM gt 193 6 PONTOS DE EXTENSAQO U u uuu 194 6 1 lt NOME DO PONTO DE EXTENS O eee 194 187 ESPECIFICA O DE CASO DE USO lt NOME DO CASO DE USO gt O template a seguir fornecido para uma especifica o de caso de uso que cont m as propriedades textuais do caso de uso Os diagramas de caso de uso podem ser desenvolvidos em uma ferramenta de modelagem visual assim como um relat rio de caso de uso com todas as suas propriedades 188 1 NOME DO CASO DE USO 1 1 BREVE DESCRICAO A descri o relata brevemente o papel e a finalidade do caso de uso 189 2 FLUXO DE EVENTOS 2 1 FLUXO BASICO Este caso de uso iniciado quando o ator pratica alguma a o Os casos de uso sempre s o iniciados por atores O caso de uso descreve o que o ator faz e o que o sistema faz em resposta Ele deve ser elaborado como um di logo entre o ator e o sistema caso de uso descreve o que ocorre no sistema mas n o como ou por qu Se forem trocadas informa es seja espec fico no que diz respeito ao conte do que passado e retornado Por exemplo n o muito esclarecedor dizer que o ator fornece informa es do cliente melhor dizer que ele fornece o nome e o endere o do cliente til fazer uso de um Gloss rio de Termos para manter
57. 2 QUIERO RECURSO sre ee 127 6 1 3 11 06 128 7 FAIXAS DE QUALIDADE EE 129 8 PRECED NCIA E PRIORIDADE I U u uuu uuu 130 9 OUTROS REQUISITOS DO PRODUTO eternas 131 91 PADR ES APLICA VE Si a OS 131 9 2 REQUISITOS DO SISTEMA eee 131 9 3 REQUISITOS DE DESEMPENHO cccoicicccococinoncncnnononcnnnnnnnonon cono nononcncnnnnons 131 9 4 REQUISITOS AMBIENTAIS eretas 131 10 REQUISITOS DA DOCUMENTACAQO u uuu 132 10 1 MANUAL DO USUARIO so saciar eating 132 102 AJUDA ON MING aa nas uuu mY 132 10 3 GUIAS DE INSTALA O E DE CONFIGURA O E ARQUIVO LEIAME 132 10 4 ROTULAGAO E 132 11 ATRIBUTOS DE RECURSOS I uuu uuu 133 111 STATUS A as s u Ra QQ ana NN 133 11 22 BENE nasyunninman ss nsn Las Das 133 113 ESFOR O rn an E to ua bans 133 ME RISCO A 134 11 5 RELEASE ALVO 134 1 VIS O 1 1 INTRODU O A finalidade deste documento coletar analisar e definir as necessidades e caracter sticas de n vel superior do lt lt Nome do Sistema gt gt Ele se concentra nos recursos necess rios aos envolvidos e aos usu rios alvo e nas raz es que levam a essas necessidades Os detalhes de como o lt lt Nome do Sistema gt gt atende a essas necessidades est o descritos nas especifica
58. 5 p 4 Passados alguns anos de crise o software come ou a reagir a partir de um quadro cr tico evoluindo cada vez mais atrav s de novas t cnicas de desenvolvimento que surgiam a cada ano em meados da d cada de 90 A ado o s novas pr ticas de desenvolvimento de software era percept vel e com a populariza o da Internet a distribui o desses conhecimentos ganhou o mundo rapidamente Assim v rias na es come avam a identificar se na produ o de tipos espec ficos de software Os Estados Unidos na produ o de software standard a Europa se tornava l der dos softwares customizados e o Jap o na produ o de solu es para o setor financeiro e jogos eletr nicos Entre essas e outras raz es que as pessoas come aram a dar o pontap inicial na cria o de uma nova empresa para desenvolvimento de solu es de software Ent o grupos de estudantes curiosos e pessoas com experi ncia adquiridas em empresas privadas come aram a organizar seus conhecimentos para produzir tecnologia e novas solu es para o mundo Engloba aqueles em que h possibilidade de instala o pelo pr prio usu rio FILHO HOCHSTETLER et al 2006 p 5 2 Nesse caso pode ter a mesma defini o de software sob demanda aquele que desenvolvido de acordo com as especifica es de um determinado cliente FILHO HOCHSTETLER et al 2006 p 5 Nesse ritmo pequenas empresas de desenvolvimento abriam suas portas a todo o mo
59. ASPER ASSOCIA O PARAIBANA DE ENSINO RENOVADO COORDENA O DE CI NCIAS DA COMPUTA O VALBERTO VIEIRA CARNEIRO VANJHONY COSMO DA SILVA AM NCIO YGOR MIKASSIO DUARTE LINS PROCESSO DE DESENVOLVIMENTO DE SOFTWARE UM ESTUDO PR TICO PARA MICRO E PEQUENAS EMPRESAS DE TI JO O PESSOA 2009 VALBERTO VIEIRA CARNEIRO VANJHONY COSMO DA SILVA AM NCIO YGOR MIKASSIO DUARTE LINS PROCESSO DE DESENVOLVIMENTO DE SOFTWARE UM ESTUDO PR TICO PARA MICRO E PEQUENAS EMPRESAS DE TI Trabalho de conclus o de curso apresentado Associa o Paraibana de Ensino Renovado como requisito parcial para a obten o do t tulo de Bacharel em Ci ncias da Computa o Orientador Maxwell Anderson 1 Amaral JO O PESSOA 2009 Ficha catalogr fica VALBERTO VIEIRA CARNEIRO VANJHONY COSMO DA SILVA AM NCIO YGOR MIKASSIO DUARTE LINS PROCESSO DE DESENVOLVIMENTO DE SOFTWARE UM ESTUDO PR TICO PARA MICRO E PEQUENAS EMPRESAS DE TI Aprovado em de de BANCA EXAMINADORA Componente da banca Institui o Componente da banca Institui o Componente da banca Institui o Valberto Dedico este trabalho minha m e Eliete que me acompanha durante toda a minha vida com amor e perseveran a Tamb m dedico minha professora e amiga Josemary pela contribui o profissional que sempre me ajudou a crescer em todas as esferas da vida Ygor Agrade o aos meus pais que sempre me incentivaram e me aju
60. Acompanhado aqui o risco Baixa M dia N o observado Baixa acompanhado 1 Deixou de existir 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 AP NDICE C 11 PLANO DE PROJETO lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt PLANO DE PROJETO VERS O 1 217 Hist rico de revis o Data Vers o Descri o Autor 219 SUM RIO 1 PLANO DE PROJETO DE SOFTWARE 221 il INTRODU O L aS at kasa E QY anata 221 daa PROPOSTO a kS Wa Sua Swan a ue 221 1 3 FOGOPO ee a E dd 221 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 221 1 5 REFERENCIA Ense Ea E 221 16 VIS O GERAL a au aa kaa aa aaa aa 221 2 nn 222 2 1 PROP SITO DO PROJETO ESCOPO E OBJETIVOS 222 2 2 PREMISSAS E RESTRI ES eternas 222 2 3 ARTEFATOS DO PROJETO da NER aa 222 2 4 EVOLU O DO PLANO DE DESENVOLVIMENTO DE SOFTWARE 222 3 ORGANIZA O DO PROJETO U uuu uu Q 223 3 1 ESTRUTURA ORGANIZACIONAL Lt 223 3 2 CONTATOS EXTERNOS ES naar 223 3 3 PAP IS E RESPONSABILIDADES 223 4 GERENCIAMENTO DO PROJUJETO 224 4 1 ESTIMATIVAS DO
61. CE C 17 PLANO DE TREINAMENTO lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt PLANO DE TREINAMENTO VERS O 1 Hist rico de revis o Data Vers o Descri o Autor SUM RIO 1 1 1 1 2 1 3 1 4 1 5 1 6 1 7 O Q ab PLANO DE TREINAMENTO I uu uuu 319 A 319 PERIODO see 319 Ao AAA AAA 319 OBJETIVO at a 319 GESTOR Mana 319 E EEE 319 PRODUTO aso sau os 319 DESAFIOS 320 IMPACTOS unan 321 FASES DO TREINAMENTO OPCIONALL U a u 322 323 RELAT RIO DO TREINAMENTO I u uuu 325 CONCLUS O o ta o ee 326 1 PLANO DE TREINAMENTO 1 1 INTRODU O Forne a uma vis o geral do documento inteiro 1 2 PER ODO Colocar o per odo de treinamento com data de previs o do termino 1 3 ESCOPO Breve descri o da utilidade do documento do que afetado e ou influenciado por ele 1 4 OBJETIVO Descri o do objetivo a ser alcan ado 1 5 GESTOR Respons vel pelo documento de Plano de Treinamento e pelo treinamento 1 6 CLIENTE Empresa pessoa ou institui o que ir receber o treinamento 1 7 PRODUTO Produto que ser passado para o cliente durante o trei
62. DADE aida alan 174 3 1 1 RNF001 Primeiro requisito nao funcional de usabilidade 174 3 1 2 RNF002 Segundo requisito n o funcional de usabilidade 174 3 2 CONFIABILIDADE 0 00 00 174 3 2 1 RNF003 Primeiro requisito n o funcional de confiabilidade 175 3 2 2 RNF004 Segundo requisito nao funcional de confiabilidade 175 3 3 DESEMPENHO cco u aa 175 3 3 1 RNF005 Primeiro requisito n o funcional de desempenho 175 3 3 2 RNF006 Segundo requisito nao funcional de desempenho 175 3 4 INTERFAGES u upa a augu mamapas sasa Qa amu una s u sasa 175 3 4 1 Interfaces do Usuarig a s u uuu uu ti n 176 3 4 2 Interfaces de Hardware EE 176 3 4 3 Interfaces de Software 176 3 4 4 Interfaces de Comunicac ao 176 4 ESCOPO NEGATIVO csi 177 1 ESPECIFICA O DOS REQUISITOS DO SOFTWARE 1 1 INTRODU O A introdu o da Especifica o de Requisitos de Software SRS fornece uma vis o geral de toda a SRS Ela cont m a finalidade o escopo as defini es os acr nimos as abrevia es as refer ncias e a vis o geral da SRS Observa o A SRS captura todos os requisitos de software do sistema ou de uma parte do sistema A seguir h um esquema de uma SRS t pica para um projeto que utiliza
63. PO DE TERMOS a ata 144 2 3 1 lt Um sub grupo de lermos ES 144 2 3 2 lt Outro sub grupo de termo gt U T 144 2 4 lt UM SEGUNDO GRUPO DE TERMOS gt u ann 145 2 4 1 lt Mais um sub grupo de termos T T 145 2 4 2 lt Outro sub grupo de termo gt U T 145 143 1 GLOSSARIO 1 1 INTRODU O A introdu o do Gloss rio fornece uma vis o geral de todo o documento Apresente todas as informa es que poder o ser necess rias para que o leitor compreenda o documento nesta se o Este documento usado para definir a terminologia espec fica do dom nio do problema explicando termos que podem ser desconhecidos do leitor das descri es de caso de uso ou de outros documentos do projeto Frequentemente este documento poder ser usado como um dicion rio de dados informal capturando defini es de dados para que as descri es de caso de uso e outros documentos do projeto possam concentrar se no que o sistema deve fazer com as informa es Este documento dever ser salvo em um arquivo denominado Gloss rio 1 2 FINALIDADE Especifique a finalidade deste Gloss rio 1 3 ESCOPO Uma breve descri o do escopo deste Gloss rio a que Projeto s ele est associado e tudo o mais que seja afetado ou influenciado por este documento 1 4 REFER NCIAS
64. PROJETOS 81 Processo de desenvolvi Detalhamento do Papel Gerente de Projetos Descri o Representa um lider Uma pessoa habilitada para assumir este papel deve ter habilidade para liderar equipes de projeto Acompanha todas atividades do processo e realiza as negocia es com o cliente Um gerente de projeto n o necessariamente deve ter conhecimentos t cnicos para que possa exercer eficientemente suas atividades dentro da empresa 4 Atribui es A Artefatos do papel gt Liderar a equipe de desenvolvimento de solu es Contratos pl Adequar a equipe ao projeto Y Planos de Projeto de Software Criar Planos de Projeto vo nto de Ri w Realizar negocia es junto ao cliente ay zu Preparar ambiente da empresa para acomodar os projetos w Providenciar recursos materiais Hardware e Software Gest o de A es Corretivas 4 T tulos Caracter sticas Exigidos w Habilidade para liderar equipes w Curso superior em tecnologia da informa o ou v Boa comunica o interpessoal administra o Comunicativo Y Experi ncia de um ano como Lider de equipe ou gerente de Receptivo projetos Saber ouvir os integrantes da equipe w Capacidade de estimular o trabalho em equipe Desejados Y Ter conhecimento em gerenciamento de projetos com PMBOK e ou CMMI Y Ter especializa o em ger ncia de projetos de software AP NDICE B 4 ARQUITETO DE SOFTWARE 85
65. Processo de desenvolvi Detalhamento do Papel Arquiteto de software Descri o Este papel representa a pessoa capaz de definir a arquitetura de uma solu o de software Ele deve ter conhecimento sobre padr es de projeto e implementa o de software um exemplo seria UML al m de conhecer v rias tecnologias e frameworks O arquiteto de software conhece ferramentas que auxiliam no desenvolvimento de um bom software 4 Atribui es A Artefatos do papel gt Desenvolver diagramas de atividade w Plano de Arquitetura de Software Desenvolver diagramas de classe Y Modelo de Implementa o Desenvolver diagramas entidade relacionamento Y Desenvolver tabelas de bancos de dados O Y Desenvolver plano de integra o se necess rio Identificando subsistemas e analisando os pontos de Integra o 4 T tulos Caracter sticas Exigidos Y Compet ncia w Curso superior em tecnologia da informa o v Boa comunica o interpessoal Experi ncia de um ano como analista de sistemas ou Capacidade para trabalhar e ou liderar equipes arquiteto de software w Capacidade de desenvolver boas solu es Desejados v Especializa o em an lise e desenvolvimento de sistemas Y Certifica es e ou comprova o de conhecimento em an lise e desenvolvimento de sistemas AP NDICE B 5 DESENVOLVEDOR 89 Processo de desenvolvimento 1 Detalhamento do Papel Desenvolvedor Descri
66. Qualidade e Produtividade em Software S o Paulo Makron Books 2001 MELO C D O Reutilizacao de Software Classifica o e Sele o de Artefatos Reutiliz veis Site do Instituto de Matem tica e Estat stica da USP S o Paulo 25 de Junho de 2004 Disponivel em lt http www ime usp br yw 2004 mac5701i monografias claudia acvm pdf gt Acesso em 28 de Outubro de 2009 MPS BR Implementac o do MPS BR em organizac es do tipo f bica de software Guia de Implementac o Parte 9 2009 14 de Novembro de 2009 4 6 PRESSMAN R S O papel evolutivo do software Traduc o de Carlos Barbosa Santos S o Paulo Makron Books do Brasil Editor Ltda 1995 4 6 p ISBN ISBN 8586804576 PRESSMAN R S Engenharia de Software 6 ed S McGraw Hill 2006 17 55 p ISBN 8586804576 PROCESSO de Desenvolvimento de Software Wikip dia a enciclop dia livre 17 de Outubro de 2009 Disponivel em lt http pt wikipedia org wiki Processo de desenvolvimento de software gt Acesso em 26 de Outubro de 2009 RATIONAL SOFTWARE CORPORATION Artefato Ator Site da Wthreex 2002 Disponivel em lt http www wthreex com rup process artifact ar_actor htm gt Acesso em 5 de Novembro de 2009 61 RATIONAL SOFTWARE CORPORATION Papel Arquiteto de Software Site da WThreex 2002 Disponivel em lt http www wthreex com rup portugues index htm gt Acesso em 31 de Outubro de 2009 SEBRAE Crit rios e conceitos para classifica o de
67. TIFICATIVA Tendo em vista este problema torna se clara a necessidade enfrentada pelas micro e pequenas empresas brasileiras de tecnologia da informa o que n o possuem ainda um processo definido para o desenvolvimento dos seus produtos e servi os Na maioria dos casos boas oportunidades aparecem mas v o embora quando exigido mais qualidade do produto de software A proposta apresentada aqui se originou a partir da necessidade observada por um grupo de universit rios graduandos em Bacharelado em Ci ncias da Computa o que pretendem abrir uma empresa de software O grupo trabalhava no desenvolvimento de um software comercial para empresas no interior da Para ba que necessitava de uma boa organiza o para a execu o de suas atividades de desenvolvimento A partir disto foi desenvolvido o Prumo organizado para atender as necessidades da equipe observando se tamb m as necessidades do cliente 1 3 OBJETIVOS GERAIS O objetivo principal produzir um processo de software adaptado para micro e pequenas empresas brasileiras de tecnologia que necessitem de uma sistematiza o de suas atividades objetivando uma melhoria principalmente na qualidade dos produtos e servi os Desta forma os objetivos gerais s o e Atender s demandas de mercado de software em busca de processos mais adequados realidade das micro e pequenas empresas e Fazer uma jun o das melhores pr ticas dos processos do RUP e MPS BR e Escla
68. Terceira atividade En sima atividade Parecer do relator lt Cidades gt 12 de March de 2010 Assinatura do cliente Assinatura do Analista de Suporte 7 CONCLUS O Ap s o treinamento dever ser escrita a conclus o onde dever ser colocado tudo que for relevante os de forma a melhorar pr ximos treinamentos AP NDICE C 18 GEST O DE A ES CORRETIVAS 329 lt Nome do projeto gt lt Nome da Empresa gt Gest o de a es corretivas gerente do lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt projeto Fase Desvio Descri o do desvio Prioridade Respons vel Fase da Onde Descri o do desvio Alta M dia Nome do ocorr ncia ocorreu o Baixa respons vel desvio pela ocorr ncia do desvio Impact Data da o ocorr ncia Impact dd mm aaaa o causad o pelo desvio Status Corrigid o aberto Escalado para lt cargo superior gt A o corretiva Descri o de qual a o tomada quando o desvio ocorrer Respons vel pela a o Respons vel pela a o 330 Observa Prazo es dd mm aaa a AP NDICE C 19 LISTA DE VERIFICA O DA QUALIDA lt Nome do projeto gt Lista de verifica o de 333 qualidade Data da verifica o Informa es Gerente de Projetos Auditor Fase verificada Auditor Fases do ciclo de vida Artefato Sigla 1 Primeira Siglo 2 Fas
69. UMENTO DE ARQUITETURA DE SOFTWARE 229 AP NDICE C 13 MODELO DE IMPLEMENTA O 249 AP NDICE C 14 PLANO DE INTEGRA O DO BUILD 261 AP NDICE C 15 PLANO DE TESTE pe 273 AP NDICE C 16 PLANO DE IMPLANTA O 299 AP NDICE C 17 PLANO DE TREINAMENTO 311 AP NDICE C 18 GEST O DE A ES CORRETIVAS 327 AP NDICE C 19 LISTA DE VERIFICA O DA QUALIDA 331 1 INTRODU O Como parte dos acontecimentos naturais sobre a Terra sua evolu o tem sido observada por v rios estudiosos e pesquisadores no mundo inteiro Na era da informa o esta evolu o n o poderia ser diferente Durante a d cada de 80 quando o desenvolvimento de novas arquiteturas de computadores priorizava o aumento da capacidade de processamento e os custos de produ o eram o foco dos pesquisadores surgiam v rios rumores sobre a crise de software Jornais em v rias partes do mundo anunciavam a decad ncia dos softwares produzidos Nesse contexto as pessoas come avam a observar que profundas mudan as na sociedade estariam por vir Naisbitt previu a transforma o da sociedade industrial em uma sociedade da informa o gerando profundos impactos sobre as pessoas no mundo contempor neo PRESSMAN 199
70. a a o a ser executada gt lt Nome do respons vel gt lt dd mm aaaa gt lt En sima a o a ser executada gt lt Nome do responsdvel gt lt dd mm aaaa gt Observadores lt Nome do presidente da reuni o gt Recursos lt Estrat gica Decis ria Informativa Negocial gt Observa es especiais Leitura necess ria 12 de mar o de 2010 Assinatura do presidente da reuni o AP NDICE C 6 DOCUMENTO DE ESPECIFICA O DE REQUISITOS lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt DOCUMENTO DE ELICITA O DE REQUISITOS VERS O 1 167 Hist rico de revis o Data Vers o Descri o Autor 169 SUM RIO 1 ESPECIFICA O DOS REQUISITOS DO SOFTWARE 171 INTRODU O a er ee 171 1 2 FINALIDADE 22 022 een ee 171 1 3 ESCOR O A A es IE AA 171 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 171 1 5 REFERENCIA e name 172 16 VIS O GERAL a G 172 2 REQUISITOS FUNCIONAIS J 173 2 1 RF001 NOME DO PRIMEIRO 173 2 2 RF002 NOME OUTRO REQUISITO 173 3 REQUISITOS NAO FUNCIONAIS I uuu 174 3 1 USABILI
71. a necess ria para desenvolver a solu o e Analisar a necessidade de treinar a equipe ou contratar pessoal j qualificado para isso fazendo um estudo e verificando a viabilidade de custo e prazo das op es dispon veis e Organizar o ambiente da empresa alocando recursos humanos e materiais de forma que possibilite maior comodidade e agilidade da equipe de desenvolvimento importante observar e ponderar outras caracter sticas que podem surgir em cada ambiente onde o processo empregado ou em cada tipo de solu o desenvolvida Al m disso necess rio identificar todos os riscos que podem vir a modificar o andamento do projeto em quest o e tomar as medidas cab veis para evit los ou gerenci los de maneira que o projeto sofra menos impacto 4 2 4 Fase de Desenvolvimento No ciclo de vida do Prumo esta corresponde a terceira fase Aqui ser o definidas as especifica es arquiteturais banco de dados e codifica o da solu o Um exemplo de especifica o arquitetural atualmente a maioria dos projetos s o definidos seguindo o paradigma de Programa o Orientada a Objetos POO assim sua arquitetura constitu da de classes e organizada em pacotes de funcionalidades Al m disso s o criados v rios diagramas utilizando UML para mostrar o relacionamento entre as classes dentro dos pacotes Outra especifica o importante nesta fase a defini o do esquema de banco de dados para a solu o sendo para
72. a se o processo ter que parar o desenvolvimento de alguma funcionalidade Uma vez mensurados os impactos da solicita o ser o avaliados e os gastos referentes mudan a ser o calculados segundo horas trabalhadas ou utilizando alguma outra t cnica interessante que traga agilidade e precis o na mensura o do esfor o da equipe Em seguida haver uma reuni o com o Cliente onde ser o apresentados os impactos analisados Depois o Gerente de Projetos junto com o Analista de Requisitos ir negociar a viabilidade das altera es com o Cliente sugerindo alternativas e solu es Logo ap s ser o definidas as adi es mudan as ou cancelamentos de funcionalidades ou do projeto como um todo Por ltimo ser executada a mudan a definida na reuni o com o Cliente Caso o ele decida que o projeto seja cancelado ser o apresentados a ele todos os encargos especificados no contrato Caso a solicita o consista em uma mudan a no projeto os documentos ser o atualizados e a equipe ser informada A mudan a solicitada ser analisada com o apoio principalmente da Matriz de Rastreabilidade que identificar quais os impactos que tal mudan a provocar no projeto Eles podem ser exclu dos atualizados ou complementados e acoplados ao projeto ent o ser gerada uma nova solicita o comum a partir da fase de solicita o e o processo seguir naturalmente 4 3 OS PAP IS RESPONSABILIDADES E ARTEFATOS Para que uma empresa
73. a vis o do Modelo de Implanta o No m nimo para cada configura o ela deve indicar os n s f sicos computadores CPUs que executam o software e suas interconex es barramento LAN ponto a ponto etc 5 VIS O DA IMPLEMENTA O Descrever a estrutura geral do modelo de implementa o a divis o do software em camadas e os subsistemas no modelo de implementa o e todos os componentes significativos do ponto de vista da arquitetura 5 1 VISAO GERAL Esta subse o nomeia e define as diversas camadas e o seu conte do as regras que determinam a inclus o em uma camada espec fica e as fronteiras entre as camadas Inclua um diagrama de componentes que mostre os relacionamentos entre as camadas 5 2 CAMADAS Para cada camada inclua uma subse o com o respectivo nome uma lista dos subsistemas localizados na camada e um diagrama de componentes 6 VIS O DE DADOS OPCIONAL Descri o da perspectiva de armazenamento de dados persistentes do sistema Esta se o ser opcional se os dados persistentes forem poucos ou inexistentes ou se a convers o entre o modelo de design e o modelo de dados for trivial 7 TAMANHO E DESEMPENHO Principais caracter sticas de dimensionamento do software que t m um impacto na arquitetura bem como as restri es do desempenho desejado 8 QUALIDADE Uma descri o de como a arquitetura do software contribui para todos os recursos exceto a funcionalidade do sistema ex
74. ade da produ o realizada naquele momento As atividades de valida o ser o executadas na passagem de fase do processo e analisar o os documentos produzidos verificando se obedecem aos padr es da empresa e se possuem algum tipo de inconformidade Essa fase objetiva aumentar a qualidade dos documentos relacionados ao sistema e consequentemente sua pr pria 4 6 2 1 Levantamento do projeto A atividade onde feita a an lise do andamento do projeto se o mesmo est sendo realizado conforme o planejado e se obedece aos padr es de qualidade definidas para O processo e para o produto Tamb m feita uma an lise dos problemas e dificuldades com o fim de evitar que estes venham a ocorrer Essa atividade desenvolvida pelo Analista de Requisitos que observar os problemas que atrapalharam a fase e os principais efeitos causados no processo atrav s da compara o das atividades realizadas e as programadas no plano de projeto de software 4 6 2 2 Avalia o da qualidade O Analista de Qualidade ir revisar as evid ncias para certificar que o processo de os padr es para qualidade do produto estejam sendo observados O objetivo dessa atividade manter a qualidade na constru o do produto e na execu o das atividades conforme observado no processo o que facilitar futuras manuten es e f cil entendimento dos envolvidos no processo 57 4 6 2 3 Reuniao O Analista de Qualidade ir passar sua avalia o acerca da an lis
75. ador tamb m realizar a implanta o da solu o Para isso ele deve realizar um Plano de Implanta o com caracter sticas bem parecida com as de um Plano de Treinamento por m possui uma maior nfase nas especifica es de configura o de hardware e software Ele tamb m respons vel pela emiss o do Comprovante de Implanta o da funcionalidade ou solu o Este artefato n o possui um modelo definido aqui ficando sua a cria o a cargo da empresa de desenvolvimento que aderir ao processo 4 3 8 Analista de Qualidade Este papel representado pela pessoa que realizar as auditorias sobre os artefatos produzidos durante o ciclo de vida do processo Ele observa os artefatos examinando os segundo os padr es estabelecidos pela empresa de desenvolvimento Para melhor desenvolver suas atividades o Analista de Qualidade faz uso da Lista de Verifica o da Qualidade Ela funciona como um checklist possibilitando um maior controle do que foi desenvolvido ou n o Os documentos j criados e verificados s o classificados em e Conforme quando um artefato est por completo aderente s pol ticas de qualidade estabelecidas pela empresa e Nao conforme quando um artefato ou parte dele n o obedece as pol ticas de qualidade da empresa e N o se aplica quando n o se pode classificar um artefato parte dele ou outra caracter stica dentro dos padr es de qualidade estabelecidos e Pendente quando uma
76. ados baseline do produto em um momento espec fico no tempo 11 2 BENEF CIO Definido pelo departamento de marketing pelo gerente do produto ou pelo analista de neg cios Todos os requisitos diferem entre si Classificar os requisitos por seu benef cio relativo para o usu rio final d in cio a um di logo com os clientes analistas e membros da equipe de desenvolvimento Usado no gerenciamento do escopo e na determina o da prioridade de desenvolvimento 11 3 ESFOR O Definido pela equipe de desenvolvimento Como algumas funcionalidades necessitam de mais tempo e de mais recursos do que outras estimar o n mero de semanas de participa o de cada pessoa ou equipe as linhas de c digo necess rias ou os pontos de fun o por exemplo a melhor maneira de avaliar a complexidade e definir expectativas do que poder ou n o ser feito em um determinado per odo de tempo Usado no gerenciamento do escopo e na determina o da prioridade de desenvolvimento 11 4 RISCO Definido pela equipe de desenvolvimento com base na probabilidade de ocorrerem eventos indesej veis no projeto como por exemplo custos excessivos atrasos na programa o ou at cancelamentos A maior parte dos gerentes de projeto considera que a categoriza o dos riscos em altos m dios e baixos suficiente embora sejam poss veis grada es ainda mais espec ficas Freg entemente os riscos poder o ser avaliados indiretamente medindo se o grau de
77. ados para que estejam prontos no devido tempo para a integra o 3 BUILDS A integra o na itera o est dividida em uma s rie de incrementos cada um resultando em um build que testado para verificar a integra o Esta se o especifica os builds que devem ser criados e os subsistemas que far o parte de cada build Para cada build esta se o deve especificar como ele constru do os crit rios para sua avalia o e como ele dever ser testado especificamente e Constru o o Scripts de build e quaisquer outras instru es que descrevem como o build ser constru do o Registros de baseline que definem as vers es dos itens de configura o usados para construir o build e Avalia o e Teste o Crit rios de avalia o uma descri o dos recursos em rela o aos quais o build ser avaliado Esses crit rios poder o incluir um subconjunto dos crit rios de avalia o no Plano de Iterac o correspondente e outros crit rios de avalia o espec ficos do build especialmente quando por exemplo tratar se de um build de arquitetura que n o ofere a muitos ou talvez nenhum recurso que seja vis vel para o usu rio final o Instru es de instala o e configura o para executar e testar o build o Casos de teste procedimentos de teste scripts de teste e resultados de teste Observa o Em todos os casos n o necess rio replicar o material neste plano as refer ncias ser o suficientes se o
78. afeta os recursos especificados no documento Vis o Liste as suposi es que se forem mudadas alterar o o documento de Vis o Por exemplo uma suposi o poder estabelecer que um sistema operacional espec fico estar dispon vel para o hardware projetado para o produto de software Se o sistema operacional n o estiver dispon vel o documento de Vis o dever ser mudado 5 RECURSOS DO PRODUTO Liste e descreva brevemente os recursos do produto Trata se dos recursos de n vel superior do sistema que s o necess rios para propiciar benef cios aos usu rios Cada recurso um servi o desejado externamente que normalmente exige uma s rie de entradas para alcan ar os resultados desejados Por exemplo um dos recursos de um sistema de rastreamento de problemas poder ser a capacidade de fornecer relat rios de tend ncias medida que o modelo de casos de uso for desenvolvido atualize a descri o para fazer refer ncia aos casos de uso Como o documento de Vis o revisado por muitas pessoas envolvidas o n vel de detalhes deve ser geral o suficiente para que todos entendam No entanto devem estar dispon veis detalhes suficientes para fornecer equipe as informa es necess rias para criar um modelo de casos de uso Para gerenciar a complexidade dos aplicativos de maneira eficiente recomend vel para qualquer sistema novo ou para uma adi o que complemente um sistema existente que seja utilizado um grau de abstra
79. ais cada tipo tem permiss o de acesso e Crie testes para cada tipo de usu rio e verifique cada permiss o criando transa es espec ficas para cada tipo de usu rio e Modifique o tipo de usu rio e execute novamente os testes para os mesmos usu rios Em cada caso verifique se as fun es ou dados adicionais est o corretamente dispon veis ou se t m seu acesso negado Estrat gias Descreva uma ou mais estrat gias que podem ser usadas pela t cnica para observar de forma precisa os resultados do teste A estrat gia combina elementos do m todo atrav s do qual a observa o pode ser feita e das caracter sticas dos resultados espec ficos que indicam um prov vel xito ou falha do teste O ideal que as estrat gias sejam autoverificadas permitindo que os testes automatizados fa am uma avalia o inicial do xito ou falha do teste No entanto tenha aten o para reduzir os riscos inerentes determina o autom tica dos resultados Ferramentas Necess rias A t cnica exige as seguintes ferramentas e Ferramenta de Automa o de Scripts de Teste e Ferramentas de investiga o e contra a viola o da seguran a por hackers e Ferramentas de Administra o da Seguran a do Sistema Operacional Crit rios de Exito A t cnica suporta o teste das fun es apropriadas poss vel tamb m que os dados afetados pelas configura es de seguran a sejam testados para cada tipo de ator conhecido
80. ambiente do cliente Planejamentos que levar o cria o dos artefatos Plano de Treinamento e Plano de Implanta o Estes ser o criados atrav s de um ou mais acordos firmados entre o cliente e a empresa de desenvolvimento devidamente documentados na Ata de Reuni o acordos visando suprir as necessidades do cliente em termo de tempo espa o e disponibilidade no ambiente dele 4 5 6 2 Treinar usu rios Esta atividade descreve como devem ser feitos os treinamentos dos usu rios finais para que eles estejam preparados para a implanta o e utiliza o da nova solu o de software Treinar os usu rios da solu o uma tarefa muito importante e deve ser feita antes da implanta o Sabe se que o ser humano naturalmente possui resist ncia mudan a e por isso importante treinar os usu rios de uma solu o antes da utiliza o efetiva Isso necess rio porque geralmente adicionada alguma mudan a nos procedimentos normais de uma atividade que pode passa a ser totalmente ou parcialmente automatizada por um software visando a exclus o ou diminui o de entraves t picos das atividades manuais Assim os treinamentos devem apresentar a nova solu o esclarecer as d vidas dos usu rios at que eles sintam se seguros 54 4 5 6 3 Implantar solu o e dar suporte Esta atividade descreve como ser feita a implanta o da solu o previamente planejada e tamb m do suporte ao cliente No caso da implanta o
81. amento de mudanega J 34 OS PAP IS RESPONSABILIDADES E ARTEFATOS 35 An E E E 36 Analista de Requisitos 37 Gerente de ProjietOS SE 39 Arquiteto de Software usan 39 Desenvolvedor 40 Analista de TOSIOS cases cds u ae 41 Analista de Suporte etc 41 Analista de Qualidade Le 42 CONFROTAMENTO DE PAPEIS 43 Distribuindo pap is em uma 43 NVELDAS ATIVIDADES sn A el eerie 44 Atividades da fase de solicita o 45 Solicitar SerVI O aa A A AE 45 Analisar Necesidad ida 46 Negociar proposta de solu o cascara 46 Atividades da fase de an lise 47 Eli itar FEQUISHOS 47 Revisar requisitos pt 48 Definir tecnologia 48 Avaliar riscos e mensurar reduiSitOS 48 Definir diretrizes de teste seele 49 Negociar regui OS ii UN e iene it evi aida ai dashed 49 Atividades da fase de planejamento 50 Planejar desenvolvimento pp 50 Preparar ambiente de
82. anejamento detalhado de tarefas Voc tamb m poder fazer refer ncia ao local em que os detalhes ser o armazenados se for adequado Para os Planos de Teste Mestre recomend vel evitar o planejamento detalhado de tarefas que freg entemente ser um esfor o improdutivo se efetuado como uma atividade antecipada no in cio do projeto Um Plano de Teste Mestre poder descrever de maneira til as fases e o n mero de itera es e fornecer uma indica o dos tipos de teste que geralmente s o planejados para cada Fase ou Itera o Observa o Nos casos em que as informa es referentes a processos e ao planejamento detalhado forem registradas em um local central e separadamente deste Plano de Teste voc ter que gerenciar os problemas originados pelo fato de existirem c pias duplicadas das mesmas informa es Para evitar que os membros da equipe consultem informa es desatualizadas recomend vel nesse caso inserir o m nimo poss vel de informa es sobre processos e planejamento no Plano de Teste para facilitar a constante manuten o das informa es e portanto simplesmente fazer refer ncia ao material que se encontra no Plano Mestre 9 NECESSIDADES AMBIENTAIS Esta se o apresenta os recursos n o humanos necess rios ao Plano de Teste 9 1 HARDWARE B SICO DO SISTEMA Os conjuntos de tabelas a seguir apresentam os recursos do sistema necess rios ao esfor o de teste descrito neste Plano de Teste
83. as Y Ensino m dio completo Conhecimentos b sicos em inform tica Y Qualquer curso com dura o m nima de 20 horas e que desenvolva contato com cliente AP NDICE B 2 ANALISTA DE REQUISITOS 77 Processo de desenvolvimento d Detalhamento do Papel Analista de Requisitos Descri o Este papel representa a pessoa que sabe identificar as necessidades do cliente e propor solu es para elas Ele detalha a especifica o de uma parte da funcionalidade do sistema descrevendo os requisitos de um ou mais casos de uso criando e detalhando os 4 Atribui es A Artefatos do papel gt Analisar necessidades do cliente Vis o de Neg cio v solu es para as necessidades do cliente Y Documento de Elicita o de Requisitos Y Apresentar as solu es propostas Documento de Casos de Uso w Elicitar e detalhar requisitos izes de R bilidad w Criar e detalhar casos de uso Criar matrizes de rastreabilidade Avaliar riscos na implementa o de requisitos 4 T tulos Caracter sticas Exigidos Habilidade para identificar problemas w Curso superior na rea de tecnologia da informa o v Boa comunica o interpessoal Y Um ano de experi ncia como analista de requisitos w Comunicativo Receptivo Desejados Especializa o em engenharia de software Y Ter participado de pelo menos cinco projetos de software AP NDICE B 3 GERENTE DE
84. as a contabilidade e constru o civil como seria o caso se estiv ssemos desenvolvendo um sistema para gerenciar projetos de constru o a apresenta o das Regras de Neg cios dos dois subdom nios diferentes pode ser confusa para o leitor Para resolver esse problema utilizamos grupos de Regras de Neg cios Ao apresentar os grupos de Regras de Neg cios forne a uma pequena descri o que ajude o leitor a entender o que lt Um grupo de regras de neg cio gt representa As Regras de Neg cios apresentadas no grupo s o organizadas em ordem alfab tica para facilitar o acesso 3 3 1 RN0003 lt Uma regra de neg cio do grupo gt A defini o de lt uma regra de neg cio do grupo gt apresentada aqui com todas as informa es necess rias para que o leitor entenda o conceito 3 3 2 RN0004 lt Outra regra de neg cio do grupo gt A defini o de lt Outra regra de neg cio do grupo gt apresentada aqui com todas as informa es necess rias para que o leitor entenda o conceito 157 3 4 GRN002 lt UM SEGUNDO GRUPO DE REGRAS DE NEGOCIO gt 3 4 1 RN0005 lt Mais uma regra de negocio do grupo gt A defini o de lt Mais uma regra de neg cio gt apresentada aqui com todas as informa es necess rias para que o leitor entenda o conceito 3 4 2 RN0006 lt Uma outra regra de neg cio de grupo gt A defini o de lt Uma outra regra de neg cio do grupo gt apresentada aqui com todas as inf
85. ata Wikip dia A enciclop dia livre 17 de Outubro de 200 Disponivel em lt http pt wikipedia org wiki Modelo em cascata gt Acesso em 26 de Outubro de 2009 AP NDICE A CICLO DE VIDA E MAPA DE ATIVIDADES Mapa do processo 65 Mapa dos processos de apoio 67 AP NDICE B PAP IS AP NDICE B 1 CLIENTE 73 Detalhamento do Papel Cliente Descrig o Este papel representa a pessoa que entende a regra de neg cio da empresa a qual se destina a solu o Ele pode ser representado por uma ou mais pessoas dependendo do projeto e da necessidade Dois perfis distintos podem ser analisadas a do cliente externo aquele enfrenta um problema em um ambiente qualquer e n o trabalha na empresa que desenvolve a solu o O outro seria o cliente interno aquele que trabalha na empresa que desenvolve a solu o e conhece a regra de neg cio da empresa a qual se destina a solu o 4 Atribui es A Artefatos do papel Y Solicitar servi os w Documentos trazidos por ele para ajudar no entendimento do w Solicitar mudan as de software problema w Assinar contratos de proposta e aceita o Y Gloss rio Descrever seus problemas de forma clara e entendivel iv Regras de Neg cio Y Especificar a Regras de Neg cio Y Solicita o Y Colaborar para o desenvolvimento de um Gloss rio 5 T tulos Caracter sticas Exigidos Receptivo Nenhum Comunicativo Observador Desejados w Clareza de id i
86. ativa dos esfor os de teste e Lista os elementos liberados do projeto de teste 1 3 ESCOPO Descreva os n veis de teste por exemplo Unidade Integra o ou Sistema e os tipos de teste como por exemplo Funcionalidade Usabilidade Confiabilidade Desempenho e Suportabilidade que ser o abordados por este Plano de Teste Tamb m importante fornecer uma indica o geral das reas importantes que ser o exclu das do escopo especialmente nos casos em que o p blico alvo possa supor sensatamente que elas ser o inclu das Observa o Evite incluir detalhes aqui que ser o repetidos nas se es Itens de Teste Alvo e Resumo dos Testes Planejados 1 4 P BLICO ALVO Forne a uma breve descri o do p blico para o qual o Plano de Teste est sendo escrito Isso ajudar os leitores do documento a identificarem se ele realmente est destinado ao seu uso e tamb m ajudar a evitar que o documento seja usado de forma inadequada Observa o Freg entemente o estilo e o conte do do documento s o alterados em fun o do p blico alvo 1 5 TERMINOLOGIA E ACR NIMOS DO DOCUMENTO Essa informa o estar presente no glos rio 1 6 REFER NCIAS Esta subse o fornece uma lista dos documentos mencionados em qualquer outra parte do Plano de Teste Identifique cada documento por t tulo n mero da vers o ou do relat rio se aplic vel data organiza o de publica o ou autor original Evite listar documentos
87. ato de aceita o que ter a assinatura de todos os papeis envolvidos na atividade e servir para validar a necessidade do cliente 4 6 1 3 Executar mudan a planejada Nessa fase ser o executadas as mudan as definidas na reuni o com o Cliente Caso seja acordado o cancelamento do projeto ser o apresentados todos os encargos ao Cliente segundo estabelecido no contrato Caso a solicita o consista em numa mudan a em uma funcionalidade da solu o de software o Gerente de Projeto e o Analista de Requisitos atualizar o os artefatos para a realiza o das altera es Durante esse processo alguns requisitos podem vir a ser invalidados por v rios motivos Entre eles podemos citar i mudan as na regras de neg cio do Cliente ii n o h mais a necessidade Para saber exatamente quais requisitos caracter sticas e recursos do processo e do produto 56 ser o afetados pela mudan a dever ser usada uma Matriz de Rastreabilidade que indicar o relacionamento entre os v rios componentes do produto de software Nesse caso componentes pode ser entendido como caracter sticas da solu o ou artefatos Os requisitos que foram invalidados segundo a Matriz de Rastreabilidade ser o exclu dos e ou substitu dos e acoplados ao projeto e ent o ser gerada uma nova solicita o comum e o processo seguir normalmente 4 6 2 Verifica o da qualidade VQA Nessa fase ser o observados os fatores determinantes da qualid
88. c observar que existem in meras abordagens que exclamam serem as melhores explicando os principais problemas que elas prop em resolver da melhor forma poss vel Em contrapartida nem todas s o adotadas pelas empresas e equipes de desenvolvimento Algumas destas equipes at tentam us las mas se a metodologia n o for flex vel o bastante ao ambiente onde est sendo empregada ent o facilmente ser o substitu das por outras que possuam essa caracter sticas O termo padr es por excel ncia usado aqui para denominar mecanismos e t cnicas amplamente utilizados para o desenvolvimento de software no Brasil e no mundo respectivamente o programa brasileiro MPS BR e o framework RUP Al m de serem referenciadas no meio acad mico como modelos conceituais para o estudo da Engenharia de Software e suas aplica es O RUP permite que voc customize facilmente um processo contendo unicamente as necessidades do seu projeto permitindo a sele o e utiliza o apenas dos componentes necess rios International Business Machines IBM 2009 Por outro lado o MPS BR um programa que objetiva a melhoria do processo de desenvolvimento de software brasileiro Ele n o define um processo propriamente dito mas sim o que um processo deve possuir Para garantir que suas pr ticas est o sendo seguidas s o definidos guias de implementa o e m todos de avalia o que usado por empresa avaliadoras contratadas para isso MPS BR
89. com plataformas Windows UNIX etc e padr es de qualidade e de seguran a UL ISO CMM 9 2 REQUISITOS DO SISTEMA Defina todos os requisitos do sistema necess rios para suportar o aplicativo Entre eles poder o estar inclu dos as plataformas de rede e os sistemas de operacionais de host suportados configura es memoria perif ricos e software fornecido 9 3 REQUISITOS DE DESEMPENHO Use esta se o para detalhar os requisitos de desempenho Os problemas de desempenho podem abranger itens como fatores de carga do usu rio largura de banda ou capacidade de comunica o taxa de transfer ncia precis o e confiabilidade ou tempos de resposta em uma s rie de condi es de carregamento 9 4 REQUISITOS AMBIENTAIS Detalhe os requisitos ambientais conforme necess rio Para sistemas baseados em hardware as quest es ambientais poder o incluir temperatura choques umidade radia o etc Para aplicativos de software os fatores ambientais podem incluir condi es de uso ambiente do usu rio disponibilidade de recursos problemas de manuten o e recupera o e tratamento de erros 10 REQUISITOS DA DOCUMENTA O Esta se o descreve a documenta o que dever ser desenvolvida para suportar a implanta o bem sucedida de aplicativos 10 1 MANUAL DO USU RIO Descreva a finalidade e o conte do do Manual do Usu rio Discuta quest es como o tamanho desejado o n vel de detalhamento a necessidade de um
90. como ela representada Da vis o de casos de uso vis o l gica vis o de processos vis o de implanta o e vis o de implementa o enumera as vis es necess rias e para cada vis o explica quais tipos de elementos de modelo ela cont m 3 METAS E RESTRI ES DA ARQUITETURA Mostra os requisitos e objetivos do software que t m algum impacto sobre a arquitetura por exemplo seguran a garantia privacidade uso de um produto desenvolvido internamente e pronto para ser usado portabilidade distribui o e reutiliza o Ela tamb m captura as restri es especiais que podem ser aplic veis estrat gia de design e implementa o ferramentas de desenvolvimento estrutura das equipes cronograma c digo fonte legado e assim por diante 4 VIS O DE CASOS DE USO Esta se o lista casos de uso ou cen rios do modelo de casos de uso quando eles representam funcionalidade central e significativa do sistema final ou quando t m uma grande cobertura arquitetural eles experimentam muitos elementos arquiteturais ou quando enfatizam ou ilustram um ponto complexo e espec fico da arquitetura 1 7 REALIZA ES DE CASOS DE USO Ilustra o funcionamento do software apresentando algumas realiza es ou cen rios de casos de uso selecionadas e explica como os diversos elementos do modelo de design contribuem para a respectiva funcionalidade 2 VIS O L GICA Esta se o descreve as partes significativas do ponto de v
91. daram a seguir em frente em busca da realiza o dos meus desejos A minha namorada pela sua paci ncia e apoio mas principalmente por suas opini es nas tomadas de decis es importantes A professora Josemary Freire pela aten o dedica o e apoio ao longo deste e de outros trabalhos realizados ao longo do curso Vanjhony Esse o termino de uma fase da minha vida eu agrade o a todas as pessoas que fizeram parte dela e a tornaram poss vel meus pais meu irm o minha menina meus amigos meus mestres meus companheiros Todos n s formandos do curso de Ci ncia da Computa o iniciado no ano 2006 1 agora fazemos parte um da vida do outro uns com mais intensidade que outros mas com certeza todos tem uma parcela de import ncia nessa conquista que obtivemos hoje AGRADECIMENTOS Agradecemos a Deus pela vida Em poder almejar novos objetivos de crescimento atrav s do conhecimento adquirido AOS nossos pais atrav s do amor incondicional da educa o e forma o cultural pelas quais obtivemos nossa conduta moral As nossas fam lias que colaboraram nesta jornada tanto em mbito psicol gico como financeiro Agradecemos aos companheiros de equipe agora amigos pelo trabalho rduo durante os v rios fins de semana seguidos dedicados ao desenvolvimento do conhecimento contido neste trabalho A todos os professores que contribu ram para a nossa forma o profissional Em especial Josemary
92. de vida de um processo descreve as fases e atividades pelas quais um projeto de software passa at ser gerada uma nova funcionalidade ou solu o a partir de uma necessidade expressa em forma de solicita o Diferente dessa defini o o ciclo de vida de um software inicia a partir da concep o do software passando por um processo de desenvolvimento seguindo pela sua utiliza o e evolu o at que ele n o atenda as necessidades do seu utilizador e caia em desuso Tomando como base esses conceito foi definido o Prumo dividido em fases do processo principal e processos de apoio 30 A 1 j An lise Planeja 7 mento GMD volvimento Figura 4 2 Ciclo de vida do Prumo Assim como podemos observar na Figura 4 2 o Prumo foi definido e separado em fases que descrevem as entradas e sa das do ciclo de desenvolvimento Solicita o e Entrega o pr prio ciclo An lise Planejamento Desenvolvimento e Teste e processos de apoio que s o o acompanhamento para ger ncia da qualidade VQA e a ger ncia de mudan as GMD Cada uma delas abordando o desenvolvimento do software sobre uma vis o diferente de acordo com os seus interesses A seguir cada uma das fases ser o explicadas para que haja maior compreens o das suas abordagens e caracter sticas Antes de iniciar as descri es das fases do ciclo de vida do Prumo ser realizada uma breve defini o de do que significa o termo fase dentro do escopo dest
93. dicione ou exclua itens conforme o necess rio Fornecedor ou Categoria ou Tipo de Nome da Marca da Desenvolvida Ferramenta Ferramenta Internamente Vers o Gerenciamento de Teste Controle de Defeitos Ferramenta ASQ para teste funcional Ferramenta ASQ para teste de desempenho Gerador de Perfil ou Monitor de Cobertura de Teste Gerenciamento de Projeto Ferramentas DBMS 9 4 CONFIGURA ES DO AMBIENTE DE TESTE Devem ser fornecidas e suportadas as seguintes Configura es de Ambiente de Teste para este projeto Implementada na Nome da Configura o Descri o Configura o F sica Configura o do usu rio comum M nima configura o suportada Motivada por fun es visuais e Sistema Operacional Internacional de Dois Bytes 10 MARCOS DA ITERA O Identifique os principais marcos da programa o que definem o contexto do Esfor o de Teste Evite repetir muitos detalhes que j estejam documentados em outros lugares como por exemplo em planos que abordam o projeto inteiro Data de in cio Data de t rmino Planejada Real Planejada Real Marco Plano de itera o acordado In cio da itera o Elabora o da baseline dos requisitos Elabora o da baseline da arquitetura Elabora o da baseline da interface com o usu rio Libera o do primeiro build para teste Aceita o do primeiro build para teste Termino do ciclo de teste do primeiro build Libera o do s
94. dos pela solu o proposta Ela n o descreve as solicita es ou os requisitos espec ficos dos usu rios e dos envolvidos j que eles s o capturados em um artefato individual de solicita es dos envolvidos Em vez disso ela fornece a base e a justificativa que explicam por que os requisitos s o necess rios 3 1 DEMOGRAFIA DO MERCADO Resuma as principais demografias do mercado que motivam as decis es do produto Descreva e posicione os segmentos do mercado alvo Fa a uma estimativa do tamanho e do crescimento dos mercados usando o n mero de poss veis usu rios ou o valor gasto por seus clientes na tentativa de satisfazer necessidades que ser o atendidas por seu produto ou melhoria Revise as principais tend ncias e tecnologias do setor Responda a estas perguntas estrat gicas Qual a reputa o da sua empresa nesses mercados Qual voc gostaria que fosse Como esse produto ou servi o suporta suas metas 3 2 RESUMO DOS ENVOLVIDOS H uma s rie de envolvidos que se interessam pelo desenvolvimento e nem todos eles s o usu rios finais Apresente uma lista resumida desses envolvidos que n o s o usu rios O resumo dos usu rios encontra se na se o 3 3 Nome Descri o Responsabilidades Informe o tipo Fa a uma breve descri o Resuma as principais responsabilidades do de envolvidos dos envolvidos envolvido no que diz respeito ao sistema em desenvolvimento ou seja o interesse dele como envolvido
95. duzir os riscos inerentes determina o autom tica dos resultados Ferramentas A t cnica exige as seguintes ferramentas e Ferramenta de Automa o de Scripts de Teste e Restaurador e reprodutor de imagem da configura o b sica e Ferramentas de backup e de recupera o e Ferramentas de monitoramento de instala o registro disco r gido CPU mem ria etc e Ferramentas e utilit rios SQL de banco de dados e Ferramentas de gera o de dados necess rias Considera es e 05 testes poder o necessitar de drivers ou de um ambiente de desenvolvimento especiais SGBD para inserir ou modificar dados diretamente no banco de dados e Os processos dever o ser disparados manualmente e Dever o ser usados bancos de dados pequenos ou de tamanho m nimo com um n mero limitado de registros para aumentar a visibilidade de quaisquer eventos n o aceit veis 5 1 2 Teste de Funcionamento O teste de funcionamento do objetivo do teste deve concentrar se em todos os requisitos de teste que possam ser diretamente associados a casos de uso ou fun es e regras de neg cios Esse teste tem por fim verificar a adequada aceita o processamento e recupera o dos dados e a implementa o apropriada das regras de neg cios Esse tipo de teste baseia se em t cnicas de caixa preta ou seja verificar o aplicativo e seus processos internos interagindo com o aplicativo atrav s da Interface Gr fica do Usu
96. e Sigla 3 Sigla n En sima Fase lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt dd mm aaaa Nome do gerente do projeto Nome do auditor ou analista de qualidade Nome da fase verificada Nome do auditor ou analista de qualidade Descri o da Resultad Respon Prazo para verifica o s vel corre o Observa es Primeira Conform Nome dd mm aaaa verifica o N o do realizada conforme respons No se Aplica pela Pendente correc o Segunda verifica o realizada Terceira verifica o realizada En sima verifica o realizada
97. e existem in meras tentativas de defini o onde cada autor enfatiza uma caracter stica diferenciada por m todos eles caminham em dire o a um ponto comum Logo alguns deles foram selecionados e ser o mencionados procurando atingir os aspectos mais relevantes ao tema abordado neste trabalho Inicialmente PRESSMAN 2006 p 16 exp e seus conhecimentos sobre a Engenharia de Software organizando os em camadas onde todas s o estruturadas com foco na qualidade do produto de software Nesse modelo o alicerce a camada correspondente ao processo de software funcionando como um adesivo que mant m unidas as camadas de tecnologia e permite o desenvolvimento racional e oportuno de softwares de computador As outras duas camadas s o m todos que compreendem as t cnicas de como fazer para construir software e as ferramentas que oferecem apoio automatizado ou semi automatizado para o processo e para os m todos Adicionalmente SOMMERVILLE 2001 p 43 afirma que a melhoria e padroniza o no processo de software pode ser implementada em v rias etapas trazendo coes o aos objetivos das atividades de uma organiza o Essa pr tica traz melhoria na comunica o entre os integrantes da equipe redu o no tempo de treinamento de um novo integrante da equipe e aumenta a economia na automa o do processo 12 Segundo MACHADO e WEBER 2001 a globaliza o da economia vem influenciando as empresas produtoras e pr
98. e trabalho Assim fase a representa o de um conjunto de atividades organizadas com um objetivo comum de desenvolver uma parte significativa de um projeto de software Geralmente elas s o dependentes entre si em alguns aspectos Os artefatos s o um exemplo ou seja numa fase geralmente s o usados artefatos criados e desenvolvidos em outras fases Por exemplo o Documento de Elicitacao de Requisitos criado na fase de an lise e utilizado nas fases de planejamento e desenvolvimento 31 4 2 1 Fase de solicita o Como observada na Figura 4 2 esta a fase de entrada no processo Ela descreve como o cliente pode expressar suas necessidades perante a equipe de desenvolvimento e como eles devem observar o problema em busca da melhor solu o Em linhas gerais o objetivo dessa fase identificar o problema entender o ambiente do cliente e lan ar uma proposta de solu o Ent o a solu o s ser encaminhada para a pr xima fase depois de autorizado pelo cliente e o mesmo assinar um contrato pr vio 4 2 2 Fase de an lise Aqui ser o utilizados os meios mais apropriados da Engenharia de Software para especificar as necessidades do cliente em forma de requisitos e casos de uso em um n vel de detalhamento aceit vel para a equipe de desenvolvimento e para o projeto Para chegar a esse n vel de aceita o s o criados v rios tipos de especifica es incluindo os diagramas e prot tipos que descrevem as necess
99. e Jader pelo apoio constante nessa jornada contribuindo para o fortalecimento dos conceitos profissionais e pessoais Ao nosso professor e orientador Maxwell Anderson que foi de fundamental import ncia nesse trabalho sempre nos estimulando e mostrando o verdadeiro potencial da Ci ncia da Computa o e da Engenharia de Software Aos celebrados pelo constante est mulo em busca da domina o global sempre adicionando ideias peculiares que nos motivaram a evoluir constantemente Enfim agradecemos a todos os amigos que direta ou indiretamente contribu ram para mais esta conquista Muit ssimo obrigado a todos LISTA DE FIGURAS Figura 3 1 Ciclo de vida do modelo sequencial cascata 19 Figura 3 2 Compara o entre os modelos em cascata incremental e iterativo 20 Figura 3 3 Modelo de processo em espiral PRESSMAN 2006 p 45 22 Figura 3 4 Arquitetura organizacional do 24 Figura 4 1 Visualiza o do Prumo em n veis n nn 28 Figura 4 2 Ciclo de vida do ee 30 Figura 4 3 Exemplo de representa o de uma atividade 45 LISTA DE GR FICOS Gr fico 1 1 Previs o de crescimento mundial do setor de software para 2005 2009 Fonte ADOS IDO 11 Gr fico 2 1 Distribui o do mercado brasileiro de softwa
100. e de Projetos para que haja o esclarecimento da solu o que ser detalhada nas atividades consequentes A proposta resulta na aceita o ou rejei o de um contrato firmado entre empresa e o Cliente para que sejam iniciadas as atividades de especifica o da solu o As propostas de solu o ser o discutidas observando a correspond ncia das necessidades no contexto especificado sendo definida como solu o a ser desenvolvida Com base nesta defini o ser elaborado o Contrato de Aceita o o 47 qual ser de responsabilidade do Gerente de Projetos Nele ser o definidos em detalhes do que se trata a funcionalidade em termos de pre os e prazos Ser o participantes desse processo o i Analista de Requisitos descrevendo as solu es propostas ii o Gerente de Projetos realizando as negocia es e preenchendo a Ata de Reuni o e iii o Cliente julgando segundo seu entendimento as solu es que ser o especificadas concordando ou n o com os contratos 4 5 2 Atividades da fase de an lise Este t pico exibe como ser o realizadas as atividades de an lise identifica o de requisitos e especifica o dos mesmos Para isso ser o expostas vis es gerais explica es e pontos importantes de cada uma das atividades 4 5 2 1 Elicitar requisitos Esta atividade descreve quais os passos necess rios para que haja uma elicita o de requisitos de maneira concreta e assertiva Ela respons vel pela defi
101. e dias meses ou anos Tempo M dio para Reparo MTTR quanto tempo o sistema poder ficar sem funcionar ap s uma falha Exatid o especifique a precis o resolu o e a exatid o atrav s de algum padr o conhecido necess rias na sa da do sistema Taxa M xima de Erros ou Defeitos geralmente expressa em termos de erros por milhares de linhas de c digo erros KLOC ou de erros por ponto de fun o erros ponto de fun o Taxa de Erros ou Defeitos categorizada em termos de erros pouco importantes importantes e cr ticos o s requisito s deve m definir o que se entende por um erro cr tico por exemplo a perda total de dados ou uma total incapacidade de usar determinadas partes da funcionalidade do sistema 3 2 1 RNFOO3 Primeiro requisito n o funcional de confiabilidade Uma descri o detalhada do requisito RNFOO3 3 2 2 RNF004 Segundo requisito n o funcional de confiabilidade Uma descri o detalhada do requisito RNFOO4 3 3 DESEMPENHO As caracter sticas de desempenho do sistema devem ser descritas nesta se o Inclua tempos de resposta espec ficos Quando aplic vel fa a refer ncia por nome aos Casos de Uso relacionados Tempo de resposta de uma transa o m dio m ximo Taxa de transfer ncia como por exemplo transa es por segundo Capacidade como por exemplo o n mero de clientes ou de transa es que o sistema pode acomodar Modos de
102. e realizada ao gerente para que este possa ter um maior controle sobre o andamento do projeto j que pode haver a necessidade de realizar algum realinhamento ao que foi planejado como tamb m manter a ader ncia da execu o dos procedimentos aos padr es de qualidade institucionalizados 4 6 2 4 Corre o O Analista de Qualidade ir comunicar os desvios aos padr es aos respons veis Os artefatos que possu rem inconformidades ser o devolvidos aos seus respectivos respons veis para que eles fa am as devidas altera es Uma vez as altera es realizadas o processo seguir seu curso normal 58 5 CONSIDERA ES FINAIS Tendo em vista todas as informa es reunidas para o desenvolvimento desse projeto observa se que muito h de fazer e estudar sobre a melhoria do desenvolvimento de software principalmente quanto ao desenvolvimento de software por pequenas empresas O objeto alcan ado neste projeto foi a modelagem de um processo de desenvolvimento reunindo caracter sticas que o torne simples por m completo o suficiente para que equipes e empresas iniciantes ou n o tenham todo o arcabou o para seguirem durante o desenvolvimento dos seus projetos Foi observado tamb m que o sucesso na implanta o de um processo de software est intimamente ligado s caracter sticas do problema a ser atacado e aos recursos dispon veis para sua resolu o O processo aqui apresentado e descrito est apto a gerir as problem t
103. egundo build para teste Aceita o do segundo build para teste Termino do ciclo de teste do segundo build Libera o do terceiro build para teste Aceita o do terceiro build para teste Termino do ciclo de teste do terceiro build Libera o do en simo build para teste Aceita o do en simo build para teste Termino do ciclo de teste do en simo build 11 PROCEDIMENTOS E PROCESSOS DE GERENCIAMENTO Resuma os processos e os procedimentos que dever o ser usados quando surgirem problemas no Plano de Teste e em sua execu o 11 1 MEDI O E AVALIA O DA EXTENS O DO TESTE Resuma o processo de medi o e avalia o a ser usado para rastrear a extens o do teste 11 2 GERACAO DE RELAT RIOS SOBRE COBERTURA DE TESTE Resuma o processo de avalia o para revisar e aceitar os produtos liberados deste Plano de Teste 11 3 APROVA O E ENCERRAMENTO Resuma o processo de aprova o e liste os cargos e os nomes dos ocupantes atuais que dever o aprovar inicialmente o plano e encerre com a execu o satisfat ria do plano AP NDICE C 16 PLANO DE IMPLANTA O lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt PLANO DE IMPLANTA O VERS O 1 Hist rico de revis o Data Vers o Descri o Autor SUM RIO 1 PLANO DE INPLANTACAQO I U u uu 307 il
104. erimentados como por exemplo menus tamanho posi o estado e foco T cnica T cnica Crie ou modifique testes para cada janela a fim de verificar a navega o adequada e os estados de objeto apropriados para cada janela e objeto do aplicativo Estrat gias Descreva uma ou mais estrat gias que podem ser usadas pela t cnica para observar de forma precisa os resultados do teste A estrat gia combina elementos do m todo atrav s do qual a observa o pode ser feita e das caracter sticas dos resultados espec ficos que indicam um prov vel xito ou falha do teste O ideal que as estrat gias sejam autoverificadas permitindo que os testes automatizados fa am uma avalia o inicial do xito ou falha do teste No entanto tenha aten o para reduzir os riscos inerentes determina o autom tica dos resultados Ferramentas A t cnica necessita da Ferramenta de Automa o de Scripts de Teste Necess rias Crit rios de A t cnica suporta o teste de cada tela ou janela principal que ser muito usada pelo xito usu rio final Considera es Nem todas as propriedades referentes a objetos personalizados e de terceiros poder o ser Especiais acessadas 5 1 4 Teste de Seguran a e de Controle de Acesso O Teste de Seguran a e de Controle de Acesso concentra se em duas reas de seguran a principais Seguran a no n vel do aplicativo incluindo o acesso aos Dados ou s Fun
105. escri o Autor 158 SUM RIO 1 REGRAS DE NEG CIOS I uu 155 Taqa INTRODU O SANS 155 1 2 FINALIDADE cr qhay 155 1 3 ESGOPO 155 TA REFERENCIAS iu en 155 1 5 VIS OGERAL O 155 1 67 DEFINIGOES 155 2 REGRAS na ee 156 21 83001 lt REGRAS DE NEG CIOS 156 2 2 RN002 lt OUTRAS REGRAS DE NEG CIO 156 2 3 GRN001 lt UM GRUPO DE REGRAS DE 156 2 3 1 RN0003 lt Uma regra de neg cio do 156 2 3 2 RN0004 lt Outra regra de neg cio do grupo 156 2 4 GRN002 lt UM SEGUNDO GRUPO DE REGRAS DE NEGOCIO gt 157 2 4 1 RN0005 lt Mais uma regra de negocio do grupo gt 157 2 4 2 RN0006 lt Uma outra regra de neg cio de grupo gt 157 155 2 REGRAS DE NEG CIOS 2 1 INTRODU O A introdu o das Regras de Neg cios oferece uma vis o geral de todo o documento Apresente todas as informa es de que o leitor pode precisar para entender o documento nesta se o Salve este documento em um arquivo denominado Regras de Neg cios 2 2 FINALIDADE Especifique a finalidade deste documento 2 3 ESCOPO Uma breve descri o do escopo do documento Regras de Neg cios o s
106. esenta os itens que ser o testados Forne a uma lista de n vel superior dos principais itens que estar o sujeitos a teste Essa lista deve incluir itens produzidos diretamente pela equipe de desenvolvimento do projeto e itens de que dependem esses produtos Por exemplo o hardware de processamento b sico dispositivos perif ricos sistemas operacionais produtos ou componentes de terceiros etc recomend vel agrupar a lista por categoria e atribuir import ncia relativa a cada motivador 4 RESUMO DOS TESTES PLANEJADOS Esta se o apresenta os recursos recomendados para o projeto lt Nome do Projeto gt suas principais responsabilidades e seu conjunto de conhecimentos ou de habilidades 4 1 RESUMO DAS INCLUSOES DOS TESTES Esta se o fornece um resumo de nivel superior dos testes que ser o executados O resumo fornecido aqui representa uma vis o geral de n vel superior dos testes que ser o e dos que n o ser o executados 4 2 RESUMO DAS EXCLUS ES DOS TESTES Forne a um resumo de n vel superior dos poss veis testes que poderiam ter sido conduzidos mas que foram explicitamente exclu dos deste plano Se voc n o for implementar ou executar um tipo de teste informe claramente que o teste n o ser executado ou implementado e justifique por que A seguir h exemplos de justificativas que poder o ser usadas e Esses testes n o contribuem para alcan ar a miss o de avalia o e N o h recursos suficientes
107. esse passo s o usadas como refer ncia as diretrizes de testes desenvolvidas na fase de an lise 4 5 5 1 Testar A atividade de testar o software embora simbolizada como nica envolve v rios tipos de testes descritos na se o Fluxo Principal Os testes verificam v rios 52 aspectos do funcionamento do software Os resultados destes testes sao verificados e remetidos para as atividades mais convenientes para serem corrigidos quando resultam em erro e Teste de integridades dos dados Esse teste verifica por exemplo se a precis o dos c lculos est dentro do especificado ou se os dados s o armazenados e exibidos ao usu rio de forma correta e concisa e Teste de interface com o usu rio verifica se todos os controles bot es caixas de listagem bot es de checagem etc est o funcionando perfeitamente Tamb m s o verificadas as posi es das caixas de mensagem exibidas e observa o da forma o dos controles durante o dimensionamento das janelas e Teste de seguran a verifica se a seguran a das informa es que trafegam entre o usu rio e o sistema WEB ou LAN ou se dados est o sendo exibidos para pap is n o autorizados e Teste de funcionamento verifica atrav s da simula o de um caso de uso real se o funcionamento do sistema est dentro do esperado e Teste de aceita o esse teste observa a aceita o do cliente em rela o s funcionalidade s desenvolvida s esperado que dura
108. estadoras de servi os de software a alcan ar o patamar de qualidade e produtividade internacional para enfrentarem a competitividade cada vez maior A norma internacional NBR ISO IEC 12207 Tecnologia da Informa o Processos de Ciclo de Vida de Software ISO IEC 12207 2008 usada como refer ncia em muitos pa ses inclusive no Brasil para alcan ar esse diferencial competitivo 13 2 MICRO E PEQUENAS EMPRESAS DE SOFTWARE Esta se o apresenta um panorama do mercado brasileiro de empresas de tecnologia da informa o Mostra v rios n meros interessantes sobre mortalidade renda l quida e o espa o que elas ocupam e a organiza o Outro ponto tratado em rela o aos recursos humanos sistematiza o das atividades e quais os principais problemas 2 1 MERCADO Como visto anteriormente o mercado brasileiro de software muito vasto e est em constante desenvolvimento Segundo reportagem exibida no site do SEBRAE BONNER 2009 foi o setor brasileiro que mais cresceu durante a ltima crise que gerou instabilidade e dor de cabe a para muitos pa ses Apesar de o Brasil ser um pa s com elevada carga tribut ria o governo tem lan ado incentivos fiscais como redu o de IPI sobre hardware regulado pela Lei 8 248 91 e altera es posteriores principalmente as leis 10176 2001 e 11 077 04 UENO 2007 p 10 mostra que em rela o ao software as propostas governamentais de redu o de impostos ainda precisam
109. eto e uma lista das restri es or amento pessoal equipamentos cronograma etc 2 3 ARTEFATOS DO PROJETO Uma tabela com os artefatos que ser o criados e entregues durante o desenvolvimento do projeto com as suas respectivas datas de entrega 2 4 EVOLU O DO PLANO DE DESENVOLVIMENTO DE SOFTWARE Uma tabela com as poss veis vers es desse plano e os crit rios para revis es 3 ORGANIZA O DO PROJETO 3 1 ESTRUTURA ORGANIZACIONAL Descreve a estrutura organizacional organograma do projeto 3 2 CONTATOS EXTERNOS Descreve como ser o os contatos externos ao projeto Para cada grupo de contato deve ser identificadas as pessoas envolvidas 3 3 PAP IS E RESPONSABILIDADES Identifica os pap is que ser o exercidos no projeto e as responsabilidades de cada um 4 GERENCIAMENTO DO PROJETO 4 1 ESTIMATIVAS DO PROJETO Mostra as estimativas de esfor o para o projeto Pode incluir adicionalmente as estimativas de custo 4 2 PLANO DE PROJETO 4 2 1 Plano de fases Inclui os seguintes t picos e Work Breakdown Structure WBS e Gr fico de Gantt das atividades e Os principais marcos do projeto e suas datas 4 2 2 Objetivos das itera es Lista os objetivos que dever o ser alcan ados para cada itera o 4 2 3 Releases Uma breve descri o de cada release 4 2 4 Cronograma do projeto Cronograma detalhado do projeto 4 2 5 Recursos do projeto 4 2 5 1 Plano de staff Identif
110. guagens de programa o O desenvolvedor deve ter conhecimentos s lidos sobre os princ pios b sicos da computa o como algoritmos e estruturas de dados al m de saber aplic los em uma ou mais linguagens de programa o O desenvolvedor dever saber trabalhar em equipe dividir o conhecimento com os demais colegas de trabalho Adicionalmente ele participa do processo de mensura o dos requisitos e identifica o dos poss veis riscos de implementa o das funcionalidades e comenta o c digo fonte da solu o tornando o de f cil compreens o Em se tratando de artefato o Desenvolvedor fica respons vel pelo Componente de Software que nada mais neste contexto do que a codifica o do modelo arquitetural l gico da solu o definido anteriormente pelo Arquiteto de Software 9 Vers o codificada da solu o e que ainda n o foi submetido a nenhum teste 41 4 3 6 Analista de Testes O papel de Analista de Testes representado por uma pessoa com habilidades para realizar diferentes tipos de testes sobre software Durante suas atividades no ciclo de vida do processo ele dever atuar em duas fases distintas A primeira atua o do Analista de Testes na fase de an lise aonde ser o realizados planejamentos para a realiza o dos testes nas fases seguintes Durante o planejamento ele elabora um artefato denominado Plano de Testes que cont m todas as diretrizes e resultados esperados para aqueles requisitos O objeti
111. ica a quantidade de pessoas e o tipo de papel requerido Pode ser incrementado com o grau de experi ncia necess rio e a aloca o desejada 4 2 5 2 Plano de aquisi o de recursos Descreve como as pessoas dever o ser recrutadas para o projeto 4 2 5 3 Plano de treinamento Lista dos treinamentos necess rios para a execu o do projeto e o perfil das pessoas que ser o treinadas al m das datas de realiza o 4 2 6 Or amento Aloca o de custos de acordo com as atividades da WBS 4 3 PLANOS DAS ITERA ES Descri o sucinta do planejamento das itera es 4 4 CONTROLE E ACOMPANHAMENTO DO PROJETO 4 4 1 Plano de ger ncia de requisitos Descri o sucinta do planejamento de ger ncia de requisitos 4 4 2 Plano de controle do cronograma Descri o sobre como o cronograma sera acompanhado e controlado 4 4 3 Plano de controle do or amento Descreve como o or amento sera acompanhado e controlado e as a es corretivas que dever o ser tomadas 4 4 4 Plano do controle de qualidade Descreve os m todos que ser o usados para controlar a qualidade e integridade dos artefatos entregues pelo projeto al m as a es corretivas em cima dos mesmos 4 4 5 Plano de comunica o Descreve como a comunica o do projeto deve acontecer quais os documentos de comunica o dever o ser gerado o formato a distribui o e a periodicidade 4 4 6 Plano de m tricas Descri o sucinta do
112. icas envolvidas no desenvolvimento de um software de forma que qualquer profissional que tenha o m nimo de conhecimento dos conceitos da Engenharia de Software possa desenvolv lo sem dificuldades atingindo um alto grau de qualidade Em resumo no decorrer do desenvolvimento do projeto foi reunida uma carga de conhecimentos que ir contribuir para a vida profissional dos participantes da equipe envolvida no desenvolvimento do Prumo Al m de resultar em um processo de software que permitir a profissionais iniciantes desenvolverem um projeto seguindo os conceitos de alguns dos principais autores contempor neos sobre o tema deste trabalho Adicionalmente seguindo as melhores pr ticas dos processos metodologias e frameworks mais utilizados no mercado Portanto engenharia qualidade 59 REFERENCIAS AGUIAR H V ROULIER A C Primitivas para Defini o de Processo PEPP SWQuality Recife 2004 Disponivel em lt www swquality com br pepp gt Acesso em 5 Dezembro 2009 AMBER S W An Introduction to Processo Patterns Site da Amby Soft 1998 Disponivel em lt http Awww ambysoft com downloads ProcessPatterns pdf gt Acesso em 4 de Novembro de 2009 AMBER S W Process Patterns Building Large Scale Systems Using Technology Cambridge Cambridge University Press 1998 BONNER W Setor de tecnologia da informa o cresce com a crise Site da Globo com jornalnacional S o Paulo 13 de Fevereiro de 2009 Disponivel
113. idades fluxos de trabalho artefatos e pap is do processo Este modelo de processo pode ser usado por uma grande equipe para desenvolver projetos de software robustos e complexos com uma grande variedade de funcionalidades o que n o interessante aos objetivos deste trabalho Por m o RUP flex vel o bastante para quem empresas de tecnologia em busca melhorias e padroniza o nos seus processos de software molde o seu pr prio processo utilizando os modelos sugeridos e adaptando as atividades e a realidade do mercado e da equipe 3 4 2 MPS Br um programa mobilizador de longo prazo criado em dezembro de 2003 e coordenado pela SOFTEX que conta com apoio do Minist rio da Ci ncia e Tecnologia FINEP SEBRAE e Banco Interamericano de Desenvolvimento SOFTEX 2009 O objetivo do programa MPS BR acr nimo a Melhoria de Processo do Software Brasileiro com duas metas a alcan ar a m dio e longo prazos e Meta t cnica visando cria o e aprimoramento do modelo MPS com resultados esperados tais como o Guias do modelo MPS o Institui es Implementadoras credenciadas para prestar servi os de consultoria de implementa o do modelo de refer ncia MR MPS o Institui es Avaliadoras credenciadas para prestar servi os de avalia o seguindo o m todo de avalia o MA MPS o Consultores de Aquisi o certificados para prestar servi os de consultoria de aquisi o de software e servi os relacionados
114. idades do cliente e a solu o proposta pela equipe de desenvolvimento Ao final desta fase estar o prontas todas as especifica es dos requisitos ou seja O problema do cliente estar totalmente entendido e a solu o modelada Uma caracter stica muito importante dessa fase a constante participa o do cliente na maioria das atividades na tentativa de garantir um melhor entendimento dos problemas e necessidades dele Dessa forma o cliente estar interagindo com a equipe de desenvolvimento tirando d vidas descrevendo necessidades e ajudando a moldar a solu o Essa uma estrat gia que tenta garantir o aumento da intera o e comunica o entre o cliente e a empresa criando uma rela o mais fortalecida e diminuindo a sensibilidade do cliente perante as renegocia es de prazo e custo havendo necessidade 4 2 3 Fase de planejamento A fase de planejamento uma fase de prepara o e gerenciamento onde s o definidos os planos para execu o das pr ximas fases Nesta fase necess rio avaliar o ambiente de desenvolvimento dispon vel para o desenvolvimento da 32 solu o Dependendo das exig ncias do projeto e do cliente ou at mesmo dos requisitos o ambiente deve ser ajustado para acomodar satisfatoriamente a constru o da solu o Durante a elabora o de um Plano de Projeto devem ser levados em considera o v rios aspectos e Observar a capacidade da equipe em trabalhar com a tecnologi
115. inho diferente do habitual normal Como a desist ncia de uma funcionalidade modifica o em outra desist ncia do projeto etc 55 4 6 1 1 Analisar solicitacao Nessa atividade ser o analisadas as influ ncias que a mudan a solicitada ir acarretar ao projeto Ser analisado se algum requisito ser invalidado ou adicionado no projeto por uma solicita o do cliente ou ainda se o processo ter que parar o desenvolvimento de alguma funcionalidade Uma vez mensurados os impactos da solicita o de mudan a ser o avaliados os gastos referentes a mudan a segundo as horas trabalhadas Essa atividade ser executada pelo Gerente de Projetos com ajuda do Analista de requisitos e do cliente Como resultado dessa atividade ser atualizado o documento de Elicita o de Requisitos e a matriz de rastreabilidade 4 6 1 2 Negociar solu o com o cliente Nesta atividade ser o apresentados ao cliente o impacto que as mudan as solicitadas ir o acarretar ao projeto e os gastos provenientes da mesma Nessa reuni o o Gerente de Projetos junto ao Analista de Requisitos ir o negociar a viabilidade das altera es com o cliente sugerindo alternativas e solu es Ent o ser o definidas as inser es mudan as ou cancelamentos de requisitos ou do projeto como um todo Essas atividades ser o executadas pelo Gerente de Projetos junto com o Analista de Requisitos e o Cliente As defini es acertadas nessa fase ser o organizadas no contr
116. ionais com capacidade para atuar em diversas atividades de acordo com a demanda exigida Portanto o Prumo surgiu como uma alternativa para aumentar as expectativas desse mercado em desenvolver software com qualidade atendendo s exig ncias do mercado nacional e internacional podendo ser utilizado sem que seja necess rio investimentos altos em consultoria 3 Artefatos s o todas as especifica es desenvolvidas durante um processo de software essa defini o envolvem documentos diagramas prot tipos ou qualquer outra informa o necess rio ao processo MELO 2004 p 5 MELO 2004 p 5 1 1 SITUACAO ENCONTRADA Uma caracter stica importante observada no mercado de cria o de software a n o padroniza o dos processos de desenvolvimento onde a maioria das empresas possui pouca ou nenhuma especifica o formal para as suas atividades Isso pode ocorrer devido escassez de recursos financeiros dispon veis para investimentos na organiza o dos processos ou mesmo a falta de conhecimento Isso deixa os produtos e servi os oferecidos por elas ficarem abaixo da qualidade exigida pelo mercado nacional e internacional Outra caracter stica observada nas empresas que n o possuem seus processos definidos a personaliza o das atividades por exemplo o profissional que desempenha a tarefa de codifica o do software pode criar seus pr prios padr es de codifica o dando nomes para vari veis procedimentos e fu
117. ista da arquitetura do modelo de design como sua divis o em subsistemas e pacotes Para cada pacote significativo ela mostra sua divis o em classes e utilit rios de classe apresentando as classes significativas do ponto de vista da arquitetura e descrevendo as suas responsabilidades bem como alguns relacionamentos opera es e atributos de grande import ncia 2 1 VIS O GERAL Esta subse o descreve toda a decomposi o do modelo de design em termos de camadas e de hierarquia de pacotes 2 2 PACOTES DE DESIGN SIGNIFICATIVOS DO PONTO DE VISTA DA ARQUITETURA Para cada pacote significativo inclua uma subse o com o respectivo nome uma breve descri o e um diagrama com todos os pacotes e classes significativos nele contidos Para cada classe significativa no pacote inclua o respectivo nome uma breve descri o e opcionalmente uma descri o de algumas das suas principais responsabilidades opera es e atributos 3 VIS O DE PROCESSOS Descreve a decomposi o do sistema em processos leves threads simples de controle e processos pesados agrupamentos de processos leves Organize a se o em grupos de processos que se comunicam ou interagem Descreva os modos principais de comunica o entre processos como transmiss o de mensagens e interrup es 4 VIS O DE IMPLANTA O Esta se o descreve uma ou mais configura es da rede f sica hardware na qual o software implantado e executado Ela um
118. ito bem com ele Uma diferen a t pica que a sa da de um incremento n o necessariamente assunto de um refinamento futuro e seu teste ou retorno do usu rio n o utilizado como entrada para planos de revis o ou especifica es para incrementos sucessivos Ao contrario a sa da de uma itera o examinada para modifica o e especialmente 20 para revis o dos objetivos das itera es sucessivas Desenvolvimento lterativo e Incremental 2009 3 3 3 Diferenciando os modelos em cascata iterativo e incremental Para firmar os conceitos dos modelos apresentados acima foi esquematizada uma pequena compara o entre elas na Figura 3 2 T m se como exemplo tr s partes que juntas comp em o software desejado Assim no modelo sequencial ou cascata todos os software trabalhado e desenvolvido de uma s vez Software desejado Vers o 1 Vers o 2 Vers o 3 Sequencial I Cascata Incremental Parte do sistema N toda a funcionalidade Iterativo Todo o sistema funcionalidade parcial Figura 3 2 Compara o entre os modelos em cascata incremental e iterativo Veja que o modelo iterativo lan a vers es de funcionalidades parcialmente implementadas Na abordagem Incremental s o desenvolvidas as funcionalidades por completo uma por uma e lan adas incrementalmente em vers es at que a ltima apresente as a solu o desejada pelo cliente O de
119. l est o todos dos detalhamentos necess rios para a execu o bem sucedida do processo S o eles 5 No Ap ndice A Ciclo de vida e atividades voc encontrar o detalhamento deste n vel 29 e Detalhamento das atividades para cada uma delas definida uma vis o geral pap is respons veis e participantes artefatos de entrada e sa da e uma vis o detalhada contendo passos principais e alternativos e Defini o dos pap is para cada um deles realizada uma breve descri o listadas as atribui es artefatos que s o de responsabilidade do papel t tulos exigidos t tulos desejados e as caracter sticas pessoais esperadas da pessoa candidata ao papel e Defini o dos artefatos nesse n vel s o disponibilizados os modelos dos artefatos necess rios para controle e execu o do processo A estrutura organizacional deles pode variar de acordo com o objetivo importante frisar que qualquer micro e pequena empresa de software pode adotar o processo e tentar adapt lo de acordo com as suas necessidade pressupondo se que tais adapta es ser o observadas por um profissional com conhecimentos seguros em Engenharia de Software e nas pr ticas do RUP e MPS BR 4 2 N VEL DO CICLO DE VIDA Para dar in cio a este t pico importante ressaltar a diferen a entre ciclo de vida de processo e ciclo de vida de software S o dois conceitos bem parecidos e que causam confus o em muitas pessoas Assim o ciclo
120. l do Ciclo de Teste Especifique os crit rios que ser o usados para determinar se os testes dever o ser prematuramente suspensos ou conclu dos para o ciclo de teste atual ou se o futuro build a ser testado dever ser alterado 7 PRODUTOS LIBERADOS Nesta se o liste os v rios artefatos que ser o criados pelo esfor o de teste e que ser o produtos liberados teis aos v rios envolvidos do esfor o de teste N o liste todos os produtos do trabalho liste apenas os que propiciam benef cios diretos tang veis aos envolvidos e os que permitem medir o xito do esfor o de teste 74 SUM RIOS DE AVALIA O DE TESTES Forne a um breve resumo da forma e do conte do dos sum rios de avalia o de testes e indique com que frequ ncia eles ser o gerados 7 1 1 Resultados Detalhados dos Testes Trata se de um conjunto de planilhas do Microsoft Excel relacionando os resultados determinados para cada caso de teste ou refere se ao reposit rio dos registros de testes e dos resultados determinados mantidos por um produto de teste especializado 7 1 2 Matrizes de Rastreabilidade Utilizando uma ferramenta como o Rational RequisistePro ou o Microsoft Excel forne a uma ou mais matrizes de relacionamentos de rastreabilidade entre os itens rastreados 8 FLUXO DE TRABALHO DE TESTE Forne a um resumo do fluxo de trabalho a ser seguido pela equipe de teste no desenvolvimento e na execu o deste Plano de Teste fluxo de traba
121. l sofisticada com suporte a plataformas cruzadas enquanto um principiante poder precisar de uma ferramenta amig vel e de f cil utiliza o Um perfil completo abranger os seguintes t picos para cada tipo de usu rio 3 7 1 lt NOME DO USU RIO gt Representante Uma breve descri o do tipo envolvido Tipo Qualifique a habilidade a forma o t cnica e o grau de sofistica o do envolvido ou seja se ele um guru executivo especialista usu rio eventual e assim por diante Responsabilidades Liste as principais responsabilidades dos envolvidos no que diz respeito ao sistema em desenvolvimento ou seja o interesse deles como envolvidos Crit rios de Sucesso Como o envolvido define sucesso De que forma o envolvido recompensado Envolvimento Qual o grau de comprometimento do envolvido no projeto Especifique quando poss vel os pap is exercidos no Rational Unified Process ou seja Revisor de Requisitos etc Produtos Liberados H produtos liberados adicionais necess rios ao envolvido Podem ser os produtos liberados do projeto ou as sa das do sistema em desenvolvimento Coment rios Problemas Problemas que interfiram no bom andamento do projeto e outras informa es relevantes devem ser relacionados aqui 3 8 RINCIPAIS NECESSIDADES DOS USU RIOS OU DOS ENVOLVIDOS Liste os principais problemas com as solu es existentes conforme o ponto de vista do envolvido ou do usu rio Para
122. lho de teste espec fico que voc usar deve ser documentado separadamente no Caso de Desenvolvimento do projeto Ele deve explicar como o projeto personalizou o fluxo de trabalho de teste b sico do RUP normalmente fase a fase Na maior parte dos casos recomend vel que nesta se o do Plano de Teste voc insira uma refer ncia se o relevante do Caso de Desenvolvimento Poder ser til e suficiente simplesmente incluir um diagrama ou uma imagem ilustrando o fluxo de trabalho de teste Os detalhes mais espec ficos das tarefas de teste individuais poder o ser definidos de v rias maneiras diferentes dependendo da cultura do projeto Veja os exemplos a seguir poder o ser definidos como uma lista de tarefas nesta se o do Plano de Teste ou em um ap ndice complementar poder o ser definidos em uma programa o central do projeto frequentemente em uma ferramenta de programa o como o Microsoft Project poder o ser documentados em listas de tarefas din micas individuais para cada membro da equipe que geralmente s o muito detalhadas para serem inseridas no Plano de Teste poder o ser documentados em um quadro branco localizado em um local central e atualizado dinamicamente poder o simplesmente n o serem documentados formalmente Com base na cultura de seu projeto voc dever listar suas tarefas de teste espec ficas aqui ou fornecer um texto descritivo explicando o processo utilizado por sua equipe para efetuar o pl
123. local como tamb m para o restante do mundo Ainda na mesma pesquisa mostrou que em 2005 existiam em torno de 23 mil empresas de TI sendo 96 delas micro e pequenas empregando mais de 700 mil pessoas e gerando uma receita l quida em torno de 25 milh es de reais Isso assegura a amplitude das possibilidades de aplica o do Prumo FILHO 2006 p 16 mostra a evolu o no setor de software atrav s de um panorama mundial apontando qual o n vel de signific ncia do mercado brasileiro perante o resto do mundo Ele apresentou a perspectiva de crescimento do setor software atrav s do Gr fico 1 1 Nele o leitor pode ver que o Brasil ocupa a quarta melhor posi o na expectativa de crescimento em compara o com outros pa ses bem mais desenvolvidos Al m disso enfatiza a import ncia do setor de software para a economia afirmando que entre todos os benef cios trazidos por esse avan o o mais importante entre eles o ganho de produtividade Isso vale para todos os setores da ind stria com rcio e servi o que focam na tecnologia como ferramenta importante para o crescimento 11 E Previs o de crescimento m dio anual 2005 2009 R ssia 17 8 ndia 17 6 China 13 3 Brasil 8 3 Espanha 8 0 UK 8 0 M xico 7 6 Irlanda 6 9 USA 5 1 Israel 4 8 Jap o 3 0 Gr fico 1 1 Previs o de crescimento mundial do setor de software para 2005 2009 Fonte Abes IDC Sobre os processos de desenvolvimento de softwar
124. los menus de instala o telas iniciais sistemas de ajuda caixas de di logo GUI etc Esta se o define as necessidades e os tipos de rotula o a serem incorporados no c digo Como exemplos podemos citar observa es sobre direitos autorais e patentes logotipos corporativos cones padronizados outros elementos gr ficos etc 11 ATRIBUTOS DE RECURSOS S o designados atributos para os recursos que podem ser usados para avaliar rastrear priorizar e gerenciar os itens do produto cuja implementa o foi proposta Todos os atributos e tipos de requisitos devem ser descritos no Plano de Gerenciamento de Requisitos No entanto talvez seja conveniente listar e descrever brevemente os atributos referentes aos recursos que foram escolhidos As subse es a seguir representam um conjunto de atributos de recursos sugeridos 11 1 STATUS Definido pela equipe de gerenciamento do projeto ap s a negocia o e a revis o Controla o andamento durante a defini o da baseline do projeto Proposto Usado para descrever recursos que est o sendo discutidos mas que ainda n o foram revisados e aceitos pelo canal oficial como por exemplo um grupo de trabalho formado por representantes da equipe do projeto do gerenciamento do produto e da comunidade de usu rios ou de clientes Aprovado Recursos que s o considerados teis e vi veis e que foram aprovados para implementa o pelo canal oficial Incorporado Recursos incorpor
125. m o Analista de Requisito montar uma Matriz de Rastreabilidade tendo para isso o suporte do Cliente Essas atividades t m o objetivo principal de refinar as informa es dos documentos mantendo a fidelidade entre as informa es nos documentos e o ambiente observado Os documentos ser o escritos de forma a simples e objetiva onde todos os envolvidos no processo possam ter um entendimento f cil sobre os conceitos descritos no documento Nessa fase os documentos de Elicita o de Requisitos e Especifica o de Casos de Uso s o atualizados conforme conveniente ao projeto 4 5 2 3 Definir tecnologia Nessa atividade ser o discutidas as quest es referentes s tecnologias a serem empregadas no desenvolvimento do projeto O analista de requisitos junto com o arquiteto de software ir definir como aproveitar melhor as tecnologias existentes observando o custo acessibilidade e adaptabilidade realidade do Cliente Uma vez analisados todos os aspectos do contexto onde o problema esta inserido o Arquiteto de Software reunir informa es de tecnologias que podem ser utilizadas para a resolu o daquele problema Junto com o Analista de Requisitos ele ira definir quais s o as tecnologias que consiste no arcabou o conceitual que servir de base para a constru o do sistema 4 5 2 4 Avaliar riscos e mensurar requisitos Esta atividade explica como deve ser feita a atividade de avalia o de riscos de implementa o e
126. ma O objetivo deste documento capturar e comunicar as decis es arquiteturais significativas que foram tomadas em rela o ao sistema 1 1 INTRODU O A introdu o do documento fornece uma vis o geral do documento inteiro Ela inclui a finalidade o escopo as defini es os acr nimos as abrevia es as refer ncias e a vis o geral do documento de arquitetura 1 2 FINALIDADE Esta se o define o papel ou finalidade do Doc de Arquitetura de Software na documenta o do projeto como um todo e descreve rapidamente a estrutura do documento O p blico alvo espec fico do documento identificado com uma indica o de como ele espera usar o documento 1 3 ESCOPO Uma breve descri o da utilidade do Documento de Arquitetura de Software do que afetado e ou influenciado por ele 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Consultar o documento Gloss rio de Neg cios 1 5 REFER NCIAS Essa sub se o deve mostrar uma lista completa de todos os documentos referenciados ao longo desse plano Identifique cada documento por t tulo n mero do relat rio se aplic vel e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas 1 6 VIS O GERAL Descreve o que o restante do documento cont m e explica como o documento est organizado 2 REPRESENTA O ARQUITETURAL Esta se o descreve qual a arquitetura de software do sistema atual e
127. material estiver presente em outros artefatos por exemplo no Artefato Plano de Teste de Itera o AP NDICE C 15 PLANO DE TESTE lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt PLANO DE TESTES VERS O 1 Hist rico de revis o Data Vers o Descri o Autor SUM RIO T PEANODE TESTE anne 281 A o 281 1 2 EINALIBADE rn Se ee 281 1 3 AO O a ass apas da 281 do A O ayau ca 281 1 5 TERMINOLOGIA E ACR NIMOS DO 282 1 6 REFER NCIAS ee aaa 282 2 MISS O DE AVALIA O E MOTIVA O DOS TESTES 283 24 MISS O DE AVALIA O unas mma asas 283 3 ITENS DE TESTE ALVO uu 284 4 RESUMO DOS TESTES PLANEJADOS 285 4 1 RESUMO DAS INCLUSOES DOS 285 4 2 RESUMO DAS EXCLUSOES DOS 285 5 ABORDAGEM DOS TESTES ana 286 5 1 TIPOS E T CNICAS DE TESTE nono nn nnna nro co nncnnns 286 5 1 1 Teste de Integridade de Dados e de Banco de Dados 286 OBJETIVO DA TECNICA net 286 TECNICAS ae aa Deere 286 ESTRATEGIAS Haare 286
128. mento e junto a esse crescimento tamb m surgiam novos problemas na organiza o padroniza o das atividades e na constru o dos produtos Em contra partida os problemas dos clientes ficavam cada vez mais complexos aumentando mais ainda a dificuldade na hora de desenvolver ou integrar sistemas Para tentar ajudar s micro e pequenas empresas de software brasileiras um modelo de implementa o de processo para desenvolvimento de software foi desenvolvido observando se o perfil e os recursos dessas empresas A partir de um estudo detalhado nasceu o Prumo com uma proposta de mostrar que poss vel desenvolver software com qualidade sem que sejam necess rias grandes equipes compostas de pessoas altamente qualificadas para isso O Prumo possibilita que micro empresas com menos de dois anos de atividade e com uma disponibilidade de recursos limitado possam utiliz lo de forma pr tica e eficiente Para isso ele utiliza um m todo de controle eficiente sem sobrecarregar a equipe e mantendo apenas os artefatos mais importantes para o desenvolvimento de software com qualidade Al m disso outra de suas caracter sticas importantes a distribui o dos pap is dispon veis para uma equipe com um n mero menor de pessoas enfatizando a sua capacidade de adapta o as diferentes equipes encontradas facilmente no mercado A import ncia dessa proposta deve se s necessidades intr nsecas do mercado capitalista em busca de profiss
129. midade dos documentos criados e atualizados no decorrer do processo 4 T tulos Caracter sticas Exigidos w Comunicativo w Curso Superior em Tecnologia da Informa o Observador Y Experi ncia de um Ano w Bom Relacionamento Interpessoal w Saber Ouvir as Opini es da Equipe Desejados Y Especializa o em Qualidade de Software Y Especializa o em Engenharia de Software AP NDICE C ARTEFATOS AP NDICE C 1 SOLICITA O SOLICITA O lt Nome do projeto gt Solicitante lt Nome do solicitante gt Papel fun o lt Nome do papel ou fun o gt Perfil da solicita o Novo servi o Mudan a Treinamento Impactos previstos No cronograma lt Quantidade adicionada ou reduzida de dias gt No custo lt Valor do aumento ou redu o no previsto gt Na qualidade lt Possivel is impacto s na qualidade gt Nos riscos lt Novo s risco s observado s gt Parecer do respons vel Aprovado Reavaliar Renegociar Observa es 12 de mar o de 2010 Assinatura do solicitante 12 de mar o de 2010 Assinatura do respons vel AP NDICE C 2 DOCUMENTO DE VIS O lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt DOCUMENTO DE VIS O VERS O 1 Hist rico de revis o Data Vers o Descri o Autor 118 115 SUMARIO 1 VIS O ee 117 LE INTRODU
130. n es da forma como ele considerar mais conveniente Esse tipo de atitude n o interessante pelo fato de que a simples troca desse profissional mudar o padr o de codifica o dos softwares produzidos tornando onerosa a manuten o deles A caracter stica de personaliza o das atividades tamb m resulta em outro fator determinante para as empresas Esse fator seria o tempo e o esfor o para adequa o e aprendizado de um novo integrante da equipe ser bem maior Al m disso sabemos que a resist ncia s mudan as uma caracter stica intr nseca do ser humano Para enfatizar o exemplo FILHO 2006 p 9 mostra que o avan o tecnol gico no setor de inform tica tende a ser maior que o progresso t cnico no uso da inform tica afirmando que a principal explica o para o descasamento entre o ritmo de inova o tecnol gica no setor de inform tica e o progresso t cnico no uso da inform tica decorre primordialmente dos custos de adapta o e aprendizado defrontados pelas empresas FILHO HOCHSTETLER et al 2006 p 9 Portanto se a empresa possuir um processo de desenvolvimento que segue os conceitos sugeridos pela literatura ou os modelos de processos mais usados no mercado ela ter um ganho significativo no desempenho e na qualidade dos seus produtos e servi os al m do risco de atraso nos prazos tamb m diminu rem e poderem vislumbrar novos mercados podendo alcan ar at a exporta o 1 2 JUS
131. n o conformidade j foi apontada em um artefato e em uma segunda verifica o ela ainda permanece inalterada ou n o apresenta qualidade satisfat ria conforme n o conforme n o se aplica e pendente 43 Quando um dos itens de verifica o classificado como n o conforme o Analista de Qualidade notificar ao papel respons vel para que este possa realizar as devidas corre es 4 4 CONFROTAMENTO DE PAP IS Como sendo um dos objetivos pretendidos para este trabalho o Prumo tamb m pode flexibilizar os seus pap is de modo a atender as necessidades do ambiente onde ele est sendo aplicado Sabe se que muitas empresas de software geralmente trabalham com um quadro de funcion rios inferior s suas necessidades quando se trata de atividades Ou seja observ vel que na maioria dos casos uma pessoa acumule v rios pap is dentro de uma organiza o Isso n o encarado aqui como um problema mas sim como caracter stica devido ao dinamismo das empresas modernas que exigem dos seus colaboradores conhecimentos e habilidades um tanto distribu das Neste caso entenda como sendo uma pessoa que possui conhecimento em v rias reas e habilidade para lidar com diversas situa es diferentes 4 4 1 Distribuindo pap is em uma microempresa Para tornar mais claro o entendimento a cerca dessa caracter stica considere um exemplo de uma empresa contendo cinco pessoas Os papeis definidos para o Prumo ser o di
132. namento 2 DESAFIOS Desafios em vista que poder o ocorrer ao longo do treinamento 3 IMPACTOS Impactos que ocorrer durante o treinamento 4 FASES DO TREINAMENTO OPCIONAL Caso exista a necessidade de dividir o treinamento em fases especificar aqui como se dar essas fases 5 EMENTA Anexar a esse documento a ementa usada no treinamento Com a especifica o do conte do hora aula recursos usados dia e etc Pode ser usada como padr o uma ementa elaborada pela UFRJ mostrada abaixo EMENTA DE CURSO IDENTIFICA O DO CURSO Nome Nome da disciplina C digo C digo da disciplina Professor es Professor 1 Professor 2 Professor n Professor es colaborador es Professor 1 Professor 2 Professor n Carga hor ria XX hora s N mero de cr ditos XX quando necess rio N vel Fundamental M dio T cnico Superior Especializac o Pr requisitos Inexiste Existente Descreva o s pr requisito s Per odo de atividades Di rio Semanal Quinzenal Mensal Trimestral Semestral Endere o da disciplina na WEB endere o eletr nico do site da disciplina OBJETIVOS Descrever textualmente os objetivos gerais e espec ficos da disciplina EMENTA Faca um breve resumo da ementa de forma textual PROGRAMA e Primeiro assunto ou tema a ser trabalhado e Segundo assunto ou tema a ser trabalhado e Terceiro assunto ou tema a ser trabalhado e
133. ni o funcional e n o funcional dos requisitos de software incluindo a especifica o dos diversos diagramas necess rios para uma defini o concreta das funcionalidades e caracter sticas da solu o de software Para dar in cio a esta atividade deve se ter em m os documentos b sicos que descreva o ambiente e o problema que o Cliente enfrenta sendo resultantes documentos t cnicos de modelagem da solu o e prot tipos para avalia o Como respons vel por essa atividade temos o Analista de Requisitos Ele re ne todas as informa es inerentes ao projeto e elabora os artefatos Documento de Elicita o de Requisitos Especifica o de Casos de Uso e Prot tipos de Interface com o Usu rio Esses documentos funcionar o como alicerce para o projeto pois servir o como reposit rio principal de informa es o no decorrer de sua execu o do projeto 48 4 5 2 2 Revisar requisitos Esta atividade d suporte atividade de elicita o de requisitos atrav s de uma revis o no conte do produzido objetivando eliminar ambiguidades requisitos duplicados erros de entendimento e identificar o relacionamento entre os requisitos Nessa atividade o Cliente deve participar ativamente identificando equ vocos do Analista de Requisitos e sugerindo mudan as e definir o corretamente os requisitos Os artefatos destinados revis o s o Documento Elicitac o de Requisitos e Documento de Especifica o de Casos de Uso Assi
134. nte esse teste seja gerada alguma solicita o de mudan a j que esse o primeiro contato do cliente com a solu o e Teste de integra o um dos testes mais importantes para a escalabilidade do sistema Esse teste observa todos os aspectos da integra o da nova funcionalidade com o sistema em caso de ser uma integra o de uma nova funcionalidade a um sistema existente Durante a realiza o dos testes normalmente s o encontradas falhas inconsist ncias e irregularidades dependendo de qual seja a corre o encaminhada para a fase e atividade respons vel por resolv las Uma funcionalidade s passar para a fase seguinte se ela passar em todos os testes submetidos Isso especifica que ela esta em estado de aceita o e funcionamento 53 4 5 6 Atividades da fase de entrega Esta fase compreende todas as atividades necess rias para a entrega da s solu o es Nesta fase inicialmente s o definidas como ser o realizadas as implanta es e treinamentos aos usu rios necessitando de uma aten o maior dos respons veis em busca de melhorar cada vez mais o relacionamento com o cliente Em seguida ser o executados todos os treinamentos e a solu o finalmente ser implantada 4 5 6 1 Planejar treinamento e integra o Nessa atividade deve ser feito o planejamento para a realiza o dos treinamentos dos usu rios finais al m do planejamento de como ser feita a implanta o da solu o no
135. ntender regras de processos de neg cios de outras empresas e sabe persuadir o cliente em busca de descri es mais precisas das necessidades dele Esse perfil se responsabiliza pelo desenvolvimento de alguns artefatos do projeto e O Primeiro artefato o Gloss rio que um documento onde est o reunidos todos os termos incomuns tanto para o cliente quanto para a equipe O objetivo dele definir um vocabul rio compartilhado entre os stakeholders envolvidos do projeto a fim de unificar o entendimento para que n o haja ambiguidades No Prumo ele usado para especificar de forma unificada os termos comuns ao Cliente e a equipe Pode ser dividido em Gloss rio de Neg cios termos comuns aos neg cios do Cliente e Gloss rio de Projeto termos comuns equipe do projeto e O outro artefato denominado como Regras de Neg cio Nele o Cliente Interno especifica detalhadamente todas as regras de neg cio e que fazem parte do dom nio do problema Para a especifica o poderiam ser usados 7 Al m do Gloss rio outros artefatos est o detalhados no Ap ndice 37 cen rios de uso Este um documento muito importante para a compreens o do problema e principalmente para o controle das mudan as j que na maioria das vezes o ambiente do cliente din mico e suas regras de negocio mudam com facilidade O segundo perfil o do Cliente Externo incorporado por uma pessoa externa empresa de desenvolvimento Ge
136. o de uma solu o Aqui s o desenvolvidas todas as especifica es arquiteturais e codifica o de uma solu o 4 5 4 1 Definir arquitetura Atividade feita pelo Arquiteto de Software sendo uma das mais importantes para o sucesso do projeto Aqui ser o definidas todas as especifica es t cnicas diagramas de classe UML por exemplo da solu o na tecnologia definida na fase de an lise Enfim todo o arcabou o necess rio para a codifica o consistente da solu o O Arquiteto de Software ira desmembrar o documento de o documento de Arquitetura de Software e ir detalh lo de forma que possa ser executado pela equipe de desenvolvimento Nessa fase ser elaborado o plano de Integra o do Build que ter o formatados todos os conceitos t cnicos que ir o estruturar o sistema 4 5 4 2 Codificar A atividade de codifica o do software define os passos necess rios para criar todo o c digo fonte de todos os m todos predefinidos na atividade de arquitetar os requisitos Aqui o desenvolvedor cria revisa e comenta o c digo fonte de forma eficiente e facilite a leitura posterior Segundo definido nas fases anteriores ser o constru dos os algoritmos que constituir o o produto de software que obedecer o ao padr o de constru o definido no Modelo de Implementa o do Software 4 5 5 Atividades da fase de teste Nesta fase s o definidos todos os testes necess rios para a avalia o das funcionalidades desenvolvidas N
137. o nas altera es dos requisitos Ele tamb m pode relacionar v rias outras caracter sticas de um projeto atrav s da rastreabilidade entre elas ou seja a interliga o existente entre caracter sticas e especifica es da solu o Para realizar esse controle podem ser usadas planilhas eletr nicas onde na linha est o expostas uma das caracter sticas e na coluna a outra Para ter uma vis o mais concreta sobre como seria esse tipo de controle consulte o Ap ndice C 9 nele h um exemplo de uma Matriz de Rastreabilidade que pode ser tomada como base para a constru o sua pr pria matriz Por fim no artefato Documento de Especifica o de Casos de Uso o Analista de Requisitos cria diagramas de casos de uso UML demonstrando claramente quem atores interage com que funcionalidade caso de uso e detalhando os atrav s de descri o formal ou diagrama de atividades UML Aqui o ator representa qualquer entidade que interaja com o sistema informado dados Ele pode ser um usu rio um subsistema ou at mesmo um sistema externo Rational Software Corporation 2002 39 4 3 3 Gerente de Projetos Uma pessoa que det m as atribui es desse papel deve possuir esp rito de lideran a e trabalho em equipe Um Gerente de Projetos deve ser capaz de liderar uma equipe de projetos de forma que ela venha ter o m ximo de desempenho poss vel Ele deve ser capaz de gerenciar de maneira efetiva os riscos de um projeto Para isso ele deve
138. odutor de imagem da configura o b sica e Ferramentas de backup e de recupera o e Ferramentas de monitoramento de instala o registro disco r gido CPU mem ria etc e Ferramentas de gera o de dados Necess rias Crit rios de A t cnica suporta o teste de Exito e Todos os principais cen rios de caso de uso e Todos os principais recursos Considera es Identifique ou descreva os itens ou problemas internos ou externos que exercem influ ncia sobre a implementa o e a execu o do teste de funcionamento Especiais 5 1 3 Teste de Interface do Usu rio O Teste de Interface do Usu rio UI verifica a intera o do usu rio com o software O teste de tem por fim assegurar que a UI forne a ao usu rio o acesso a navega o adequados atrav s das fun es do objetivo do teste Al m disso o teste de UI assegura que os objetos contidos na UI funcionem conforme o esperado e estejam em conformidade com padr es corporativos ou da ind stria Objetivo da Experimentar o seguinte para observar e registrar a conformidade com padr es e o comportamento alvo e navega o pelo objetivo do teste para verificar se reflete os requisitos e fun es de neg cios incluindo a navega o janela a janela e campo a campo e o uso de m todos de acesso teclas de tabula o movimentos do mouse e teclas aceleradoras e As caracter sticas e os objetos das janelas poder o ser exp
139. orma es necess rias para que o leitor entenda o conceito AP NDICE C 5 ATA DE REUNI O 161 ASSUNTO T TULO DATA HOR RIO LOCAL Reuni o presidida por lt Nome do presidente da reuni o gt Tipo de reuni o lt Estrat gica Decis ria Informativa Negocial gt Facilitador a lt Nome do facilitador a gt Secret rio a lt Nome do secret rio a gt Cronometrista lt Nome do a cronometrista gt Participantes lt Participante 1 gt lt Participante 2 gt lt Participante n gt T PICOS DA AGENDA e PRIMEIRO T PICO DA AGENDA e SEGUNDO T PICO DA AGENDA e ENESIMO T PICO DA AGENDA TEMPO ALOCADO PRIMEIRO T PICO DA AGENDA APRESENTADOR Discuss o lt Nome do presidente da reuni o gt Conclus es lt Estrat gica Decis ria Informativa Negocial gt Itens de a o Respons vel Prazo lt Primeira a o a serexecutada gt lt do respons vel gt lt dd mm aaaa gt lt Segunda a o a ser executada gt lt Nome do respons vel gt lt dd mm aaaa gt lt En sima a o a ser executada gt lt Nome do responsdvel gt lt dd mm aaaa gt TEMPO ALOCADO SEGUNDO TOPICO DA AGENDA APRESENTADOR Discussao lt Nome do presidente da reuni o gt Conclus es lt Estrat gica Decis ria Informativa Negocial gt 162 Itens de a o Respons vel Prazo lt Primeira a o a ser executada gt lt Nome do responsdvel gt lt dd mm aaaa gt lt Segund
140. os meios de comunica o podem ser adotados e especificados em um outro artefato denominado Plano de Comunica o geralmente usado em grandes projetos 4 5 1 2 Analisar necessidade Essa atividade descreve como ser realizada a atividade de an lise de necessidades do Cliente que solicitou um servi o Ela especifica tamb m como observar o ambiente do Cliente em busca de conhecimentos mais detalhados sobre o problema em quest o e a forma como as pessoas que s o afetadas por ele abordam a problem tica e prop e solu es para os mesmos Ser o identificadas as necessidades expostas na Solicita o e ent o ser o reunias a maior quantidade de informa es poss veis sobre aquele contexto Para essa atividade ser o necess rios o artefato de Vis o de Neg cio Gloss rio e Regras de Neg cio sendo estes utilizados pelos pap is Cliente e Analista de Requisitos O Analista de Requisitos ser respons vel por analisar o cen rio da solicita o as necessidades do Cliente receber e propor sugest es de solu o para o problema das partes envolvidas J o Cliente ser respons vel por disponibilizar essas informa es e propor solu es para o problema 4 5 1 3 Negociar proposta de solu o Esta atividade indica de que forma ocorrer o processo de negocia o da proposta de solu o feita pelo Analista de Requisitos e Gerente de Projetos Em vis o geral prop e se uma reuni o entre Cliente Analista de Requisitos e Gerent
141. para executar esses testes e Esses testes s o desnecess rios devido aos testes executados por xxxx Segundo um prisma heur stico se voc achar que perfeitamente conceb vel que um dos membros de seu p blico espere que um determinado aspecto de teste seja inclu do e se voc n o pretender ou n o puder inclu lo justifique sua exclus o Se a equipe concordar que a exclus o bvia voc provavelmente n o precisar list la 5 ABORDAGEM DOS TESTES Esta se o apresenta a estrat gia recomendada para criar e implementar os testes necess rios As se es 3 Itens de Teste Alvo e 4 Resumo dos Testes Planejados identificaram que itens ser o testados e que tipos de testes ser o executados Esta se o descreve como esses testes ser o realizados Um aspecto a ser considerado na abordagem dos testes as t cnicas que ser o usadas Dever ser inclu do um resumo de como cada t cnica poder ser implementada de uma perspectiva manual e ou automatizada e os crit rios para comprovar que a t cnica til e eficaz Para cada t cnica forne a uma descri o a seu respeito e defina por que uma parte importante da abordagem dos testes resumindo brevemente como ela ajuda a alcan ar a Miss o de Avalia o ou como aborda os Motivadores dos Testes Outro aspecto a ser discutido nesta se o os modelos de Erro ou Falha que s o aplic veis e as maneiras de abordar como avalid los 5 1 TIPOS E T CNICAS DE TESTE
142. plano de coleta medi o e avalia o das m tricas 4 5 PLANO DE GER NCIA DE RISCOS Descri o sucinta do planejamento de ger ncia de riscos 4 6 PLANO DE ENCERRAMENTO Descri o sucinta sobre as atividades de encerramento do projeto 5 PLANOS DE APOIO AO PROCESSO 5 1 PLANO DE GER NCIA DE CONFIGURA O Refer ncia para o plano de ger ncia de configura o 5 2 PLANO DE AVALIA O Descreve como o produto ser homologado as t cnicas de homologa o e os crit rios de aceita o 5 3 PLANO DE DOCUMENTA O Descri o sucinta dos templates utilizados durante o projeto 5 4 PLANO DE GARANTIA DE QUALIDADE Refer ncia para o plano de garantia de qualidade 5 5 PLANO DE SOLU O DE PROBLEMAS Descri o sobre como relatar e solucionar problemas utilizando as ferramentas de ger ncia de mudan as 5 6 PLANO DE MELHORIA DO PROCESSO Descri o sucinta sobre o planejamento para melhorar continuamente o processo de desenvolvimento de software AP NDICE C 12 DOCUMENTO DE ARQUITETURA DE SOFTWARE lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt DOCUMENTO DE ARQUITETURA DE SOFTWARE VERS O 1 233 Historico de revisao Data Versao Descri o Autor 235 SUM RIO 1 DOCUMENTO DE ARQUITETURA DE 237 1 1
143. presa 2 2 TERMINOLOGIA Nessa se o ser o definidos como ser o nomeadas os elementos estruturais que constituem o projeto segundo necessidade e paradigmas usados Vari veis Forne a a regra de como ser o atribu dos os seus nomes M todos Forne a a regra de como ser o atribu dos os seus nomes Atributos Forne a a regra de como ser o atribu dos os seus nomes Classes Forne a a regra de como ser o atribu dos os seus nomes Pacotes Forne a a regra de como ser o atribu dos os seus nomes Fun es Forne a a regra de como ser o atribu dos os seus nomes Sub fun es Forne a a regra de como ser o atribu dos os seus nomes 2 3 DOCUMENTA O Forne a um documenta o do c digo fonte Defina como o autor organizar as informa es autorais e de vers o no c digo AP NDICE C 14 PLANO DE INTEGRA O DO BUILD lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt PLANO DE INTEGRA O DO BUILD VERS O 1 Hist rico de revis o Data Vers o Descri o Autor SUM RIO 1 PLANO DE INTEGRA O DO BUILD I u uuu 269 INOUE 269 2 EINALD DE ee 269 fios ES OR een ee 269 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 269 1 5 REFERENCIAS L L Rn ae 269 1 6 VIS O GERAL
144. que exercem influ ncia no contexto mas que n o foram mencionados diretamente Especifique as fontes a partir das quais as vers es oficiais das refer ncias podem ser obtidas como por exemplo nomes UNC de intranet ou c digos de refer ncia de documento Essas informa es podem ser fornecidas por um anexo ou outro documento 2 MISS O DE AVALIA O E MOTIVA O DOS TESTES Forne a uma vis o geral da miss o e da motiva o dos testes que ser o conduzidos nesta itera o 2 1 MISSAO DE AVALIA O Forne a uma breve senten a que defina a miss o do esfor o de avalia o na itera o atual Essa senten a poder incorporar uma ou mais preocupa es incluindo e Localizar o maior n mero de erros poss vel e Localizar problemas importantes e Avaliar os riscos da qualidade percept vel e Informar sobre os riscos percept veis do projeto e Certificar segundo um padr o e Verificar uma especifica o requisitos design ou alega es e Informar sobre a qualidade do produto e Satisfazer os envolvidos e Informar sobre os testes e Cumprir as determina es do processo e por diante Cada miss o fornece um contexto diferente para o esfor o de teste e altera a maneira como o teste dever ser abordado 3 ITENS DE TESTE ALVO A listagem abaixo identifica os itens de software de hardware e elementos de suporte do produto que foram identificados como objetivos dos testes Esta lista repr
145. r caso Prioridad 0 Essencial O Importante O Desej vel 3 REQUISITOS N O FUNCIONAIS Aqui ser o descritos os requisitos n o funcionais suas caracter sticas e sua import ncia para o projeto 3 1 USABILIDADE Esta se o cont m todos os requisitos que afetam a usabilidade Por exemplo e Especifique o tempo de treinamento necess rio para que usu rios normais e usu rios com conhecimentos avan ados se tornem produtivos em opera es espec ficas e Especifique per odos de tempo mensur veis para tarefas t picas ou baseie os requisitos de usabilidade do novo sistema em outros sistemas que os usu rios conhe am e gostem e Especifique requisitos de forma que estejam em conformidade com padr es de usabilidade comuns como por exemplo os padr es CUA da IBM ou os padr es GUI da Microsoft 3 1 1 RNFOO1 Primeiro requisito n o funcional de usabilidade Uma descri o detalhada do requisito RNFOO1 3 1 2 RNFOO2 Segundo requisito n o funcional de usabilidade Uma descri o detalhada do requisito RNFOO1 3 2 CONFIABILIDADE Os requisitos de confiabilidade do sistema devem ser especificados aqui A seguir h algumas sugest es Disponibilidade especifique a porcentagem de tempo dispon vel xx xx as horas de uso o acesso manuten o as opera es de modo degradado etc Tempo M dio entre Falhas MTBF normalmente especificado em horas mas tamb m poder ser especificado em termos d
146. ralmente representado pela pessoa que procura a solu o ou algu m indicado por ele com capacidade para responder s quest es problem ticas enfrentadas Este perfil de cliente pode apresentar pouco ou quase nenhum conhecimento sobre computadores de um modo geral e Sobre artefatos o Cliente Interno respons vel por todos os documentos fornecidos por ele para defini o e entendimento do problema Esses artefatos podem ser dos mais variados tipos relat rios planilhas anota es desenhos documentos etc At o momento foram analisados esses dois perfis de Cliente que se encaixam no Prumo por m nada impede que outros perfis sejam observados e considerados 4 3 2 Analista de Requisitos O papel de Analista de Requisitos representa a pessoa que consegue observar o ambiente do Cliente identificando os problemas e propondo solu es vi veis e interessantes para o ele O Analista de Requisitos tamb m deve possuir habilidades para persuadir o Cliente deixando o a vontade para expor suas ideias e necessidades independente do perfil de Cliente considerado Como observado no Ap ndice B 2 defini o do papel e Ap ndice A ciclo de vida e mapa de atividades o Analista de Requisitos possui atribui es de comunica o com o Cliente e desempenha atividades importantes para a empresa por isso ele respons vel pelo artefato Documento de Vis o de Neg cio Neste documento est o contidas informa es relevantes como as van
147. rcado de duas pontas enfatizando a import ncia da vis o de uma empresa diante do mercado consumidor e da sua equipe de desenvolvimento Ele menciona que os fabricantes de sistemas operacionais devem observar os dois lados do mercado para que seu produto seja aceito e utilizado amplamente Numa ponta est o os fabricantes de aplicativos que precisam de recursos atrativos e incentivos para produzir softwares cada vez melhores Na outra ponta est o os usu rios na expectativa de usufruir de um sistema operacional f cil e com bons aplicativos dispon veis 10 O exemplo citado acima serve para refor ar a posi o que as empresas de software devem tomar para que atendam as expectativas da sua equipe oferecendo a eles uma estrutura organizacional e um processo de desenvolvimento bem definido Consequentemente a empresa passar a produzir softwares com mais qualidade e assim atraindo cada vez mais clientes Outra pesquisa interessante foi desenvolvida pela Associa o das Empresas Brasileiras de Tecnologia da Informa o Software e Internet ASSESPRO sobre pol ticas tribut rias para o desenvolvimento do setor de tecnologia da informa o Em um dos t picos UENO 2007 p 5 mostra que o Brasil possui o 7 lugar mercado mundial de software com crescimento anual variando em torno dos 11 nos ltimos quinze anos Isso significa que o mercado brasileiro tem capacidade para produzir solu es interessantes n o somente para o mercado
148. re de acordo com a classifica o das empresas 2224444000nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 14 LISTA DE TABELAS Tabela 2 1 Classifica o das micro e pequenas empresas de software brasileiras seg ndo o SE 15 LISTA DE SIGLAS E ABREVIATURAS ABES Associa o Brasileira das Empresas de Software ASSESPRO Associa o das Empresas Brasileiras de Tecnologia da Informa o Software e Internet BID Banco Interamericano de Desenvolvimento CMMI Capability Maturity Model Integration DER Diagrama Entidade relacionamento ER Entidade Relacional diagrama FINEP Financiadora de Estudos e Projetos GMS Gerenciamento de Mudan a de Software GQS Gerenciamento de Qualidade de Software ISO International Organization for Standardization IBM International Business Machines MA MPS M todo de Avalia o para Melhoria do Processo de Software MCT Minist rio da Ci ncia e Tecnologia MPS BR Melhoria do Processo de Software Brasileiro POO Programa o Orientada Objetos paradigma RUP Rational Unified Process SEBRAE Servi o Brasileiro de Apoio s Micro e Pequenas Empresas SGC Software para gerenciamento de credi rios SOFTEX Sociedade Brasileira para a Promo o da Exporta o de Software RESUMO Este trabalho apresenta uma proposta de um processo de desenvolvimento de software para micro e pequenas empresa de tecnologia da informa o Sua cons
149. recer os conceitos sobre aplica es que envolvem a defini o e implanta o de um processo de software 1 4 OBJETIVOS ESPEC FICOS Especificamente este trabalho pretende atender as necessidades do grupo universit rio citado anteriormente na produ o de um software denominado Software para Gerenciamento de Credi rios Devido s caracter sticas da equipe serem muito semelhantes com as de uma micro empresa pretende se e Definir um processo de desenvolvimento de software voltado para micro e pequenas empresas e Propor uma abordagem ou modelo de processo que ajude a visualizar melhor os v rios n veis de detalhamento de um processo de software e Definir cada n vel de detalhamento do processo de forma a esclarecer precisamente a aplica o de cada uma e Utilizar um estudo de caso como justificativa para o desenvolvimento deste trabalho 1 5 FUNDAMENTA O TE RICA Sobre este assunto j foram realizadas pesquisas abordando alguns aspectos por outros pesquisadores estudantes e profissionais da rea de tecnologia da informa o e telecomunica es As linhas seguintes mostrar o alguns desses trabalhos e quais caracter sticas se assemelham a solu o apresentada enfatizando o diferencial deste Um estudo encomendado pela Associa o Brasileira das Empresas de Software Abes analisou v rios aspectos do mercado de brasileiro software sendo que em uma das se es FILHO 2006 p 8 observa o como um me
150. revis o Data Vers o Descri o Autor 201 SUM RIO 1 PROT TIPO DE INTERFACE COM O USU RIO 203 INTRODUC O canto isa TSE NS A usu ama ai aan 203 2 EINALD DE nana nana ana Qhas ana a 203 iI SAMOS Co ger na ns nt sata na nas SAS 203 TA REFERENCIAS anne co ad 203 1 5 VISAO GERAL SS E UA DS 203 2 MODELOS aa u uuu 204 2 1 BUM MODELOS 204 22 OUTRO MODE Osio 204 2 3 lt UMGRUPO DE MODELOS gt 204 2 3 1 lt Um modelo do grupo gt susi 204 2 3 2 lt Outro modelo do grupos T 204 1 PROT TIPO DE INTERFACE COM O USU RIO 1 1 INTRODU O A introdu o do Prot tipo de interface com o usu rio fornece uma vis o geral de todo o documento Apresente todas as informa es que poder o ser necess rias para que o leitor compreenda o documento nesta se o Este documento usado para definir a terminologia espec fica do dom nio do problema explicando termos que podem ser desconhecidos do leitor das descri es de caso de uso ou de outros documentos do projeto Freg entemente este documento poder ser usado como um dicion rio de dados informal capturando defini es de dados para que as descri es de caso de uso e outros documentos do projeto possam concentrar se no que o sistema deve fazer com as informa es Este doc
151. roporcionar entender os objetivos e os m todos utilizados no processo de forma integral Al m disso ter em m os um processo de desenvolvimento de software que mostrar formas de como aproveitar melhor seus recursos proporcionando um aumento na qualidade dos servi os prestados e na produtividade da empresa como um todo ABSTRACT This paper presents a proposal for a process of software development for micro and small enterprise information technology lts construction was motivated from the need for a group of students with a real customer who needed a software to help manage your company In search of a concrete development systematic ensuring a good quality of the software product they sought the knowledge gained answers and solutions to achieve these goals It was then that the Plummet to guide them towards an easy efficient and competitive merchandising From it were also carried out field research and literature noting characteristics of the target market Then surprise Not only them but the vast majority of the Brazilian software market consists of micro and small businesses that need to add quality to the process of software production Therefore this proposal becomes also a study that can be widely used to reduce costs and improve resource distribution of micro and small business IT With the aim of theoretical readers were discussed concepts of some major authors Pressman Sommerville processes methods sequential
152. s mais usadas no dia a dia das empresas Finalizando com alguns modelos denominados aqui como padr es por excel ncia por serem considerados muito importantes para o desenvolvimento de um bom processo de software 3 1 DEFINI O DE PROCESSO Por ser um termo com ampla utiliza o nas diversas reas do conhecimento faz se necess rio um direcionamento do seu significado ao tema em quest o A primeira defini o abrangente o bastante para explicar o conceito logo um processo pode ser definido como uma s rie de a es na qual uma ou mais entradas s o utilizadas para produzir uma ou mais sa das AMBER 1998 Caracter stica bastante vis vel nas atividades do Prumo 3 2 DEFINI O DE PROCESSO DE SOFTWARE Assim pensando em Engenharia de Software define se como um conjunto de passos parcialmente ordenados visando atingir uma meta que neste caso entregar um produto de software com qualidade dentro dos prazos e custos estabelecidos Diversos autores renomados tentam definir processo de software enfatizando os aspectos mais importantes Sendo assim SOMMERVILLE 2001 p 44 define como sendo um conjunto de atividades direcionadas constru o de um produto de software Esta defini o pode ser ainda mais abrangente aplicando as seguintes palavras de PRESSMAN Um processo de software base para o controle gerencial de projetos de software e estabelecimento do contexto no qual os m todos t cnicos s o aplicados o
153. s produtos de trabalho modelos documentos dados relat rios formul rios etc s o produzidos os marcos s o estabelecidos a qualidade assegurada e as modifica es s o adequadamente geridas 2006 p 17 18 Observa se facilmente que todos eles possuem um mesmo referencial atingir o objetivo de entregar um produto de software com qualidade e atendendo as expectativas do cliente Quando o objetivo alcan ado todos os envolvidos no processo estar o satisfeitos tanto a equipe por desenvolver um bom trabalho quando o cliente por ter um sistema confi vel e financeiramente acess vel 3 3 MODELOS DE PROCESSOS O estudo de modelos de processos de software interessante para observar como a organiza o das atividades faz a diferen a no momento de se produzir um software Por isso os t picos seguintes abordam os modelos Cascata Iterativo Incremental Espiral e traz exemplos de metodologias geis de desenvolvimento tentando explicar como eles abordam e organizam suas propostas de processos de software e apresentando seus pontos positivos e negativos 3 3 1 Modelo em cascata o paradigma mais antigo da engenharia de software sendo algumas vezes chamado de ciclo de vida cl ssico PRESSMAN 2006 p 39 um modelo de desenvolvimento de software sequencial no qual o desenvolvimento visto como um fluir constante para frente como uma cascata atrav s das fases de an lise de defini o dos requisitos design
154. s refer ncias podem ser obtidas 2 PLANEJAMENTO DE IMPLANTA O Descreva todas as atividades executadas na implanta o do produto para o cliente As atividades incluem planejamento teste beta prepara o de itens a serem disponibilizados empacotamento envio instala o do produto treinamento e suporte 2 1 RESPONSABILIDADES Identifique as responsabilidades do cliente e da equipe de desenvolvimento na prepara o para a implanta o O mais importante nesta se o a descri o do envolvimento do cliente nos testes de aceita o e no processo de tratamento de discrep ncias 22 PROGRAMA O Descreva o programa e os marcos para a condu o das atividades de implanta o Os marcos de implanta o devem ser compat veis com os marcos do projeto Leve em considera o os seguintes detalhamentos do fluxo de trabalho de Implanta o Planejamento da implanta o Desenvolvimento do material de suporte Gerenciamento dos testes de aceita o o Testes de aceita o no local de desenvolvimento o Testes de aceita o no local de implanta o Produ o da unidade de implanta o Gerenciamento do programa beta Gerenciamento da produ o em massa e do empacotamento do produto Disponibiliza o do produto pela internet 3 RECURSOS Liste os recursos e suas fontes necess rios para executar as atividades de implanta o 3 1 INSTALACOES Se aplic vel descreva as instala
155. sentante Quem o representante do envolvido no projeto Opcional se j estiver documentado em outro lugar Forne a nome da pessoa Representante Uma breve descri o do tipo envolvido Tipo Qualifique a habilidade a forma o t cnica e o grau de sofistica o do envolvido ou seja se ele um guru executivo especialista usu rio eventual e assim por diante Responsabilidades Liste as principais responsabilidades dos envolvidos no que diz respeito ao sistema em desenvolvimento ou seja o interesse deles como envolvidos Crit rios de Sucesso Como o envolvido define sucesso De que forma o envolvido recompensado Envolvimento Qual o grau de comprometimento do envolvido no projeto Especifique quando poss vel os pap is exercidos no Rational Unified Process ou seja Revisor de Requisitos etc Produtos Liberados H produtos liberados adicionais necess rios ao envolvido Podem ser os produtos liberados do projeto ou as sa das do sistema em desenvolvimento Coment rios Problemas Problemas que interfiram no bom andamento do projeto e outras informa es relevantes devem ser relacionados aqui 37 PERFIS DE USU RIOS Descreva cada usu rio nico do sistema preenchendo a seguinte tabela para cada tipo de usu rio Lembre se de que os tipos de usu rio poder o ser os mais diversos como por exemplo gurus e principiantes Por exemplo um guru poder precisar de uma ferramenta flex ve
156. senvolvimento sequencial apresenta um aspecto que n o muito interessante para o mercado de software atual Como se pode ver o software especificado desenvolvido testado e integrado de forma completa e implantado de uma s vez Assim os desenvolvedores n o conseguem acompanhar as necessidades do cliente 21 com as regras de neg cio dele mudando rapidamente devido ao dinamismo do mercado Sendo assim ao praticar o desenvolvimento de software com essa abordagem prov vel que o ele n o consiga atender as necessidades do cliente desde a sua concep o Por m esta forma de desenvolver software facilita o aprendizado e entendimento pelo fato de que as atividades est o organizadas sequencialmente A vantagem do modelo incremental em rela o ao sequencial que ele possibilita a inser o de funcionalidades de cada vez Assim o cliente come a a utilizar uma parte da solu o de cada vez solicitando mais funcionalidades ou m dulos para desenvolvimento e integra o A desvantagem desse modelo que uma vez definida a funcionalidade e o desenvolvimento iniciado o cliente s poder solicitar altera es ap s o desenvolvimento dela Podendo em alguns casos causar o desenvolvimento errado de uma funcionalidade devido uma m interpreta o dos requisitos ou se o cliente n o tiver se expressado da forma correta A iteratividade por si s j interessante ou seja criar uma funcionalidade de forma i
157. ser bem melhoradas para se tornarem atrativas para o setor Em se tratando de processo a Sociedade Brasileira para a Promo o da Exporta o de Software SOFTEX apoiada por v rias institui es entre elas o Minist rio da Ci ncia e da Tecnologia MCT criaram em 2003 um modelo de refer ncia para Melhoria do Processo de Software Brasileiro MPS BR adaptado para a realidade e a cultura local e dentro dos padr es internacionais como ISO IEC 12 207 ISSO IEC 15 504 e CMMI DEV Trazendo mais credibilidade e seguran a para os produtos de software desenvolvidos no Brasil A se o 3 4 2 trar mais informa es sobre o MPS BR 14 2 2 PERFIL DAS EMPRESAS 5 1 8 Micro 8 Pequena M dia E Grande Gr fico 2 1 Distribui o do mercado brasileiro de software de acordo com a classifica o das empresas Segundo a pesquisa da Abes FILHO HOCHSTETLER et al 2006 p 21 existiam cerca de 7 7 mil empresas que atuando no desenvolvimento produ o e distribui o de software e presta o de servi os Deste total 54 s o de empresas de distribui o 22 de servi os relacionados e 24 atuam na produ o de software Al m disso como mostra o Gr fico 2 1 as empresas que empregam menos de 50 funcion rios micro e pequenas equivalem a 94 do mercado 23 ORGANIZA O A organiza o das micro e pequenas empresas de software do pa s tamb m algo muito importante e deve ser levado em considera o sob v
158. sidades est o descritos nas especifica es suplementares e de caso de uso A introdu o do documento de Vis o oferece uma vis o geral de todo o documento Ela cont m a finalidade o escopo as defini es os acr nimos as abrevia es as refer ncias e a vis o geral deste documento Vis o 1 2 FINALIDADE Especifique a finalidade deste documento Vis o 1 3 ESCOPO Uma breve descri o do escopo deste documento Vis o a que Projeto s ele est associado e tudo o mais que seja afetado ou influenciado por este documento 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Estas informa es est o presentes no gloss rio 1 5 REFER NCIAS Esta subse o apresenta uma lista completa de todos os documentos mencionados no documento de Vis o Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 1 6 VIS O GERAL Esta subse o descreve o que o restante do documento Vis o cont m e explica como o documento est organizado 2 PADROES DE CONSTRU O 2 1 MODELO ESTRUTURAL Forne a o padr o da estrutura visual das classes a serem criadas Ser definido onde ser o descritos coment rios instancia o de objetos endenta o e etc De modo geral ser mostrado o modelo de classe fun o da em
159. somente requisitos em estilo de linguagem natural tradicional sem modelagem de casos de uso Essa SRS captura todos os requisitos em um nico documento com se es aplic veis inseridas a partir das Especifica es Suplementares que n o ser o mais necess rias Para ter acesso a um template de uma SRS que utilize a modelagem de casos de uso que consiste em um pacote contendo Casos de Uso do modelo de casos de uso e Especifica es Suplementares aplic veis assim como outras informa es de suporte consulte o arquivo rup srsuc dot poss vel organizar a SRS de v rias maneiras diferentes Consulte o padr o IEEE830 1998 para obter explica es mais detalhadas assim como outras op es de organiza o de uma SRS 1 2 FINALIDADE Especifique a finalidade desta SRS A SRS descreve totalmente o comportamento externo do aplicativo ou do subsistema identificado Ela tamb m descreve requisitos ndo funcionais restri es de design e outros fatores necess rios para fornecer uma vis o completa e abrangente dos requisitos do software 1 3 ESCOPO Uma breve descri o do aplicativo de software ao qual se aplica a SRS do recurso ou de outro agrupamento de subsistemas do s modelo s de Casos de Uso associado s a ela e de tudo o que for afetado ou influenciado por este documento 1 4 DEFINI ES ACR NIMOS E ABREVIA ES Esta subse o fornece as defini es de todos os termos acr nimos e abrevia es necess
160. stribu dos para esse n mero de pessoas considerando a grande quantidade de atividades que cada papel possui n o tornando um ou outro papel sobrecarregado ao ponto de deixar o processo ineficiente Nos projetos de software cada papel tem seu objetivo e interesses definidos por m alguns deles n o podem ser exercidos simultaneamente pela mesma pessoa por correrem o risco de agredir a qualidade do produto e do processo Em contrapartida outros pap is podem ser agrupados de forma eficiente devido s caracter sticas que cada um deles possuem A seguir continuaremos com um exemplo O primeiro agrupamento a ser considerado realiza a jun o entre os pap is de Cliente interno e Analista de Requisitos onde o segundo incorpora as atribui es 44 do primeiro O objetivo dessa jun o est no fato de o Analista de Requisitos tamb m possuir caracter sticas de comuni o com o Cliente externo Logo o Analista de Requisitos passa a ser respons vel pelo artefato de Regras de Neg cio e Gloss rio O segundo agrupamento une o Arquiteto de Software com o Desenvolvedor Nesse caso O primeiro papel passar a desempenhar todas as atribui es do segundo ficando respons vel pelo Componente de Software e realizando todo o processo de codifica o O terceiro agrupa o Gerente de Projetos com o Analista de Qualidade sendo motivado pelo fato de o primeiro papel acompanhar todas as atividades do processo Assim al m dele gerenciar
161. t Primeiro fluxo alternativo gt As alternativas mais complexas s o descritas em uma se o separada mencionada na subse o fluxo b sico da se o fluxo de eventos Pense nas subse es fluxo alternativo como comportamentos alternativos cada fluxo alternativo representa um comportamento alternativo geralmente devido a exce es que ocorrem no fluxo principal O tamanho desses fluxos poder ser t o extenso quanto o necess rio para descrever os eventos associados ao comportamento alternativo Quando um fluxo alternativo termina os eventos do principal fluxo de eventos s o retomados a menos que seja especificado algo em contr rio 2 2 2 lt Um subfluxo alternativo gt 190 Os fluxos alternativos por sua vez podem ser divididos em subse es se isso contribuir para maior clareza 2 2 3 lt Segundo fluxo alternativo gt Pode haver e muito provavelmente haver uma s rie de fluxos alternativos em um caso de uso Mantenha cada fluxo alternativo separado para aumentar a clareza O uso de fluxos alternativos melhora a legibilidade do caso de uso e evita que os casos de uso sejam decompostos em hierarquias de casos de uso Lembre se de que os casos de uso s o apenas descri es textuais e que sua finalidade principal documentar o comportamento de um sistema de maneira clara concisa e compreensivel 191 3 REQUISITOS ESPECIAIS Normalmente um requisito especial um requisito n o funcional espec fico de um caso
162. tagens que o cliente ter caso ele contrate a solu o Al m disso esse documento especifica em detalhes o ambiente do cliente e identifica quais os poss veis usu rios e envolvidos no projeto mostrando Um cen rio uma narrativa textual ou pict rica de uma situa o de uso de uma aplica o envolvendo usu rios processos e dados reais ou potenciais REZENDE 2003 38 para cada um deles as caracter sticas atribui es e necessidades Adicionalmente s o elicitados todos os problemas enfrentados e as poss veis solu es para eles z Outra atividade desempenhada pelo Analista de Requisitos a identifica o defini o e especifica o de requisitos em casos de uso Em consequ ncia disso ele se torna respons vel pelos artefatos Documento de Elicita o de Requisitos e Documento de Especifica o em Casos de Uso No Documento de Elicita o de Requisitos ele organiza os requisitos dando um n mero identificador e uma descri o para cada um dos requisitos funcionais RF representam as funcionalidades da solu o n o funcionais RNF representam as caracter sticas da solu o e cria um escopo negativo deixando expl cito o que n o faz parte da solu o Uma forma de ele organizar os requisitos e identificar o relacionamento entre eles criando uma Matriz de Rastreabilidade Este artefato pode relacionar tanto RF com RF quanto RF com RNF sendo importante para identificar o impact
163. tensibilidade confiabilidade portabilidade e assim por diante Se essas caracter sticas possu rem significado especial como implica es de seguran a garantiam ou privacidade elas dever o ser delineadas claramente AP NDICE C 13 MODELO DE IMPLEMENTA O lt Nome da Empresa gt lt Slogan gt lt Rua gt N lt N mero gt lt Bairro gt lt Cidade gt lt UF gt CEP lt CEP gt lt NOME DO PROJETO gt MODELO DE IMPLEMENTA O DE SOFTWARE VERS O 1 253 Historico de revisao Data Versao Descri o Autor 255 SUMARIO 1 MODELO DE IMPLEMENTA O DE SOFTWARE 257 A o a 257 t2 RINALIDAD E NS 257 fios naa nana 257 1 4 DEFINI ES ACR NIMOS E ABREVIA ES 257 1 5 PREFERENCIAS Ouo asia asin SI NIN 257 86 VIS O GERAL A a 258 2 PADROES DE CONSTRU O iaa 259 2 1 MODELO ESTRUTURAL reter 259 22 TERMINOLOGIA a 259 23 _ DOCUMENTA CAQ a 259 1 MODELO DE IMPLEMENTA O DE SOFTWARE 1 1 INTRODU O A finalidade deste documento coletar analisar e definir as necessidades e caracter sticas de n vel superior do lt lt Nome do Sistema gt gt Ele se concentra nos recursos necess rios aos envolvidos e aos usu rios alvo e nas raz es que levam a essas necessidades Os detalhes de como o lt lt Nome do Sistema gt gt atende a essas neces
164. terada permite ao cliente expressar sua necessidade de forma fragmentada e analisada observando os equ vocos e mudan as ocorridas no ambiente do cliente Isso torna o produto de software mais adequado s necessidades do cliente Em contrapartida essa itera o no desenvolvimento pode levar o cliente a atrapalhar o andamento do projeto com a inser o desordenada de funcionalidades 3 3 4 Modelo em espiral Este modelo tem o objetivo de prover um metamodelo que pode acomodar diversos processos espec ficos Isto significa que podemos encaixar nele as principais caracter sticas dos modelos vistos anteriormente adaptando os a necessidades espec ficas de desenvolvedores ou s particularidades do software a ser desenvolvido Este modelo prev prototipa o desenvolvimento evolutivo e c clico e as principais atividades do modelo cascata 22 Planejamento estimativa cronograma An lise de Risco Modelagem N an lise de projeto plan O mplanta o entrega a feedback eaten Figura 3 3 Modelo de processo em espiral PRESSMAN 2006 P 45 Sobre esse modelo SIMAO amp VARELA dizem O modelo em espiral foi proposto por Boehm em seu artigo de 1988 A Spiral Mode of Software Development and Enhancement como forma de integrar os diversos modelos existentes a poca eliminando suas dificuldades e explorando seus pontos fortes Este modelo foi desenvolvido para abranger as melhores caracter sticas tan
165. to Suposi es e depend ncias 4 1 PERSPECTIVA DO PRODUTO Esta subse o do documento de Vis o coloca o produto na perspectiva de outros produtos relacionados e do ambiente do usu rio Se o produto for independente e totalmente auto suficiente exponha isso aqui Se o produto for um componente de um sistema maior esta subse o dever relacionar como esses sistemas interagem e identificar as interfaces relevantes entre os sistemas Uma maneira f cil de exibir os principais componentes do sistema maior suas interconex es e interfaces externas atrav s de um diagrama de bloco 4 2 RESUMO DOS RECURSOS Resuma os principais benef cios e recursos que o produto fornecer Por exemplo um documento Vis o referente a um sistema de suporte ao cliente poder usar esta se o para abordar a documenta o de problemas o roteamento e a elabora o de relat rios de status sem mencionar a quantidade de detalhes necess ria a cada uma dessas fun es Organize as fun es de modo que a lista possa ser compreendida pelo cliente ou por qualquer pessoa que esteja lendo o documento pela primeira vez Uma tabela simples relacionando os principais benef cios e seus recursos de suporte poder ser suficiente Por exemplo Recursos de suporte Beneficios para o cliente Novo recurso 1 Benef cio que ele trar pra o cliente Novo recurso 2 Benef cio que ele trar para o cliente 4 3 SUPOSI ES E DEPEND NCIAS Liste cada fator que
166. to do ciclo de vida cl ssico como da prototipagem acrescentando ao mesmo tempo um novo elemento a an lise de riscos que falta a esses paradigmas SIM O e VARELA 2009 p 10 Um ponto a ser observado nesse modelo a an lise de risco que segundo DUTRA 2008 p 25 exige muita experi ncia da equipe Al m disso pode ser dif cil convencer os clientes que a abordagem evolucion ria control vel Ela exige compet ncia consider vel na avalia o de riscos e depende dessa compet ncia para ter sucesso Se um risco importante n o dor descoberto e gerenciado fatalmente ocorrer o problemas 3 3 5 Modelo gil Os processos em desenvolvimento gil de software parecem ser mais eficientes do que as metodologias antigas por m mesmo utilizando menos tempo do programador no desenvolvimento de softwares funcionais de alta qualidade tem a desvantagem de ter uma perspectiva de negocio que n o prov uma capacidade de 23 planejamento em longo prazo Em ess ncia eles proveem mais funcionalidades por custo benef cio Existem v rias metodologias que podem ser consideradas como abordagens geis entre elas Scrum Programa o Extrema XP FDD Crystal Clear DSDM entre outras Processo de Desenvolvimento de Software 2009 As metodologias geis n o ser o definidas por estarem fora do contexto deste trabalho 3 4 PADR ES POR EXCEL NCIA Ao pesquisar sobre modelos e metodologias para desenvolvimento de software vo
167. tru o foi motivada a partir da necessidade de um grupo de universit rios com um cliente real que necessitava de um software para ajudar a gerenciar da sua empresa Em busca de um desenvolvimento concreto sistem tico que garanta de uma boa qualidade do produto de software eles buscaram nos conhecimentos cient ficos adquiridos respostas e solu es para alcan ar tais objetivos Foi ent o que nasceu o Prumo para gui los rumo a uma solu o f cil eficiente e mercadologicamente competitiva A partir dele tamb m foram realizadas pesquisas de campo e bibliogr ficas observando caracter sticas do mercado alvo Veio a surpresa N o s eles mas uma grande fatia do mercado brasileiro de software composta por micro e pequenas empresas que precisam adicionar qualidade ao seu processo de produ o de software Por isso esta proposta se torna tamb m um estudo que pode ser amplamente utilizado para reduzir custos e melhorar a distribui o dos recursos de uma micro e pequena empresa de TI Com o objetivo de embasar teoricamente os leitores foram discutidos conceitos de alguns dos principais autores Pressman Sommerville processos metodologias sequencial interativo e incremental espiral gil e frameworks RUP sobre o assunto na atualidade de forma que o leitor tera uma maior intimidade com os termos e t cnicas que ser o usados no decorrer do texto Ao final o leitor ter adquirido uma carga de conhecimentos que lhe p
168. u seja OS artefatos necess rios para o bom desenvolvimento da atividade No canto superior direito est o os artefatos de sa da ou seja artefatos criados ou atualizados na atividade Finalizando no centro encontra se a denomina o dela Negociar proposta de solu o Figura 4 3 Exemplo de representa o de uma atividade 4 5 1 Atividades da fase de solicita o Este t pico explica a organiza o das atividades que compreendem a fase de solicita o quais os seus objetivos e demais especifica es necess rias 4 5 1 1 Solicitar servi o Esta atividade descreve como o cliente deve entrar em contato com a empresa de desenvolvimento de solu es de software para solicitar um novo servi o ou como ele deve proceder em caso de solicita o de mudan a de funcionalidade Aqui o cliente ir contatar a empresa em busca de solucionar suas necessidades vindo a iniciar uma Solicita o A forma de representa o mostrada acima denominada PEPP AGUIAR e ROULIER 2004 utilizada para representar o MA MPS de propriedade SWQuality Consultoria e Sistemas e est distribu da sob a licen a Creative Commons de Atribui o Uso N o Comercial 2 5 Brasil podendo ser utilizada por terceiros desde que referenciada 46 As solicita es geradas nesta atividade s o de responsabilidade do Cliente onde o artefato Solicita o representa o principal meio de comunica o ativo do Cliente e a empresa Outr
169. umento dever ser salvo em um arquivo denominado Gloss rio 1 2 FINALIDADE Especifique a finalidade deste Prot tipo de interface com o usu rio 1 3 ESCOPO Uma breve descri o do escopo deste Prot tipo de interface com o usu rio a que Projeto s ele est associado e tudo o mais que seja afetado ou influenciado por este documento 1 4 REFER NCIAS Esta subse o fornece uma lista completa de todos os documentos mencionados em qualquer outra parte do Prot tipo de interface com o usu rio Identifique cada documento por t tulo n mero do relat rio se aplic vel data e organiza o de publica o Especifique as fontes a partir das quais as refer ncias podem ser obtidas Essas informa es podem ser fornecidas por um anexo ou outro documento 1 5 VIS O GERAL Esta subse o descreve o que o restante do Prot tipo de interface com o usu rio cont m e explica como o documento est organizado 2 MODELOS Os modelos definidos aqui ser o descritos por meio de imagens com o objetivo de facilitar a implementa o e apresenta o dos modelos de interface de usu rio ao cliente Ser o apontados os casos de uso e requisitos relacionados 2 1 lt UM MODELO gt O modelo ser descrito por meio da imagem e um texto que dar uma breve explica o do que se trata este modelo junto com os requisitos e os modelos de caso de uso relacionados 2 2 lt OUTRO MODELO gt O modelo ser descrito por meio da
170. vidades desta fase o leitor pode consultar os Ap ndice A Ciclo de vida e mapa de atividades 4 2 6 Fase de Entrega Esta fase como explicado na se o 4 2 a fase de sa da da funcionalidade do ciclo de vida do processo Nela s o desenvolvidos os planejamentos para treinamento dos usu rio e implanta o da solu o Os cursos preparat rios para que os usu rios aprendam a utilizar a solu o antes da utiliza o ser o desenvolvidos Ap s o 34 treinamento a nova solu o j poder ser implantada podendo ser necess rio um acompanhamento da utiliza o durante alguns dias caso o cliente solicite z Nessa fase o acompanhamento importante para que se tome conhecimento de como a solu o est sendo encarada na pr tica Al m disso importante observar qual o comportamento dos usu rios em rela o nova funcionalidade e se esta est desempenhando satisfatoriamente sua fun o 4 2 7 Verifica o da qualidade A fase de verifica o da qualidade ou valida o faz parte de um dos processos de apoio do Prumo sendo realizado sempre nas transi es entre as fases principais do ciclo de vida do processo O objetivo dele garantir a qualidade do produto de software que est sendo criado sendo necess ria para isso uma verifica o na qualidade dos principais produtos de software criados Al m disso a verifica o tamb m acompanha a qualidade do processo como um todo a partir de uma an lise
171. vis o arquitetural do software a decomposi o da vis o o agrupamento dos elementos e as interfaces entre esses principais agrupamentos Portanto comparado aos outros pap is a vis o do Arquiteto de Software ampla e n o detalhada Rational Software Corporation 2002 40 Um dos artefatos pelo qual o Arquiteto de Software respons vel o Documento de Arquitetura do Software que oferece diversas vis es arquiteturais de representa o da solu o Nele s o inseridos por exemplo e Vis o l gica representa o do ponto de vista da arquitetura do modelo de design dividindo em subsistemas e pacotes Dentro de cada pacote est a representa o das classes significativas do ponto de vista da arquitetura e Vis o de implanta o descreve uma ou mais configura es f sicas do computador ou da rede indicando como o software utilizar esta estrutura e Vis o de dados descreve a perspectiva de armazenamento dos dados persistentes podendo ser inseridos os diagramas DER e ER No Prumo o Arquiteto de Software tamb m determina como ser feita a integra o de uma nova funcionalidade ao sistema definindo qual a ordem em que devem ser desenvolvidos os builds e quais os subsistemas que eles fazem parte Para isso ele cria o artefato Plano de Integra o do Build 4 3 5 Desenvolvedor Este papel representa a pessoa capaz de traduzir problemas do mundo humano para o mundo computacional atrav s de lin
172. vo disso garantir que as funcionalidades especificadas pelo Cliente n o perder o a ess ncia dos resultados esperados A segunda atua o deste papel na fase de Testes Nela o Analista de Testes acompanha a execu o de todos os testes e compara os resultados com as diretrizes contidas no artefato Plano de Testes definido anteriormente por ele Ele tamb m realiza as atividades de um testador executando todos os testes especificados Como atribui es este papel desempenha por exemplo testes de unidade testes de integra o testes de seguran a de dados testes de aceita o e demais testes necess rios para garantir um bom n vel de qualidade para a solu o 4 3 7 Analista de Suporte O papel do Analista de Suporte deve ser incorporado por uma pessoa capaz de realizar treinamentos para os usu rios sobre sistemas computacionais Para realizar suas atribui es de maneira eficiente ele deve ser comunicativo e ter boa rela o interpessoal j que ele estar em contato tanto com os futuros usu rios da solu o e com o Cliente O Treinador antes da realiza o dos treinamentos desenvolve um Plano de Treinamento contendo todas as especifica es necess rias para a realiza o dos treinamentos dos usu rios Nele est o contidas informa es como per odo de execu o das atividades produtos a serem treinados recursos a serem utilizados etc 42 Durante a defini o do Prumo foi decidido que o Trein

Download Pdf Manuals

Related Search

Related Contents

Swingline Antimicrobial  Lenovo ThinkCentre M73  Widex Mind 220 CIC  Dynex 10-Sheet Quick Setup Guide  Panasonic AG-HVX200 All in One Printer User Manual  Thermal Arc SP 2001 Spool Gun Assembly Owner`s Manual_  HOUZER S-175U EARTH Instructions / Assembly  CB300R cp_intro.PMD  MODE D`EMPLOI DE LA BOUILLOTTE SECHE - l-effet-lin  Philips LR14E2B  

Copyright © All rights reserved. Failed to retrieve file