Home

Apostila - waltenomartins.com.br

1. tao remover passageri 7 remover passageiro 10 minutos Ie da decolagem techado 170 Exemplo Diagrama de Estados da Classe Carro apenar r Neutro e a Re 9 a apertar n apertar n mN Segunda Terceira Para defini o dos estados o que deve ser feito e Pensar nas etapas de vida ou nos estados que o objeto pode passar e Levantar todos os eventos ou as a es ou funcionalidades do sistema que alteram o objeto Passos para o desenvolvimento 1 passo Identifique os estados da classe e Em defini o ou definindo e Entrevistando e Finalizada Voltar ao enunciado e descobrir os estado do objeto Pesquisa 2 passo Identifique os eventos ou a es do sistema que alteram o estado do objeto e Cadastrar pesquisa Prof Walteno Martins Parreira Jr P gina 71 Engenharia de Software e Digitar entrevista e Fechar pesquisa Na identifica o dos eventos tem se que buscar as a es que s o executadas no sistema para a classe em quest o ou seja tem se que identificar quais s o as a es no sistema que alteram o estado da Pesquisa 3 passo Desenhe o Diagrama Depois de empregar os passos anteriores o desenho do diagrama se torna muito f cil Lembre se que o diagrama pode ser enriquecido com Em Defini o outras caracter sticas do sistema como a a o condi es de guarda agrupamento de estados e o compartimento de
2. E 1m ED Jep msoleannaoa e serdauria OANZINVISNNS Td 30 SOSS32COHd S aF MOS 3sWH POLOHA 30 OLN3WVION38393 OO 50557904 30 DONS DENT Para estes mesmos 42 processos de gerenciamento de projetos do PMBOK a matriz a seguir prov uma vis o quantitativa de sua distribui o pelas reas de conhecimento e pelos grupos de processos 2010 M rcio d vila Inicia o Planejamento gt Execu o gt Controle Encerramento Riscos s Integra o n Pelo diagrama f cil perceber algumas caracter sticas l gicas dos processos de gerenciamento de um projeto e Praticamente todas as reas de conhecimento s o abordadas nas atividades de Planejamento definir estimar e planejar cada aspecto e de Monitoramento e Controle controlar no PMBOK 4 edi o o processo de Gerenciar a equipe passou ao grupo de Execu o deixando apenas a rea de RH sem processos no grupo de Controle e quanto a Execu o os aspectos envolvidos mais ativamente s o a equipe RH as comunica es as aquisi es e a garantia da qualidade e aiintegra o se faz presente em todos os momentos do projeto e na figura com as descri es os grupos de processos representam os tipos de atividades as reas de conhecimento caracterizam os assuntos e seu cruzamento induz de forma bastante intuitiva os respectivos verbos definir planejar estimar gerenciar monitorar controlar encerrar etc
3. Fer Funda o Universidade do Estado de Minas Gerais Educacional 2 i de Ituiutaba Funda o Educacional de Ituiutaba FUNDA O ASSOCIADA Curso de Engenharia da Computa o LEI 18 384 2009 Engenharia de Software UEMG APOSTILA ENGENHARIA DE SOFTWARE 1 Prof Walteno Martins Parreira J nior www waltenomartins com br waltenomartins yahoo com 2013 Engenharia de Software SUM RIO 1 SOFTWARE E ENGENHARIA DE SOFTWARE eee 3 ES RENI IIo Dc 3 liM CSO UWAIOS S e Seen cte oto i ee OU tre eMe REED aaa 3 1 3 Problemas associados ao software sssssessseseseseeeeeeeeee eene eene eene eene ens 4 1 4 A Import ncia do Software rear cearena aca enne nnne nnne 4 1 5 O Papel Evolutivo do Software rr ceeereaaceeraaacareanaacaneaa 4 1 6 Aplica es do Softwares e eter deret tete a eee sape 7 1 7 Engenharia de Software Uma Defini o essesssesseeeeeeeeeee eene 8 1 8 O que engenharia de Software sessesssssssssesseeeeeeeeeeenee nennen nennen 8 1 8 1 M todo baseado na Decomposi o de Fun es eeeeeeeee 9 1 8 2 M todo baseado na Estrutura de Dados serrana 9 1 8 3 M todo de An lise baseado na Orienta o a Objeto sse 9 1 9 Paradigmas de Engenharia de Software sese 9 1 10 Processos de Software enosmeren et ette tee ere sb a
4. Cliente c digoDoCliente Oraanizac o limiteDeCr dito 9 S incluirPedido atenderPedido t 1 lt Composi o i Classe Organiza o Cliente Cl sse Associativa a Multiplicidade Pedido item quantidade Produto MAE incluirItemPedido e Generaliza o calcular TotalPedido INST disjun o incompleto Opera es Subclasse Restri o Chocolate Biscoito 111 Prof Walteno Martins Parreira Jr P gina 59 Engenharia de Software 5 3 1 Pacotes Os pacotes l gicos s o agrupamentos de elementos de um modelo Um sistema pode ser dividido em pacotes para melhorar o entendimento e para aumentar a produtividade Os pacotes l gicos s o agrupamentos de elementos de um modelo No modelo de an lise eles podem ser utilizados para formar grupos de classes com um tema comum pode ser til para a divis o do trabalho na equipe de desenvolvimento Os pacotes da figura s o usados para agrupar classes especializadas em rela o a esses aspectos Pacotes l gicos podem ter rela es de depend ncia e pertin ncia entre si Salor Academica Setor Administrativo Funcianang RENNES Do Disciplina p CREE w e 5 3 2 Associa o Associa o o relacionamento entre as classes estabelece um v nculo entre objetos Tipos de associa o e Associa o simples bin ria un ria e n ria e Agrega o Composi o Generaliza o a A associa o bin ria a mai
5. 1 10 Processos de Software Segundo lan Sommerville Um processo de software um conjunto de atividades e resultados associados que levam produ o de um produto de software Embora existam muitos processos de software diferentes h atividades fundamentais comuns a todos eles tais como e Especifica o de software e Projeto e implementa o de software e Valida o de software e Evolu o do software A melhoria dos processos de software podem ser implementadas de diferentes maneiras como ser o estudados posteriormente 1 11 Os desafios da Engenharia de Software Neste s culo XXI os principais desafios ser o e O desafio do legado que fazer a manuten o e a atualiza o dos softwares atuais sem apresentar grandes custos e ao mesmo tempo prosseguir com a presta o dos servi os corporativos essenciais e O desafio da heterogeneidade que refere se a desenvolver t cnicas para construir softwares confi veis e que sejam flex veis para lidar com diferentes tipos de equipamentos e sistemas e O desafio do fornecimento que deve apresentar uma redu o do tempo gasto no desenvolvimento e implanta o do software sem comprometer a qualidade Prof Walteno Martins Parreira Jr P gina 10 Engenharia de Software 2 T CNICAS DE ENTREVISTAS E DE COLETA DE DADOS 2 1 Introduc o Este texto apresenta algumas diretrizes para as entrevistas que voc far durante a fase de an lise de sistemas do p
6. Relacionamento entre um elemento mais geral e um mais espec fico tamb m conhecido como heran a ou classifica o O elemento mais espec fico pode conter somente informa o adicional acerca do elemento mais geral completo todos conhecidos Genesaliza o fe Conta fincompleto nem todos conhecidos s disjun o s o mutuamente Bancaria exclusivos A restri o lt sobreposi o podem ocorrer simultaneamente Fundo de Conta Poupan a A es Corrente 7 Especializa o 122 O uso das restri es facultativo e serve para identificar o que est desenhado nas especializa es da superclasse Pode ser que estejam todos os subtipos desenhados no diagrama se fosse colocado no exemplo acima poder amos dizer que todas as contas s o do tipo Fundo Corrente ou Poupan a neste caso a restri o seria completo Caso tenha algum tipo de conta n o mostrado no desenho como Conta Aplica o ter amos a restri o sendo Prof Walteno Martins Parreira Jr P gina 62 Engenharia de Software incompleto Para as restri es de sobreposi o temos que uma conta banc ria pode se comportar como poupan a e como conta corrente o dinheiro n o fica parado nunca est no m nimo rendendo os juros da poupan a Se o sistema n o funcionar desta forma ou seja uma conta banc ria uma conta poupan a ou corrente ou fundo de a es temos a restri o de disjun o b Classes Abstratas e uma class
7. e substantivos que descrevem os processos de gerenciamento relacionados Engenharia de Software Isso mostra que os conceitos e melhores pr ticas que o PMBOK re ne organiza e formaliza est o naturalmente presentes na ess ncia do gerenciamento de qualquer bom projeto 4 6 3 Gerencia do projeto O gerente do projeto a pessoa designada pela organiza o respons vel pela condu o do projeto com a miss o de zelar para que os objetivos do projeto sejam atingidos O gerente de projetos tem sido caracterizado por um perfil profissional com dom nio e experi ncia especializados nos processos e nas reas de conhecimento do gerenciamento de projetos O trabalho do gerente de um projeto pode ser sintetizado em dois grandes elementos e Planejar antes e Controlar durante as atividades do projeto e seu gerenciamento conforme se pode constatar pela concentra o de processos de gerenciamento de um projeto abrangendo todas os aspectos envolvidos e Comunicar os gerentes de projetos passam a maior parte do seu tempo se comunicando com os membros da equipe e outras partes interessadas do projeto Al m disso os gerentes de projetos devem dominar diversas habilidades interpessoais que utilizam com frequencia dentre as quais se pode destacar e Comprometimento responsabilidade tica e honestidade e Transpar ncia franqueza clareza e objetividade e Lideran a agrega o motiva o e entusiasmo e Solu o de conflitos
8. uma t cnica de observa o de fatos muito efetiva Ela pode ser usada para diversas finalidades como processamento e confirma o de resultados de uma entrevista identifica o de documentos que devem ser coletados para an lise esclarecimento do que est sendo feito no ambiente atual Esta t cnica simples Durante algum tempo o analista fica observando os usu rios em seu ambiente enquanto eles executam suas tarefas di rias Frequentemente o analista far perguntas para conhecer o funcionamento e as atividades desenvolvidas E importante explicar para as pessoas que ser o observadas o que ser observado e porque Os passos para a observa o s o a Antes Prof Walteno Martins Parreira Jr P gina 19 Engenharia de Software Identifique as reas a serem observadas Obter a aprova o da gerencia apropriada para executar a observa o Obter os nomes e fun es das pessoas chaves que ser o envolvidas no estudo de observa o Explicar a finalidade do estudo b Durante Familiarizar se com o local de trabalho a ser observado Observar os agrupamentos organizacionais atuais Observar as facilidades manuais e automatizadas em uso Coletar amostras de documentos e procedimentos escritos que s o utilizados nos processos observados Acumular informa es estat sticas das tarefas observadas frequ ncia que ocorrem estimativas de volumes tempo de dura o etc Enquanto interage com os usu rios te
9. A mensagem s ser executada se a Indica que pode ocorrer repeti o do condi o for verdadeira passo oops Condi o de Guarda aparece entre Inclus o e Extens o no Caso de Uso Cada cen rio do caso de uso tem um diagrama de sequ ncia teremos um diagrama de sequ ncia para o curso principal do caso de uso estendido ou inclu do e no diagrama de sequ ncia do que inclui colocamos uma nota com a observa o Observa es para o desenvolvimento do diagrama e permitido o uso de Notas a qualquer momento mas cuidado para n o poluir o desenho e Existem autores que utilizam a fronteira como objeto de interface entre o sistema e o ator representando as telas do sistema outros autores preferem instanciar cada fronteira com o nome das telas outros autores n o utilizam fronteira de forma nenhuma Ache sua forma de desenhar e O Diagrama de Sequ ncia um descobridor de m todos e um validador da sequ ncia de passos da descri o do caso de uso e Se houver necessidade de colocar algum m todo na fronteira podemos inserir uma ou n classe de fronteira atualize o diagrama de classes contendo os m todos gen ricos e par metros do sistema Prof Walteno Martins Parreira Jr P gina 68 Engenharia de Software 5 5 Diagrama de Estado O que o Diagrama de Estados Representa os estados que um objeto pode possuir e a ordem pela qual ele passa por estes estados desde sua cria o at sua destrui o Estuda o
10. cadastrado como a fun o a data de our admiss o CPF RG nome endere o Espeeihca o OCX D 3 PX T data de nascimento n da CTPS telefone O sistema permitir a consulta do RD4 2 Validar funcion rio e altera o dos campos Seguran a O X D P X T CPF mediante a valida o do CPF caso seja alterado RD4 3 i Armazenar os o ea HERE UN os dados Especifica o O X D P X T dido mediante a conclus o da altera o Legenda O Obrigat rio D Desej vel P Permanente T Transit rio 3 3 Etapas da An lise de Requisitos O analista executa ou coordena cada uma das tarefas associadas an lise de requisitos de software Durante as tarefas de identificac o ele comunica se com o pessoal do usu rio cliente com a finalidade de conhecer as caracter sticas existentes no ambiente O analista convoca o pessoal de desenvolvimento durante as tarefas de avalia o e s ntese de forma que as caracter sticas do software sejam corretamente definidas O analista geralmente o respons vel pelo desenvolvimento de uma Especifica o de Requisitos de Software e participa de todas as revis es Assim a An lise de Requisitos dividida em v rias etapas 3 3 1 Analise do Problema Nesta fase inicial o analista estuda os documentos de Especifica o do Sistema e o Plano de Software como forma de entender o posicionamento do software no sistema e revisar o
11. o de uma linguagem de especifica o orientada ao processo 3 a especifica o deve levar em conta o sistema do qual o software faz parte e o ambiente no qual o sistema vai operar 4 a especifica o deve representar a vis o que os usu rios ter o do sistema 5 uma especifica o deve ser operacional no sentido de que ela deve permitir mesmo num n vel de abstra o elevado algum tipo de valida o 6 uma especifica o deve ser localizada e fracamente acoplada o que s o requisitos fundamentais para permitir a realiza o de modifica es durante a A figura a seguir apresenta uma proposta de estrutura para o documento de Especifica o dos Requisitos do Software O documento inicia com uma Introdu o que apresenta as principais metas do software descrevendo o seu papel no contexto do sistema global As informa es prestadas nesta se o podem ser inclusive inteiramente extra das do documento de Plano de Software O documento que apresenta a Especifica o de Requisitos de Software tem o seguinte esbo o mas n o exclusivamente Introdu o 1 Refer ncias do sistema 2 Descri o geral 3 Restri es de projeto do software Il Descri o da Informa o 1 Representa o do fluxo de informa o a Fluxo de dados b Fluxo de controle 2 Representa o do conte do de informa o 3 Descri o da interface com o sistema IIl Descri o Funcional 1 Divis o funcional em parti
12. o hier rquica de processos e MHT Modelo Hier rquico de Tarefas se baseia na decomposi o hier rquica de tarefas 1 8 2 M todo baseado na Estrutura de Dados Abordagem baseada na decomposi o de um problema a partir dos dados Exemplos de tipos de modelos dessa classe e MER Modelagem Entidade Relacionamento e T cnica de Warnier 1 8 3 M todo de An lise baseado na Orienta o a Objeto Os tipos de modelos que representam essa classe s o e UML Unified Process nota o de modelagem independente de processos de desenvolvimento e Cen rios 1 9 Paradigmas de Engenharia de Software Segundo Roger Pressman Paradigmas s o os modelos de processos que possibilitam e ao gerente o controle do processo de desenvolvimento de sistemas de software e ao desenvolvedor a obter a base para produzir de maneira eficiente software que satisfa a os requisitos preestabelecidos Os paradigmas especificam algumas atividades que devem ser executadas assim como a ordem em que devem ser executadas A fun o dos paradigmas diminuir os problemas encontrados no processo de desenvolvimento do software e deve ser escolhido de acordo com a natureza do projeto e do produto a ser desenvolvido dos m todos e ferramenta a ser utilizado e dos controles e produtos intermedi rios desejados Os paradigmas ser o estudados no em outro capitulo Prof Walteno Martins Parreira Jr P gina 9 Engenharia de Software
13. e Quem ir usar as funcionalidades b sicas do sistema e Existe funcionalidade para administrar e manter o sistema Quem ir executar tais atividades e Algum dispositivo de hardware inicializa alguma funcionalidade ou interage de alguma forma com o sistema e O sistema ir interagir com outros sistemas Lembre se o ator interage com o sistema Conceito de Caso de Uso uma sequ ncia de a es que um sistema desempenha para produzir um resultado observ vel por um ator espec fico E uma classe n o uma inst ncia O nome do Caso de Uso deve ser uma frase indicando a a o que realiza Um caso de uso um conjunto de passos a descri o da intera o entre ator e sistema e o tratamento das suas exce es Um caso de uso tem in cio meio e fim O Caso de Uso em si uma sequ ncia de a es que um sistema desempenha para produzir um resultado observ vel por um ator espec fico Em outras palavras um caso de uso define uma funcionalidade do sistema com um conjunto de a es tomadas pelo ator e a previs o da rea o por parte do sistema O Caso de Uso uma classe n o uma inst ncia A sua especifica o descreve a funcionalidade como um todo incluindo erros poss veis alternativas e exce es que podem ocorrer durante sua execu o O nome do Caso de Uso deve ser uma frase indicando a a o que realiza Cuidado para n o identificar um caso de uso no lugar de um passo Um caso de uso tem um conjunto de passos
14. es 2 Descri o funcional a Narrativa de processamento b Restri es limita es c Exig ncias de desempenho d Restri es de projeto e Diagrama de apoio 3 Descri o do controle Prof Walteno Martins Parreira Jr P gina 27 Engenharia de Software a Especifica o do controle b Restri es de projeto IV Descric o Comportamental 1 Estados do sistema 2 Eventos e ac es V Crit rios de Validac o 1 Limites de desempenho 2 Classes de testes 3 Rea o esperada do software 4 Considera es especiais VI Bibliografia VII Ap ndice Onde cada se o pode ser entendida como sendo Introdu o declara as metas e os objetivos do software decervendo o no contexto do sistema baseado em computador Se o Descri o da Informa o apresenta uma descri o detalhada do problema que o software deve resolver Se o Descri o Funcional apresenta uma descri o de cada fun o exigida para resolver o problema Se o Descri o Comportamental examina a opera o do software como uma consequencia de eventos externos e caracter sticas de controle internamente geradas Se o Crit rios de Valida o Como reconhecer uma implementa o bem sucedida Quais classes de testes devem ser levadas a efeito para validar a fun o o desempenho e as restric es A especifica o dos crit rios de valida o age como uma revis o impl cita de todas as demais exig
15. habilidades ferramentas e conhecimento na condu o de opera es da empresa O termo usado para essa tend ncia ou filosofia o gerenciamento por projetos que visa alinhar os grandes objetivos estrat gicos da empresa com in meros projetos coordenados e gerenciados de forma a garantir a sua execu o no menor tempo na melhor qualidade e no melhor custo 4 2 Atividades de Gerenciamento O trabalho de um gerente de software varia muito dependendo da organiza o e do produto a ser desenvolvido Na maioria das vezes ele assume algumas ou todas as seguintes atividades e Elabora o de propostas e Planejamento e programa o de projetos e Levantamento dos custos do projeto e Monitoramento e revis es de projetos e Sele o e avalia o de pessoal e Elabora o de relat rios e apresenta es 4 3 Etapas essenciais do Planejamento no MS Project Segundo Kimura 2002 p 11 deve se seguir uma estrutura simples mas eficaz de planejamento para a utiliza o do MS Project Na figura abaixo s o apresentadas as etapas essenciais para que se possa elaborar o escopo do projeto no software MS Project Cada etapa ser definida no software Planejamento do Escopo Y Formatac o Inicial do T bnc Pn nau pu Cronograma uum Salvar Linha Prof Walteno Martins Parreira Jr de Base P gina 30 Defini o do Engenharia de Software 4 4 Especificac o de Requisitos de Software A etap
16. prio o sistema sucessos f ceis com projetos simples planilhas eletr nicas por exemplo podem ter lhe dado a impress o de que todos os sistemas s o f ceis de implementar Isso pode explicar a impaci ncia em rela o ao analista 2 6 Outros Problemas As diretrizes acima alertaram sobre os in meros problemas pol ticos com que o analista pode se defrontar em uma entrevista e os muitos motivos pelos quais o usu rio pode mostrar se hostil Mas ainda existem alguns problemas para os quais deve se estar atento Uma discuss o que focalize mais os problemas de implementa o do que os problemas dos requisitos Isso muitas vezes ocorre quando o usu rio diz Eis como eu gostaria que voc constru sse o sistema Isso acontece quase sempre quando o usu rio est raciocinando em termos da implementa o do sistema atual e pode acontecer se o usu rio conhecer alguma coisa da tecnologia de computadores ex quando ele possui um PC particular ou quando ele um ex programador Lembrar que n o obriga o em uma entrevista de an lise descrever caracter sticas de implementa o do sistema a n o ser que sejam t o importantes que realmente perten am ao modelo de implementa o do usu rio Confus o entre sintomas e problemas Isso ocorre em muitas reas n o apenas na rea do processamento de dados O que pode acontecer nas entrevistas de an lise de sistemas Entretanto boa parte dele depende de onde a fronteira foi estabel
17. responder a esse coment rio lembre se de que o analista n o o patr o dessa pessoa e que n o est em posi o de garantir que o emprego dela n o esteja em perigo ou de inform la do contr rio Ele vai considerar o analista como o perito em efici ncia cuja tarefa orientar a dire o em como o emprego dele pode ser eliminado pela informatiza o A solu o para esse problema caso ele ocorra fazer com que seja levado ao conhecimento dos n veis superiores dos usu rios e obter o pronunciamento oficial se poss vel pessoalmente ou por escrito Prof Walteno Martins Parreira Jr P gina 16 Engenharia de Software Voc n o conhece nossa empresa como voc quer dizer nos como deve ser o novo sistema A resposta a essa pergunta Voc tem raz o E por isso que o estou entrevistando para saber o que voc pensa sobre quais devam ser os requisitos Por outro lado dever sugerir v rias maneiras de melhorar as coisas especialmente se parte ou todo o servi o realizado atualmente pelo usu rio for em um antigo e ineficiente sistema assim esse tipo de coment rio pode ser inevit vel Entretanto o verdadeiro truque continuar sendo t o respeitoso quanto poss vel e reconhecer constantemente a experi ncia do usu rio na sua rea embora continuando a perguntar se ele poderia explicar lhe porque sua id ia n o funcionaria Voc est tentando mudar o modo como as coisas s o feitas aqui O artif cio neste caso
18. rios Todos os funcion rios dever o informar o projeto que trabalharam quais foram as atividades desempenhadas e o per odo Os gerentes ou coordenadores dever o aprovar ou reprovar as horas cadastradas dos funcion rios para os projetos de sua responsabilidade Diagrama de Caso de Uso Especifica uma intera o entre um usu rio e o sistema no qual o usu rio tem um objetivo muito claro a atingir e O funcion rio cadastra aloca o das suas horas e O gerente aprova horas e O funcion rio consulta as horas trabalhadas Imagine a tela ou o conjunto de telas que far parte de uma funcionalidade e imagine a intera o do usu rio com o sistema qual a a o do usu rio e como o sistema ir reagir quais os campos que ter o lista de bancos quais os campos que o usu rio dever informar valores aqui devemos prever todas as rea es do sistema se o usu rio digitar letra no lugar do n mero como o sistema ir reagir Neste momento podemos prever inclusive quais as mensagens de alerta erro que retornar o ao usu rio afinal de contas o caso de uso servir de base para os testes Diagrama de Caso de Uso Sistema de Controle de Horas w UU FEN N E Ww Cadastrar Projeto Funcionano Consultar M s G9 Q T E D Cadastrar Tarefa ZN NR Gerente Aprovar Horas Diagrama de Caso de Uso Alguns casos de uso que podem ser aplicados ao sistema de controle de horas s o este um exemplo os casos de uso n
19. Demitir Funcion rio A o identificarCartao validarSenha Condi o de Guarda Senha inv lida falha detectada Observe que o evento o que faz com que o objeto mude de estado seu conceito est intimamente ligado ao da transi o 5 5 1 M quina de Estados Os superestados s o utilizados para minimizar a desorganiza o do diagrama de estados Os superestados s o compostos de dois ou mais subestados de uma mesma transi o A m quina de estados ou Superestado ou Estado Composto foi criada para agrupar estados e facilitar a leitura do diagrama M quinas de estado aninhadas servem para subdividir estados complexos em estruturas mais simples Subestado um estado que parte de um estado composto Superestado Subestado 3 Nas figuras exibidas abaixo percebe se a facilidade da leitura permitida pelo superestado Perceba que tanto o voo aberto quanto lotado passam para a situa o fechado independente da situa o anterior o que faz com que o voo passe para fechado s o os 10 minutos antes da decolagem Prof Walteno Martins Parreira Jr P gina 70 Engenharia de Software o agendado l adicionar passageiro adicionar gt f gt ieneio di o 1 aberto 5 lotado remover O i ae passageira 7 remover passageiro Y 10 minu S 10 minutos antes da u p decolagem y techado J NX adicionando passageiros adicionar passageiro celo dm SON ato 1
20. Ela inclui o conjunto de tarefas que levam a um entendimento de qual ser o impacto do software sobre o neg cio do que o cliente quer e de como os usu rios v o interagir com o software Ent o a etapa de suma import ncia no processo de desenvolvimento de um software principalmente porque ela estabelece o elo de liga o entre a aloca o do software em n vel de sistema realizada na etapa de Engenharia de Sistema e o projeto do software Desta forma esta etapa permite Ao engenheiro de software e especificar as necessidades do software em termos de fun es e de desempenho e estabelecer as interfaces do software com os demais elementos do sistema e especificar as restri es de projeto Ao engenheiro de software analista e uma aloca o mais precisa do software no sistema e a constru o de modelos do processo dos dados e dos aspectos comportamentais que ser o tratados pelo software Ao projetista e a obten o de uma representa o da informa o e das fun es que poder ser traduzida em projeto procedimental arquitet nico e de dados Al m disso poss vel definir os crit rios de avalia o da qualidade teste do software a serem verificados uma vez que o software esteja conclu do 3 2 Oque s o requisitos Como sistemas computacionais s o constru dos para serem utilizados no mundo real necess rio que sejam modelados como uma parte do mundo real O dom nio de uma aplica o
21. as informa es colhidas na entrevista e executar bastante trabalho com os dados brutos Pode haver DFD a serem desenhados ou itens a serem criados no dicion rio de dados c lculos de custo benef cio podem precisar ser feitos as informa es provenientes da entrevista podem precisar ser correlacionados com dados de outras entrevistas e assim por diante Em qualquer caso os dados dessa entrevista ser o manipulados documentados analisados e convertidos em uma forma que o usu rio pode nunca ter visto antes Desse modo pode ser necess rio marcar uma entrevista posterior para verificar Prof Walteno Martins Parreira Jr P gina 14 Engenharia de Software e que o analista n o cometeu nenhum engano em seu entendimento do que o usu rio Ihe disse e Que o usu rio n o mudou de opini o nesse nterim e que o usu rio entende a nota o ou a representa o gr fica dessas informa es 2 4 4 Utilize Ferramentas Automatizadas que Sejam Adequadas Mas N o Abuse Durante a entrevista pode se achar conveniente utilizar ferramentas de prototipa o principalmente se o objetivo da entrevista for discutir a vis o que o usu rio tem da interface pessoa m quina De modo semelhante se estiver revisando um diagrama de fluxo de dados e discutindo poss veis modifica es poder achar pr tico usar uma ferramenta CASE Lembre se que o objetivo dessas ferramentas facilitar as discuss es e n o complic las elas devem permit
22. ciclo de vida de uma classe um caso de uso um pacote ou uma opera o mas mais comumente utilizado para classe ou melhor para os objetos de uma classe Serve para estudar certos tipos de l gicas que envolvem transi es poss veis entre diferentes estados de um sistema O diagrama de estados visa o estudo do comportamento do objeto Como os diagramas na UML s o complementares o diagrama de classe deve ter uma propriedade para a informa o do estado do objeto criado e o diagrama de caso de uso deve prever a altera o do estado deste objeto nas v rias etapas do seu ciclo de vida O diagrama de estados observa o comportamento de uma inst ncia Em sistemas complexos o trabalho muito extenso e dif cil a UML indica o uso do diagrama de estado por classe mostrando os estados que os objetos dessa classe podem assumir e as transi es que eles podem fazer entre estados sendo ideal para descrever o comportamento de um nico objeto O sistema em um determinado estado recebe est mulos entradas os trata para exibir respostas sa das Est mulo Estado Inicial Estado Final e Assintura de evento condi o de guarda Resposta Express o de a o cl usula de envio Um Diagrama de Estado relaciona eventos e estados Quando um evento recebido o estado subsequente depende do estado corrente e do evento A modifica o de estado causada por um evento chamada transi o Um diagrama de estados um grafo cuj
23. com o caso de uso z A e lt aigcugos inclu do seta tracejada Ou seja p il t Solicitar Servico e Cadastrar Venda l s podem ser executadas se pes tandane Es gt Cadastrar Pagamento for executada Prof Walteno Martins Parreira Jr P gina 56 Engenharia de Software Neste caso a solu o foi pensada de forma que quando houver o Comando de Jantar necessariamente haver o Pagamento de Conta da mesma forma quando houver Comando de Almo o haver Pagamento de Conta O importante saber ler o que est desenhado no exemplo o sistema somente ser acionado ao final do processo quando haver o registro do consumo almo o ou jantar e logo em seguida o pagamento da conta lt cinclui gt gt Comandar Jantar Pagar e Conta E e io M Comandar lt lt inclui gt gt M Almo o Generaliza o entre casos de uso Os UCs filhos podem adicionar e redefinir o comportamento do UC pai atrav s da inser o de sequ ncias adicionais de a es em pontos arbitr rios da sequ ncia do UC pai Este tipo de relacionamento mais facilmente detectado na descri o do caso de uso quando uma a N exce o n o necessariamente um Receber erro ou ocorre com frequ ncia N Pagamento Z Receber pagamento em cheque Receber pagamento em dinheiro e Receber pagamento em cart o s o EE EU A especializa es do caso de uso Receber Cw Receber N TUR Receber Receber Pagamento Pagamento C Pagamento Pagamento
24. como uma f brica de objetos id nticos Possui atributos e m todos Uma descri o de um conjunto de objetos que compartilham os mesmos atributos opera es relacionamentos e sem ntica Rumbaugh Um gabarito para diversos objetos que Prof Walteno Martins Parreira Jr P gina 42 Engenharia de Software descreve como estes objetos s o estruturados internamente Jacobson Um conjunto de objetos que compartilham uma estrutura comum e um comportamento comum Booch a Classe x Objeto Classe Pessoa Objeto Jo o Exemplo Classe x Objeto Para criar efetivamente um objeto n s devemos instanci lo class Aluno f private String nome private int matric A aluno String s int m f M todo nome Construtor matric m H Aluno ai new Aluno Joao 2202 Classe Objeto Aluno Jo o Aluno Nome String Nome Jo o Matric Num Matric 2202 aluno buscarAluno MES Outro Exemplo Classe x Objeto Inst ncias da classe Casa objetos Casa cl new Casa cl numero 12 Casa cl cor Color yellow numero cor Casa c2 new Casa c2 numero 56 abrePorta c2 cor Color red Casa c3 new Casa c3 numero 72 c3 cor Color white c3 abrePorta A classe casa como uma forma que ir criar objetos semelhantes Observe que cada objeto tem caracter stica pr pria a cor o n mero Prof Walteno Martins Parreira Jr P gina 43 Engenharia de Software Heran a Capacidade
25. de um novo objeto tomar atributos e opera es de um objeto existente permitindo criar classes complexas sem repetir c digo Representa generaliza o e especializa o Uma especializa o pode incluir novos m todos e atributos ve culo a Generaliza o modelo ano caminh o carro carga maxima NE i tara A Especializa o carro esportivo Heran a continua o Mamifero class Cachorro extends Mamifero x Ra a Come Atributos dos objetos da classe private String nome private String cor private int peso private float energia Construtores formas da classe Cachorro Cachorro String s nome s Cachorro nome Sem nome o f M todos comportamentos dos objetos da classe amp yPeso 1 Integer void setPeso int v peso v amp Energia float int getPeso return peso T geli s String void corre Cachorro 0 A void late getPeso integer S setPeso v integer Corre VLate Polimorfismo muitas formas Permite que opera es com o mesmo nome mas com uma sem ntica de implementa o diferente sejam ativadas por objetos de tipos diferentes V rios comportamentos que uma mesma opera o pode assumir Saldo correntista Saldo nce 2 Saldo fundo Saldo fundo Saldo renda poupan de a es balanceamento fixa Uma opera o chamada polim rfica quando trabalha de formas diferentes Prof Walteno Ma
26. dependendo da personalidade do entrevistado e do tema da entrevista pode se precisar de um conjunto de estilos para extrair as informa es necess rias Alguns estilos que podem mostrar se teis Relacionamentos Pedir ao usu rio para explicar o relacionamento entre o que est em discuss o e as demais partes do sistema Se o usu rio estiver falando sobre um assunto p ex um cliente pedir lhe que explique seu relacionamento sob outros aspectos se ele estiver descrevendo uma fun o ex uma bolha de um DFD pedir lhe que explique seu relacionamento com outras fun es Isso n o s o auxiliar a descobrir mais detalhes sobre o item em pauta mas tamb m o ajudar a descobrir interfaces ex fluxos de dados de uma bolha para outra no DFD e relacionamentos formais Pontos de vista alternativos Solicitar ao usu rio que descreva o ponto de vista de outros usu rios em rela o ao item que esteja sendo discutido Perguntar ao usu rio por exemplo o que seu chefe pensa sobre uma bolha do DFD ou um tipo de objeto do DER ou pergunte o que pensa seu subordinado Detalhamento Solicitar ao usu rio uma informal descri o narrativa do item em que estiver interessado Fale me sobre o modo como voc calcula o valor das remessas Ou se estiver falando com o usu rio sobre um tipo de objeto no DER poderia dizer lhe Fale me a respeito de um cliente O que voc sabe ou precisa saber sobre um cliente Depend ncias Perguntar
27. e trata as exce es desses passos Na descri o do caso de uso que teremos que pensar quais as a es que o caso de uso desempenhar Alguns exemplos de casos de uso Cadastrar Cliente Registrar Venda Fechar Caixa etc Caracter sticas e Regras sempre inicializado por um ator que pode faz lo direta ou indiretamente no sistema S o conectados aos atores atrav s de associa es de comunica o Prof Walteno Martins Parreira Jr P gina 54 Engenharia de Software Sempre devolve um valor como resposta Um caso de uso tem in cio meio e fim completo n o ter terminado at que um valor tenha sido retornado Um caso de uso como dito anteriormente representa uma funcionalidade do sistema tem in cio uma entrada uma solicita o tem meio um processamento uma grava o e tem um fim uma confirma o uma impress o o resultado de uma consulta na tela Por exemplo Selecionar exemplar utilizando dentro de algum outro lugar compra de livros talvez O caso de uso mostrado como uma elipse e seu nome pode vir dentro do desenho ou abaixo do mesmo Exemplos de Caso de Uso o Cadastrar N J e Cadastrar cliente Cliente A e Cadastrar pedido e Consultar produto e Emitir nota fiscal AOON e Fechar caixa etc o NET d Tipos de Intera es Comunica es usadas desde a vers o Cadastrar Cliente 1 3 Estere tipos e Extens o mostra a exce o os casos especiais e cursos 1 alter
28. em um diagrama de sequ ncia e Quando uma mensagem de cria o enviada geralmente s ncrona o s mbolo do objeto mostrado no local onde foi criado e Quando for destru do marcado com um X Exemplo No diagrama pode se observar que a inst ncia de Cliente criada a partir da Janela de Atendimento Pode se notar que a inst ncia de Cliente aparece um pouco abaixo da inst ncia da l janela indicando que ela foi criada depois l pedido z _ l gt z Pedido naopen ErmCadPedido A figura mostra um X na linha de vida da inst ncia de cliente indicando a sua exclus o Note que a linha de vida do objeto n o segue adiante Excluir Pedido y ErmExcluiPedido y Pedido excluiPedido y gt K Prof Walteno Martins Parreira Jr P gina 67 Engenharia de Software Exemplo de diagrama de sequ ncia Cadastrar Venda Curso Normal Venda a vista 4 Infoma ltens Atendente 2 tetalicar venda J buscaValoro 4 forma de pagamento 5 Nendasa vistali ZzavandaD A condi o no diagrama de sequ ncia representada atrav s de uma express o entre colchetes Condi o de Guarda e indica que a mensagem s ser executada se a condi o for verdadeira A repeti o vista com o uso do asterisco e indica que o passo poder ser repetido indefinidamente Condi o Repeti o CPFValido CadastrarCliente Adicionar Item
29. entrevista por onde ele preferir Alguns usu rios desejar o come ar pelas sa das isto pelos relat rios e valores de dados que eles querem que o sistema produza na realidade eles talvez nem saibam que entradas ser o necess rias para produzir as sa das desejadas Outros usu rios poder o estar mais interessados nas entradas ou nos detalhes de uma transforma o funcional Outros ainda preferir o falar sobre os detalhes dos dados de um dep sito de dados Deve se esfor ar para enxergar os requisitos do sistema da perspectiva desses usu rios e conservar esta perspectiva em mente quando fizer as perguntas necess rias sua entrevista 2 4 6 Use um Estilo Adequado de Entrevistar Como diz William Davis Davis 1983 Sua atitude em rela o entrevista importante na determina o de seu sucesso ou fracasso Uma entrevista n o uma competi o Evite ataques evite o uso excessivo do jarg o t cnico conduza uma entrevista n o uma tentativa de persuas o Fale com as pessoas n o fale muito alto nem muito baixo nem indiretamente Uma entrevista n o um julgamento Fa a perguntas detalhadas mas n o fa a perguntas para confirmar outras respostas Lembre se que o entrevistado o perito e que voc que precisa de respostas Para concluir de modo algum critique a credibilidade de outras pessoas Prof Walteno Martins Parreira Jr P gina 15 Engenharia de Software Fazer perguntas detalhadas nem sempre f cil
30. escopo do software utilizado para definir as estimativas de projeto Um elo de comunica o Prof Walteno Martins Parreira Jr P gina 23 Engenharia de Software entre o analista e o cliente deve ser estabelecido A meta do analista nesta fase identificar os principais fatores do problema a ser resolvido pela tica do cliente Logo reconhecer o problema a ser resolvido Nesta fase encontra se a especificac o do sistema o planejamento o contato do analista com o cliente com a inten o de entender a vis o do cliente com rela o ao problema 3 3 2 Avalia o do problema e sintetiza o da solu o Esta fase envolve a an lise dos fluxos de informa o e a elabora o de todas as fun es de tratamento e os aspectos de comportamento do software Ainda importante que uma defini o de todas as quest es relacionadas interface com o sistema al m de uma especifica o das restri es do projeto Terminada a an lise o analista pode iniciar a s ntese de uma ou mais solu es para o problema Na s ntese das eventuais solu es o analista deve levar em conta as estimativas e as restri es de projeto Este processo de avalia o e s ntese prossegue at que o analista e o cliente estejam de acordo sobre a adequa o das especifica es realizadas para a continuidade do processo Nesta fase tem se o entendimento do problema e faz se a identifica o das informa es que ser o necess rias ao usu rio iden
31. m todo mais complexo Esta figura mostra as atividades necess rias do sistema para a execu o do Cadastro de Aloca o exibindo todos os cen rios do caso de uso uso da decis o Observe que h atividades que podem ser executadas em paralelo threading O diagrama de atividade baseado em um caso de uso inteiro todos os cen rios ou em uma classe buscar logon valldar Data lt t ata India Cadastrar Aloca o Diagrama de Componentes Mostra como os diferentes subsistemas de software formam a estrutura total de um sistema Um Diagrama de Componentes exibe a hierarquia de depend ncia entre os componentes do sistema Um componente pode ser entendido como uma tela do sistema uma biblioteca dlls um arquivo de cr ticas arquivos js um execut vel etc Prof Walteno Martins Parreira Jr SQL Server P gina 51 Engenharia de Software O site tem v rias camadas as p ginas asp chamam algumas regras neste diagrama vemos qual a depend ncia entre elas Lembre que os componentes s o bibliotecas execut veis telas tabelas uma parte qualquer do sistema Diagrama de Implanta o Mostra como est o configurados o hardware e o software dentro de um determinado sistema O Diagrama de Implanta o mostra o layout f sico da rede onde cada n representa uma m quina podendo mostrar a configura o delas hardware e software e tamb m onde cada componente ir ser instalado Servid
32. mero de aprova es reprova es e trancamentos em todas as disciplinas por um determinado per odo de tempo A especifica o de um requisito funcional deve determinar o que se espera que o software fa a sem a preocupa o de como ele faz E importante diferenciar a atividade de especificar requisitos da atividade de especifica o que ocorre durante o design do software No design do software deve se tomar a decis o de quais a fun es o sistema efetivamente ter para satisfazer quilo que os usu rios querem 4 4 2 Requisitos n o funcionais Requisitos n o funcionais s o aqueles relacionados ao ambiente onde o sistema est inserido Um servidor mais robusto um firewall ou um usu rio especializado em determinado procedimento pode ser visto como requisitos n o funcionais S o exemplos de requisitos n o funcionais e a base de dados deve ser protegida para acesso apenas de usu rios autorizados e o tempo de resposta do sistema n o deve ultrapassar 30 segundo e o software deve ser operacionalizado no sistema Linux e o tempo de desenvolvimento n o deve ultrapassar seis meses Prof Walteno Martins Parreira Jr P gina 31 Engenharia de Software A necessidade de se estabelecer os requisitos de maneira de forma precisa cr tica na medida em que o tamanho e a complexidade do software aumentam Os requisitos exercem influ ncia uns sobre os outros Por exemplo o requisito de que o software de ter grande por
33. na manuten o de software come ou a absorver recursos em ndices alarmantes E ainda pior a natureza personalizada de muitos programas tornava os virtualmente imposs veis de sofrer manuten o Uma crise de software agigantou se no horizonte A terceira era da evolu o dos sistemas computadorizados come ou em meados da d cada de 1970 e continua ate hoje Os sistemas distribu dos m ltiplos computadores cada um executando fun es concorrentemente e comunicando se um com o outro aumentaram intensamente a complexidade dos sistemas baseados em computador As redes globais e locais as comunica es digitais de largura de banda handwidth elevada e a crescente demanda de acesso instant neo a dados exigem muito dos desenvolvedores de software A terceira era tamb m foi caracterizada pelo advento e generaliza o do uso de microprocessadores computadores pessoais e poderosas esta es de trabalho workstations de mesa O microprocessador gerou um amplo conjunto de produtos inteligentes de autom veis a fornos de microondas de rob s industriais a equipamentos para diagnostico de soro sang neo Em muitos casos a tecnologia de software esta sendo integrada a produtos por equipes t cnicas que entendem de hardware mas que frequentemente s o principiantes em desenvolvimento de software O computador pessoal foi o catalisador do crescimento de muitas empresas de software Enquanto as empresas de software da segunda era
34. ncia artificial finalmente sa ram do laborat rio para a aplica o pratica em problemas de amplo espectro do mundo real O software de rede neural artificial abriu excitantes possibilidades para o reconhecimento de padr es e para capacidades de processamento de informa es semelhantes as humanas Quando nos movimentamos para a quinta era os problemas associados ao software de computador continuam a se intensificar e A sofistica o do software ultrapassou nossa capacidade de construir um software que extraia o potencial do hardware e Nossa capacidade de construir programas n o pode acompanhar o ritmo da demanda de novos programas e Nossa capacidade de manter os programas existentes amea ada por projetos ruins e recursos inadequados Em resposta a esses problemas est o sendo adotadas pr ticas de engenharia em toda a industria 1 6 Aplica es do Software O software pode ser aplicado a qualquer situa o em que um conjunto previamente especificado de passos procedimentais um algoritmo tiver sido definido O conte do de informa es e a previsibilidade s o fatores importantes na determina o da natureza de um aplicativo Desenvolver categorias gen ricas para as aplica es de softwares uma tarefa muito dif cil Quanto mais complexo o sistema mais dif cil determinar de forma clara os v rios componentes do software Pode se dividir as aplica es em e Software B sico que um conjunto de
35. ncias Bibliografia e Ap ndice A bibliografia cont m refer ncias a todos os documentos que se relacionam com o software O ap ndice traz informa es que complementam a especifica o Dados de tabelas descri o detalhada de algoritmos quadros gr ficos e outros materiais s o apresentados como ap ndice Prof Walteno Martins Parreira Jr P gina 28 Engenharia de Software 4 GERENCIAMENTO DE PROJETOS O fracasso de muitos projetos de softwares grandes nas d cadas de 60 e 70 foi uma indicac o das dificuldades de gerenciamento de software que as empresas enfrentavam Muitos destes projetos fracassaram porque a abordagem gerencial estava errada as necessidades de gerenciamento de projetos de softwares s o diferentes das empregadas em empresas de manufatura ou de fabricas O trabalho do gerente de software garantir que o projeto cumpra as restri es impostas or ament rias de prazos de requisitos etc e entregar um produto de software que contribua para as metas da empresa Eles s o os respons veis por planejar e programar o desenvolvimento do projeto supervisionam o trabalho para assegurar que ele seja realizado em conformidade com os padr es requeridos e monitoram o progresso para verificar se est dentro do prazo e do or amento aprovado O bom gerenciamento n o pode garantir o sucesso do projeto mas o mau gerenciamento geralmente resulta no fracasso do projeto Como explica Carneiro 2000 durante algum tem
36. ncias para a ger ncia pois o pessoal de n vel operacional pode relutar em admitir que as opera es nem sempre seguem os padr es oficiais de trabalho 2 7 Formas Alternativas de Coleta de Dados As entrevistas n o s o o nico modo de coleta de informa es sobre os requisitos de um sistema Na realidade quanto mais informa es puder colher de outras fontes mais produtivas poder o ser as entrevistas pessoais Alternativas para as entrevistas Question rios Pode remeter question rios escritos para os usu rios dentro da organiza o para as pessoas ou setores que interagem com o sistema para os diretores que aprovaram o projeto e para outros Demonstra es feitas pelos fornecedores Os fornecedores de hardware e os fornecedores de software podem j haver desenvolvido sistemas prontos para a aplica o em que voc esteja interessado Solicitando lhes uma demonstra o dos recursos desses sistemas pode n o somente auxili lo a decidir se o produto uma boa solu o mas tamb m revelar fun es e dados armazenados que voc pode n o ter percebido Visitas a outras instala es Procure outras empresas que estejam no mesmo ramo de atividades ou que tenham sistemas semelhantes aquele em que voc esteja trabalhando Combine uma visita instala o para obter informa es diretas sobre as caracter sticas e aptid es do sistema Coleta de dados Procure formul rios relat rios manuais procedimentos escritos
37. nendo adiada ad RE 21 did ANtrodu O Pr 21 3 2 Oque S O TEQUISILOS sc E ERR 21 3 3 Etapas da An lise de Requisitos cr enne enne 23 3 3 1 Analise do Problema ene ederet ete edente bte ree een 23 3 3 2 Avalia o do problema e sintetiza o da solug o eeeeee 24 3 9 3 Modelagen ees oet erre terree c er beet e RE E Pere uu ens edet ame reed 24 3 3 4 Especifica o dos Requisitos insistieron dde aser seee oie i Eii iaeiae 24 Deda AREVIS O aeina raa SEEE a E E tud ed EE NEETI EARE R RE 24 3 4 Processos de comunica o e Ea a a 25 32 Prnc pios da an lise eie ere epe n ee eaa NGA En Sao asian apar 26 3 5 1 O dominio da Informa o e te eer e e eet erdt cantos 26 3 25 2 MOdelagetm eee ete e er eee redeo at ee In e cene ne 26 3 53 Particionariento ene hibet de E RR eire UE 26 3 67 culte P 27 Prof Walteno Martins Parreira Jr P gina 1 Engenharia de Software 4 GERENCIAMENTO DE PROJETOS 29 4 1 O que Gerenciamento de Projetos e enne enne 29 4 2 Atividades de Gerenciamento erre Ea aa a i 30 4 3 Etapas essenciais do Planejamento no MS Project 30 4 4 Especifica o de Requisitos de Software erre 31 44 4 Requisitos funcionais 4 1n ded ee etse eee ert qa die ai PERCHE ee doe 31 4 4 2 Requisitos n o funcionais l eene eene nenne ethernet
38. nennen nennen 31 4 5 Organiza o deatividades sere eee e ee e eee 32 45 1 Marco de Projetos eser e ede e Or ee o EROR de DU ag aaa 32 4 5 2 Programa o de projeto erre E ea REE eene 32 4 5 3 Diagramas de barras e redes de atividades 33 4 6 PMBOK Project Management Body of Knowledge esee 35 4 6 1 Projeto e seu gerenciamiento noiai n e a et nennen eene 36 4 6 2 Processos do gerenciamento de projetos eese nere 37 4 6 3 Gerencia do projeto i eee eter er oet ges rore topo tt eerte er Ee Fert R EE 40 4 6 4 Partes interessadas no projeto eee etn nnne 40 5 UML ose eene fore a ab e b ito telle pue reete etate ei errem pa a 42 SA UCONCENOS T 42 9 2 Casos de USO der eor tee etat Ud a R AE P ELE 53 5 2 1 Como fazer o Diagrama de Casos de Uso re 57 2 39 Diagrama de Cla386 eee rere FER IRR SNNT Ee Fe uto e PN eeu dao aparte 59 AME oo T 60 2 92 ASSOCIA O coe Ut rt UU TE SUPER NDS EGER IPIE aU Rampa AI ERR ARES 60 23 23 97 ASTePaCaO eet i sr ue RE et 61 5 3 4 Go JP M 61 23 9 9 ASSOCIA ES either exe la teorie EN Let Ee eese ias inca das 62 5 3 0 Navegabilid de e eed epe aW terea eiie 64 5 97 ANISIDIIIGHGO cia cr er n ER bcn Sedet vedete urbt QU Rd bp tS 64 23 4 Daagramia de Sequ ncia oroia e ia esa E E lee aree Tee E E npe ete oon poete 66 5 4 1 O Que
39. o detalhada e Estar alerta para perceber conectivos persuasivos por exemplo certamente claramente e perguntar por que eles est o presentes e Procurar termos vagos por exemplo usualmente s vezes pe a esclarecimentos e Quando forem fornecidas listas que n o estejam completas certificar se de que todos os itens sejam entendidos e Estar certo de que os limites declarados n o contenham pressuposi es n o declaradas por exemplo Os c digos v lidos variam de O a 100 Inteiro Reais Logo que a revis o for conclu da a Especifica o de Requisitos de Software assinada pelo cliente e pelo desenvolvedor A especifica o torna se um contrato de desenvolvimento de software 3 4 Processos de comunica o Na maioria das vezes o desenvolvimento de um software motivado pelas necessidades de um cliente que tem a necessidade de automatizar um sistema existente ou obter um novo sistema completamente automatizado E o software desenvolvido por um desenvolvedor ou por uma equipe de desenvolvedores que normalmente n o conhecem profundamente o negocio Uma vez desenvolvido o software ser provavelmente utilizado por usu rios finais os quais n o s o necessariamente os clientes que originaram o sistema Assim existem tr s partes envolvidas no processo de desenvolvimento de um produto de software o cliente o desenvolvedor e os usu rios Para que o processo de desenvolvimento seja condu
40. o est o levantados na totalidade do sistema e O funcion rio cadastra tarefa para o cadastramento da tarefa ser necess ria a intera o entre o funcion rio e o sistema pois o funcion rio dever informar a data da atividade o hor rio hora in cio e fim de sua realiza o o sistema dever exibir o Prof Walteno Martins Parreira Jr P gina 47 Engenharia de Software logon do funcion rio e uma lista de atividades e projetos o funcion rio dever selecionar uma categoria e uma OP e opcionalmente informar FSA OS Sistema Aplica o e Observa o e ent o solicitar a confirmar a tarefa o sistema dever gravar a tarefa e exibir a lista de tarefas O funcion rio consulta m s o funcion rio seleciona lt lt ou gt gt e navega pelos meses e suas tarefas cadastradas O gerente aprova hora O gerente dever informar o projeto e o sistema ir listar todos os funcion rios que lancaram horas no projeto e que ainda est o aguardando aprova o o gerente seleciona o funcion rio e seleciona todas as horas do funcion rio e ent o confirma a aprova o das suas horas Diagrama de Caso de Uso Descri o Nome Cadastrar Aloca o Descri o O Cadastro da aloca o pode ser feito por periodo data inicial final se o funcion rio estiver trabalhando na mesma atividade e projeto e pode tambem ser feita pontualmente caso o funcionario trabalhe para um projeto fora do seu cotidiano Ator Funcionario Curso
41. odo em que o usu rio n o est dispon vel ou esteja mergulhado sob outras press es e emerg ncias e Fazer perguntas erradas e obter respostas erradas A an lise de sistemas como Tom DeMarco gosta de dizer uma forma de comunica o entre estranhos Os usu rios e os analistas de sistemas t m vocabul rios diferentes experi ncias b sicas diferentes e muitas vezes um diferente conjunto de pressuposi es percep es valores e prioridades Desse modo f cil fazer ao usu rio uma pergunta racional sobre os requisitos do sistema e o usu rio n o entender absolutamente a pergunta sem que nenhum dos dois perceba o fato E f cil para o usu rio prestar lhe algumas informa es sobre os requisitos e o analista n o entender essas informa es novamente sem que nenhum dos dois perceba o fato As ferramentas de modelagem s o uma tentativa de fornecer uma linguagem comum e sem ambig idades para diminuir esses mal entendidos Por m as entrevistas costumam ser realizadas em uma l ngua comum ingl s espanhol franc s portugu s etc portanto o problema real Isso explica porque t o importante marcar entrevistas subsequentes para confirmar que ambas as partes entenderam as perguntas e as respostas e Criar ressentimentos rec procos Existem algumas raz es pelas quais o usu rio pode n o se sentir vontade ou mesmo colocar se em posi o antag nica na entrevista com um analista de sistema ex porque ele percebe q
42. programas para dar apoio a outros programas Tem como caracter stica uma forte intera o com o hardware opera es concorrentes compartilhamento de recursos uso por m ltiplos usu rios e m ltiplas interfaces e Software de Tempo Real s o programas que monitora analisa e controla eventos do mundo real devendo responder aos est mulos do mundo externo com restri es de tempo pr determinadas e Software Comercial a maior rea de aplica o de softwares s o aplica es que gerenciam as opera es comerciais de modo a facilitar o gerenciamento comercial do neg cio da empresa permitindo tamb m a tomada de decis es e Software Cientifico e de Engenharia s o caracterizados por algoritmos de processamento num rico dependentes da coleta e processamento de dados para as mais variadas reas do conhecimento e Software Embutido s o desenvolvidos para executar atividades muito espec ficas e inseridos em produtos inteligentes tanto para atividades comerciais como para atividades domesticas e Software de Computador Pessoal s o produtos desenvolvidos para o uso pessoal do computador tais como planilhas eletr nicas processadores de textos jogos etc e Software de Intelig ncia Artificial faz uso de algoritmos n o num ricos para resolver Prof Walteno Martins Parreira Jr P gina 7 Engenharia de Software problemas complexos que n o apresentam facilidades computacionais num ricas ou de
43. projeto Desde a inicia o do projeto a equipe de gerenciamento precisa identificar as partes interessadas internas e externas Ao longo do planejamento e da execu o do projeto o gerente do projeto e sua equipe devem gerenciar as diferentes necessidades preocupa es e expectativas das partes interessadas bem como a influ ncia destas no projeto para garantir um resultado bem sucedido Alguns exemplos de poss veis partes interessadas podem incluir e Patrocinador Sponsor pessoa ou grupo que fornece os recursos financeiros para a realiza o do projeto e que tamb m prov o aval estrat gico e pol tico que viabiliza e promove o projeto e o defende e A equipe do projeto que inclui o gerente do projeto a equipe de gerenciamento do projeto e outros membros da equipe que executam trabalho no projeto mas n o est o necessariamente envolvidos com o gerenciamento e Clientes e usu rios e Presidente donos e executivos e Acionistas e investidores e Gerentes funcionais e Escrit rio de projetos Project Management Office PMO gerentes e comit s de portf lios e de programas e Fornecedores e parceiros comerciais e Concorrentes e Governo em suas diversas esferas e poderes e Organismos de regula o e fiscaliza o internos e externos incluindo auditorias ag ncias conselhos sindicatos e associa es institucionais profissionais e oficiais e Organiza es n o governamentais ONG e Comunidades vi
44. registros imagens de tela de terminais e listagens de programas que j existam na organiza o usu ria Lembre se todavia que esses recursos normalmente est o relacionados com a implementa o atual do sistema devemos lembrar que isto costuma incluir informa es redundantes e ou contradit rias e ou obsoletas N o obstante isto muitas vezes um bom ponto de partida para voc familiarizar se com o terreno antes de iniciar as entrevistas pessoais com o usu rio Pesquisa externa Se voc estiver construindo um sistema para uma nova aplica o para a qual o usu rio n o disp e de qualquer experi ncia para descrever os requisitos talvez seja necess rio tentar obter informa es em sociedades profissionais ou em peri dicos e livros t cnicos e em relat rios de pesquisas Prof Walteno Martins Parreira Jr P gina 18 Engenharia de Software 2 7 1 Question rio de Pesquisa Essa ferramenta muito conveniente quando h um grande n mero de usu rios ou v rios grupos de usu rios em locais diferentes Nestas situac es n o pr tico entrevistar todas as pessoas mas t o logo as informa es obtidas atrav s dos question rios tenham sido analisadas podem ser realizadas entrevistas com usu rios selecionados Podem ser usados diversos formatos para o question rio de pesquisa tais como de m ltipla escolha lista de verifica o checklist quest es abertas descritivas e combina es das anteriores Os passos pa
45. servi os e A qualidade do software desenvolvido que insuficiente 1 4 A Import ncia do Software Durante as tr s primeiras d cadas da era do computador o principal desafio era desenvolver um hardware que reduzisse o custo de processamento e armazenagem de dados Ao longo da d cada de 1980 avan os na microeletr nica resultaram em maior poder de computa o a um custo cada vez mais baixo Hoje o problema diferente O principal desafio durante a d cada de 1990 melhorar a qualidade e reduzir o custo de solu es baseadas em computador solu es que s o implementadas com software PE Maior Poder de Computac o Avancos da Microeletr nica puta a Custo Baixo O Software o mecanismo que possibilita aproveitar e dar vaz o a esse potencial Assombrosa qualidade de armazenamento e processamento O poder de um computador mainframe da d cada de 1980 agora est a disposi o sobre uma mesa As assombrosas capacidades de processamento e armazenagem do moderno hardware representam um grande potencial de computa o O software o mecanismo que nos possibilita aproveitar e dar vaz o a esse potencial 1 5 O Papel Evolutivo do Software O contexto em que o software foi desenvolvido est estreitamente ligado a quase cinco d cadas de evolu o dos sistemas computadorizados O melhor desempenho de hardware menor tamanho e custo mais baixo precipitaram o aparecimento de sistemas baseados em computadores mais
46. seta fechada nota o pr pria para indicar heran a Extens o Essa nota o pode ser usada para representar fluxos complexos opcionais ou anormais O caso de uso estendido referenciado nas precondi es do caso de uso extensor Prof Walteno Martins Parreira Jr P gina 55 Engenharia de Software Extens o O caso de uso B estende o caso de uso A quando B representa uma situac o opcional ou de exce o que normalmente n o ocorre durante a execu o de A Essa nota o pode ser usada para representar fluxos complexos opcionais ou anormais O caso de uso estendido referenciado nas precondi es do caso de uso extensor As precondi es s o a primeira parte dos fluxos dos casos de uso Extens o 1 Ato ou efeito de estender ou estender se 2 Qualidade de extenso 3 F s Propriedade que t m os corpos de ocupar certa por o do espa o 4 Desenvolvimento no espa o 5 Vastid o 6 Grandeza for a intensidade 7 Por o de espa o 8 Comprimento 9 Superf cie rea 10 Ramal telef nico com o mesmo n mero do telefone principal usado geralmente em resid ncias ou escrit rios Dicion rio Aur lio Exemplo O desenho informa que o cadastro do cliente pode ser chamado diretamente da solicita o do servi o mas esta uma a o que pode ocorrer ou n o Observe que o caso de uso que estende tem uma rela o de depend ncia com o caso de uso estendido seta tracejad
47. sofisticados Mudamos dos processadores a v lvula para os dispositivos Prof Walteno Martins Parreira Jr P gina 4 Engenharia de Software microeletronicos que s o capazes de processar 200 milh es de instru es por segundo Em livros populares sobre a revolu o do computador Osborne caracterizou uma nova revolu o industrial Toffler chamou o advento da microeletronica de a terceira onda de mudan a na historia humana e Naisbitt previu que a transforma o de uma sociedade industrial em uma sociedade de informa o ter um profundo impacto sobre nossas vidas Feigenbaum e McCorduck sugeriram que a informa o e o conhecimento controlados por computador ser o o foco principal de poder no s culo XXI e Stoll argumentou que a comunidade eletr nica criada por redes e software e a chave para a troca de conhecimentos em todo o mundo Quando se iniciava a d cada de 1990 Toffler descreveu uma mudan a de poder em que as velhas estruturas de poder governamental educacional industrial econ mico e militar se desintegrar o enquanto os computadores e o software levar o a uma democratiza o do conhecimento Primeiros Anos Segunda Era Terceira Era Quarta Era 1950 a 1960 1960 a 1970 1970 a 1980 1980 a 2000 Orienta o Batch Sistemas Distribu dos Sistemas do Desktop poderosos dm d A Tecnologias Orientadas Distribuic o Limitada Tempo Real Hardware de Baixo Custo Objetos Software Customizado Banco de Dados
48. uso teremos todas as funcionalidades do sistema Para cada funcionalidade iremos descrever as intera es entre o ator e as rea es do sistema O que constitui um bom ator ator e Atores n o s o parte do sistema eles interagem com o sistema Fornecem dados e ou recebem Sistema Fronteira informa o do sistema Atores e Uma mesma pessoa pode assumir pap is diferentes e V rias pessoas podem assumir o mesmo papel e Identificando o ator Prof Walteno Martins Parreira Jr P gina 53 Engenharia de Software a O ator Cliente o mesmo que ator Inadimplente se o inadimplente usar o sistema de forma diferente somente poder consultar novas formas de pagamento eles s o atores diferentes b N o devemos criar ator para cada coadjuvante temos que identificar um grupo de personagens que desempenham o mesmo papel por exemplo Gerente de Projeto e o Coordenador da Equipe acessam as mesmas telas e desempenham o mesmo trabalho no sistema portanto pertencem ao mesmo grupo de personagens de Ger ncia Um Ator uma classe com um cone padr o Exemplos de atores e Cliente e Sistema de RH apareceria e Gerente e Atendente e Sistema de Contas a Pagar e Scanner 2 v px Leitur crio e Leitor tico O ator aquele que utiliza o sistema para passar informa es Pode ser outro sistema um hardware um grupo de pessoas Mas t m que necessariamente interagir com o sistema Como Identificar os Atores
49. 5 Mg em cheque em dinheiro gt C em cart o 4 Os UCs filhos herdam os atributos a opera es e sequ ncias de comportamento do UC pai Os UCs filhos podem adicionar e redefinir o comportamento do UC pai atrav s da inser o de sequ ncias adicionais de a es em pontos arbitr rios da sequ ncia do UC pai Os UCs filhos podem substituir o UC pai em qualquer lugar que ele aparece Relacionamentos de inclus o e extens o do use case filho tamb m modificam o use case do pai Normalmente a similaridade entre use cases identificada ap s a descri o dos casos 5 2 1 Como fazer o Diagrama de Casos de Uso Para facilitar a identifica o na constru o do diagrama dividimos a constru o em tr s partes e A primeira a identifica o dos poss veis casos de uso lembrar que caso de uso uma funcionalidade do sistema e tem in cio meio e fim Exemplo Empresa de manuten o em equipamentos m dicos N Evento Use Case Ator Resposta Vendeccr fecha novo contrasto Regstwar contrato vendedor Cortrsto registrado 2 Creme solata servi o Regstar cnamaca Cierte Chamade regstsca 3 Supervisor scicta chamadas Gerar cnamacas Supervisor Chamadas pencemes geradas peoce tes peoce ctez Supervisor alocs t cnico Abocar t cnico Superv scr Tecrico siocscc s Tecrico morma o fechamento ds Fechar chamsds Supervscr Chamade encerrada cnamaca Vendeccr cadastra novo cheme Cadasty cien Vendedor Cterte cadastraco 7 Superv
50. ESSMAN Roger S Engenharia de Software 3 edi o S o Paulo Makron Books 1995 SOMMERVILLE lan Engenharia de Software 6 edi o S o Paulo Addison Wesley 2003 YOURDON Edward Administrando o ciclo de vida do sistema 2 edi o Rio de Janeiro Editora Campus 1989 An lise Estruturada Moderna 3 Edi o Rio de Janeiro Editora Campus 1992 Nota do Professor Este trabalho um resumo do conte do da disciplina para facilitar o desenvolvimento das aulas devendo sempre ser complementado com estudos nos livros recomendados e o desenvolvimento dos exerc cios indicados em sala de aula e a resolu o das listas de exerc cios propostas Prof Walteno Martins Parreira Jr P gina 75
51. Normal Cadastro de Periodo sistema cadastra trabalho de 9 00 ate as 18 00hs 1 Funcion rio informa data inicial e fina 2 Sistema exibe logon do usu rio cadastrado e lista Tarefas e Projetos 3 Funconario seleciona tarefa e projeto e informa O5 Sistema e Observa o 4 Funcion rio confirma cadastro de trabalho 5 Sistema registra Aloca o Cursos Alternativos Exce es Passo 1 Cadastro de Aloca o Pontual Passo 1 Caso data invalida 1 Funcion rio informa data e hora in cio e fim 1 Sistema exibe mensagem de data inv lida 2 Retomar ao passo 2 do curso normal 2 Retomar ao passo 1 do curso normal Passo 5 Caso Tarefa Projeto ou Data n o informados 1 Sistema exibe mensagem a tarefa o projeto e a data devem ser informados 2 Retomar ac passa 3 do curso normal Diagrama de Classe A pr xima tarefa a classifica o dos objetos envolvidos neste processo e a rela o de uns com os outros Diagramas de classe mostram a estrutura geral do sistema e tamb m as suas propriedades relacionais e de comportamento No Funcion rio Horas Trabalhadas Projeto Tarefa Diagrama de Classe os objetos envolvidos no sistema de controle de horas s o agrupados em classes Uma classe um conjunto de objetos Na classe de funcion rios os atributos incluem o logon nome unidade filial e n mero funcional Esta classe tamb m armazena a opera o buscarLogon dentre outras aqui ainda n o de
52. Sistemas Especialistas Programa o Artesanal Produto de Software Impacto de Consumo Computa o paralela em Administra o PEE FE S Software House intelig ncia embutida Ferramentas CASE Espec fica Sem Documenta o Reutiliza o Redes Neurais artificiais A tabela descreve a evolu o do software dentro do contexto das reas de aplica o de sistemas baseados em computador Durante os primeiros anos do desenvolvimento de sistemas computadorizados o hardware sofreu continuas mudan as enquanto o software era visto por muitos como uma reflex o posterior A programa o de computador era uma arte secundaria para a qual havia poucos m todos sistem ticos O desenvolvimento do software era feito virtualmente sem administra o ate que os prazos come assem a se esgotar e os custos a subir abruptamente Durante esse per odo era usada uma orienta o batch em lote para a maioria dos sistemas Not veis exce es foram os sistemas interativos tais como o primeiro sistema de reservas da American Airlines e os sistemas de tempo real orientados a defesa como o SAGE Na maior parte entretanto o hardware dedicava se a execu o de um nico programa que por sua vez dedicava se a uma aplica o espec fica Durante os primeiros anos o hardware de prop sito geral tornara se lugar comum O software por outro lado era projetado sob medida para cada aplica o e tinha uma distribui o relativamente limi
53. a ou seja a O Cadastro do Cliente s pode ser executada se Solicitar Servi o for executado antes Nendante asEygr dsz Inclus o Essa nota o pode ser usada para representar subfluxos complexos e comuns a v rios casos de uso O caso de uso inclu do referenciado no fluxo do caso de uso que inclui O caso de uso A inclui o caso de uso B quando B representa uma atividade complexa comum a v rios casos de uso Essa nota o pode ser usada para representar subfluxos complexos e comuns a v rios casos de uso O caso de uso inclu do referenciado no fluxo do caso de uso que inclui Exemplo Um controle de pedidos de um restaurante em que foram identificados os seguintes casos de uso Comandar Jantar Comandar Bebida Comandar Sobremesa Na figura percebe se que na funcionalidade Comandar Jantar pode se ter um atalho para Comandar Bebida ou Comandar Sobremesa Esta t cnica aplicada para facilitar o uso do sistema Aten o o uso dos casos de uso estendidos s o facultativos ou seja pode haver o pedido de jantar sem bebida e sem sobremesa amp aslendes umm l oem Bebida y Comandar k P i Jantar pra Drs Comandar amp astendes d nad Melhorando Cadastrar Pagamento s o passos comuns a Solicitar Servico e Cadastrar Venda por este motivo este conjunto de passos isolado em outro caso de uso Pode se observar tamb m que o caso de uso que inclui tem uma rela o de depend ncia
54. a dadas Ee ett deerit 10 1 11 Os desafios da Engenharia de Software sse 10 2 TECNICAS DE ENTREVISTAS E DE COLETA DE DADOS 11 2 Jntrod cao cere eU e Ete UR E ERE P Ue EUR E e QU RM SEE EN EUN Ez Rent 11 2 2 Tipos de Entrevistas asas ett ore Hi PER LI PL T LM S e eiue Erbe teet enn 11 2 3 Problemas Fundamentais eese ener aa aE asai a ennt 12 2 4 Diretrizes Para a Realiza o de Entrevistas 13 2 4 1 Desenvolva um Plano Geral de Entrevistas erre 13 2 4 2 Certifique se de que tem Autoriza o para Falar com os Usu rios 13 2 4 3 Planeje a Entrevista para Fazer Uso Eficiente do Tempo esses 14 2 4 4 Utilize Ferramentas Automatizadas que Sejam Adequadas Mas N o Abuse 15 2 4 5 Tente Descobrir quais Informa es o Usu rio tem mais Interesse 15 2 4 6 Use um Estilo Adequado de Entrevistar erre 15 2 5 Poss veis Formas de Resist ncia na Entrevista eseeeeesseseeeeeeeeeeeenen 16 2 0 Qutros Probl mas setas tee siss ee as pia an ies age ho a E A A 17 2 7 Formas Alternativas de Coleta de Dados renan 18 21 11 Question rio de Besquisa i e HERE ere te T e ete e dietas 19 21 2 Observa es no ambiente e eie entente Ier tede enne terreni reete ae Aan 19 3 ANALISE DE REQUISITOS eei dos
55. a de levantamento de requisitos composta por diversas t cnicas que visam obter do cliente as informa es necess rias para desenvolver o projeto do sistema de informa o Essas t cnicas podem ser e Entrevistas n o estruturadas Informal ou sem agenda pr definida e Entrevistas estruturadas Com uma agenda pr definida e Observa o do comportamento Observar os usu rios em seu ambiente de trabalho e Aprendizagem com o usu rio Analisa e discute com o usu rio a maneira como feito o trabalho e Prototipagem Desenvolvimento de um modelo que simular o sistema real e Brainstorming Reuni o com v rias pessoas onde todos discutem um tema central e An lise de textos O usu rio descreve as necessidades textualmente t cnica muito usada atualmente e Reutilza o de requisitos Reaproveitamento de padr es ou requisitos de outros sistemas Os requisitos podem ser funcionais e n o funcionais 4 4 1 Requisitos funcionais Os requisitos funcionais s o aqueles que fazem parte do sistema como um relat rio espec fico um campo a mais em um cadastro etc Ele normalmente tem a finalidade de agregar valor ao usu rio ou facilitar o trabalho que ele desenvolve S o exemplos de requisitos funcionais e o software deve possibilitar o c lculo dos gastos di rios semanais mensais e anuais com pessoal e o software deve emitir relat rios de compras a cada quinze dias e os usu rios devem poder obter o n
56. ado novos conceitos e vis es da linguagem 5 1 Conceitos Paradigma uma forma de pensar e perceber o mundo real e determina o que escolhemos como significativo e o que descartamos ao compreender ou descrever o que existe ou ocorre no mundo em torno de n s A mudan a de paradigma uma oportunidade de encontrar novas interpreta es para antigas quest es bem como para rever solu es tidas como definitivas Dizemos que a O O constitui um novo paradigma computacional pois representa uma mudan a na forma de pensar e conceber sistemas e programas de computador A estrat gia de O O para modelagem de sistemas baseia se na identifica o dos objetos que desempenham ou sofrem a es no dom nio do problema e dos padr es de coopera o e intera o entre estes objetos Abstra o Permite ignorar os aspectos de um assunto n o relevante para o prop sito Diminui a complexidade Objeto alguma coisa que pode ser identificada distintamente Qualquer coisa real ou abstrata respeito da qual armazenamos dados e os m todos que os manipulam Martin Odell Uma entidade capaz de armazenar um estado informa o e que oferece um n mero de opera es comportamento para ou consultar ou alterar o estado Jacobson E algo que possui estado comportamento e identidade Booch DS m E Nome Sebasti o c e35 Data Nasc 10 01 1964 Sal rio R 12 500 00 3 m Da ae En Classe Pode ser vista
57. ados ou neg cios n o confie na sua mem ria e Aten o ao Neg cio N o desvie de foco nem inclua funcionalidades extras se o cliente n o solicitou Prof Walteno Martins Parreira Jr P gina 72 Engenharia de Software 6 PROJETO DE SISTEMAS 6 1 Aspectos Fundamentais do Projeto de Sistemas 6 2 Projeto Orientado a Objetos Prof Walteno Martins Parreira Jr P gina 73 Engenharia de Software 7 FERRAMENTAS CASE Prof Walteno Martins Parreira Jr P gina 74 Engenharia de Software BIBLIOGRAFIA CARNEIRO Margareth Fab ola S Gerenciamento de Projetos apostila ENAP 2000 D VILA M rcio PMBOK e gerenciamento de projetos 2001 Dispon vel em lt http www mhavila com br topicos gestao pmbok html gt Acesso em 10 fev 2012 FORCHESATTO Andr Luiz Apostila de Engenharia de Software Xanxere Universidade do Oeste de Santa Catarina INPE Engenharia de Software Dispon vel em lt http www2 dem inpe br ijar AnalEstr html gt acesso em 20 jul 2013 KIMURA Marcos Curso b sico de MS Project apostila Bras lia ENAP 2002 PAULA FILHO Wilson de P dua Engenharia de Software Fundamentos M todos e Padr es 1 edi o Rio de Janeiro LTC Editora 2001 PARREIRA J NIOR Walteno M TEODORO NETO Euclides M amp GOMES Gina Marcia S An lise e Programa o Orientada ao Objeto in Encontro de Inicia o Cient fica e III Encontro de Pesquisa ILES ULBRA Itumbiara GO 2002 PR
58. ados que possibilitam que os programas manipulem adequadamente a informa o e 3 documentos que descrevem a opera o e o uso dos programas N o h duvida de que outras defini es mais completas poderiam ser oferecidas Mas precisamos de algo mais que uma defini o formal O software um elemento de sistema l gico e n o f sico Portanto o software tem caracter sticas que s o consideravelmente diferentes das do hardware 1 O software desenvolvido e projetado por engenharia n o manufaturado no sentido cl ssico O software n o se desgasta 3 A maioria dos softwares feita sob medida em vez de ser montada a partir de componentes existentes Prof Walteno Martins Parreira Jr P gina 3 Engenharia de Software 1 3 Problemas associados ao soflware Existem um conjunto de problemas associados ao software que v rios autores chamam de crise do software Este conjunto de problemas n o se limitam ao software que n o funciona adequadamente mas ab range tamb m prob lemas associados a forma de desenvolvimento destes softwares a forma como efetuada a manuten o destes softwares como atender a demanda por novos softwares e como desenvolver novos softwares cada vez mais rapidamente Os problemas que atingem o desenvolvimento podem ser descritos como e Estimativas de prazos e de custos que s o frequentemente imprecisos e Produtividade dos profissionais da rea que n o tem acompanhado a demanda por novos
59. an lise direta 1 7 Engenharia de Software Uma Defini o Urna primeira defini o de engenharia de software foi proposta por Fritz Bauer na primeira grande conferencia dedicada ao assunto O estabelecimento e uso de s lidos princ pios de engenharia para que se possa obter economicamente um software que funcione eficientemente cm m quinas reais A engenharia de software uma deriva o da engenharia de sistemas e de hardware Ela abrange um conjunto de tr s elementos fundamentais m todos ferramentas e procedimentos que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a constru o de software de alta qualidade produtivamente Os m todos de engenharia de software proporcionam os detalhes de como fazer para construir o software Os m todos envolvem um amplo conjunto de tarefas que incluem planejamento c estimativa de projeto an lise de requisitos de software e de sistemas projeto da estrutura de dados arquitetura de programa e algoritmo de processamento codifica o teste e manuten o Os m todos da engenharia de software muitas vezes introduzem uma nota o gr fica ou orientada a linguagem especial e introduzem um conjunto de crit rios para a qualidade do software As ferramentas de engenharia de software proporcionam apoio automatizado ou semi automatizado aos m todos Atualmente existem ferramentas para sustentar cada um dos m todos anota
60. ao usu rio se o item em discuss o depende para sua exist ncia de alguma outra coisa Isso especialmente til quando se discutem poss veis tipos de objetos e relacionamentos no DER Em um sistema de controle de pedidos por exemplo pode se perguntar ao usu rio se seria poss vel haver um pedido sem que haja um cliente Confirma o Dizer ao usu rio o que acha que ouviu ele dizer usar suas pr prias palavras em lugar das dele e pe a confirma o Pode se dizer Deixe me ver se entendi o que voc disse 2 5 Poss veis Formas de Resist ncia na Entrevista Deve se estar preparado para o fato de que alguns usu rios ser o contr rios id ia de uma entrevista essa uma das raz es para garantir que o chefe ou algu m com autoridade no setor esteja ciente e tenha permitido a entrevista Algumas das obje es mais comuns e algumas poss veis respostas a essas obje es Voc est tomando tempo demais de mim A resposta a isso explicar que compreende e desculpar se pelo tempo que precisar tomar mas que j preparou tudo e far a entrevista no tempo mais curto poss vel Isso naturalmente exige que o analista chegue pontualmente na hora marcada para o in cio da entrevista mantenha a discuss o no rumo previsto e encerre a no momento em que tenha dito que o faria Voc est amea ando meu emprego Isso muitas vezes uma rea o emocional que pode ou n o ter fundamento Embora possa pensar em v rias maneiras de
61. as entrevistas por m impedindo que elas sejam feitas ele estar enviando uma mensagem pol tica para o chefe do chefe do seu chefe Por todos esses motivos uma boa medida obter uma pr via autoriza o Na maior parte dos casos basta uma autoriza o verbal se a organiza o for terrivelmente burocr tica ou paran ica pode se precisar de uma autoriza o escrita Isso a prop sito tamb m significa que o analista deve estar atento pol tica organizacional se tiver certeza da necessidade de falar com um usu rio normalmente um usu rio do n vel operativo com quem tenha sido avisado para n o conversar 2 4 3 Planeje a Entrevista para Fazer Uso Eficiente do Tempo O principal aspecto desta sugest o que deve se compreender que est tomando o tempo do usu rio e que ele ou o chefe dele pode achar at que o analista esteja desperdi ando o tempo dele Assim sendo importante o planejamento e prepara o t o antecipadamente quanto poss vel para poder fazer uso eficiente da entrevista A primeira coisa a fazer certificar se de que o usu rio conhece o assunto da entrevista Em alguns casos isso pode ser feito por telefone em outros pode ser adequado preparar uma lista das perguntas que ser o feitas ou dos t picos que ser o abordados ou dos DFD que necessita ser revisados e remet la ao usu rio com um dia ou dois de antecipa o Se n o puder fazer isso um ind cio de que de fato o analista n o est
62. com visibilidade todos os atributos e m todos navegabilidade restri es Cuidado com associa es que tenham multiplicidades m nimas 1 em perspectiva de implementa o Como no exemplo o cliente tem no m nimo um servi o e o servi o tem no m nimo um cliente associado D vidas que podem aparecer Os atores identificados viram classes Cuidado nem todo ator uma classe O ator quem executa a a o se houver a necessidade de armazenar quem executou a a o a sim teremos o ator como classe no diagrama de classe Prof Walteno Martins Parreira Jr P gina 65 Engenharia de Software e identifiquei as classes mas os m todos em qual classe coloco Os m todos trabalham com as informa es da classe onde ele ir ficar lembre se do encapsulamento e identifiquei alguns m todos gen ricos que trabalham informa es de v rias classes como fazer Existem as classes de projetos ou Utilit rios que facilitam o agrupamento de m todos gen ricos por exemplo emitirNotaFiscal um m todo que trabalha com informa o da filial do produto do pedido e do cliente 5 4 Diagrama de Sequ ncia Intera o uma especifica o comportamental que inclui uma sequ ncia de trocas de mensagem entre um conjunto de objetos dentro de um contexto Existem dois diagramas de Intera o e Diagrama de Sequ ncia intera o entre objetos ao longo do tempo mostrando todos os objetos que participam do contexto e a se
63. de todos esses aspectos desde o in cio do projeto passando pelo planejamento e outras fases do projeto at a sua conclus o A Integra o dos processos tamb m tratada como uma disciplina pelo PMI Na perspectiva da utiliza o do software MS Project todas estas disciplinas ou reas de conhecimento podem e devem ser contempladas na realiza o de um projeto A metodologia de gerenciamento de projetos a base sobre a qual todos os trabalhos dever o ser efetuados O software apenas auxiliar o gerente a estruturar a metodologia a uma forma mais eficaz e integrada de trabalho 4 6 1 Projeto e seu gerenciamento Um projeto um esfor o tempor rio empreendido para criar um produto servi o ou resultado exclusivo Tempor rio n o significa necessariamente de curta dura o mas sim que um projeto possui um in cio e um t rmino definidos Isso distingue o projeto dos trabalhos operacionais de natureza cont nua E exclusivo indica a singularidade da natureza de cada projeto pois mesmo que elementos repetitivos ou similares possam estar presentes em algumas entregas do projeto o resultado de cada projeto obtido sob uma combina o exclusiva de objetivos circunst ncias condi es contextos fornecedores etc O gerenciamento de projetos consiste na aplica o de conhecimentos habilidades ferramentas e t cnicas adequadas s atividades do projeto a fim de atender aos seus requisitos S o definidas nove reas de con
64. desenvolveram v rios m todos de an lise e especifica o de software identificando problemas e suas causas Cada m todo tem suas caracter sticas que s o nicas mas todos compartilham alguns princ pios fundamentais a O dom nio da informa o b Modelos e c Parti es 3 5 1 O dom nio da informa o Composto por dados e eventos Para entender o dom nio da informa o cada um destes tr s pontos de vista deve ser considerado para dados e eventos a fluxo da informa o representa a maneira pela qual os dados e eventos se modificam medida que cada um se movimenta pelo sistema Ao longo deste caminho novas informa es podem ser introduzidas a partir de um dep sito Uma entrada pode ser transformada em informa es intermedi rias at alcan ar a sa da b conte do da informa o representa os dados e os itens de controle que comp em um determinado item de informa o mais amplo c estrutura da informa o representa a organiza o interna dos dados que comp e um item de informa o 3 5 2 Modelagem Obter maior compreens o do que deve ser constru do Os modelos devem ser capazes de modelar a informa o que o software transforma as fun es que possibilitam as transforma es e o comportamento do sistema quando a transforma o est ocorrendo Durante a an lise de requisitos constru mos modelos que se concentram naquilo que o software deve fazer e n o como ele deve fazer Pap is dos modelos cr
65. dos anteriormente Quando as ferramentas s o integradas de forma que a informa o criada por uma ferramenta possa ser usada por outra estabelecido um sistema de suporte ao desenvolvimento de software chamado engenharia de software auxiliada por computador CASE Computer Aided Software Engineering O CASE combina software hardware e um banco de dados de engenharia de software uma estrutura de dados contendo importantes informa es sobre analise projeto codifica o e teste para criar um ambiente de engenharia de software que seja an logo ao projeto auxiliado por computador engenharia auxiliada por computador para o hardware Os procedimentos da engenharia de software constituem o elo de liga o que mant m juntos os m todos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de computador Os procedimentos definem a sequ ncia em que os m todos ser o aplicados os produtos deliverables que se exige que sejam entregues documentos relat rios formul rios etc os controles que ajudam a assegurar a qualidade e a coordenar as mudan as e os marcos de referencia que possibilitam aos gerentes de software avaliar o progresso A engenharia de software compreende um conjunto de etapas que envolve m todos ferramentas e os procedimentos Essas etapas muitas vezes s o citadas como paradigmas da engenharia de software Um paradigma de engenharia de software e escolhido tendo se como base a natureza do pro
66. e esperar que outra seja encerrada Depende da intui o e experi ncia do gerente de projeto Prof Walteno Martins Parreira Jr P gina 32 Engenharia de Software Identificar atividades Requisitos Identificar depend ncias de software de atividades Estimar recursos para atividades Alocar pessoas s atividades Criar diagramas de projeto Diagramas de atividades e diagramas de barra 4 5 3 Diagramas de barras e redes de atividades Nota es gr ficas utilizadas para ilustrar a programa o de projeto Apresentam a divis o do projeto em atividades As atividades n o devem ser muito pequenas Devem durar pelo menos uma semana a n o em situa es bem espec ficas As redes de atividades mostram depend ncias entre atividades e o caminho cr tico Os diagramas de barra mostram para quando est programado o in cio e t rmino da atividade bem como os respons veis por cada atividade Um exemplo de programa o de um projeto apresentando as atividades T1 a T12 Atividade Dura o Depend ncias o tempo estimado para cada atividade em dias dias as depend ncias para iniciar as TI 8 atividades e os seus respectivos marcos M1 a T2 15 MB T3 15 TI M1 A partir do quadro de atividades poss vel T4 10 desenvolver os diagramas T 10 T2 T4 M2 T6 5 T1 T2 M3 E 20 T1 M1 T8 25 T4 M5 T9 15 T3 T6 M4 T10 15 T5 T7 M7 TIl 7 T9 M6 T12 10 T11 M8 Prof Walten
67. e problemas e Negocia o influ ncia e persuas o e Decis o iniciativa e proatividade e Organiza o e disciplina e Autocontrole equil brio e resili ncia e Empreendedorismo e Efic cia O PMI mant m um C digo de tica e Conduta Profissional Project Management Institute Code of Ethics and Professional Conduct criado para incutir confian a profiss o de gerenciamento de projetos e auxiliar os praticantes a se tornarem melhores profissionais Para isso o c digo descreve as expectativas que os profissionais de gerenciamento de projetos tem de si e de seus colegas Ele exige que os profissionais demonstrem compromisso com a conduta tica e profissional sendo espec fico quanto obriga o b sica de responsabilidade respeito justi a e honestidade Isso inclui respeitar as leis regulamentos e pol ticas organizacionais e profissionais Mais que ser um facilitador o gerente de projetos deve fazer a diferen a no bom andamento e no sucesso dos projetos 4 6 4 Partes interessadas no projeto Partes interessadas intervenientes ou do termo em ingl s stakeholders s o todas as pessoas e organiza es envolvidas no projeto ou cujos interesses podem ser positiva ou Prof Walteno Martins Parreira Jr P gina 40 Engenharia de Software negativamente afetados pela realiza o ou pelos resultados do projeto As partes interessadas tamb m podem exercer influ ncia sobre o projeto e sobre os membros da equipe do
68. e que define o comportamento e atributos para subclasses Veiculo e N o instanciada diretamente me Diri Iri e Uma classe abstrata pode conter opera es igir abstratas S o opera es cuja implementa o n o D especificado na superclasse somente sua assinatura e As classes que herdarem essa opera o dever o implement la sendo a implementa o diferente para cada classe ou mant la abstrata Barco Dirigir Dirigir c Classe associativa Ocorre quando h necessidade de colocar informa o em uma associa o Os dados de emprego s existem se houver uma pessoa e uma empresa se n o houver esta associa o n o existir emprego Emprego Data in cio Sal rio Cargo Empresa Pessoa Depend ncia entre Classes e Relacionamento de depend ncia uma conex o sem ntica entre dois elementos do modelo e Qualquer altera o no elemento independente Curso poder afetar o elemento dependente Agenda de Curso e Como identificar depend ncias i Quando uma classe tem uma opera o que usa uma inst ncia de outra classe como par metro ii Uma classe chama uma opera o que de escopo de outra classe Agenda de T Curso Curso Prof Walteno Martins Parreira Jr P gina 63 Engenharia de Software 5 3 6 Navegabilidade Indica a refer ncia de objetos de um classe a objetos de outra classe Como no exemplo indica se que uma divul
69. ecida no diagrama de contexto se a queixa do usu rio um sintoma ou um problema depende Prof Walteno Martins Parreira Jr P gina 17 Engenharia de Software de ela estar associada a alguma coisa dentro dos limites do sistema ou fora deles Desse modo deve se dar especial aten o ao desenvolvimento do modelo ambiental O usu rio pode ser incapaz de explicar o que ele quer que o sistema fa a ou pode mudar de opini o Esse um problema comum e o analista de sistemas deve estar preparado para ele Quanto maior for esse problema mais importante torna se a prototipa o Desentendimento entre usu rios de mesmo n vel subordinados e chefes Infelizmente isso coloca o analista de sistemas no papel de mediador entre as partes em desentendimento Como analista n o pode abdicar desse papel n o pode dizer Quando voc s decidirem o que querem e entrarem em um acordo procurem me Em vez disso deve se agir como um negociador conduzindo todos os interessados a uma sala e trabalhando com eles na tentativa de chegar a um consenso Isso infelizmente envolve habilidades e procedimentos fora do escopo deste texto Descobrir disparidades entre o padr o oficial e a pratica do trabalho Durante as entrevistas o analista descobre que podem existir algumas disparidades entre a vers o oficial de como o sistema funciona e como realmente ocorre no n vel operacional Neste caso o analista deve utilizar a diplomacia quando relatar estas discrep
70. eee I Digitar entrevist transi es internas igitar entrevista Entrevistando P Fechar pesquisa Finalizada am Quando utilizar este diagrama Nem todas as classes podem ser representadas por um diagrama de estados simplesmente por n o possuir estados a serem analisados Se a classe tem um atributo status ou situa o um indicativo de que o objeto ter comportamentos diferentes de acordo com os valores atribu dos neste atributo Esta indica o pode ser vista por associa o com minimalidade 0 indica que o estado da classe pode ser diferente se tiver esta associa o O uso do Diagrama de Estados facultativo ele s ser utilizado quando houver necessidade de representar os estados de uma classe o estudo do ciclo de vida que um objeto poder trilhar Em um contexto geral percebe se que o diagrama de estados depende do diagrama de classes e do diagrama de casos de uso e pode se ter mais de um diagrama de estados por sistema Lembrar mais uma vez que os diagramas se completam e conforme v o sendo identificados os eventos estados devem ser revistos e o diagrama de classes e casos de uso Os diagramas devem estar coerentes 5 5 2 Para terminar e Busque a padroniza o nos nomes Atributos M todos e Classes co cliente id_pe a num_func nu_endere o e Todos os elementos de modelagem Caso de Uso Classe Objeto etc devem estar no singular e Fa a sempre dicion rios de d
71. encelarCliente Package vis vel em um pacote Visibilidade Para facilitar a cria o do diagrama de classes deve se seguir os passos 1 Passo Identificar as Informa es do Sistema classes e atributos 2 Passo Desenhar o diagrama Agora o que foi identificado anteriormente entrar no desenho como uma classe ou atributo ou m todo ou associa o ou n o entra no modelo Ilo 3 Passo Relacionar todas as classes levantadas Os objetos de uma determinada classe fazem refer ncia a quais outros objetos 4 Passo detalhar atributos e m todos Atributos Leia atentamente os casos de uso e identifique as necessidades de informa o M todos Inicialmente podemos ter ideia dos m todos mas o diagrama de sequ ncia ir ajudar bastante a levantar os m todos 5 Passo fazer batimento com as descri es dos casos de uso para verificar se h diverg ncias Pode haver necessidade de cria o de novos casos de uso Podem ser descobertas novas classes atributos Observa es Fa a o diagrama pensando em conjuntos O conjunto de clientes servi os e o relacionamento entre eles ali s o que Cliente classe sen o um conjunto de objetos contrata O diagrama de classes pode ser feito com perspectivas diferentes podemos fazer uma vers o visando a parte conceitual entendimento das classes e suas associa es outra vers o para especifica o e outra para implementa o
72. ento do sistema de acordo com o tempo e a troca de mensagens entre os objetos S o levantadores de m todos Gr fico de Estados diagrama comportamental que mostra uma m quina de estados dando nfase ao comportamento ordenado por eventos de um objeto Atividades diagrama comportamental que mostra uma m quina de estados dando nfase ao fluxo de uma atividade para outra Componentes diagrama estrutural que mostra um conjunto de componentes e seus relacionamentos Implanta o diagrama estrutural que mostra um conjunto de n s e seus relacionamentos F sd X XH o E Comportamentais Prof Walteno Martins Parreira Jr P gina 46 Engenharia de Software Os diagramas de caso de uso sequ ncia colabora o de estado e de atividade s o ditos Comportamentais pois modelam aspectos din micos do sistema mostram na maioria das vezes como as entidades interagem para a execu o de uma funcionalidade Os outros diagramas de classe de objetos de componente e de implanta o s o estruturais pois modelam como o nome diz a estrutura do sistema sua parte est tica mostram como as entidades s o compostas e seus relacionamentos c Exemplo Sistema de Controle de Horas Para analisar cada diagrama pode se basear em um sistema de aloca o das horas trabalhadas Time Sheet O Sistema de Controle de Horas funciona para que a empresa tenha controle sobre as horas trabalhadas dos seus funcion
73. envolvem uma mesma ideia de neg cio devem ser abstra dos em um nico caso de uso e Um erro comum achar que um caso de uso uma atividade simples um caso de uso definido na sua descri o um conjunto de passos e Evitar palavras estrangeiras lembrando se que o Diagrama de Caso de Uso serve para valida o com o usu rio e N o desenhar associa o entre atores somente permitido a generaliza o e O Diagrama de Casos de Uso uma excelente ferramenta para levantamento de requisitos portanto cuidado com os falsos requisitos a Requisito falso tecnol gico na modelagem de sistemas h o termo tecnologia perfeita deve se abstrair todos os problemas de tecnologia b Requisito falso arbitr rio funcionalidade que o sistema n o precisa possuir para atender ao seu prop sito 5 3 Diagrama de Classe a ess ncia da UML trata se de uma estrutura l gica est tica em uma superf cie de duas dimens es mostrando uma cole o de elementos declarativos de modelo como classes tipos e seus respectivos conte dos e rela es E composto de e Classes atributos Carro e m todos 3 A modeo e Associa es sadio chassi in Endereco concicao irt z e estado int peco int busracamb piaca Ini void CalrudaNuguslb void Empregado nome im endere o int telefone ini Hata dmissan dataDemizssao dr iPadido Exemplo ds Atributos Associa o Pedido
74. finidas Os Diagramas de Classe suportam heran a de outros sistemas Prof Walteno Martins Parreira Jr P gina 48 Engenharia de Software Funcion rio logon nnme unidada filial nu funcional data hora initio hora fim a s sisterma obsenatan aprovada alocacann Diagrama de Sequ ncia Mostra uma intera o organizada em forma de uma sequ ncia dentro de um determinado per odo de tempo Os participantes s o apresentados dentro do contexto das mensagens que transitam entre eles O diagrama de sequ ncia um diagrama de intera o Um Diagrama de Sequ ncia oferece uma vis o detalhada de um caso de uso Ele mostra uma intera o organizada em forma de uma sequ ncia dentro de um determinado per odo de tempo e contribui para que se processe a documenta o do fluxo de l gica dentro da aplica o Os participantes s o apresentados dentro do contexto das mensagens que transitam entre eles Num sistema de software abrangente um Diagrama de Sequ ncia pode ser bastante detalhado e pode incluir milhares de mensagens Cadastrar Aloca o Curso Normal Funcianario 4 data inicial e final 2 buscarLogonQ re 3 busca Tarefa puscarProjeto To F J 5 Informa tarefa prod OS sisterna e olle erva o 7 aloca o T i 6 Confirma Aloca o Prof Walte
75. ga o feita tem a responsabilidade de informar a qual programa pertence Como no diagrama de classe n o tem a representa o de chave estrangeira a navegabilidade indica que a divulga o ter a chave estrangeira da entidade programa pois divulga o ter a responsabilidade de saber qual programa faz refer ncia Divulga o Programa Papeis em associa o Qualificador Restri o ou propriedade Agrega o j ordenado 1 9 Classe A K gt eme imo Classe B 3 possui Generalizac o P a Nome do papel Multiplicidade Composi o Classe D Classe C Navegabilidade Classe D 130 Multiplicidade Classe Exatamente 1 a Classe Muitos zero ou mais 0 1 Classe opcional zero ou um Classe Sequ ncia especificada 5 3 7 Visibilidade Uma Classe pode definir o tipo de acesso que seus membros propriedades e m todos permitir o s demais partes do sistema Em uma escala progressiva de privacidade dos membros os tipos de acesso poss veis s o p blico protegido e privado Prof Walteno Martins Parreira Jr P gina 64 Engenharia de Software Visibilidade Classe P blica todas as x outras classes t m Cliente CEN c digoDoCliente Protegida vis vel gsitua o Atributos dentro da mesma classe e limiteDeCr dito subclasses obterLimiteDeCr dito Privada vis vel bloquearCliente M todos dentro da mesma classe jc
76. gistrado no contrato recebe um n mero de manuten o gerado pelo sistema amp o sistema registra as cotas de pagamento do contrato com base nas informa es fomecidas pelo vendedor referentes a quantidade de cotas dafa base de pag gamento e pesquisando o valor de manuten o de cada tipo de equipamento o sistema registra as cotas de pagamento do contrato Curso alternativo Passo 2 Caso o cliente desejado n o esteja cadastrado 1 1 0 sistema gera um aviso de ciente n o cadastrado 2 ESTENDER Cadastrar Cilente 3 retornar ao passo 3 e A terceira parte o desenho do diagrama ap s a identifica o e a descri o dos casos de uso o desenho do diagrama fica f cil Exemplo ep alente PX amp i pi chamada cguacendee Cienie wendedor o Reglsirar coniraza C D alocar t cnico cadastrar ipo equip cadaslrar t cnico Gerar chamadas pendentes 0 o jo o ln pnm Supersisor Fechar chamada e ui cadastrar problema cadastrar solu o Observa es sobre desenvolvimento de casos de Uso e Evitar na descri o o caso de uso sem fim aquele que est sempre retornando a algum passo loop e Procurar sempre iniciar um caso de uso com uma a o do Ator Prof Walteno Martins Parreira Jr P gina 58 Engenharia de Software e Procurar organizar os casos de uso de modo que seja melhor aproveitado o polimorfismo na hora da implementa o agrupando os a n vel macro ou seja os casos de uso que
77. hecimento 5 97e caracterizam os principais aspectos envolvidos em wtegra o um projeto e no seu gerenciamento e Integra o o e Escopo amp 2 T e Tempo I e e Custos e Qualidade e Recursos humanos Escopo e Comunica es e Riscos e Aquisi es Escopo Tempo Custos e Qualidade s o os principais determinantes para o objetivo de um projeto entregar um resultado de acordo com o escopo no prazo e no custo definidos com qualidade adequada em outras palavras o que quando quanto e como Recursos Humanos e Aquisi es s o os insumos para produzir o trabalho do projeto Comunica es e Riscos devem ser continuamente abordados para manter as expectativas e as incertezas sob controle assim como o projeto no rumo certo E Integra o abrange a orquestra o de todos estes aspectos Prof Walteno Martins Parreira Jr P gina 36 Engenharia de Software Um projeto consiste nisso pessoas e m quinas que utilizam tempo materiais e dinheiro realizando trabalho coordenado para atingir determinado objetivo 4 6 2 Processos do gerenciamento de projetos A aplica o dos conhecimentos requer a ado o eficaz de processos apropriados Cada rea de conhecimento abrange diversos processos no gerenciamento de projetos Um processo um conjunto de a es e atividades interrelacionadas que s o executadas para alcan ar um objetivo Cada processo caracterizado por suas entradas as ferramentas e as t cn
78. iados durante a an lise dos requisitos a Ajuda o analista a entender a informa o fun o e o comportamento b Torna se ponto principal para revis o c Torna se base para o projeto a qual pode ser mapeada para um contexto de implementa o 3 5 3 Particionamento Muitas vezes os problemas a serem resolvidos s o excessivamente complexos apresentando grande dificuldade para a sua compreens o e consequente resolu o como um todo Para dominar de forma completa os problemas em an lise um princ pio fundamental a decomposi o do problema em parte menores denominado de particionamento Prof Walteno Martins Parreira Jr P gina 26 Engenharia de Software A partir do particionamento do problema e da an lise de cada parte o entendimento fica facilitado E poss vel estabelecer as interfaces de cada parte do problema de modo que a fun o global do software seja realizada O procedimento b sico de particionamento o estabelecimento de uma estrutura hierarquizada de representa o da fun o ou da informa o dividindo em parti es o elemento superior podendo esta divis o ser efetuada segundo uma abordagem vertical deslocando se verticalmente na hierarquia ou horizontal 3 6 Especifica o O modo de especifica o reflete na qualidade da solu o Ela representa o que deve ser implementado Princ pios da especifica o 1 a separa o entre funcionalidade e implementa o 2 utiliza
79. icas que podem ser aplicadas e as sa das resultantes Os cinco grupos de processos de gerenciamento de projetos s o e Inicia o e Planejamento e Execu o e Monitoramento e Controle e Encerramento 82007 M rcio F xila Baseada 2m figura do PlviBok Al m de conceituar os aspectos fundamentais do gerenciamento de projetos de forma a promover um vocabul rio comum dentro dessa profiss o o Guia PMBOK documenta define e descreve processos de gerenciamento de projetos e os apresenta didaticamente organizados em um cap tulo por rea de conhecimento Em cada processo s o abordadas suas entradas e sa das suas caracter sticas bem como os artefatos t cnicas e ferramentas envolvidas O diagrama com fluxo proposto por Mauro Sotille relaciona de forma gr fica e sint tica todos os 42 processos de gerenciamento de um projeto descritos no PMBOK 4 Edi o indicando tamb m os cinco grupos em que os processos se distribuem e as respectivas reas de conhecimento associadas a cada um dos processos Prof Walteno Martins Parreira Jr P gina 37 YL INd seiduo vp eod op sojaloig op ojueurerouar1er o1qos soSniry op ov5os eu oAjuodsip e iog ome iod ojsodoud oxnjp woo eureiseia SER DEMO LIDE T E OS LAO pio SE MO EGO T oyeload op DEN aaa E Jejouedaf d eS HERO HO IL AUAM RIT TES TR TR ES T8 o mea A ONU EIE S FO DI IT TETETE TED akud op oujeqen o Joao 8 EPOP I
80. ir que o analista e o usu rio examinem alternativas e modifica es com rapidez e facilidade elas podem ajudar a registrar o conhecimento de um requisito do usu rio e corrigir imediatamente quaisquer erros que tenha sido cometido Se a tecnologia introduzir se no assunto deve se deixar fora da entrevista Se o usu rio tiver de aventurar se al m de seu ambiente normal de atividade para outro pr dio na sala do computador poder encarar a ferramenta como um aborrecimento Se o usu rio n o estiver familiarizado com a tecnologia de computadores e for solicitado a utilizar a ferramenta poder rejeit la E se o analista n o estiver familiarizado com a ferramenta ou se a ferramenta for lenta apresentar erros ou de emprego limitado isso interferir sensivelmente na entrevista Em qualquer desses casos talvez seja prefer vel usar a ferramenta off line depois da entrevista ent o poder mostrar ao usu rio a sa da da ferramenta sem causar quaisquer problemas desnecess rios 2 4 5 Tente Descobrir quais Informa es o Usu rio tem mais Interesse Se o analista tiver de desenvolver um modelo completo de sistema para alguma parte de um sistema possivelmente necessitar determinar entradas sa das fun es caracter sticas tempo dependentes e a mem ria armazenada do sistema Por m a ordem em que se obt m essas informa es costuma n o ter muita import ncia Mas pode significar muito para o usu rio e deve deix lo come ar a
81. is com pessoal e o software deve emitir relat rios de compras a cada quinze dias e os usu rios devem poder obter o n mero de aprova es reprova es e trancamentos em todas as disciplinas por um determinado per odo de tempo A especificac o de um requisito funcional deve determinar o que se espera que o software fa a sem a preocupa o de como ele faz E importante diferenciar a atividade de especificar requisitos da atividade de especificac o que ocorre durante o design do software No design do software deve se tomar a decis o de quais a fun es o sistema efetivamente ter para satisfazer quilo que os usu rios querem Requisitos n o funcionais s o as qualidades globais de um software como manutenibilidade usabilidade desempenho custos e v rias outras Normalmente estes requisitos s o descritos de maneira informal de maneira controversa por exemplo o gerente quer seguran a mas os usu rios querem facilidade de uso e s o dif ceis de validar S o exemplos de requisitos n o funcionais a base de dados deve ser protegida para acesso apenas de usu rios autorizados o tempo de resposta do sistema n o deve ultrapassar 30 segundo o software deve ser operacionalizado no sistema Linux o tempo de desenvolvimento n o deve ultrapassar seis meses Requisitos nao funcionais Prof Walteno Martins Parreira Jr P gina 22 Engenharia de Software A necessidade de se estabelecer os requi
82. isor informa possivel Cadasta prctiemas Supervisor ProDer acadsstsco prebiems Prof Walteno Martins Parreira Jr P gina 57 Engenharia de Software e A segunda tarefa a descri o dos casos de uso neste momento pode se identificar os verdadeiros casos de uso do sistema casos de uso com um dois ou tr s passos podem sair do modelo e seus passos podem ser identificados como sendo de outro caso de uso Pode ser identificada tamb m a necessidade de criar um caso de uso novo quando identificado um conjunto de passos iguais em mais de um caso de uso Exemplo Nome Regictrar contrato Atcr Vendedor descri o Este use case respons vel pelo cadastramento de novos contratos no sistema Curso Normal 1 0 sistema apresenta os cientes cadastrados S o listados 05 nomes e o CGC dos cientes O vendedor seleciona um cilente 3 vendedor Informa dados basicos do contrato O vendedor deve informar a dafa de In cio data de t rmino e a quantidade de cotas de pagamento 4 o sistema apresenta os tipos de equipamentos cadastrados 5 o vendedor Informa os equipamentos que far o parte do contrato Para cada equipamento deve se selecionar um tipo de equipamento e Informar seu n mero de s rie e data de fabrica o amp o sistema registra o contrato O sistema registra dafa de In cio e data de t rmino e gera um n mero sequencial nico Independente do ciente 7 0 sistema registra os equipamentos do contrato cada equipamento re
83. jeto e da aplica o os m todos e as ferramentas a serem usados os controles e os produtos que precisam ser entregues 1 8 O que engenharia de Software um conjunto integrado de m todos e ferramentas utilizadas para especificar projetar implementar e manter um sistema Segundo Ariadne Carvalho amp Thelma Chiossi no livro Introdu o Computa o a Engenharia de Software Uma disciplina que re ne metodologias m todos e ferramentas a Prof Walteno Martins Parreira Jr P gina 8 Engenharia de Software ser utilizados desde a percep o do problema at o momento em que o sistema desenvolvido deixa de ser operacional visando resolve problemas inerentes ao processo de desenvolvimento e ao produto de software Pode se definir como e Um m todo uma prescri o expl cita de como chegar a uma atividade requerida por um modelo de ciclo de vida visando otimizar a execu o das atividades que foram especificadas e As ferramentas proporcionam apoio automatizado ou semi automatizado aos m todos Os M todos de Desenvolvimento de Sistema se diferenciam pela maneira como o problema deve ser visualizado e como a solu o do problema deve ser modelada S o eles 1 8 1 M todo baseado na Decomposi o de Fun es Abordagem estruturada caracterizada pela decomposi o das fun es Os tipos de modelos que representam as fun es s o e DFD Diagrama de Fluxo de Dados se caracteriza pela decomposi
84. mento Os objetos se F N aprovar Horas laprovada NI movem atrav s de diferentes N estados por serem influenciados por Aprovar Horas laprovafa 8 est mulos externos O Diagrama de Estado mapeia estes diferentes estados em que se encontram os objetos e desencadeia eventos que levam os objetos a se encontrarem em determinado estado em um dado momento Ermiar Horas Diagrama de Atividade Descreve a sequ ncia de atividades com suporte para comportamento condicional e paralelo Componentes e Atividade ou estado de atividade o estado de estar executando algo e Comportamento condicional a decis o branches uma transi o de entrada nica com v rias sa das na execu o s pode ter um fluxo de sa da ou seja as sa das s o mutuamente exclusivas b intercala es merges m ltiplas transi es de entrada Prof Walteno Martins Parreira Jr P gina 50 Engenharia de Software convergindo para uma de sa da marca o final de um comportamento condicional e Comportamento paralelo a Jun o joins converge duas ou mais transa es em uma mas esta s ocorre se as iniciais tiverem sido terminadas b Separa o forks tem uma transi o de entrada e v rias transi es em paralelo de sa da Diagrama de Atividade Cadastrar Aloca o O Diagrama de Atividade uma ferramenta til para desenhar a solu o de implementa o e pode estar baseada em um caso de uso ou pode definir um
85. mostrar ao usu rio que embora possa estar propondo algumas radicais mudan as na implementa o do sistema atual n o pensamento modificar as caracter sticas essenciais desse sistema exceto nas reas onde eles mesmos tenham solicitado uma altera o Devemos lembrar que algumas das caracter sticas da implementa o do sistema atual podem ser preservadas por causa das interfaces do sistema atual com outros sistemas externos que exijam que as entradas ou sa das apresentem formatos prescritos N o queremos esse sistema Esta uma varia o da queixa voc est querendo tirar meu emprego A verdadeira resposta que o analista est ali conduzindo a entrevista porque a dire o quer o novo sistema N o da sua compet ncia convencer os usu rios operativos que eles devem querer o novo sistema fazer isso colocar o peso da responsabilidade sobre seus ombros onde ela n o deve ficar Por que voc est desperdi ando nosso tempo com esta entrevista Sabemos o que queremos e se voc fosse competente voc saberia imediatamente o que queremos Por que voc n o vai em frente e constr i o sistema Esta uma reclama o dif cil de se lidar porque relaciona se com o fato fundamental de que os usu rios e os analistas de sistemas est o falando l nguas diferentes e estranhas Lembre se que com a disponibilidade das linguagens de quarta gera o e dos computadores pessoais o usu rio pode achar que pode construir ele pr
86. nativos e Inclus o a utiliza o de um caso de uso por outros casos de uso que possuem este comportamento em comum E um estere tipo de depend ncia Exemplo Num caixa autom tico tanto o caso de uso Retirar Dinheiro quanto Fazer Transfer ncia usam Validar Cliente obrigat rio x caneluis gt e Generaliza o indica que um caso de uso uma varia o de outro por exemplo no caso de pagamento de contas poder amos ter uma variac o de pagamento em dinheiro e outra variac o pagamento em cart o Ds Relacionamentos Os diagramas de casos de uso podem ser simplificados por meio da heran a entre atores Os diagramas de casos de uso podem ser simplificados por meio da heran a entre atores Neste caso mostra se um caso de uso comum aos atores espec ficos que se comunicam pe apenas com o ator gen rico A figura mostra as especializa es de Gerente em PMA rut gt Gerente de Compras e Gerente de Vendas Trata se I de uma rela o de heran a entre os atores ou seja todas as caracter sticas e fun es de Gerente ser o herdadas pelos atores que est o abaixo dele Tanto o Gerente de Compras quando o Gerente de m Vendas podem executar o caso de uso Emiss o de Gerente vereris relat rios porque eles s o herdeiros especializa es de Gerente Lembre se que a seta aponta para o que est sendo especializado Note que a ponta da
87. nham de fato sido utilizadas elas s o relativamente raras e n o ser o discutidas em maiores detalhes neste texto A entrevista mais utilizada ainda a reuni o pessoal entre um analista de sistemas e um usu rio final 2 3 Problemas Fundamentais Inicialmente pode parecer que o processo de entrevistar um usu rio seja uma quest o simples e direta Afinal o analista e o usu rio s o pessoas inteligentes e capazes de expressarem Os dois s o pessoas racionais e ambos t m o mesmo objetivo passar informa es relativas a um novo sistema proposto da mente do usu rio para a do analista Qual o problema Na realidade existem muitos problemas que podem ocorrer Em muitos projetos de alta tecnologia tem se observado que a maioria dos problemas dif ceis n o envolvem hardware nem software mas sim o pleopleware Os problemas de peopleware na an lise de sistemas s o muitas vezes encontrados nas entrevistas Os problemas mais comuns a que voc deve estar atento s o e Entrevistar a pessoa errada no momento errado muito f cil por causa dos problemas e interesses organizacionais falar com a pessoa que o perito oficial na orienta o do usu rio que demonstra nada saber a respeito dos verdadeiros requisitos do sistema tamb m poss vel perder a oportunidade de falar com o usu rio desconhecido que realmente sabe quais s o os requisitos Mesmo que encontre a pessoa certa talvez o analista tente entrevist la durante um per
88. no Martins Parreira Jr P gina 49 Engenharia de Software Diagrama de Colabora o Mostra como um grupo de objetos num caso de uso interage com os demais Cada mensagem numerada para documentar a ordem na qual ela ocorre O diagrama de colabora o tamb m um diagrama de intera o Um Diagrama de Colabora o outro tipo de diagrama de intera o Assim como no Diagrama de Sequ ncia o Diagrama de Colabora o mostra como um grupo de objetos num caso de uso interage com os demais Cada mensagem numerada para documentar a ordem na qual ela ocorre Os diagramas de colabora o e de sequ ncia s o equivalentes a diferen a que o diagrama de sequ ncia tem o tempo como participante fundamental a wa Pini Funcion rio Em O diagrama da figura equivalente ao diagrama de sequ ncia anterior Podemos dizer que o diagrama de colabora o e o diagrama de sequ ncia s o isom rficos ou seja podemos obter uma vis o a partir da outra Enquanto o diagrama de sequ ncia tem uma vis o temporal o diagrama de colabora o apresenta uma vis o espacial dos objetos Diagrama de Estado Mapeia diferentes estados em que se encontram os objetos e desencadeia eventos que levam os objetos a se Diagrama de Estado Classe Aprova o encontrarem em determinado estado d em um dado momento J7 Enviar Horas O estado de um objeto definido Aguardando pelos seus atributos em um determinado mo
89. nte ser objetivo e n o comentar as formas de trabalho de maneira n o construtiva Observar tamb m as exce es Terminando as observa es agrade a s pessoas o apoio e a colabora o dispensada ao seu trabalho Documente as descobertas resultantes das observa es Consolide os resultados Reveja os resultados consolidados com as pessoas observadas e ou com seus superiores Prof Walteno Martins Parreira Jr P gina 20 Engenharia de Software 3 ANALISE DE REQUISITOS 3 1 Introdu o A compreens o dos requisitos de software um ponto fundamental para o sucesso de um projeto de software Independentemente da qualidade com que o software venha a ser projetado e implementado ele certamente trar problemas para o cliente usu rio se a sua an lise de requisitos foi mal realizada A an lise de requisitos uma tarefa que envolve antes de tudo um trabalho de entendimento refinamento modelagem e especifica o das necessidades e desejos relativos ao software que dever ser desenvolvido Nesta tarefa tanto o cliente quanto o desenvolvedor v o desempenhar um papel de grande import ncia uma vez que caber ao primeiro a formula o de modo concreto das necessidades em termos de fun es e desempenho enquanto o segundo atua como indagador consultor e solucionador de problemas Logo a engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles v o trabalhar para resolver
90. ntrevistados respondam por escrito a um question rio formal ou solicitando que descrevam por escrito os requisitos do novo sistema Tamb m podemos aumentar as entrevistas pela presen a de v rios especialistas que podem at conduzir a entrevista enquanto o analista de sistemas participa como assistente como peritos em ind stria comercio psic logos comportamentais e negociadores E finalizando deve se lembrar que outros meios de obten o de dados ex videocassete gravadores etc podem ser utilizados para registrar uma entrevista Durante a d cada de 80 uma forma especializada de entrevista tornou se popular em algumas empresas conhecida como JAD Joint Application Development ou projeto acelerado ou an lise em equipe e por v rios outros nomes Ela consiste em uma r pida entrevista e um processo acelerado de coleta de dados em que todos os principais usu rios e o pessoal da an lise de sistemas agrupam se em uma nica e intensiva reuni o que pode prolongar se de um dia a uma semana para documentar os requisitos do usu rio A reuni o costuma ser supervisionada por um profissional experiente e bem treinado que atua como mediador para encorajar melhores comunica es entre os analistas de sistemas e os usu rios Frequentemente este supervisor apoiado por algumas pessoas que se dedicam integralmente ao processo Prof Walteno Martins Parreira Jr P gina 11 Engenharia de Software Embora todas essas varia es te
91. o todo parte Da mesma forma um projeto pode trabalhar com classes e funcion rios que poder o ser utilizados por outro projeto significa que ao chegar ao fim de um projeto as classes e os funcion rios podem ser reaproveitados Documento Projeto Q a G ro N Y N 5 3 4 Composi o uma varia o da agrega o mas sendo que o objeto parte s pertence a um todo e s o extremamente dependentes do todo podemos considerar c rculo que qualquer dele o do O ponto todo gera um efeito cascata nas partes Composi o Um tipo Au mais forte de relacionamento todo parte o relacionamento de ponto composi o c rculo Prof Walteno Martins Parreira Jr P gina 61 Engenharia de Software composi o Nesse caso os objetos da classe parte n o t m exist ncia independente da classe todo E uma especializa o da Agrega o A composi o imp e a cardinalidade de no m nimo 1 Os exemplos sugerem que as p ginas e a capa do livro comp em um livro e n o podem compor outro livro Assim como os quartos do hotel somente pertencer o a ele n o faz sentido retirar o quarto do cadastro e aproveitar para outro hotel a parte n o existe sem o todo Exemplos Livro N Pedido 1 Pedido item quantidade incluirPedido eT ETT atenderPedido dra Todo Parte 5 3 5 Associa es Existem quatro tipos principais de associa es a Generaliza o Especializa o
92. o Diagrama de Sequ ncia sssssssssssseeeeeeeeeen ener 66 5 5 Diagramia de Estado erected d eee aaa a aia iaaa 69 2 5 1 M quima de Estados eH toas rete eqs ie ig t deed id 70 5 3 2 P ra terminat dr or Re d e t UE Ae E zr eco 72 6 PROJETO DE SISTEMAS erc rette ab besote se raro toe MEO EP ERES 73 6 1 Aspectos Fundamentais do Projeto de Sistemas eeeeeene 73 6 2 Projeto Orientado a Objetos a aiia aa aara rea iia 73 T FERRAMENTAS CASE sas ade ate Poma ep eie e oe A 74 BIBLIOGRAFIA ose e atit tedesca t O tasa UR 75 Prof Walteno Martins Parreira Jr P gina 2 Engenharia de Software 1 SOFTWARE E ENGENHARIA DE SOFTWARE 1 1 Introduc o No inicio da d cada de 1980 uma reportagem de primeira pagina da revista Business Week apregoava a seguinte manchete Software A Nova For a Propulsora O software amadurecera tornara se um tema de preocupa o administrativa Em meados da d cada de 1980 uma reportagem de capa da Fortune lamentava Uma Crescente Defasagem de Software e ao final da d cada a Business Week avisava os gerentes sobre a Armadilha do Software Automatizar ou N o No come o da d cada de 1990 uma reportagem especial da Newsweek perguntava Podemos Confiar em Nosso Software enquanto o Wall Street Journal relacionava as dores de parto de uma grande empresa de software com um artigo de primeira p gina intitulado Criar Software Novo E
93. o Martins Parreira Jr P gina 33 Engenharia de Software A Rede de Atividades desenvolvida a partir do Quadro de atividades observando os Marcos e o Caminho Principal caminho em negrito 14 7 99 15days 19 9 99 O Diagrama de Barra de atividades considerando as datas iniciais de cada atividade os Marcos definidos e a Margem de atraso para cada atividade quando isto poss vel em fun o das depend ncias das atividades anteriores E TER Prof Walteno Martins Parreira Jr P gina 34 Engenharia de Software O Diagrama de aloca o de pessoas no projeto si 1 7 187 25 15 8 228 29 8 5 9 12 9 io HL fe IRI Os principais riscos de projeto devem ser identificados avaliados e monitorados de forma a elaborar planos preventivos gerenciamento de riscos ou planos para administrar os riscos 4 6 PMBOK Project Management Body of Knowledge Um dos principais difusores do gerenciamento de projetos e da profissionaliza o do gerente de projetos o Instituto de Gerenciamento de Projetos PMI Project Management Institute Fundado nos Estados Unidos em 1969 o PMI uma associa o profissional mundialmente difundida atualmente com meio milh o de membros em mais de 180 pa ses O PMI distribu do geograficamente pelo mundo em Cap tulos O PMI Project Management Institute identifica 9 nove reas de conhecimento em gerenciamento de projetos Apesar desta abordagem de apresent las de forma
94. o de uso Objetivo dos casos de uso a Descrever os requisitos funcionais do sistema de maneira consensual entre usu rios e desenvolvedores de sistemas b Fornecer uma descri o consistente e clara sobre as responsabilidades que devem ser cumpridas pelo sistema al m de formar a base para a fase de desenho c Oferecer as poss veis situa es do mundo real para o teste do sistema Requisito uma caracter stica do sistema ou a descri o de algo que o sistema capaz de realizar para atingir seus objetivos O requisito pode ser de dois tipos e Funcional quando descreve uma intera o entre o sistema e seu ambiente Exemplo Cadastro do Cliente Consulta pedidos etc ou e N o Funcional tamb m chamado de requisito de qualidade quando descreve uma restri o do sistema Exemplo amig vel tempo de resposta de 3 segundos etc Cen rio descreve a intera o entre o ator e o sistema Um caso de uso pode ter v rias termina es sucessos e insucessos cada enredo cada inst ncia chamada de cen rio Iterar Tornar a dizer repetir Intera o A o rec proca de dois ou mais corpos uns nos outros A intera o ou comunica o o relacionamento entre o ator e o sistema Pode existir relacionamento entre casos de uso extens o inclus o e generaliza o sistema mm ED Os atores pessoas outros sistemas perif ricos interagem com o sistema atrav s de uma fronteira No diagrama de caso de
95. o projeto al m do prazo e custos tais como o escopo do projeto o que deveria ser feito foram identificados como importante para a gest o de um projeto tratar a quest o de qualidade ou seja atender ao especificado e tratado entre as partes Outros aspectos foram sendo agregando ao gerenciamento de projeto tais como risco e comunica o Todo projeto tem risco e o planejamento e tratamento desses riscos faz parte das atividades de gerenciamento do projeto Comunica o tamb m fator fundamental em um projeto Sem a devida comunica o entre os envolvidos um projeto pode estar fadado ao Prof Walteno Martins Parreira Jr P gina 29 Engenharia de Software insucesso As informa es devem fluir no tempo na profundidade e no conte do desejado por cada envolvido de acordo com a sua necessidade ou grau de envolvimento N o deve se esquecer que os projetos s o executados por pessoas Ent o o cuidado com o ser humano tais como a motiva o da equipe o recrutamento de pessoas especializadas para cada tipo de tarefa o treinamento a forma o de time e outros aspectos s o tamb m fundamentais ao sucesso do projeto Em alguns projetos t m que adquirir bens ou produtos e o gerenciamento dessas aquisi es tamb m s o importantes para a condu o de um projeto Existe uma tend ncia das empresas em administrar as opera es com a abordagem de projeto Essa abordagem de forma simplificada prev a aplica o das t cnicas
96. o que pode ser bastante interessante principalmente em sistemas interativos Ent o a etapa de especificar os requisitos consolida fun es interfaces desempenho o contexto e as restri es do sistema 3 3 5 Revis o De posse de um Manual do Usu rio mesmo em est gio preliminar vai permite ao cliente uma revis o dos requisitos de interface pelo menos ainda num est gio bastante prematuro do desenvolvimento de software Desta forma algumas indaga es resultantes de uma m defini o de alguns aspectos do software podem ser evitadas Prof Walteno Martins Parreira Jr P gina 24 Engenharia de Software Portanto juntos cliente e analista avaliar o o objetivo do projeto com o intuito de eliminar poss veis redund ncias inconsist ncias e omiss es do sistema obtendo uma mesma vis o Ent o a revis o observada primeiramente em n vel macrosc pico Neste n vel os revisores tentam garantir que a especifica o seja completa consistente e precisa As seguintes quest es s o consideradas e As metas e os objetivos do software permanecem consistentes com as metas e os objetivos do sistema e Interfaces importantes para todos os elementos do sistema foram descritas e O fluxo e a estrutura de informa o s o adequadamente definidos para o dom nio da informa o Etc Para desenvolver respostas a muitas das quest es apresentadas a revis o pode focalizar um n vel detalhado Diretrizes para uma revis
97. or de Apica o Fagna ASP L 4 L I I L i Servidor ce Negro os zE SistemaiVEB OLL BancoGenerico DLL Servidor de Barco de Dados SQL Server A locadora tem a necessidade de processar seus dados num sistema cliente servidor com um banco de dados centralizado contendo todos os registros que os profissionais da empresa ter o que acessar Os representantes de loca o de ve culos precisam ter acesso imediato aos dados sobre a disponibilidade de ve culos Por outro lado os mec nicos precisam ter meios para destacar que determinado carro est passando por um processo de manuten o Exemplo de Diagrama de Implanta o ao Servidor Aplica o PENTIUM IV 2Ghz O diagrama de PENTIUM IV 2Ghz implanta o poder ser 2544 Lam 10 100 80 Gb usado para caracterizar o Onch i hardware e o software necess rio a ser instalado nos n s m quinas ou a perif ricos Inclusive o Lan 16 100 barramento de conex o a entre os n s Clente Configura o minima PENTIUM It IE 5 0 Prof Walteno Martins Parreira Jr ragina 22 Engenharia de Software 5 2 Casos de Uso Caso de Uso Um conjunto de sequ ncias de a es que um sistema desempenha para produzir um resultado observ vel de valor a um ator espec fico Deve ser usado quando se deseja visualizar o comportamento de v rios objetos dentro de um nico cas
98. os n s s o estados e cujos arcos direcionados s o transi es rotuladas com nomes de eventos Deve ser constru do um Diagrama de Estados para cada classe cujos objetos apresentem algum comportamento din mico significante Exemplo Item comercializ vel condi oDeInspec oAtual 1 Evento Estado Recebido a inspetorSelecionaltem Soblnspe o mix d i rog taltem registrarRejeicao Aprovado Rejeitado condi o 1 a o 1 evento 1 atributos Estado 1 Estado 2 Prof Walteno Martins Parreira Jr P gina 69 Engenharia de Software Conceitos usados na Transi o Evento a especifica o de uma ocorr ncia o que ir ocasionar a altera o do estado de um objeto A o atividade at mica que n o pode ser interrompida Condi o de Guarda Somente ir mudar para o estado se a condi o for verdadeira Aparece entre colchetes na transi o Na transi o a seta entre estados fica com o nome do evento ou o que foi respons vel na mudan a de estado do objeto Na altera o do estado de um objeto pode ser necess rio executar alguns m todos isso representado atrav s da a o que tamb m poder aparecer na transi o ou dentro do estado A condi o de guarda tamb m ser exibida na transi o Exemplos dos Componentes Estado Pronto em Manuten o Checando Finalizando Efetuando Transa o em Consulta em Interna o Evento Cadastrar Empregado
99. po o principal enfoque do gerenciamento de projetos era a ger ncia do tempo fazer com que as coisas acontecessem dentro do prazo esperado Em algumas empresas em especial no governo o enfoque de gerenciamento de projeto era mais or ament rio ou seja quando acabasse o dinheiro acabaria o projeto A engenharia de software distinta de outros tipos de engenharia tornando o gerenciamento de software dif cil As principais diferen as s o e O produto intang vel e N o h processo de software padr o e Grandes projetos de software s o frequentemente nicos 4 1 Oque Gerenciamento de Projetos Segundo Carneiro 2000 o Gerenciamento de projetos a aplica o de Conhecimento Habilidades Ferramentas e T cnicas nas atividades de projetos de forma a atender ou superar as expectativas dos stakeholders interessados atores participantes e que envolve o balanceamento de e Escopo tempo custo e qualidade e Necessidades requisitos definidos e expectativas subjetivos ou n o definidos e Diferentes expectativas e necessidades de todos aqueles que participam do projeto direta ou indiretamente Indica que para fazer o gerenciamento de projetos n o necess rio apenas a vontade ou a necessidade da realiza o dessa tarefa E preciso reconhecer que o gerente de projetos precisa de conhecimentos espec ficos da rea para melhor desempenhar as suas fun es Outros elementos foram se juntando ao gerenciamento d
100. preparado para a entrevista E se o usu rio n o tiver lido o material remetido sinal de que e est muito ocupado e est desinteressado e op e se a toda a id ia da entrevista ou e incapaz de entender as perguntas apresentadas Um aspecto relacionado coletar antes da entrevista tantos dados pertinentes quanto poss vel Se houver formul rios ou relat rios que sejam pertinentes discuss o geralmente poder obt los antecipadamente Se existirem outros documentos escritos do usu rio descrevendo o novo ou o antigo sistema consiga os e estude os antes da entrevista Se tiver preparado as perguntas antecipadamente o analista deve ser capaz de realizar a entrevista em uma hora ou menos Isso importante n o s o usu rio geralmente incapaz de reservar mais do que uma hora de cada vez mas tamb m as pessoas normalmente n o conseguem se concentrar intencionalmente principalmente se estiverem examinando diagramas um tanto estranhos por mais do que uma hora Isso naturalmente significa que deve se organizar a entrevista para abranger um escopo relativamente limitado focalizando normalmente uma parte do sistema Isso tamb m pode significar que tenha de marcar algumas entrevistas com o mesmo usu rio para abranger inteiramente a rea em que ele est envolvido Finalizando marcar uma reuni o subsequente para rever o material que foi coletado Normalmente ap s a entrevista o analista ir para sua mesa com todas
101. qu ncia de mensagens trocadas e Diagrama de Colabora o representa a troca de mensagens entre um conjunto de objetos 5 4 1 O Que o Diagrama de Sequ ncia Os diagramas de sequ ncia s o orientados para exprimir o desenrolar temporal de sequ ncias de a es dif cil representar l gicas de sele o e repeti o sem prejudicar a legibilidade do diagrama Os roteiros representam desdobramentos da l gica do caso de uso prefer vel usar diagramas separados para representar roteiros resultantes de diferentes caminhos l gicos Os diagramas de colabora o s o elaborados baseados na descri o de um fluxo do caso de uso juntamente com o diagrama de classes visto que os diagramas de intera o representam as mensagens entre os objetos que s o os passos levantados na descri o e os objetos s o as classes identificadas no diagrama de classes Componentes do Diagrama de Sequ ncia Objetos Mensagem retorno auto chamada condi o Linha de Vida Caixa de Ativa o Remo o I uet Tr S E Nini Frontera Umpedido Pedido E dido Unitenstem Item I I I Solicita pedido i l I onc eo nl Prepere I l l I I Hr Prepare temEstoqu I verificar l p liac Mensagem Condi o ter stogue precipio Caixa de retirar H predsaRepor Ativa o pu I I p t TET l x dot I I I ExcluPedido Umpedido Retorno I HN mamma c I li Linha de Vida Remo o Prof Wal
102. r usu rio um departamento ou divis o ou do representante da empresa que estar auxiliando o projeto de desenvolvimento do sistema Em qualquer caso os usu rios t m leg timas raz es em querer aprovar antecipadamente quem ser entrevistado e Eles podem saber que alguns usu rios n o ser o capazes de compreender ou exprimir bem os requisitos do sistema e Eles podem desconfiar de que alguns dos usu rios do n vel operativo sejam rebeldes que apresentar o requisitos falsos ou requisitos que a dire o n o aprova e Eles podem recear que as entrevistas interfiram com as atribui es normais de trabalho que os usu rios tenham de executar Por causa disso desejar o marcar as entrevistas para os momentos apropriados e Eles podem recear que as entrevistas sejam vistas como o in cio de um esfor o de substitui o dos usu rios humanos por um sistema computadorizado provocando demiss es e coisas desse g nero e Eles podem considerar que eles pr prios os diretores sabem mais a respeito dos requisitos do sistema do que qualquer outro e por isso n o desejam que voc entreviste qualquer usu rio de n vel operativo Prof Walteno Martins Parreira Jr P gina 13 Engenharia de Software e Pode estar havendo uma batalha pol tica em andamento em um n vel de chefia muito mais elevado entre o setor usu rio e a organiza o de desenvolvimento de sistemas Desse modo o gerente usu rio pode n o ter reais obje es a su
103. ra Uma Tarefa Agonizante Essas manchetes e muitas outras iguais a elas eram o anuncio de uma nova compreens o da import ncia do software de computador as oportunidades que ele oferece e os perigos que apresenta O software agora ultrapassou o hardware como a chave para o sucesso de muitos sistemas baseados em computador Seja o computador usado para dirigir um negocio controlar um produto ou capacitar um sistema o software um fator que diferencia A inteireza e a oportunidade das informa es oferecidas pelo software e bancos de dados relacionados diferenciam uma empresa de suas concorrentes O projeto e a capacidade de ser amig vel ao ser humano human friendly de um produto de software diferenciam no dos produtos concorrentes que tenham fun o id ntica em outros aspectos A intelig ncia e a fun o oferecidas pelo software muitas vezes diferenciam dois produtos de consumo ou industrias id nticas E o software que pode fazer a diferen a 1 2 Software H 20 anos menos de 1 do p blico poderia descrever de forma intelig vel o que significa software de computador Hoje a maioria dos profissionais bem como a maior parte do p blico acham que entendem o que software Ser que entendem Uma descri o de software num livro did tico poderia assumir a seguinte forma Software 1 instru es programas de computador que quando executadas produzem a fun o e o desempenho desejados 2 estruturas de d
104. ra a utiliza o do question rio de pesquisa s o a Prepara o do question rio e Identifique o tipo de informa o que deseja obter como problemas experimentados ou oportunidades a explorar e Definidos os requisitos escolha um formato apropriado para o question rio e Monte quest es de forma simples clara e concisa e Se incluir quest es abertas observar o espa o necess rio para a resposta e Agrupar as quest es por t picos ou reas afins e Se poss vel enviar junto com o question rio uma carta da dire o da empresa explicando os motivos e a import ncia da pesquisa para a organiza o b Identifica o dos respondentes e O question rio deve ser personalizado com o nome fun o e localiza o do respondente e Elaborar um controle de identifica o das pessoas que receber o os question rios Utilizar o controle para monitorar a situa o dos question rios c Distribui o do question rio e Distribua o question rio junto com as instru es de preenchimento e Indique claramente o prazo para a devolu o do question rio e a forma de devolu o d An lise das respostas e Consolide e an lise as informa es fornecidas pelos question rios devolvidos e Documente as principais descobertas e Envie uma c pia do relat rio com as principais descobertas para cada respondente como uma cortesia pelo tempo dedicado pesquisa 2 7 2 Observa es no ambiente A an lise de observa o
105. rojeto de desenvolvimento de um sistema Provavelmente entrevistar usu rios gerentes auditores programadores e auxiliares que utilizam sistemas j existentes informatizados ou manuais e tamb m v rias outras pessoas envolvidas Por que fazemos entrevistas durante a an lise de sistemas Porque e Precisamos coletar informa es sobre o comportamento de um sistema atual ou sobre os requisitos de um novo sistema de pessoas que t m essas informa es armazenadas em algum lugar em suas cabecas e Precisamos verificar nossa pr pria compreens o como analistas de sistemas do comportamento de um sistema atual ou dos requisitos de um novo sistema Essa compreens o deve ser adquirida atrav s de entrevistas em combina o com informa es coletadas de modo independente e Precisamos coletar informa es sobre o s sistema s atual is para a execu o do estudo de custo benef cio para o novo sistema 2 2 Tipos de Entrevistas A forma mais comum de entrevista uma reuni o pessoal e direta entre voc talvez acompanhado por at dois analistas auxiliares do projeto e um ou mais interlocutores entrevistados Normalmente s o efetuadas anota es por um dos entrevistadores menos costumeiramente a entrevista pode ser gravada ou um a secret rio a tomar notas durante a entrevista Pode se perceber que as informa es obtidas em uma entrevista tamb m podem ser obtidas por outros meios por exemplo solicitando se que os e
106. rtins Parreira Jr P gina 44 Engenharia de Software Sobrescrita M todos com a mesma Empregado assinatura em uma heran a A Assinatura a identidade do m todo nomeMetodo quantidade e tipos par metros CalcularSalarioMes salario real CalcularSalarioMes salario comissao real real CalcularSalarioMes dias inteiro Vendedor CalcularSalarioMes horas inteiro comiss o CalcularSalarioMes Empregado Oooo Nome Funcao Desenhar pi p2 p3 p4 Dt Admissao Desenhar alt larg Empregado nome Empregado nome funcao dt M todos na mesma classe com assinatura diferente Sobrecarga Mensagem a comunica o entre objetos A execu o de um m todo ativada atrav s do envio de uma mensagem Persist ncia O objeto pode sobreviver ap s a consecu o do sistema a exist ncia do objeto pode persistir ao tempo isto significa que o objeto deve ser armazenado de alguma forma Um objeto n o persistente tamb m chamado de transiente Estere tipo um mecanismo de extens o e estende a sem ntica de meta modelo Podem ser criados pelo usu rio atrav s de cones ou entre aspas lt lt gt gt Existem estere tipos pr definidos na UML ser visto adiante Encapsulamento o processo de impedir que os atributos de uma classe sejam lidos ou modificados por outras classes Ele garante a inviolabilidade dos dados aumentando a robustez do sistema Os atributo
107. s valores armazenados de um objeto devem ser consultados ou modificados atrav s dos m todos da classe do objeto O uso de m todos como interface deve garantir o reaproveitamento e atualiza o do objeto Um objeto externo tem acesso aos m todos p blicos e estes tem garantido o acesso a atributos definidos na classe Existem tamb m m todos privados acess veis somente por m todos do mesmo objeto Vamos ver visibilidade ao final do diagrama de classes Papel a face que a classe pr xima a uma das extremidades apresenta classe encontrada na outra extremidade da associa o A mesma classe pode executar pap is iguais ou diferentes em outras associa es Prof Walteno Martins Parreira Jr P gina 45 Engenharia de Software emprega Companhia 1 E OBS e Pode ter empregado cadastrado sem estar alocado a nenhuma cia e 0 e 1 1 1 b Os Diagramas Diagrama uma apresenta o gr fica de um conjunto de elementos uma proje o em um sistema A UML inclui nove diagramas Classes diagrama estrutural que mostra um conjunto de classes interfaces colabora es e seus relacionamentos Objetos diagrama estrutural que mostra um conjunto de objetos e seus relacionamentos Casos de Uso diagrama comportamental que mostra uma interac o dando nfase organiza o estrutural de objetos que enviam e recebem mensagens Intera o Sequ ncia e Colabora o descrevem o comportam
108. s comum nos Associa o Bin ria diagramas de classe Cliente 2 pedido b Associa o Un ria ou Autorelacionamento Ocorre quando h necessidade de relacionar dois objetos de uma mesma classe Estado nome Nu Habitantes 1 engloba nome Nu Habitantes 4 Engloba 1 Nu Hab tantes 0 c Associa o n ria Representa o relacionamento com mais de duas classes Prof Walteno Martins Parreira Jr Avalia o P gina 60 Funcion rio Engenharia de Software O exemplo acima est exibindo o relacionamento de avalia o de um funcion rio em um projeto e esta avalia o para um quesito Ent o por exemplo o funcion rio Jo o ser avaliado em pontualidade no projeto A e ter uma nota de avalia o quando ele for trabalhar no Projeto B ele poder ter outra nota de avalia o no mesmo quesito Os quesitos servem para pontuar os funcion rios e s o exemplos organiza o limpeza pontualidade etc 5 3 3 Agrega o Usada para denotar relacionamentos todo parte por exemplo um avi o tem cauda fuselagem e asas como partes Neste exemplo a cauda a fuselagem e as asas do avi o poder o ser utilizadas em outro avi o E se o planador for exclu do talvez as partes continuem existindo para um dia compor outro planador po asaDireita Fuselagem As figuras mostram dois exemplos de agrega o um documento pode ter figuras e par grafos Este ser o membros do document
109. s e novos n veis de sofistica o de software e hardware Sistemas de tempo real podiam coletar analisar e transformar dados de m ltiplas fontes dai controlando processos e produzindo sa da em milissegundos e n o em minutos Os avan os da armazenagem on line levaram primeira gera o de sistemas de gerenciamento de bancos de dados A segunda era tamb m foi caracterizada pelo uso do produto de software e pelo advento das software houses O software era desenvolvido para ampla distribui o num mercado interdisciplinar Programas para mainframes e minicomputadores eram distribu dos para centenas e s vezes milhares de usu rios Empres rios da industria governos e universidades puseram se desenvolver pacotes de software e a ganhar muito dinheiro A medida que o numero de sistemas baseados em computador crescia bibliotecas de software de computador come aram a se expandir Projetos de desenvolvimento internos nas empresas produziram dezenas de milhares de instru es de programa Os produtos de software comprados no exterior acrescentaram centenas de milhares de novas instru es Uma nuvem negra apareceu no horizonte Todos esses programas todas essas instru es tinham de ser corrigidos quando eram detectadas falhas alterados conforme as exig ncias do usu rio se modificavam ou adaptados a um novo hardware que fosse comprado Essas atividades foram chamadas coletivamente de manuten o de software O esfor o despendido
110. separada por raz es did ticas deve se estud las com a percep o de todas est o intimamente interligadas O gerenciamento de um projeto sem a aplica o do conhecimento de uma ou mais destas reas poder implicar em uma defici ncia do pr prio projeto que normalmente s constatada tardiamente Depois ter despendido muito esfor o custo e tempo para encontrar as raz es desta defici ncia Editado na forma de livro o Guia PMBOK est atualmente na quarta edi o de 2008 e traduzido oficialmente para diversos idiomas inclusive o portugu s do Brasil As edi es anteriores foram publicadas nos anos de 1996 2000 e 2004 O PMBOK formaliza diversos conceitos em gerenciamento de projetos como a pr pria defini o de projeto e do seu ciclo de vida Tamb m identifica na comunidade de gerenciamento de projetos um conjunto de conhecimentos amplamente reconhecido como boa pr tica aplic veis maioria dos projetos na maior parte do tempo Estes conhecimentos est o categorizados em nove reas e os processos relacionados s o organizados em cinco grupos ao longo do ciclo de vida do projeto Prof Walteno Martins Parreira Jr P gina 35 Engenharia de Software Todas estas disciplinas aliadas s t cnicas m todos e ferramentas de cada uma apoiam a condu o do projeto de forma a garantir qualidade atendimento aos prazos custos e requisitos desejados Cabe ao gerente de projetos integrar todas essas disciplinas cuidando
111. sitos de forma precisa cr tica na medida que o tamanho e a complexidade do software aumentam Os requisitos exercem influ ncia uns sobre os outros Por exemplo o requisito de que o software deve ter grande portabilidade por exemplo ser codificado em Java pode implicar em que o requisito desempenho n o seja satisfeito programas em Java s o em geral mais lentos Requisitos de dom nio s o os requisitos que se originam do dom nio da aplica o do sistema e que refletem caracter sticas desse dom nio Podem ser requisitos funcionais ou n o funcionais Eles podem ser novos requisitos funcionais podem tamb m restringir requisitos funcionais existentes ou estabelecer como devem ser executados determinados c lculos espec ficos S o exemplos de requisitos de dom nio e deve haver uma interface padr o com o usu rio para todos os bancos de dados com base no padr o Z39 50 e em raz o das restri es de direitos autorais alguns documentos devem ser exclu dos imediatamente ap s serem fornecidos Um exemplo de documenta o para um requisito funcional e que contempla tr s requisitos n o funcionais Nome RF4 Manter funcion rio Oculto Evidente x Descri o O sistema permite a consulta altera o e exclus o do funcion rio Requisitos Dominio Nome Restri o Categoria Obrigatoriedade Perman ncia O sistema dever permitir a altera o dos campos do funcion rio que j est RDA
112. steja correto e atualizado as empresas muitas vezes modificam se com muito mais frequ ncia do que o ciclo editorial anual em que os diagramas s o produzidos O fato de conhecer o esquema organizacional n o diz necessariamente com quem o analista deve entender se s vezes a pessoa que mais sabe a respeito de algum aspecto de um sistema um funcion rio administrativo ou burocrata que sequer aparece no organograma Muitas vezes existem tr s n veis de usu rios em uma organiza o grande e complexa o usu rio verdadeiro o usu rio supervisor operativo e o usu rio supervisor executivo e muitas vezes de grande import ncia falar com todos os tr s n veis Em muitos casos tamb m importante conversar com os usu rios na sequ ncia adequada e na combina o certa Por vezes o analista poder saber em que sequ ncia os usu rios dever o ser entrevistados face a seu conhecimento geral da organiza o e por vezes os pr prios usu rios lhe dir o uma vez que saibam que ser o entrevistados 2 4 2 Certifique se de que tem Autoriza o para Falar com os Usu rios Em algumas organiza es informais n o haver restri es na escolha dos usu rios com quem falar ou sobre como as entrevistas ser o marcadas Por m isso n o comum em empresas grandes politicamente perigoso vagar pela organiza o usu ria realizando entrevistas sem pr via autoriza o Na maioria dos casos a autoriza o vir ou do encarregado de um seto
113. tabilidade por exemplo ser implementado em Java pode implicar em que o requisito desempenho n o seja satisfeito programas em Java s o em geral mais lentos Os requisitos podem ser classificados tamb m pelo seu tipo e Requisitos operacionais e Requisitos de seguran a e Requisitos de desempenho e Especifica es de Hardware e software e Entre outros 4 5 Organiza o de atividades As atividades em um projeto devem ser organizadas de modo a produzir sa das tang veis para os gerentes julgar o progresso 4 5 1 Marco de Projeto Marco de projeto a conclus o de uma etapa do projeto o ponto final de uma atividade de processo de software O processo com prototipa o por exemplo permite uma defini o direta de marcos de progresso Atividades Estudo de projeto Especifica o de requisitos Desenvolvimento de prot tipo An lise de requisitos Estudo de viabilidade Marcos Um marco de projeto o resultado previsto de uma atividade em que algum relat rio formal de progresso deve ser apresentado ger ncia 4 5 2 Programa o de projeto Envolve a divis o do trabalho total de um projeto em atividades distintas e avalia o do tempo necess rio para completar cada uma destas atividades Coordenar as atividades paralelas de modo que a for a de trabalho seja otimizada Minimizar depend ncias entre tarefas para evitar atrasos causados por uma tarefa ter qu
114. tada O produto software isto e programas desenvolvidos para serem vendidos a um ou mais clientes estava em sua inf ncia A maior parte do software era desenvolvida e em ultima analise usada pela pr pria pessoa ou organiza o Voc escrevia o colocava o em funcionamento e se ele falhasse era voc quem o consertava Uma vez que a rotatividade de empregos era baixa os gerentes podiam dormir trang ilos com a certeza de que voc estaria l se defeitos fossem encontrados Por causa desse ambiente de software personalizado o projeto era um processo impl cito realizado no c rebro de algu m e a documenta o muitas vezes n o existia Durante os primeiros anos aprendemos muito sobre a implementa o de sistemas baseados em computador mas relativamente pouco sobre engenharia de sistemas de computador Por justi a entretanto devemos reconhecer os muito surpreendentes sistemas baseados em computador desenvolvidos durante essa poca Alguns deles permanecem em uso ate hoje e constituem feitos que s o um marco de refer ncia e que continuam a justificar a admira o Prof Walteno Martins Parreira Jr P gina 5 Engenharia de Software A segunda era da evolu o dos sistemas computadorizados estendeu se de meados da d cada de 1960 at o final da d cada de 1970 A multiprograma o e os sistemas multiusu rios introduziram novos conceitos de intera o homem m quina As t cnicas interativas abriram um novo mundo de aplica e
115. teno Martins Parreira Jr P gina 66 Engenharia de Software e Mensagem pode ser um evento ou qualquer outra informa o necess ria mas sempre com expectativa de a o a ser executada Pode incluir par metros contendo algum dado adicional e a resposta do objeto destinat rio depende do m todo associado mensagem Pode ser tamb m etiquetada com uma express o booleana veja exemplo e Linha de vida do objeto representa a exist ncia do objeto e Auto chamada ou auto delega o quando uma opera o chama a si pr pria e Caixa de ativa o o tempo em que o objeto fica ativo em mem ria Restri o a restri o utilizada sempre quando n o poss vel demonstrar algum requisito no desenho do diagrama Podemos utilizar no Diagrama de Sequ ncia a restri o para indicar uma restri o de tempo de retorno de uma resposta o que bastante v lido para um sistema de tempo real Sistemas de Tempo Real s o caracterizados por terem que atender n o apenas a correta execu o l gica das tarefas como tamb m a limites de tempo de execu o Para que uma tarefa em tempo real seja considerada bem sucedida ela deve ser conclu da com sucesso e dentro de um tempo pr determinado como representar este requisito na UML Atrav s do Diagrama de Sequ ncia colocando restri es de tempo nas execu o das atividades Cria o e exclus o de Objetos e Cria o e exclus o de objetos tamb m s o representados
116. tifica o das informa es que ser o necess rias ao sistema e a sele o da melhor solu o poss vel dentro das solu es propostas 3 3 3 Modelagem A partir da tarefa de avalia o e s ntese o analista pode estabelecer um modelo do sistema o qual permitir uma melhor compreens o dos fluxos de informa o e de controle assim como dos aspectos funcionais e de comportamento Este modelo ainda distante de um projeto detalhado servir de refer ncia s atividades de projeto assim como para a cria o da especifica o de requisitos Em muitas situa es como forma de refor ar o conhecimento sobre a viabilidade do software a ser desenvolvido pode ser necess rio o desenvolvimento de um prot tipo de software como alternativa ou como trabalho paralelo an lise de requisitos Logo modelar um recurso usado para o suporte da s ntese da solu o o modelo vai apresentar ferramentas que facilitar o o entendimento do sistema como as funcionalidades informa es e comportamento do sistema 3 3 4 Especifica o dos Requisitos A etapa de An lise de requisitos culmina com a produ o de um documento de Especifica o de Requisitos de Software que registra os resultados das tarefas realizadas Eventualmente pode ser produzido como documento adicional um Manual Preliminar do Usu rio Embora pare a estranho a produ o deste manual permite que o analista passe a olhar para o software da tica do cliente usu rio
117. ue o verdadeiro objetivo do novo sistema que o analista est especificando tomar lhe o emprego E o analista pode ressentir se do modo como o usu rio est respondendo as perguntas Em qualquer caso o ressentimento pode surgir entre as duas partes tornando a comunica o muito mais dif cil N o existe um modo m gico de garantir que esses problemas n o ocorrer o eles s o a consequ ncia das intera es pessoa a pessoa e cada uma dessas intera es nica Contudo as sugest es dadas a seguir podem ajudar a reduzir a probabilidade desses problemas fora isso depender de pr tica para melhorar cada vez mais em cada entrevista subsequente Prof Walteno Martins Parreira Jr P gina 12 Engenharia de Software 2 4 Diretrizes Para a Realizac o de Entrevistas As seguintes diretrizes podem ser de grande aux lio na dire o de entrevistas bem sucedidas com o usu rio 2 4 1 Desenvolva um Plano Geral de Entrevistas Antes de tudo extremamente importante que o analista descubra quem deve ser entrevistado Caso contr rio desperdicar o tempo de todos e criar um enorme tumulto por falar com pessoas erradas sobre coisas erradas Isso requer que obtenha um organograma da empresa que mostre as pessoas da organiza o usu ria bem como a hierarquia entre elas Se n o existir um organograma formal encontrar algu m que saiba como a organiza o funciona e pedir ajuda Se o organograma existir certificar se de que e
118. uma atividade extremamente importante para se compreender a necessidade e a import ncia do sistema a ser constru do e definir os requisitos que tornam o sistema til Prof Walteno Martins Parreira Jr P gina 21 Engenharia de Software Requisitos s o objetivos ou restri es estabelecidas por clientes e usu rios do sistema que definem as diversas propriedades do sistema Os requisitos de software s o obviamente aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software Um conjunto de requisitos pode ser definido como uma condi o ou capacidade necess ria que o software deve possuir para que o usu rio possa resolver um problema ou atingir um objetivo ou ent o para atender as necessidades ou restri es da organiza o ou dos outros componentes do sistema Tradicionalmente os requisitos de software s o classificados segundo Sommerville em requisitos funcionais n o funcionais e de dom nio Os requisitos funcionais s o a descri o das diversas fun es que clientes e usu rios querem ou precisam que o software ofere a Eles definem a funcionalidade desejada do software O termo fun o usado no sentido gen rico de opera o que pode ser realizada pelo sistema seja atrav s comandos dos usu rios ou seja pela ocorr ncia de eventos internos ou externos ao sistema S o exemplos de requisitos funcionais e o software deve possibilitar o c lculo dos gastos di rios semanais mensais e anua
119. vendiam centenas ou milhares de copias de seus programas as empresas da terceira era vendem dezenas e ate mesmo centenas de milhares de c pias O hardware de computador pessoal est se tornando rapidamente um produto prim rio enquanto o software oferece a caracter stica capaz de diferenciar De fato quando a taxa de crescimento das vendas de computadores pessoais se estabilizou em meados da d cada de 1980 as vendas de software continuaram a crescer Na industria ou em mbito domestico muitas pessoas gastaram mais dinheiro cm software do que aquilo que despenderam para comprar o computador no qual o software seria instalado A quarta era do software de computador esta apenas come ando As tecnologias orientadas a objetos est o rapidamente ocupando o lugar das abordagens mais convencionais para o desenvolvimento de software em muitas reas de aplica o Autores tais como Feigenhaum McCorduck e Allman prev em que os computadores de quinta gera o arquiteturas de computa o radicalmente diferentes e seu software correlato exercer o um profundo impacto sobre o equil brio do poder pol tico e industrial em todo o mundo As t cnicas Prof Walteno Martins Parreira Jr P gina 6 Engenharia de Software de quarta gera o para o desenvolvimento de software j est o mudando a maneira segundo a qual alguns segmentos da comunidade de software constr em programas de computador Os sistemas especialistas e o software de intelig
120. zido com sucesso necess rio que os desejos do cliente e as expectativas dos eventuais usu rios finais do sistema sejam precisamente transmitidos ao desenvolvedor Este processo de transmiss o de requisitos do cliente e dos usu rios ao desenvolvedor invariavelmente apresenta relativa dificuldade considerando alguns aspectos e geralmente os clientes n o entendem de software ou do processo de desenvolvimento de um programa e o desenvolvedor usualmente n o entende do sistema no qual o software vai executar Prof Walteno Martins Parreira Jr P gina 25 Engenharia de Software A boa comunica o entre a equipe de desenvolvimento e o cliente fundamental para a realiza o de sucesso da atividade de an lise de requisitos Nem sempre a boa comunica o alcan ada devido aos motivos j citados Uma An lise de Requisitos bem sucedida deve representar corretamente as necessidades do cliente e dos usu rios satisfazendo por m s tr s partes envolvidas incluindo o desenvolvedor O que verificado em boa parte dos projetos de software que o cliente nem sempre entende perfeitamente quais s o as suas reais necessidades assim como os usu rios t m dificuldades para exprimir as suas expectativas com rela o ao que est sendo desenvolvido Um primeiro resultado desta etapa deve ser sem d vida o esclarecimento a respeito do que s o estas necessidades e expectativas 3 5 Princ pios da an lise Pesquisadores
121. zinhan a e popula o abrangida pelas a es e resultados do projeto Outros elementos importantes que influenciam projetos s o as culturas e estilos organizacionais bem como os fatores ambientais da empresa do mercado da sociedade e da localiza o geopol tica onde o projeto acontece Prof Walteno Martins Parreira Jr P gina 41 Engenharia de Software 5 UML Os conceitos da orienta o a objetos s o bem difundidos desde o lan amento da primeira linguagem orientada a objetos a linguagem SIMULA O desenvolvimento de sistemas de software suportados por m todos de an lise e projeto que modelam esse sistema de modo a fornecer para toda a equipe envolvida uma compreens o completa do projeto A UML Unified Modeling Language a sucessora de um conjunto de m todos de an lise e projeto orientados a objeto A UML um modelo de linguagem n o um m todo Um m todo pressup e um modelo de linguagem e um processo O modelo de linguagem a nota o que o m todo usa para descrever o projeto O processo s o os passos que devem ser seguidos para se construir o projeto A UML define uma nota o e um meta modelo A nota o representa a sintaxe da linguagem composta por elementos gr ficos Um meta modelo um diagrama de classe A UML foi desenvolvida por Grady Booch James Rumbaugh e lvar Jacobson que s o conhecidos como os tr s amigos A UML a jun o do que havia de melhor nas tr s metodologias e que foi adicion

Apostila - waltenomartins.com.br

Contents

Download Pdf Manuals

Related Search

Related Contents