3ª prova pós web 1ª chamada

878 visualizações

Publicada em

Atividade da Pós em Desenvolvimento WEB.

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
878
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
11
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

3ª prova pós web 1ª chamada

  1. 1. 3ª Prova Pós Web - INGRESSO: 08/08/2014 - A sua prova presencial de Recuperação - ESPECIALIZAÇÃO EM TECNOLOGIAS PARA APLICAÇÕES WEB ocorrera em: Dia: 27/06/2015 Horario: 08:30 as 10:00 (Horario de Brasilia) Disciplinas: PROJETOS ÁGEIS, ANÁLISE DE SISTEMAS, BANCO DE DADOS, DESIGN DE INTERFACES, INTERAÇÃO HUMANO-COMPUTADOR TECNOLOGIA EM ANÁLISE DE SISTEMAS WEB AULA 1 Unidade 1 – INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS RESUMO: O objetivo da presente unidade é apresentar os principais fundamentos sobre gerenciamento de projetos. Nesse sentido,será abordado o ciclo de vida básico de um projeto, suas principais tarefas e como esse processo contribui para o sucesso de um projeto. Além disso, de forma resumida, será apresentado como estruturar um projeto aplicando princípios básicos considerados boas práticas de gestão de projetos. Ao final, será possível entender e aplicar ferramentas essenciais à gestão eficiente de projetos desoftware. DEFINIÇÃO DE PROJETO Afinal de contas, o que é um projeto? Segundo o PMI (2008), projeto é “[...] um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. Ainda segundo o PMI:  Temporário significa que todos os projetos possuem um início e um final definidos. Embora não recomendado, muitos projetos ou não definem claramente uma data de início ou terminam muito além do programado.  Temporário não significa necessariamente de curta duração; muitos projetos duram vários anos. Exemplo de projetos longos são as missões espaciais que podem durar mais de uma década para serem concluídas.  Temporário não se aplica ao resultado do projeto, que poderá perdurar por muitos anos após a conclusão do projeto. As pirâmides do Egito são um exemplo claro do resultado duradouro de um projeto.
  2. 2. O resultado de um projeto é exclusivo, único. Saiba mais sobre os principais conceitos em gestão de projetos:http://www.gestaodeprojeto.info/introducao Mas o que pode ser administrado como um projeto? Projetos surgem, por exemplo, de problemas ou oportunidades pessoais ou organizacionais.Logo, projetos lidam com situações não muito comuns. Por exemplo, uma empresa de software deseja implantar um novo procedimento de teste de software. Nesse sentido, projetos envolvem muitas incertezas e geralmente geram mudanças ao acrescentarem algo novo. Então, projetos não lidam com situações do dia a dia, ou seja, projetos não administram rotina. Rotinas geralmente não envolvem incertezas e o resultado é previsível.
  3. 3. Muitas palavras novas? Baixe um pequeno dicionário de “Projetês” no endereço:http://www.gestaodeprojeto.info/arquivos/PMBOK_Port_glossario.zip?attr edirects=0 Entretanto, gerenciar por meio de projetos não se aplica somente no ambiente organizacional, você pode administrar determinados objetivos pessoais por meio de projetos. Por exemplo, o curso de especialização que você está fazendo poderia ser administrado por meio de um projeto. Note que o curso é algo novo em sua vida, irá acrescentar algo à sua vida profissional, deverá ser realizado num determinado prazo, envolverá custos, riscos, ou seja, exigirá um planejamento que possibilite que você atinja seu objetivo: ser um especialista em Desenvolvimento de Aplicações Web Baseadas na Tecnologia JAVA. Vídeo: o que é um projeto: O quadro 1 apresenta algumas diferenças entre rotina e projeto. Saiba mais: Maximiano (2010, p. 4-13) apresenta uma visão geral sobre projetos. CICLO DE VIDA DO PROJETO
  4. 4. Como os projetos são organizados? Projetos podem ser divididos em fases que possibilitam melhor controle gerencial. O ciclo de vida do projeto define as fases que conectam o início de um projeto ao seu final. Segundo o PMI (2008), um ciclo de vida (vide figura 1) é um processo que determina um conjunto de ações e atividades inter-relacionadas realizadas para obter um conjunto pré-especificado de produtos, resultados ou serviços. Cada uma das fases define um grupo de processos que são aplicados iterativamente (de forma incremental) e repetitivamente. Segundo Trentim (2011), o grupo de processo de Inicialização é responsável pela definição e autorização de um novo projeto; o grupo de processos de Planejamento define o que será feito e como será realizado; o grupo de processos de Execução coloca em prática o planejamento; o grupo de processo de Monitoramento e Controle verifica se a execução está em conformidade com o planejado e o grupo de processo de Encerramento é responsável pela finalização do projeto.
  5. 5. Como pode ser percebido, o ciclo de vida do projeto ajuda a organizar todos os processos necessários à realização do projeto. Ele estabelece uma sequência, agrupa processos comuns, dá uma visão geral sobre todo o percurso que deverá ser realizado entre o início e o término do projeto entre outras vantagens. Então, o ciclo de vida de um projeto é um fatorimportante para o sucesso do projeto. O ciclo de vida do projeto é similar a um mapa: um mapa indica o início, o destino, a rota que conduz ao destino, os locais pelos quais deveremos passar, dá uma noção do progresso, ou seja, onde estou no trajeto? Ao pensar sobre o ciclo de vida de um determinado projeto, considere algumas questões que deverão ser respondidas: » Que trabalho técnico deve ser realizado em cada fase. Por exemplo, em qual fase deve ser realizado o trabalho do Analista de Sistema, Programador, Administrador do Banco de Dados (DBA), etc. » Quando as entregas devem ser geradas em cada fase e como cada entrega é revisada, verificada e validada. Por exemplo, quando o diagrama Entidade Relacionamento (DER) deverá ser entregue? Quem irá revisá-lo? Quando será revisado?
  6. 6. » Quem está envolvido em cada fase. Por exemplo, na fase de planejamento do projeto deverá ser coletado os requisitos do software, então, quais são os interessados (stakeholders)? » Como controlar e aprovar cada fase. Por exemplo, quando sei que a atividade Engenharia de Requisitos foi concluída, como saberei se a atividade está dentro do prazo? Como saberei se realmente a atividade foi concluída? Quais critérios indicam que a atividade foi concluída dentro das expectativas? Saiba mais: Ciclo de vida do projeto de software: http://www.oficinadanet.com.br/artigo/1912/o_ciclo_de_vida_de_um_projeto_de_i nformatica Vídeo: ciclo de vida do projeto: Normalmente um projeto envolve diretamente e indiretamente vários interessados (stakeholders[1]) e saber quem está envolvido no projeto é um fatorimportantíssimo para o sucesso do projeto. Por exemplo: imagine que você irá construir uma casa nova para sua família. Esse projeto irá envolver diversas pessoas, principalmente sua família. Então, imagine que você deixou de ouvir sua família sobre quais características a casa deveria ter. O que você acha que aconteceria quando sua família se mudasse para a nova casa? Será que eles a aprovariam? Bom, talvez sim, ou talvez a desaprovassem por completo, ou talvez dissessem “acho que poderia ser assim”, etc., etc. Partes interessadas no projeto podem ser pessoas ou organizações ativamente envolvidas no projeto ou cujos interesses podem ser afetados com o resultado da execução ou do término do projeto. Eles podem também exercer influência (positiva ou negativa) sobre os objetivos e resultados do projeto. [1] Stakeholders é um termo em inglês muito utilizado na literatura. Nesse material, stakeholder será empregado comointeressado.
  7. 7. Exemplo de interessados: Clientes que comprarão e/ou usarão o produto resultante do projeto, órgãos ou agências regulamentadoras que podem interferir no projeto, pessoas ou organizações que disponibilizarão recursos ao projeto, pessoas ou organizações afetadas pelo projeto, parceiros ou terceiros que participarão do projeto, equipe de Projeto, fornecedores de produtos ou serviços ao projeto, competidores/concorrentes, etc. Trentim (2011) apresenta um exemplo resumido no formato de uma tabela (vide figura 2) de informações que poderiam ser registradas sobre as partes interessadas no projeto. A tabela destaca, por exemplo, o interesse de cada parte interessada, a influência dessa parte interessada no projeto e o impacto que essa parte poderia provocar no projeto.
  8. 8. Quer saber mais sobre as partes interessadas? Acesse o endereço: http://www.gestaodeprojeto.info/analise-dos-stakeholders Gerente de Projeto O gerente de projeto (ou GP) desempenha um papel fundamental no projeto, ele é o responsável global por todo trabalho realizado no projeto. Além disso, o gerente atua como um meio, uma interface, entre o projeto e os interessados nele. O GP é um cargo temporário, ou seja, ele existe enquanto o projeto existir. Normalmente o gerente é definido logo nas etapas iniciais do projeto. Dentre tantas responsabilidades, o GP supervisiona o planejamento, desenvolvimento e operação do projeto. Cleland; Ireland (2007) listam outras responsabilidades atribuídas aos gerentes de projeto: » redistribuem recursos conforme a necessidade do projeto; » monitoram a competência da equipe do projeto; » gerenciam mudanças; » monitoram o prazo, custo, risco, qualidade, etc. do projeto; » relatam o andamento do projeto aos interessados;
  9. 9. » motivam a equipe. Saiba mais: Ouça o PODCAST de Ricardo Vargas sobre as responsabilidade do GP: http://www.ricardo-vargas.com/pt/podcasts/projectmanagerresponsibilities/ Vídeo: Perfil profissional do GP: OS DESAFIOS DO PROJETO Gerenciar projetos implica numa “batalha” diária entre algumas restrições: tempo, custo, qualidade, escopo e satisfação do cliente. Note que essas variáveis reagem quando se modifica uma delas. Por exemplo, o que aconteceria se você percebesse que o projeto está atrasado e que precisa recuperar o tempo para entregar no prazo? Bom, você poderia apontar algumas alternativas, por exemplo: contratar mais pessoas ou trabalhar um pouco mais (hora extra). Acredito que você tenha percebido que essas duas medidas podem
  10. 10. provocar um impacto na outra variável: o custo. Logo, para recuperar o tempo terei que aumentar o custo. Vamos assistir a vídeo aula 1 Outra alternativa para realizar o projeto dentro do tempo estimado sem aumentar o custo seria deixar de realizar algumas tarefas. Entretanto, isso poderia impactar na qualidade do projeto. Então, caberá ao gerente de projeto a árdua habilidade de equilibrar essas variáveis, de decidir se aumentará o custo ou diminuirá a qualidade. Ou melhor, qual o ponto de equilíbrio entre entre custo, tempo, qualidade e escopo que resulte na satisfação do cliente. PMI e PMBOK Como você percebeu, gerenciar projetos envolve muito conhecimento, apresenta muitos desafios e envolve muitos riscos. Logo, você poderia se perguntar, diante de tanta complexidade, serei eu capaz de administrar um projeto? Realmente, é muito difícil e quase sempre, diante de uma nova área, nos sentimos incapazes. Entretanto, em 1969, na Pensilvânia (EUA), cinco voluntários também se depararam com as mesmas questões.Então, eles decidiram fundar o PMI – Project Management Institute (ou, em português, Instituto de Gerenciamento de Projetos). O PMI é uma organização sem fins lucrativos e atualmente está presente em mais de 185 países com mais de 650.000 membros associados.
  11. 11. O PMI está organizado em capítulos que são estabelecidos nos mais diferentes países. São mais de 250 capítulos estabelecidos em todo mundo. No Brasil já foram estabelecidos 13 capítulos. Segundo o PMI, essas comunidades, abertas a membros do PMI e dirigidas por voluntários, dão suporte para a troca de conhecimento e para redes de trabalho, pontos centrais da missão do PMI. Saiba mais sobre o PMI: Acesse o endereço: http://brasil.pmi.org Entre os principais objetivos do PMI encontra-se o desenvolvimento de conhecimentos para gerenciamento de projetos e, certamente, uma das principais contribuições do PMI é o guia PMBOK – Project Management Body of Knowledge (ou, em português, Guia para o Corpo de Conhecimento em Gerenciamento de Projetos). PODCAST: PMBOK quarta edição: http://www.ricardo-vargas.com/pt/podcasts/newpmbok/ Segundo o PMI (2008), o Guia PMBOK identifica um conjunto de conhecimento em gerenciamento de projetos amplamente reconhecido como uma boa prática. O PMI ainda enfatiza que “boa prática” significa que existe um consenso geral de que a aplicação correta dessas habilidades, ferramentas e técnicas pode aumentar as chances de sucesso em uma ampla gama de projetos.
  12. 12. Logo, o Guia PMBOK é uma fonte indispensável de conhecimento para quem pretende gerenciar um projeto. Os conteúdos do Guia PMBOK estão separados por área de conhecimento para as quais são definidos e explicados os processos necessários à sua aplicação. Deve-se deixar claro, entretanto, que cabe ao usuário do Guia definir como o conhecimento será aplicado, então, o Guia apenas sugere boas práticas e, portanto, cabe ao usuário avaliar sua pertinência em relação ao projeto ao qual se pretende aplicar as boas práticas propostas pelo Guia. O Guia é constantemente atualizado e encontra-se atualmente em sua 4ª edição, distribuída em 2008. Nessa edição, o conteúdo do Guia apresenta 42 processos. Os 42 processos podem ser divididos de duas formas (vide figura 3): agrupados por áreas de conhecimento ou agrupados por grupos de processos.
  13. 13. Fonte: http://www.pmtech.com.br/artigos/Processos_PMBOK_4a_Mauro_Sotille.pdf. Na figura 3, do lado direito, pode-se observar uma legenda. Nessa legenda são apresentadas as 9 áreas de conhecimento com sua respectiva cor e ícone: Integração, Escopo, Tempo, Custos, Qualidade, RH (Recursos Humanos), Comunicação, Riscos e Aquisição. Pode-se perceber ainda na figura 3 que os processos (retângulos numerados) possuem uma cor e um ícone (Figura 4). Considerando esses dados e tomando como exemplo o processo “4.1 Desenvolver o termo de abertura do projeto” localizado no topo do lado esquerdo da figura, podemos classificar esse processo na área de conhecimento Integração. Então, todo retângulo na cor “amarelo claro” e que apresenta o ícone “estrela” é classificado como
  14. 14. um processo de Integração. Você perceberá que existem 6 processos de integração espalhados pela figura. Também perceberá que os processos espalhados pela figura, na verdade, estão contidos dentro de uma divisão. Cada uma das divisões é um grupo de processos. Tomando ainda como exemplo o processo 4.1 “Desenvolver o termo de abertura do projeto”, você perceberá que ele está numa divisão intitulada “Processos de Iniciação”. Você notará ainda que apenas dois processos são classificados como processo de Iniciação. Vídeo: Grupos de processos PMBOK: Esses dois modos de visualizaros processos de gerenciamento sugeridos pelo PMBOK estão relacionados e são úteis da seguinte forma, por exemplo: Se você estiver na fase de Planejamento de um projeto, quais processos você poderia empregar para planejar seu projeto? Considerando a figura 3, você perceberá que o PMBOK sugere 20 processos que podem ser realizados no planejamento de um projeto. Quer saber mais sobre o PMI e PMBOK? Acesse o endereço:http://www.linhadecodigo.com.br/artigo/974/iniciacao-ao-pmbok-no- gerenciamento-de-projetos.aspx Por outro lado, se você estiver avaliando os possíveis riscos de seu projeto, quais processos poderiam ser realizados? Nesse caso você irá localizarna figura 3 todos os
  15. 15. seis processos que possuem o ícone “raio” (eles estão distribuídos em dois grupos de processos: “Planejamento” e “Monitoramento e Controle”). Esses processos são processos relacionados ao gerenciamento de riscos de um projeto. O Guia PMBOK é um tema relativamente extenso. O propósito aqui foi propiciar uma visão ampla sobre seu conteúdo e organização. Conhecer as boas práticas apresentadas pelo Guia certamente é uma leitura recomendada para todos aqueles que querem aprofundar seus conhecimentos em gerenciamento de projetos. O Guia PMBOK é uma leitura obrigatória para quem tem interesse em gestão de projetos. Você pode obter mais informações sobre a aquisição do Guia PMBOK no endereço:http://brasil.pmi.org/brazil/PMBOKGuideAndStandards.aspx GRUPOS DE PROCESSO Como apresentado anteriormente, os 42 processos do PMBOK estão agrupados em 5 grupos: Iniciação, Planejamento, Monitoramento e Controle, Execução e Finalização. A intenção em agrupar os 42 processos é organizá-los e permitir que se tenha uma visão do progresso do andamento do projeto.
  16. 16. Segundo o PMI (2008), cada grupo de processo possui, de modo geral, as seguintes responsabilidades. Grupo de Processos de inicialização: Os processos desse grupo têm por objetivo definir, iniciar um novo projeto ou nova etapa do projeto. Uma vez o projeto seja autorizado a iniciar, nessa etapa é definido o gerente do projeto, identificadas as partes interessadas e alocado os recursos entre outros processos. Grupo de processos de planejamento: Define o escopo do projeto, ou seja, o que será responsabilidade do projeto, refina os objetivos e estabelece as ações que conduzirão ao objetivo geral do projeto. Grupo de processos de execução: é formado pelos processos responsáveis pela execução do trabalho definido no planejamento. Grupo de processos de monitoramento e controle: nesse grupo estão os processos responsáveis pelo monitoramento do projeto, ou seja, averigua se tudo está ocorrendo como previsto, realizado como planejado e, caso contrário, toma medidas para contornar da melhor forma possível eventuais problemas. Grupo de processos de encerramento: Agrupa os processos encarregados de finalizar todos os procedimentos, documentar as lições aprendidas, registrar todas as informações entre outros. Definir os processos de um projeto é como um jogo de xadrez, cada projeto (partida) exige uma estratégia diferente. CERTIFICAÇÕES DO PMI Para os interessados em gerenciamento de projetos, o PMI oferece seis certificações profissionais que tem por objetivo demonstrar que o profissional possui
  17. 17. conhecimento, experiência e competências em determinadas áreas do gerenciamento de projetos. As certificações emitidas pelo PMI são reconhecidas mundialmente e os profissionais que as possui são muito valorizados no mercado. Atualmente o PMI oferece seis certificações.  Certificação PMP – Profissional de Gerenciamento de Projetos (PMP).  Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos.  Certificação PgMP – Profissional de Gerenciamento de Programas.  Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI.  Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI.  Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI. PODCAST: Ouça o podcast sobre a certificação CAPM: http://www.ricardo-vargas.com/pt/podcasts/capm-certification-part-1-of-2/ Para obter uma certificação do PMI, você deve primeiramente atender aos requisitos de elegibilidade delineados no portal do PMI e detalhados nos manuais de
  18. 18. certificações. A seguir, você deve fazer três avaliações – a revisão da inscrição, o exame da certificação e a avaliação múltipla. Quer saber mais sobre as certificações do PMI? Acesse o endereço:http://brasil.pmi.org/brazil/FAQ/CertificationFAQ.aspx PROJETOS DE SUCESSO Segundo o PMI (2008), o ciclo de vida do projeto apresenta algumas características comuns entre diferentes projetos (Figura 6). Essas informações são valiosas principalmente para quem está iniciando em gestão de projetos. Vamos assistir a vídeo aula 2 Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante as fases intermediárias e caem rapidamente conforme o projeto é finalizado. Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos das mudanças e correções de erros geralmente aumentam significativamente conforme o projeto se aproxima do término. Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante as fases intermediárias e caem rapidamente conforme o projeto é finalizado.
  19. 19. Para saber mais sobre a importância do planejamento, leia o artigo disponível em Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos das mudanças e correções de erros geralmente aumentam significativamente conforme o projeto se aproxima do término. Segundo o PMI (2008), para que um projeto seja bem sucedido, a equipe deve: » Selecionar processos adequados; » Usar uma abordagem apropriada; » Cumprir os requisitos dos interessados; » Equilibrar as demandas (escopo, tempo, custo, qualidade e satisfação do cliente). Vídeo: Obtendo resultados com Gerenciamento de Projetos: . RESUMO Nessa unidade foi apresentado a definição de projeto, seus benefícios e aplicações e diferenças em relação às rotinas. Assim como outras áreas, os projetos possuem um ciclo de vida comum, genérico, composto pelas etapas: iniciação, planejamento, execução, acompanhamento e controle e finalização. Também foi enfatizado que é fundamental identificar todas as partes interessadas no projeto, bem como as principais atribuições do responsável direto pelo projeto: o gerente de projeto. Além disso, foi apresentado a norma internacional PMBOK, mantida pelo PMI, a qual apresenta boas práticas em gestão de projetos. Também foi descrito como os profissionais podem obter maior aceitação no mercado por meio de certificações profissionais. Finalmente, foram destacadas algumas características gerais sobre projetos e fatores de sucesso. Primeiros passos, acesse o endereço: http://www.gestaodeprojeto.info/7passos
  20. 20. CLELAND, David, I.; IRELAND, Lewis R. Gerenciamento de projetos. Rio de Janeiro: LTC, 2007. MAXIMIANO, Antonio Cesar Amaru. Administração de projetos: como transformar ideias em resultados. 4. ed. São Paulo: Atlas, 2010. MOURA, Dácio Guimarães de; BARBOSA, Eduardo F. Trabalhando com projetos: planejamento e gestão de projetos educacionais. 2. ed. Petrópolis: Vozes, 2007. PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenciamento de projetos, 4. ed. Newton Square, PA: PMI, 2008. TRENTIM, Mário Henrique. Gerenciamento de projetos: guia para certificações CAPM e PMP. São Paulo: Atlas, 2011. TECNOLOGIA EM ANÁLISE DE SISTEMAS WEB AULA 1 Unidade 2 – PLANEJANDO UM PROJETO RESUMO: O objetivo da presente unidade é apresentar os passos básicos sobre o planejamento de um projeto e uma visão geral sobre métodos ágeis. Nesse sentido, será discutido o objetivo do projeto e seu papel no planejamento do projeto. Você também irá conhecer como definir as responsabilidades de um projeto por meio da definição do escopo. Além disso, aprenderá como dividir todo o trabalho necessário para realizar um projeto por meio da Estrutura Analítica do Projeto (EAP). Também entenderá porque a EAP é um dos instrumentos fundamentais para planejar um projeto: tempo, responsabilidades, estimativas de custo, tarefas, etc. Finalmente, será apresentada uma visão geral sobre os métodos ágeis e, em particular, uma visão um pouco mais aprofundada sobre a abordagem ágil SCRUM. INICIANDO UM PROJETO: O OBJETIVO
  21. 21. “Nenhum caminho adiantará se você não sabe aonde ir.” Definir o objetivo do projeto certamente é um dos principais passos para um projeto. Os objetivos são descrições concretas do que o projeto está tentando alcançar. Iniciar um projeto sem tê-lo definido claramente é praticamente sentenciar o projeto ao fracasso. Os objetivos do projeto (geral e específico) devem incluir os critérios mensuráveis do sucesso do projeto: técnicos, de negócios, custo, cronograma e qualidade. Isto é, deve ser descrito de tal forma que seja possível verificar ao final do projeto se eles foram ou não atingidos. Nesse sentido, os objetivos do projeto podem incluir metas de custo, cronograma e qualidade. Ou seja, Um objetivo bem escrito será específico, mensurável, alcançável/realizável, realístico e com uma clara indicação do tempo. Um contraexemplo de escrita de um objetivo: “Melhorar a qualidade no atendimento ao cliente por meio da implantação de um call center”. Nesse contraexemplo não está claro como o objetivo poderá ser verificado, pois não faz referência a custo, tempo, datas ou critérios de qualidade. Deste modo, não seria possível verificar se o projeto atendeu aos critérios.
  22. 22. Agora, leia a escrita de um objetivo que contém elementos que podem ser verificados: “O projeto objetiva entregar no prazo de 180 dias a contar a partir da data de 01/10/2008, com custo de investimento de R$ 5 milhões dentro do padrão internacional NPCS 3001 atualmente praticados pela corporação um serviço de call center para suportar o atendimento à clientes da rede de Lojas Fictícia”. Note que na descrição do objetivo constam a entrega do projeto (sublinhado contínuo) e elementos mensuráveis (sublinhado pontilhado), ou seja, possíveis de serem verificados: valores, prazo, data e norma de qualidade. Portanto, um objetivo atua como um farol para um navio, um ponto de referência para onde se quer chegar. Logo, o objetivo deve ser escrito de tal forma que fique claro o resultado pretendido. Ouça o PODCAST sobre objetivo de um projeto: http://www.ricardo-vargas.com/pt/podcasts/smart_objective/ O objetivo do projeto pode ser subdividido em objetivos menores. Por exemplo, imagine que você pretenda viajar para um determinado destino, você mora em São Paulo e pretende ir para Osasco – SP (Figura 1). Por se tratar de um trajeto curto, aproximadamente 23 Km, normalmente, você não se preocuparia muito, pois se trata de um trajeto relativamente simples.
  23. 23. Agora, imagine que você pretende ir de São Paulo para Dourados no Mato Grosso do Sul (Figura 2). Bom, agora você vai pensar, é uma rota relativamente extensa, aproximadamente 1000 Km e, para complicar, você não conhece muito bem o trajeto. Então, o que você faria? Provavelmente, você estabeleceria a rota, ou seja, pontos intermediários até o ponto final: São Paulo a Ourinhos, Ourinhos a Presidente Prudente, Presidente Prudente a Presidente Epitácio, Presidente Epitácio a Glória de Dourados e, finalmente, Glória de Dourados a Dourados. Bom, por que você varia dessa maneira? Porque seria mais seguro você alcançar seu destino final por meio do alcance de destinos mais curtos. A soma dos objetivos mais curtos é igual à soma de todo o trajeto até o destino final. Essa estratégia diminui a complexidade ao lidar com problemas menores, você resolve um problema de cada vez e, ao resolver todos os problemas menores, você teoricamente resolveria todo o problema. Então, considerando o exemplo acima, o destino final é nosso objetivo geral, e os destinos intermediários são nossos objetivos intermediários. ESCOPO Após definiro objetivo ou objetivos do projeto, devemos reunir todos os interessados no projeto e tratar do escopo do projeto. Mas, o que é escopo? Segundo Maximiano
  24. 24. (2010), escopo do projeto é o produto ou conjunto de produtos que o projeto deve entregar – a um cliente, patrocinador ou usuário. Uma analogia: imagine que o escopo do projeto é como um quebra-cabeça de montagem de peças. Somente estará completo e terá significado se todas as peças estiverem no seu devido lugar. Agora, considere um exemplo real: é comum empresas de software desenvolverem para um cliente um produto de software, mas será apenas o software a única entrega do projeto? Acredito que na maioria dos casos não. Por exemplo, não basta apenas entregar o software, em muitos casos é necessário instalá-lo no ambiente do cliente, logo, a implantação/instalação do software também é uma entrega do projeto. Outras possíveis entregas seriam: treinamento dos usuários, entrega do manual do sistema, entrega do instalador, migração de dados do sistema antigo para o novo sistema (quando se tratar de uma atualização), etc. Percebe-se, portanto, que a definição do escopo, ou seja, das entregas (em inglês, no singular,delivery) é uma parte fundamental do processo de gerenciamento de projetos. A definição incorreta do escopo pode provocar o fracasso de um projeto. Pensar no escopo é definir realmente o deve ser entregue. Muitos projetos definem entregas desnecessárias que não contribuem para o objetivo do projeto. É comum na descrição do escopo do projeto, para torná-lo mais claro ainda, não só a descrição das entregas, mas também a descrição do que NÃO será entregue, ou seja, àquelas entregas que não farão parte do escopo. Por exemplo: não faz parte do escopo do projeto: » Fornecer licenças de qualquer tipo de software necessário ao funcionamento do software objeto do projeto. » Projetar, instalar e configurar qualquer tipo de infraestrutura de redes de computadores.
  25. 25. » Fornecedor qualquer tipo de hardware necessário ao funcionamento do software objeto do projeto. » Realizar qualquer tipo de treinamento, exceto o treinamento de uso do software objeto do projeto. Saiba mais. Veja um exemplo de declaração do escopo do projeto: https://docs.google.com/viewer?a=v&pid=sites&srcid=Zmd2Z3AxMC5tYXVyaWNpb3ZpZWl yYS5uZXR8bG9naXN0aWNhLXNhbHZhZG9yLTIwMTR8Z3g6NTU2NzE0MzU2NmY0NTU ESTRUTURA ANALÍTICA DO PROJETO (EAP) Relembrando a analogia do mapa, o projeto possui um objetivo geral que pode ser subdividido em objetivos menores. Essa estratégia permite diminuir a complexidade do projeto pois, geralmente, partes menores são mais fáceis de administrar. E, após concluir cada uma das partes, a soma delas formaria o todo, ou seja, o projeto. Segundo Trentim (2011, p. 99), EAP é o “Processo de subdivisão das entregas e do trabalho do projeto em componentes menores de modo a facilitar as estimativas e o gerenciamento do trabalho”. A EAP permite decompor todo o trabalho do projeto em partes menores que serão mais fáceis de estimar e gerenciar. A EAP – Estrutura Analítica do Projeto (ou, em inglês, WBS – Work Breakdown Structure) é uma abordagem que permite decompor todo o trabalho do projeto em partes menores, mais fáceis de gerenciar. Existe diversas representações para a EAP, mas a mais comum é na forma de uma árvore invertida (Figura 3).
  26. 26. Nessa representação, como pode ser observado na Figura 3, o primeiro nível pode representar o produto final, ou serviço, ou ainda todo o trabalho do projeto. O segundo nível representa a primeira decomposição do primeiro nível, ou seja, “Pintar uma sala” foi dividida em: Preparação de materiais, preparação da sala, pintura da sala e limpeza da sala. O terceiro nível representa a divisão de cada elemento do segundo nível. Por exemplo, a “Preparação de materiais” ainda foi dividida em: comprar tintas, comprar escada, comprar rolos e comprar removedor de papel de parede. Quer saber mais sobre a EAP? Leia o material disponível em: http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto A EAP pode ter vários níveis. Sua profundidade dependerá do nível de detalhamento necessário que se deseja dar ao projeto. Alguns níveis podem ser mais detalhados que outros, por exemplo, considerando a Figura 4, a qual apresenta uma outra forma
  27. 27. de representar uma EAP, “Pesquisa” e “Escrita” foram subdivididas para o terceiro nível. Entretanto, a “Apresentação” não foi dividida. A cada nível da EAP pode ser atribuído um número. Os números também obedecem a hierarquia dos níveis (Figura 5). Como ainda pode ser percebido na Figura 5, uma EAP também pode ser representada no formato textual. Você já percebeu, portanto, que a divisão dos trabalhos acadêmicos normalmente empregam a abordagem da EAP. A EAP de um projeto pode ser representada em diversos formatos: gráfico, textual, tabular, hierarquia, etc. Regra dos 100% A regra dos 100% é um princípio aplicado à EAP a qual define que a soma de cada elemento imediatamente abaixo de um nível decomposto é igual a 100% do elemento imediatamente acima. Segundo o PMI (2008), a aplicação desta regra vale para todos os níveis na hierarquia: a soma de todo o trabalho dos níveis "filhos" deve ser igual a 100% do trabalho representado pelo "pai" e a EAP não deve incluir qualquer trabalho que saia do escopo existente do projeto, isto é, ele não pode incluir mais do que 100% do trabalho...”.
  28. 28. Vídeo sobre EAP http://www.ricardo-vargas.com/pt/videos/140/ Para ilustrar, considerando a Figura 7 (parte do exemplo apresentado na Figura 6), você deve ter notado que o nível 1, “Trabalho da disciplina” representa o projeto inteiro. Entretanto, todo esse projeto foi divididoem três partes. Cada uma das partes representa uma porção do projeto inteiro, logo, a soma dessas partes deve ser igual a todo o trabalho do projeto. Também deve ter notado que as partes possuem quantidade de trabalho diferentes, ou seja, as partes não precisam ter a mesma quantidade de trabalho, entretanto, a soma de trabalho dessas partes deve totalizar 100% do trabalho total. Você também deve ter notado na Figura 6 que a regra dos 100% pode ser aplicada para todos os níveis da EAP. Por exemplo, considerando a Figura 8, todo trabalho do item “Pesquisa” foi dividido ainda em duas tarefas: “Resumo Livros” e “Resumo Artigos”. Note que o trabalho “Pesquisa” representa 40% de todo o trabalho do projeto. Entretanto, todo esse trabalho, ou seja, 100% do trabalho “pesquisa” foi dividido em duas tarefas e cada uma delas representará 50% de todo o trabalho “Pesquisa”. Nesse caso, o trabalho foi dividido em duas tarefas com a mesma quantidade de trabalho. Esse raciocínio pode ser aplicado os demais níveis da EAP e é o gerente de projeto junto ao interessado que deve definir o nível de detalhamento da EAP, bem como as estimativas de trabalho de cada nível.
  29. 29. Até quando decompor a EAP? Segundo o PMI (2008), os responsáveis pelo escopo devem “subdividir as entregas do projeto em componentes menores e mais GERENCIÁVEIS, até que as entregas do trabalho estejam definidas no nível de PACOTES DE TRABALHO” (PMBOK, 2004). Saiba mais. Ouça o PODCAST sobre EAP e uma técnica de decomposição: http://www.ricardo-vargas.com/pt/podcasts/wbs/ E, o que é pacote de trabalho? Segundo Maximiano (2010), pacote de trabalho é o “conjunto delimitado de atividades do projeto […] atribuídas a uma pessoa ou unidade funcional”. Em outras palavras, o pacote de trabalho é o último nível da EAP, a folha, e é sobre o pacote de trabalho que se deve embasar o planejamento e estimativas do projeto.
  30. 30. Um nível, ao ser dividido, deve gerar pelo menos dois outros subníveis, ou seja, um nível não pode ser subdividido em apenas mais um nível (veja contraexemplo na Figura 9 – Nível 4). Mas a principal do pacote de trabalho é facilitar o planejamento. Vamos assistir a vídeo aula 3 Para cada pacote de trabalho pode ser definido, por exemplo: objetivo, tarefa(s), entrega(s), recurso(s), orçamento, duração e critérios de aceitação. O pacote de trabalho é a unidade que permite estimar com mais precisão diversos indicadores do projeto, como: tempo, custo, recursos, etc. Quer saber mais? Ouça um PODCAST sobre como definir o tamanho de um pacote de trabalho: http://www.ricardo-vargas.com/pt/podcasts/when-much-sometimes-is-too-much/
  31. 31. Tomando como exemplo a Figura 11, que apresenta a EAP para uma coleta de dados, teríamos seis pacotes de trabalho. Para cada um deles poderíamos definir: objetivo, tarefa(s), entrega(s), recurso(s), entregas, orçamento, duração, critérios de aceitação. A Figura 12 ilustra o planejamento do pacote de trabalho “Roteiro” da EAP apresentada na Figura 11. A EAP apresentada na Figura 11 associada ao detalhamento do pacote de trabalho apresentado na Figura 12 pode ser utilizado como referência para a elaboração do cronograma do projeto. O cronograma do projeto é uma ferramenta indispensável que permite o controle e acompanhamento
  32. 32. do projeto pelo gerente do projeto. A Figura 13 apresenta um exemplo de cronograma elaborado com base na EAP da Figura 11 e pacote de trabalho ilustrado na Figura 12. Cada nó (item que é desmembrado) é transformado numa tarefa agrupadora (tarefa resumo) e os pacotes de trabalho são transformados em tarefas do projeto. Saiba mais. Ouça o PODCAST e saiba mais sobre EAP e Pacote de Trabalho: http://www.ricardo-vargas.com/pt/podcasts/work_package_tasks_dictionary/ MÉTODOS ÁGEIS Os método ágeis surgiram do encontro de 17 metodologistas, em 2001. O grupo formou a Aliança Ágil. Com base em um manifesto, o grupo definiu um conjunto de princípios que deveria dar uma resposta aos seguintes pontos: » Aos chamados métodos pesados (ou peso pesados) que tornavam o desenvolvimento desoftware moroso e complexo. » Alto índice de fracasso dos projetos da área de TI. » Distanciamento dos interessados, ou seja, as metodologias de desenvolvimento mantinham os interessados distantes do processo de desenvolvimento de software. » Paradigma comando e controle (gerência e equipe). Essa abordagem torna a equipe apenas uma executora de tarefas.
  33. 33. Métodos ágeis foi a resposta que a comunidade encontrou como alternativa para o gerenciamento de projetos mais flexível. Pesquisas apontam (Figura 14) que os método ágeis são mais efetivos que os métodos tradicionais. Pesquisa realizada pelo Standish Group apontou que 42% dos projetos ágeis alcançaram sucesso frente a apenas 14% dos métodos tradicionais, no caso, o método Cascata (Waterfall). As abordagens tradicionais focam o tempo e custo e, como você sabe, quando nós direcionamos maior prioridade para uma dessas variáveis, a outra ou outras variáveis sofrem as consequências. Por exemplo, para cumprir os contratos principalmente em relação ao custo e tempo, muitas empresas acabam por diminuir as entregas, ou seja, o escopo. Então, o cliente recebe um produto bem menor que o combinado inicialmente.
  34. 34. Os métodos ágeis buscam o equilíbrio das variáveis escopo, tempo e custo com foco maior na variável escopo, ou seja, é uma abordagem orientada ao produto. Diferentemente das abordagens tradicionais, os métodos ágeis focam o escopo, ou seja, é dada a preferência para as entregas do projeto. Mas, você poderia perguntar? Como fica o tempo e o custo? Bom, funciona assim: uma lista de necessidades por ordem de prioridade é definida e, se o tempo ou o custo forem atingidos antes de terminar a lista, teoricamente, todas as necessidades de maior prioridade foram entregues ao cliente restando, portanto, as necessidades de menor prioridade. Alguns dos principais métodos ágeis: » Programação Extrema – eXtreme Programming (XP). » Framework Scrum. » Desenvolvimento Dirigido à Funcionalidade (FDD – Feature Driven Development). » Método de desevolvimento de Sistemas Dinâmicos – DSDM (Dynamic Systems Development Method). » Desevolvimento Adaptável de Software – Adaptive Software Development. » Crystal. » Programação Pragmática – Pragmatic Programming. » Desenvolvimento Dirigido a Teste – Test Driven Development. » Modelagem ágil – Agile Modeling. As abordagens ágeis são estruturadas segundo alguns valores (Figura 16) e princípios estabelecidos pelos metodologistas no encontro de 2001. Esses valores, no total 4, e princípios, no total 12, formam a base dessas metodologias. Saiba mais sobre os princípios ágeis:
  35. 35. http://agilemanifesto.org/iso/ptbr/principles.html Vamos assistir a vídeo aula 4 SCRUM Scrum é um framework de gerenciamento ágil de projeto de software proposto por Jeff Sutherland em 1993. Todo trabalho é dividido em pequenos ciclos de desenvolvimento chamados Sprints. CadaSprint dura entre uma a quatro semanas. Ao final de cada Sprint é entregue uma parte funcional do produto. SCRUM aceita que inevitavelmente haverá mudanças no projeto. O processo de gerenciamento proposto pelo Scrum é relativamente simples: 1. Inicialmente é eleito um responsável pelos requisitos, ou proprietário do produto (product owner) que define a mantém atualizada uma lista com todos os requisitos (product backlog) do usuário ou cliente. 2. Numa 1ª reunião (Sprint Planning Meeting), são selecionados o “mediador” (Scrum Master) e os requisitos (prioridade e tempo).
  36. 36. 3. Numa 2ª reunião, a equipe (Scrum Team) calcula e divide as tarefas (sprint Backlog). Essa porção de requisitos (interação) que será desenvolvida é chamada de sprint e dura entre 1 e 4 semanas. Ao final de um sprint é entregue uma parte funcional do produto. 4. Durante uma sprint são realizadas reuniões diárias com duração de 15 minutos. Ao final da sprint é realizada a reunião de revisão e preparação para o próximo sprint. Vídeo sobre a implantação do Scrum na Globo.com: Equipe Scrum e seus Papéis O Product Owner (proprietário do produto) é a única pessoa responsável pelo gerenciamento doBacklog do Produto e por garantir o valor do trabalho realizado pelo Time. O Product Owner (ou PO) pode ser o cliente, um gerente de produto, um usuário, etc. É recomendado que o Product Owner conheça o produto que será desenvolvido e que tenha uma boa interação com os demais interessados no projeto, visto somente ele ser o responsável pelos requisitos do produto.
  37. 37. Times (multifuncionais) auto-organizados de desenvolvedores, analistas, engenheiros, especialistaem banco de dados, etc. transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. É importante destacar que os Times Scrum devem ser pequenos para que de fato produzam resultados satisfatórios. Muitas experiências com Times grandes (com 10 ou mais integrantes) tem mostrado que a produtividade diminui significativamente. Isto porque o Time Scrum deve se comunicar intensamente e, Times com muitos integrantes tendem a ter dificuldades no processo de comunicação. O Scrum Master é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras. Ele não tem autoridade (no sentido de chefe), mas é o responsável pela equipe, coordena os eventos, avalia os resultados (produtividade), ou seja, é a interface da equipe perante os demais interessados, assim como o Product Owner é a interface dos interessados (lado cliente/usuário). TimeBox
  38. 38. Timebox (caixa do tempo) significa a delimitação no tempo de uma tarefa/evento. Vários eventos no Scrum são limitados no tempo, por exemplo, uma Sprint deve ser realizada entre 1 e quatro semanas e as reuniões tem duração entre 15 minutos a 4 horas (dependendo da reunião). Quer saber mais sobre Timebox? Leia o artigo disponível em: http://blog.myscrumhalf.com/2011/11/time-box-no-scrum/ Planejando a Sprint Como você já deve ter percebido, Sprint (Figura 18) é uma porção de todo o processo supostamente necessário para desenvolver o produto final. Geralmente, uma Sprint deve durar entre duas e quatro semanas. As Sprints de um projeto devem ter a mesma duração. Vamos assistir a vídeo aula 5 Como você deve ter percebido na Figura 18, uma Sprint implementa uma parte dos requisitos (ou histórias) listados no Product Backlog, essa porção de requisitos que será implementado na Sprint é chamado de Sprint Backlog. Ao final de uma Sprint, deve-se entregar o resultado planejado para a Sprint e, esse resultado, deve acrescentar algo ao produto, incrementá-lo, além, é claro, de ser funcional.
  39. 39. Saiba mais sobre o que são histórias de usuários: Antes de ser iniciada, a Sprint é planejada na Reunião de Planejamento 1. Nessa reunião os requisitos ou histórias são selecionados de tal forma que caibam dentro do tempo definido para a Sprint. Os requisitos ou histórias selecionados devem ser sempre os de maior prioridade. A prioridade dos requisitos é definida pelo Product Owner. Uma vez a lista esteja pronta (Sprint Backlog), é realizada a Reunião de Planejamento 2. Essa reunião tem por objetivo subdividir os requisitos ou histórias em tarefas. Os integrantes do Time selecionam as tarefas que desejam realizar. Executando a Sprint Uma vez definidas as tarefas e seus responsáveis, é iniciada a execução da Sprint. À medida que aSprint é executada, o Time compara o planejado ao realizado. Diariamente são realizadas reuniões pelo Time, os quais discutem o andamento e impedimentos da Sprint. Essas reuniões, normalmente realizadas em pé, ocorrem no início da manhã ou final da tarde e duram em média 15 minutos. A reunião aborda os seguintes temas: 1) O que você fez ontem? 2) O que você fará hoje? E, 3) Há impedimentos no seu caminho?
  40. 40. Finalizando a Sprint Após o término da Sprint, é realizada a reunião de Revisão. Participam dessa reunião o Time, Scrum Master (SM) e Product Owner (PO). O Time apresenta os resultados ao PO que por sua vez avalia se os requisitos (histórias) foram implementadas satisfatoriamente. Se não for aceito, os requisitos reprovados voltam para o Product Backlog e farão parte de uma nova Sprint. Após o término da reunião de Revisão também é realizada a reunião de Retrospectiva. Nessa reunião são discutidos os pontos negativos e positivos da Sprint. São propostas melhorias que farão parte da nova Sprint. Quer saber mais? Leia o glossário SCRUM: http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/ RESUMO Nessa unidade, nós discutimos um pouco sobre como iniciar um projeto, bem como a importância sobre a definição clara, mensurável e precisa do objetivo do projeto. Vimos também que todo projeto deve definir o escopo do projeto, ou seja, o que faz e o que não faz parte do projeto. Aprendemos que a EAP ou Estrutura Analítica do Projeto é um instrumento fundamental para descrever e planejar um projeto. Finalmente, discutimos sobre um pouco sobre uma nova abordagem de gestão de projeto: os métodos ágeis. Percebemos que os métodos ágeis tem apresentado, nos últimos anos, resultados melhores que métodos tradicionais como o método Cascata. Vimos também sobre o Scrum, uma abordagem ágil muito utilizada por empresas de desenvolvimento de software. Finalmente, discutimos alguns detalhes sobre o Scrum: valores, princípios, processo, papéis envolvidos e dinâmicas.
  41. 41. Revisão sobre o Scrum, Assista ao vídeo que apresenta um resumo sobre o Scrum: Visão geral Apresentação da disciplina: CURSO: especialização em Tecnologias para Aplicações WEB DISCIPLINA: ANÁLISE DE SISTEMAS DOCENTE: iolanda cláudia sanches catarino Apresentação do Professor: Sou a professora Iolanda, mestre em Ciência da Computação pela UFSCar, docente da UNOPAR na graduação e pós-graduação desde 1996 e atuo na área de engenharia de software como analista de sistemas. Sejam bem-vindos à disciplina de Análise de Sistemas! Primeiramente, abordarei uma contextualização do paradigma orientado a objetos, daUnified Modeling Language (UML), do Processo Unificado e uma visão geral da metodologia Enterprise Knowledge Development (EKD) que é uma abordagem para a modelagem organizacional, facilitando a compreensão do negócio para iniciar a modelagem das atividades de Análise de Requisitos e Análise. Na sequência, trabalharemos com os dois principais diagramas da atividade de Análise – o Diagrama de Casos de Uso e o Diagrama de Classes, integrando-os com o Diagrama de Atividades que se aplica a qualquer domínio de software. Objetivos:  Conhecer fundamentos sobre o paradigma orientado a objetos;  Conhecer a Linguagem de Modelagem Unificada – UML e suas técnicas de modelagem;  Conhecer e aplicar técnicas de modelagem da atividade de análise de sistemas, priorizando os dois principais diagramas da UML – Diagrama de Casos de Uso e Diagrama de Classes. Conteúdo Programático:  Paradigma Orientado a Objetos: histórico, características e conceitos;  A Linguagem de Modelagem Unificada - Unified Modeling Language (UML): histórico e visão geral das técnicas de modelagem;
  42. 42.  Modelo de Use Cases: Diagrama de Use Cases e Documentação de Use Cases;  Diagrama de Classes;  Diagrama de Atividades;  Diagrama de Sequência;  Diagrama de Máquina de Estados;  Especificação das técnicas de modelagem com ferramenta CASE. Metodologia: Na unidade utilizaremos todos os recursos necessários e disponíveis para o desenvolvimento da discussão do conteúdo, sendo assim, faremos uso de:  Textos da própria Web Aula e de outros sites que possam contribuir para a discussão;  Vídeos que possam esclarecer ou aprofundar determinados conteúdos;  Fóruns para discussão de tópicos onde seja possível a troca de ideias e conteúdos entre os discentes e docentes;  Avaliações virtuais onde será realizada a verificação do aprendizado;  Entre outros recursos que poderão ser utilizados visando maior entendimento da matéria. Avaliação Prevista: Cada web aula conterá uma avaliação virtual composta de 5 questões (sendo assim, temos 2 web-aulas com 5 questões cada). Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Critérios para Participação dos Alunos no Fórum: Quando houver fórum de discussão o aluno será avaliado quanto ao conteúdo de sua postagem, onde deverá comentar o tópico apresentando respostas completas e com nível crítico de avaliação pertinente ao nível de pós-graduação. Textos apenas concordando ou discordando de comentários de outros participantes do fórum sem a devida justificativa ou complementação não acrescentam em nada ao debate da disciplina, sendo assim, devem ser evitados. Os textos devem sempre vir acompanhados das justificativas para a opinião do discente sobre o conteúdo discutido, para que assim, possamos dar continuidade ao debate em nível adequado. Além disso, podem ser utilizados citações de artigos, livros e outros recursos que fundamentem a opinião ou deem sustentação a sua posição crítica sobre o assunto. Deve ser respeitado o tópico
  43. 43. principal do fórum, evitando debates que não tem relação com o tema selecionado pelo professor. Habilidades e competências Ampliar seus conhecimentos sobre os aspectos teóricos contidos nas diversas correntes do pensamento sobre a temática discutida na disciplina; Compreender a importância dos temas trabalhados para a formação profissional; Articular a relação teoria e prática no exercício da profissão, por meio do entendimento da visão do mundo moderno e globalizado. 1 TECNOLOGIAS PARA APLICAÇÕES WEB WEB AULA 1 Unidade 1 – Análise de Sistemas Atualmente, a transformação organizacional tem sido amplamente discutida e praticada, pois a transição entre negócios e tecnologias de informação, bem como a integração das funcionalidades de um Sistema de Informação (SI) com os requisitos organizacionais tem sido o grande problema das organizações e da engenharia de sistemas. Então, iniciamos esclarecendo dois conceitos: Engenharia de Sistemas e Engenharia de Software! Figura 1 – Engenharia de Sistemas. Fonte: Thinkstock (2012). A Engenharia de Sistemas contempla todos os aspectos relacionados ao desenvolvimento de sistemas com base em computadores, incluindo hardware, software e engenharia de processos, e aEngenharia de Software é uma parte da Engenharia de Sistemas que se ocupa de todos os aspectos
  44. 44. da produção de software (SOMMERVILLE, 2003). Para Pressman (2002), a Engenharia de Software abrange um conjunto de 3 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. O método proporciona os detalhes de “como fazer” para construir o software. Envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto, análise de requisitos,análise e projeto, implementação e testes. Sommerville (2003) define que um método é uma abordagem estruturada para o desenvolvimento de software, para facilitar a produção de software de alta qualidade, apresentando uma boa relação custo-benefício. Todos os métodos apresentam modelos de um sistema (técnicas de modelagem) que possam ser representados graficamente por diagramas, na maioria, ou de forma descritiva, sendo que cada técnica de modelagem tem um objetivo e aplicabilidade para melhor especificar o projeto. Na literatura, há vários métodos de desenvolvimento renomados e reconhecidos pelo mercado. Não existe o método ideal e diferentes métodos têm áreas de aplicação diversificada. As ferramentas proporcionam apoio automatizado ou semi-automatizado aos métodos de desenvolvimento de software, como por exemplo, as ferramentas Computer Assited Software Engineering (CASE) - Engenharia de Software Auxiliada por Computador, de modelagem, de banco de dados e de linguagens de programação. Os procedimentos definem o planejamento do projeto, a sequência de execução das atividades, as técnicas de modelagem que são adotadas do método escolhido, a sequência de execução das atividades e demais regras e padrões adotados no desenvolvimento do software. Podemos concluir que o desenvolvimento de um SI deve abranger a definição de uma metodologia que contemple métodos, técnicas de modelagem, arquitetura e tecnologias a serem adotados no desenvolvimento do sistema, visando um software com qualidade que atenda plenamente os requisitos dos usuários e assim, agregue inteligência ao negócio. 2 Os vários métodos e metodologias de desenvolvimento de sistemas dos paradigmas Estruturado e Orientado a Objetos abrangem um conjunto de técnicas de modelagem específicas para documentar as principais fases de um processo de desenvolvimento – Levantamento de Dados, Análise, Projeto e Implementação, conforme ilustra a figura a seguir. Figura 2 – Processo de Desenvolvimento.
  45. 45. Fonte: Do autor (2012). A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma visão lógica do negócio e independente de tecnologias de desenvolvimento. Muitos modelos de requisitos existentes descrevem o ambiente organizacional por meio de entidades e atividades, porém não representam as razões envolvidas nos processos de decisões, o qual dificulta o desenvolvimento de um SI que atenda plenamente os requisitos da organização. Assim, para garantir a identificação dos requisitos de um SI, sugere-se adotar a modelagem organizacional, previamente, visando identificar, definir e especificar os objetivos e processos próprios da organização (CATARINO; CAZARINI, 2008). A Modelagem Organizacional é um processo de modelagem complexa, pois envolve questões que necessitam de conhecimentos específicos ou tácitos dos participantes envolvidos nos processos de negócio, questões de gestão de pessoas e questões técnicas relacionadas aos objetos ou serviços da organização. A metodologia Enterprise Knowledge Development (EKD) (BUBENKO, 1998) é uma abordagem para a Modelagem Organizacional que facilita a aquisição do conhecimento da estrutura organizacional e estratégica, auxiliando na identificação dos requisitos organizacionais para, assim, melhorar a compreensão do domínio e a interação entre os usuários e o SI.
  46. 46. Para continuar aprendendo sobre EKD, acesse os links: http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104- 530X2004000200006 http://www.teses.usp.br/teses/disponiveis/18/18135/tde-25112008-153952/pt- br.php 3 1. Paradigma Orientado a Objetos O paradigma Orientado a Objetos é uma abordagem para o desenvolvimento de aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza o software como uma coleção de objetos que contém tanto a estrutura dos dados como o comportamento. É uma maneira de pensarnos problemas, utilizando modelos organizados a partir de conceitos do mundo real. A programação orientada a objetos teve início nos anos 1970 com a linguagem SIMULA, parte da linguagem Smalltalk desenvolvida pela Xerox PARC, mas ganhou grande visibilidade durante a década de 1980. Os conceitos básicos do desenvolvimento de software orientado a objetos levaram mais de 10 anos para amadurecerem. Da mesma forma que era difícil pensar em programação estruturada quando as linguagens disponíveis eram Assembler e Fortran, também ficava difícil pensar em programação orientada a objetos quando não se dispunha de linguagens como C++, Ada e Java. A abordagem orientada a objetos baseia-se nos conceitos da orientação a objetos, apresentando melhorias significativas de qualidade e um aumento constante da produtividade para o desenvolvimento de aplicações. A complexidade do desenvolvimento de sistemas tem aumentado em função de mudanças tecnológicas expressivas em poder de processamento e facilidade de uso, face à demanda por um mercado competitivo e dinâmico. Sua principal característica é a uniformização dos formalismos utilizados na análise, no projeto e na implementação. Outras características se destacam, como: a) Reusabilidade: refere-se à diminuição de custos por meio do reaproveitamento (reutilização) de componentes de software e diminuição do tempo de desenvolvimento do sistema. Segundo Booch; Jacobson e Rumbaugh (2000, p. 20), “[...] os componentes são partes físicas e substituíveis de um sistema, que proporcionam a realização de um conjunto de interfaces”; b) Manutenibilidade: refere-se ao grau de impacto de alterações corretivas e evolutivas, nosoftware , para realizar mudanças bem localizadas dos objetos, não acarretando propagações descontroladas por todo o software; c) Confiabilidade: refere-se a um controle de segurança e organização que é estabelecido às classes de objetos, obtido pelo encapsulamento, tornando o acesso às estruturas de dados privado aos objetos; d) Extensibilidade: refere-se às partes do software que têm o seu uso estendido a objetos pertencentes às classes criadas posteriormente. Classes genéricas podem
  47. 47. ser acrescidas de funcionalidades, gerando classes mais especializadas, aplicando o conceito de herança. Acompanhando a evolução das linguagens de programação orientadas a objetos, os métodos de modelagem orientados a objeto surgiram entre meados da década de 1980 e 1990. Os métodos suportam os mesmos conceitos básicos da orientação a objetos, apresentando técnicas de modelagem com notação e interpretação particular dos elementos que compõem a técnica. Os diversos métodos que surgiram para apoiar o paradigma orientado a objetos, tiveram uma grande diversidade de autores. No início da década de 1990, os pesquisadores James Rumbaugh, Ivar Jacobson e Grady Booch uniram as melhores características destacadas em suas técnicas de modelagem e construíram um padrão de referência para modelagem orientada a objetos, surgindo aUnified Modeling Language (UML) – Linguagem de Modelagem Unificada. 4 O elemento principal da abordagem orientada a objetos é o conceito de objeto. Na definição de Booch; Jacobson e Rumbaugh (2000, p. 456), um objeto é “[...] uma entidade com uma fronteira bem-definida e uma identidade que encapsula o estado e comportamento”. Para Rumbaugh (1994, p. 31), um objeto é “[...] um conceito, uma abstração, algo com limites nítidos e significado em relação ao problema em causa”. A figura a seguir ilustra um objeto. Figura 3 – Exemplo de Objeto. Fonte: Thinkstock (2012). Podemos definir um objeto como sendo qualquer coisa concreta ou abstrata com existência perceptível no mundo real que possa ser individualizado por possuir características e comportamento próprio, ou seja, todos os objetos têm identidade e são distinguíveis. Para rever os conceitos da orientação a objetos, acesse o link: http://books.google.com.br/books?id=BPVHsG17bAYC&printsec=frontcover&dq=co nceitos+da+orienta%C3%A7%C3%A3o+a+objetos&hl=pt- BR&sa=X&ei=TviYUNLgFIf28wSOpICYCw&ved=0CDkQ6AEwAQ#v=onepage&q=con ceitos%20da%20orienta%C3%A7%C3%A3o%20a%20objetos&f=false
  48. 48. 2. Introdução à Unified Modeling Language (UML) A UML consiste da fusão dos métodos de Booch, Rumbaugh (OMT- Object Modeling Technique) e Jacobson (OOSE – Object-Oriented Software Engineering). A fusão iniciou com o trabalho de Rumbaugh e Booch, que criaram um método a partir de pontos fortes de cada um, surgindo o Unified Method – UM 0.8, apresentado ao público em 1995. Logo a seguir, em meados de 1996, Jacobson integrou-se ao grupo e lançaram a UML versão 0.9. A partir daí, criaram forças com cooperação de grandes empresas, lançando no mercado com aprovação da Agência Americana de Padrões – Object Management Group (OMG) em julho de 1997, considerando um padrão mundial. A concretização da UML aconteceu em 1997. Conforme Booch; Jacobson e Rumbaugh (2000, p. 13), a UML é “[...] uma linguagem padrão para a elaboração da estrutura de projetos de software . A UML é uma linguagem para visualização, especificação, construção e documentação de artefatos que façam uso de sistemas complexos desoftware ”. A UML contempla uma representação gráfica por meio das técnicas de modelagem que especificam vários elementos (objetos, classes, atributos etc) da abordagem orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas se apoia no desenvolvimento incremental, por meio de modelos que podem evoluir com a inclusão de novos detalhes. VÍDEO 1 00:00 00:00 Atualmente, a OMG é a organização responsável em manter e administrar a UML. Para mais informações sobre a OMG, acesse o link: http://www.omg.org/ Segue-se um resumo da evolução da UML: Quadro 1 – Cronograma de evolução da UML. Ano Versão 1995 UML 0.8 (Booch e OMT) 1996 UML 0.9 (Booch, OMT e OOSE) 1997 UML 1.0 (padronizada pelo OMG – Object Management Group) UML 1.1 (revisada e adotada pelo OMG) 1998 UML 1.3 (nova revisão) 2001 UML 1.4 2003 UML 1.5 2005 UML 2.0 2007 UML 2.1.1 (setembro)e 2.1.2 (novembro)
  49. 49. 2009 UML 2.2 2010 UML 2.3 2011 UML 2.4.1 (agosto) Fonte: Do autor (2012). Veja o vídeo a seguir que apresenta a evolução das tecnologias. https://www.youtube.com/watch?v=WDFkHCfVe5Y E a UML, porque evolui? A UML contempla uma representação gráfica, por meio das técnicas de modelagem que especificam vários elementos (objetos, classes, atributos etc) da abordagem orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas se apoia no desenvolvimento incremental, a partir de modelos que podem evoluir com a inclusão de novos detalhes. Um modelo é uma descrição simplificada da realidade, apresentado a partir de uma perspectiva específica e criado para proporcionar uma melhor compreensão do sistema. Cada modelo pode ser expresso em diferentes níveis de precisão, constituindo um conjunto de diagramas consistentes entre si e acompanhados de técnicas de modelagem textuais. Um diagrama é uma visão sobre um modelo, o qual proporciona uma representação parcial do sistema. Figura 4 – Modelo x Diagrama. Fonte: Do autor (2012). Booch, Jacobson e Rumbaugh (2000) consideram as principais características da UML: a) centrado na arquitetura: a arquitetura do sistema é utilizada como principal artefato para a conceituação, construção, gerenciamento e evolução do sistema em desenvolvimento, representando uma visão do projeto como um todo. O conceito de arquitetura de software incorpora os aspectos estáticos e dinâmicos mais importantes do sistema. A arquitetura é influenciada por muitos fatores, tais como a plataforma de software sobre a qual o sistema vai rodar (sistema operacional, sistema gerenciador de banco de dados, protocolos para comunicação em rede, etc.), blocos de construção reutilizáveis (frameworks, componentes e patterns), considerações de distribuição, sistemas legado e requisitos não funcionais;
  50. 50. b) orientado a Casos de Uso: os casos de uso são utilizados como o principal artefato para o estabelecimento do comportamento desejado do sistema; c) processo iterativo: contempla o gerenciamento de sequências de versões executáveis e incrementais, sendo que cada nova versão incorpora os aprimoramentos incrementais em relação às demais. Uma versão do sistema liberada resulta em uma iteração concluída. De uma forma geral, a UML privilegia a descrição de um sistema segundo três perspectivas:estrutural – representa a visão estática do sistema; funcional – representa as funcionalidades do sistema, ou seja, os serviços que o sistema disponibiliza aos usuários; dinâmica – representa o comportamento dos objetos em tempo de execução. Para mais informações sobre a UML, acesse o link: http://www.uml.org/ 6 A UML 2.0 abrange quatorze técnicas de modelagem, classificadas em estrutural e comportamental. As técnicas de modela Modularidade gem estruturais enfatizam a estrutura dos elementos a partir da identificação dos objetos, colaborando para modelagem estática do sistema. As técnicas de modelagem comportamentais enfatizam o comportamento e a interação entre os elementos do sistema, colaborando para modelagem dinâmica do sistema. Quadro 2 – Relação das técnicas de modelagem da UML 2.0 Estruturais Comportamentais Diagrama de Classes Diagrama de Casos de Uso Diagrama de Objetos Documentação de Casos de Uso Diagrama de Estruturas Compostas Diagrama de Atividade Diagrama de Pacotes Diagrama de Máquina de Estados Diagrama de Componentes Diagrama de Sequência Diagrama de Implantação Diagrama de Comunicação Diagrama de Interação Geral Diagrama de Tempo Fonte: Do autor (2012). Figura 5 – Técnicas de Modelagem da UML.
  51. 51. Fonte: Thinkstock (2012). Para conhecer e saber mais sobre as técnicas de modelagem da UML, acesse o link: . A arquitetura da UML 2.0 é composta de duas bibliotecas, a Infrastructure – metamodelo superior – e a Superstructure, que define os elementos que compõem as notações de modelagem da UML, criadas pela extensão e acréscimo dos elementos básicos definidos na Infrastructure. Para facilitara reutilização de um software , essa arquitetura assegura que o projeto do software seja especificado com: a) modularidade: organizam-se os elementos da modelagem em pacotes, ou seja, em unidades pequenas, bem definidas e fáceis de usar; b) camadas: representa o refinamento dos elementos de um modelo para organizar e facilitar o uso, obtendo um refinamento dos modelos por meio da abstração dos elementos; c) extensibilidade: permite a personalização dos elementos existentes de um modelo, para que, assim, novos elementos não tenham que ser criados para solucionar novos problemas. Para continuar aprendendo, acesse os links: OMG Unified Modeling LanguageTM(OMG UML), Infrastructure: http://www.omg.org/spec/UML/2.4.1/Infrastructure OMG Unified Modeling LanguageTM(OMG UML), Superstructure: http://www.omg.org/spec/UML/2.4/Superstructure 7 2.1 O Processo Unificado
  52. 52. O Unified Process (BOOCH, JACOBSON; RUMBAUGH, 2000) surgiu para apoiar o desenvolvimento desoftware s orientado a objetos, fornecendo uma forma sistemática e evolutiva de modelar sistemas com a UML. O Processo Unificado consiste na repetição de uma série de ciclos durante o processo de desenvolvimento de um sistema, permitindo uma gerência mais efetiva de projetos complexos. Cada ciclo é concluído com uma versão do produto pronta para distribuição e é subdividido em quatro fases sucessivas: Concepção, Elaboração, Construção e Transição. Cada fase, por sua vez, é subdivida em iterações que passam por todos os cincos workflows (fluxo de trabalho, atividades) do processo: Requisitos, Análise e Projeto, Implementação e Teste. As fases representam os aspectos dinâmicos do processo e tratam a dimensão do tempo de execução. As atividades são executadas de forma incremental e evolutiva, representando os aspectos estáticos do processo. A ênfase sobre as várias atividades muda em cada fase do processo, como mostra a figura a seguir. Figura 6 – Ciclo de vida do Processo Unificado. Fonte: Adaptado de Medeiros (2010, p. 16). Na fase de Concepção define-se a ideia inicial do negócio, o domínio do problema e a delimitação do escopo do projeto. É feita a identificação dos atores que irão interagir com o sistema, definindo a natureza dessa interação em uma perspectiva de alto nível, destacando os principais casos de uso do sistema. Assim, esta fase evidencia o planejamento, sendo necessário, posteriormente, identificar, definir e analisaros requisitos do sistema. Ao término desta fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento, ou seja, a viabilidade do projeto. A atividade principal da fase de Concepção está no entendimento dos requisitos e a determinação do escopo do projeto.
  53. 53. Na fase de Elaboração define-se o comportamento funcional dos requisitos do sistema, estabelecendo a arquitetura e mecanismos para tratar aspectos abrangentes do sistema, conforme o domínio do problema. Assim consolida-se a fase de concepção, agregando valor a cada iteração-incremento que sofre. As atividades da fase de Elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis, podendo prever com precisão os custos e prazos para a conclusão do desenvolvimento. A atividade principal da fase de Elaboração é a definição e modelagem dos requisitos, ainda que algum trabalho de projeto e implementação seja realizado para prototipar uma versão dosoftware. Na fase de Construção define-se uma arquitetura executável do sistema para implementação, validação e testes do software. As atividades principais da fase de Construção concentra-se no projeto e na implementação, visando evoluir e melhorar o protótipo inicial, até obter o primeiro produto operacional. Na fase de Transição o sistema é disponibilizado à comunidade usuária com acompanhamento constante, devido à demanda de novas funções ou ajustes do sistema. A atividade principal da fase de Transição é a de testes, visando garantir que o sistema atenda os requisitos do usuário com qualidade. Além disso, usuários devem ser treinados, características ajustadas e elementos esquecidos adicionados ao projeto, fazendo a realimentação das atividades por fase. Para mais informações sobre o Processo Unificado, acesse o link: http://books.google.com.br/books?id=B1fy5scNtaIC&printsec=frontcover&hl=pt- BR#v=onepage&q&f=false 8 3. Atividade: Análise de Requisitos Nesta seção vamos abordar uma breve revisão da Engenharia de Requisitos para relembrar o conceito de requisitos funcionais, que na atividade de Análise de Requisitos ou apenas Requisitos é especificado como casos de uso. A Engenharia de Requisitos (Requirements Engineering) preocupa-se com o quê deve ser feito, ou seja, a compreensão do problema e não como fazer, considerando o domínio do sistema. A Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar os serviços e restrições (SOMMERVILLE, 2011). O domínio de um sistema engloba o contexto para o qual será provida uma solução, sendo que o processo de reconhecimento do domínio caracteriza a definição de sua
  54. 54. fronteira. O conteúdo de um domínio compreende fatos, regras, necessidades, conceitos, agentes etc. Veja o vídeo a seguir: https://www.youtube.com/user/IBMbrasil?v=LQ5RlWMNtB0 Como o projeto de um software pode atender plenamente as necessidades do usuário? Considerando um modelo de engenharia de software como o Processo Unificado, a atividade de Análise de Requisitos ou, simplesmente, Requisitos visa identificar, analisar, definir e especificar os requisitos do sistema. Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento (SOMMERVILLE, 2011). Sommerville (2011) classifica previamente os requisitos de um sistema em: requisitos de usuário erequisitos de sistema. Requisitos de usuário são declarações em uma linguagem natural com complemento de diagramas ou não, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar. Requisitos de sistema são descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software, sendo que o documento de requisito de sistema (especificação funcional) deve definirexatamente o que deve ser implementado. CONCLUINDO: Requisitos de Usuário: expressa os requisitos abstratos de alto nível; Requisitos de Sistema: expressa a descrição detalhada do quê o sistema deve fazer. Exemplo: Os requisitos de sistema são classificados em dois tipos: Requisitos Funcionais (RF): são declarações de serviços que o sistema deve fornecer, de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações. Requisitos Não Funcionais (RNF): são restrições aos serviços
  55. 55. ou funções oferecidos pelo sistema. Incluem restrições de tempo, restrições no processo de desenvolvimento e restrições impostas pelas normas organizacionais. Muitas vezes, aplicam-se ao sistema com o um todo. Surgem por meio das necessidades dos usuários, devido a restrições de orçamentos, políticas organizacionais etc. CONCLUINDO: Requisitos Funcionais: descrevem o que o sistema deve fazer – funcionalidades; Requisitos Não Funcionais: expressam restrições que o software deve atender ou qualidades específicas que o software deve ter. 9 Exemplos de definição de requisitos em linguagem natural:  O sistema deve prover um cadastro de cursos de extensão – RF;  O sistema deve prover um cadastro de autores (professor responsável pelo curso) dos cursos – RF;  O sistema deve prover um cadastro dos candidatos (internos: alunos e externos: pessoas da comunidade externa) – RF;  O sistema deve prover um cadastro das inscrições para os cursos de extensão – RF;  O sistema deve prover um relatório de inscritos nos cursos de extensão diariamente e por período – RF;  O sistema deve prover um relatório dos cursos de extensão por situação (Ativo, Confirmado, Encerrado ou Cancelado) – RF;  O período mínimo de inscrições de um curso de extensão deve ser de 20 dias – RNF;  O cadastro de candidatos externos deve ser via Web – RNF;  O cadastro das inscrições para um curso de extensão dever ser via Web – RNF;  O cadastro dos candidatos internos deve ser integrado com o sistema acadêmico (cadastro de funcionários – professores) – RNF;  O candidato ao se inscrever em um curso deve receber um e-mail de confirmação como tempo máximo de 10 segundos após a transação – RNF. Para modelar os requisitos funcionais de um sistema podemos adotar o Diagrama de Casos de Uso que, posteriormente, guiará o processo de desenvolvimento, conforme o Processo Unificado. Das técnicas da UML, o Diagrama de
  56. 56. Sequência também pode ser adotado para especificar o cenário de cada caso de uso. Para continuar aprendendo sobre Requisitos, acesse o link: http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0210666_06_cap_02.pdf RESUMO: Com a competitividade na era do conhecimento as organizações contam com sistemas computacionais, principalmente, os Sistemas de Informação para prover apoio à tomada de decisão de gestores táticos e estratégicos de forma que agregue inteligência ao negócio. Esta Web Aula apresentou uma contextualização da Engenharia de Sistemas, uma introdução da Unified Modeling Language (UML), descrevendo seu histórico, principais características e técnicas de modelagem da UML 2.0, uma visão do Processo Unificado com suas fases e atividades de desenvolvimento e uma introdução à atividade de Análise de Requisitos. Vamos iniciar o nosso fórum! As técnicas de modelagem da UML atendem a documentação de todos os tipos de sistemas de software? Qual a sua opinião? Figura 7 – Sistemas de Software. Fonte: Thinkstock (2012). BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: guia do usuário. Rio de Janeiro: Campus, 2000.
  57. 57. BUBENKO Janis; STIRNA, Janis; BRASH, Danny. EKD user guide. Dpt of computer and systems sciences. Stockholm: Royal Institute of Technology, 1998. CATARINO, I. C. S.; CAZARINI, E. W. Utilizando a metodologia enterprise knowledge development no processo de desenvolvimento de sistemas de apoio à decisão. UNOPAR Científica Ciências Exatas Tecnológicas. Londrina, v. 7, p. 77- 84, nov. 2008. Disponível em:. Aceso em: nov. 2012. MEDEIROS, Ernani. Desenvolvendo software com UML 2.0 - definitivo. São Paulo: Pearson Brasil, 2010. PRESSMAN, Roger S. Engenharia de software. 5. ed. São Paulo: Makron Books, 2002. SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison-Wesley, 2003. SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011. THINKSTOCK. Logical graph webshop, online store, internet shop. 2012. Disponível em: <http://www.thinkstockphotos.com/image/stock-photo-logical-graph- webshop-online-store- internet/140810423/popup?al=140810423&sq=140810423/c=431,253,632,254,93 ,28,34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,47 7,623,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291, 696,344,629,614,647/f=PIHVX/s=DynamicRank>. Acesso em: nov. 2012. THINKSTOCK. Smartphone with cloud of application icons. 2012. Disponível em: <http://www.thinkstockphotos.com/image/stock-photo-smartphone-with-cloud-of- application- icons/131404860/popup?al=131404860&sq=131404860/f=PIHVX/s=DynamicRank >. Acesso em: nov. 2012. THINKSTOCK. Software architecture class diagram. 2012. Disponível em: http://www.thinkstockphotos.com/image/stock-photo-software -architecture-class- diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28, 34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,62 3,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696, 344,629,614,647/f=PIHVX/s=DynamicRank Acesso em: nov. 2012. THINKSTOCK. Software architecture class diagram. Disponível em:http://www.thinkstockphotos.com/image/stock-photo-software -architecture- class- diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28, 34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,62 3,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696, 344,629,614,647/f=PIHVX/s=DynamicRankAcesso em: nov. 2012. THINKSTOCK. Software engineering word cloud. 2012. Disponível em: SUGESTÕES DE LEITURA BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. Rio de Janeiro: Elsevier, 2007. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The unified modeling language: user guide. Massachussets: Longman, 2000.
  58. 58. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2006. GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec, 2008. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James.The unified software development process. New York: Addison-Wesley, 2000. LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2007. MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2: do conceitual à implementação. Rio de Janeiro: Brasport, 2010. PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004. RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1994. TECNOLOGIAS PARA APLICAÇÕES WEB WEB AULA 1 Unidade 2 – Análise de Sistemas 4. Atividade: Análise A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma visão lógica do negócio e independente de tecnologias de desenvolvimento. As técnicas de modelagem propostas pela UML não estão vinculadas, diretamente, a uma atividade (Análise, Projeto, Implementação e Testes) do processo de desenvolvimento de software e não dizem quem deve fazer o quê, quando e como. Alguns autores como Ernani Medeiros (2010) e Bezerra (2007) sugerem a adoção do Diagrama e Documentação de Casos de Uso, do Diagrama de Classes, do Diagrama de Objetos e do Diagrama de Estruturas Compostas para modelar a atividade de Análise e, posteriormente, fazer um refinamento dessas técnicas e complementar com os diagramas de iteração para modelar a atividade de Projeto, representando uma visão física de desenvolvimento. Para mais informações sobre a UML acesse o catálogo da OMG: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML Na UML, os agrupamentos que organizam um modelo (conjunto de diagramas) são chamados de pacotes. O Diagrama de Pacotes tem por objetivo representar os subsistemas ou submódulos englobados por um sistema de forma a determinar as partes que o compõem. Demonstra como os elementos estão organizados nos
  59. 59. pacotes e as dependências que existem entre os elementos e os próprios pacotes (GUEDES, 2008). A notação do Diagrama de Pacotes contempla a representação dos pacotes e da dependência entre os pacotes. Pacotes são utilizados para agrupar elementos, para modelar subsistemas e para a modelagem de subdivisões da arquitetura de uma linguagem. Um Pacote pode se subdividir em outros pacotes. O nome do Pacote deve ser representativo e único. Um relacionamento de Dependência representa as dependências entre os pacotes, indicando que o elemento necessita, de alguma forma, do elemento do qual depende. A Figura 8 exemplifica um Diagrama de Pacotes. Figura 8 – Exemplo de Diagrama de Pacotes: Fonte: Do autor (2012). 1 4.1 Diagrama de Casos de Uso Para melhorar a compreensão do domínio e garantir que um sistema atenda às reais necessidades dos usuários, o Diagrama de Casos de Uso auxilia a fase de Análise de Requisitos, ajudando a especificar, visualizar e documentar as características e serviços do sistema. Na fase de Análise, o Diagrama de Casos de Uso representa um refinamento dos requisitos funcionais do sistema. A técnica de modelagem de casos de uso foi idealizada por Ivar Jacobson, na década de 1970. Segundo Bezerra (2007), o Modelo de Casos de Uso (MCU) é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele. O MCU é um modelo de análise que representa um refinamento dos requisitos funcionais do sistema em desenvolvimento. Segundo Guedes (2008), o Diagrama de Casos de Uso demonstra o comportamento externo do sistema, procurando apresentar o sistema por meio de uma perspectiva do usuário, demonstrando as funções e serviços (casos de uso) oferecidos e quais usuários (atores) poderão utilizar cada serviço. Para Booch; Jacobson e Rumbaugh (2006), o Diagrama de Casos de Uso representa os aspectos dinâmicos do sistema, tendo um papel central para a modelagem do comportamento de um sistema, de um
  60. 60. subsistema ou de uma classe. Cada um mostra um conjunto de casos de uso e atores e seus relacionamentos. O Diagrama de Casos de Uso representa as funcionalidades do sistema e os elementos externos ao sistema que interagem com ele. É o diagrama mais abstrato, flexível e informal da UML, sendo utilizado no início da modelagem do sistema, na atividade de análise, embora venha a ser consultado e, possivelmente, modificado durante todo o processo de engenharia do software. Apresenta uma linguagem simples e de fácil compreensão para que os usuários possam ter uma ideia geral de como o sistema irá se comportar, sendo um modelo com uma perspectiva externa do sistema. Um Diagrama de Casos de Uso é representado pelos elementos. Atores, Casos de Uso eRelacionamentos. Um Diagrama de Casos de Uso deve ser feito com base na especificação da fronteira do sistema, permitindo identificar um subsistema ou o sistema completo, assim delimitando o contexto do sistema. Atores: os Atores representam os papéis desempenhados pelos diversos usuários que poderão utilizar ou interagir com os serviços (funcionalidades) do sistema, ou seja, é qualquer elemento externo ao sistema que interage com ele. A interação significa que um Ator troca informações com o sistema, enviando dados para o sistema processar ou recebendo informações processadas. Normalmente, o Ator inicia a interação com o sistema. Eventualmente um Ator pode representar algum hardware especial ou mesmo um outro software que interaja com o sistema. Assim, um ator pode ser qualquer elemento externo que interaja com osoftware (GUEDES, 2008). Os Atores são representados por símbolos de “bonecos magros”, contendo uma breve descrição logo abaixo do seu símbolo que identifica qual o papel que o Ator assume dentro do diagrama. Cada ator deve representar um único papel. A Figura 9 ilustra a notação de Ator e a Figura 9 ilustra o exemplo de alguns Atores. Figura 9 – Exemplo de Atores. Fonte: Do autor (2012). Casos de Uso: um Caso de Uso (use case) representa qualquer interação de serviços entre um Ator e o sistema, sem revelar a estrutura e o comportamento interno do sistema. Cada serviço deve ser representado, individualmente, como um Caso de Uso. A Figura 10 ilustra o exemplo de alguns Casos de Uso. Os Casos de Uso referem-se aos serviços, tarefas ou funções oferecidas pelo sistema. São utilizados para expressar e documentar os comportamentos pretendidos para as funções do sistema (GUEDES, 2008). 2 Os Casos de Uso são documentados, demonstrando o comportamento pretendido para o Caso de Uso e quais funções ele executará quando for solicitado. Os Casos de
  61. 61. Uso são representados por uma elipse, contendo uma breve descrição dentro do seu símbolo que identifica qual serviço o Caso de Uso assume. Recomenda-se nomear um Caso de Uso com verbo no infinitivo mais substantivo(s). Exemplo: Cadastrar Curso ou Manter Curso, Realizar Avaliação, Lançar Nota de Avaliação. Figura 10 – Exemplo de Casos de Uso. Fonte: Do autor (2012). Relacionamentos: a interação entre um Ator e um Caso de Uso é representada por um relacionamento. Os relacionamentos possíveis são: associação, generalização, extensão e inclusão. Associação: é um tipo de relacionamento entre os Atores que interagem com o sistema, entre os Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Uma associação entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se, de alguma maneira, da função representada pelo Caso de Uso (GUEDES, 2011). Uma Associação é representada por uma reta, ligando o Ator ao Caso de Uso, podendo indicar a Navegabilidade da Associação, que indica se as informações são fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator ou ambos (não indica a navegabilidade). Uma Associação pode possuiruma descrição própria ou um nome, quando há necessidade de esclarecer alguma informação que está sendo transmitida. A Figura 11 ilustra a notação de Associações e a Figura 12 ilustra o exemplo de associações entre os Atores e Casos de Uso. No relacionamento de Associação entre um Ator e Caso de Uso pode-se indicar a multiplicidade, o qual especifica o número de vezes que um Ator pode utilizar um determinado Caso de Uso. Figura 11 – Notação de Associação. Fonte: Do autor (2012). Figura 12 – Exemplo de Associação entre Atores e Casos de Uso.
  62. 62. Fonte: Do autor (2012). 3 Generalização é um tipo de relacionamento entre Casos de Uso ou entre Atores. A Generalização de Atores é uma representação abstrata de papéis e a Generalização de Casos de Uso representa dois ou mais Casos de Uso que apresentam características semelhantes. Representa-se um Caso de Uso Geral (Generalização), que descreve as características compartilhadas por todos os Casos de Uso Especializados (Especialização). A estrutura do Caso de Uso Geral é herdada pelos Casos de Usos Especializados. A Figura 13 ilustra o exemplo de Generalização de Atores e Casos de Uso. Figura 13 – Exemplo de Generalização entre Atores e Casos de Uso. Fonte: Do autor (2012). A Extensão representa um relacionamento estendido entre Casos de Uso, indicando que o Caso de Uso “base” incorpora implicitamente o comportamento de outro Caso de Uso em um local especificado pelo Caso de Uso “estendido”. Um relacionamento
  63. 63. estendido é utilizado para a modelagem da parte de um Caso de Uso que o usuário poderá considerar como um comportamento opcional do sistema ou de um subfluxo separado, que é executado somente sob determinada condição. O relacionamento de dependência <<extend>> é representado por uma seta que parte do Caso de Uso “estendido” para o Caso de Uso “base”. A Figura 14 ilustra um exemplo de Extensão entre os Casos de Uso. Às vezes, não está claro qual é a condição para que um Caso de Uso estendido seja executado, assim, pode-se acrescentar uma Restrição. Restrições são representadas por uma nota explicativa, contendo o texto que determina a condição entre chaves. Figura 14 – Exemplo do Relacionamento de Extensão. Fonte: Do autor (2012). O relacionamento de Inclusão representa um relacionamento de dependência entre Casos de Uso, indicado pelo estereótipo <<include>>. Esse relacionamento é utilizado quando existe uma situação ou rotina comum a mais de um Caso de Uso. A inclusão indica uma obrigatoriedade com outro Caso de Uso, sendo que a execução do primeiro obriga também a execução do segundo. Um relacionamento de Inclusão pode ser comparado à chamada de uma sub-rotina. O relacionamento de dependência <<include>> é representado por uma seta que parte do Caso de Uso “base” para o Caso de Uso “incluído”. A Figura 15 ilustra um exemplo de Inclusão entre os Casos de Uso. Figura 15 – Exemplo do Relacionamento de Inclusão. Fonte: Do autor (2012).
  64. 64. Para mais informações sobre Use Cases acesse: http://www.ivarjacobson.com/resource.aspx?id=1282 4 Após a criação do Diagrama de Casos de Uso, complementam-se os Casos de Uso com uma documentação. O formato de documentação de um Caso de Uso é flexível, permitindo que se documente o Caso de Uso da forma que se considerar melhor, até mesmo pelo uso de pseudocódigo ou de código de uma linguagem de programação. O formato usual é em cenários – principal e alternativos. Para continuar aprendendo sobre Documentação de Casos de Uso, acesse os links: http://books.google.com/books?isbn=8574524441 http://books.google.com/books?isbn=8574522546 VÍDEO 2 00:00 00:00 4.2 Diagrama de Classes Considerando que o Diagrama de Casos de Uso está concluído, a próxima etapa é analisar os Casos de Uso para iniciar o trabalho de identificação das classes de objetos, o qual se faz necessário compreender como o sistema está estruturado internamente para que as funcionalidades sejam executadas. As classes de objetos muitas vezes podem ser identificadas, também, como substantivos nas descrições do domínio do problema. A partir da elaboração de um primeiro estágio do Diagrama de Classes, o mesmo evoluirá à medida que o sistema é desenvolvido, o qual o diagrama deve ser incrementado com novos detalhes, assim tendo novos estágios refinados do Diagrama de Classes. O Diagrama de Classes representa a modelagem da parte estática do sistema, representando um conjunto de Classes com seus atributos, operações e relacionamentos. O objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas pelo sistema e como estas se relacionam. Esse diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-se em definir sua estrutura lógica (GUEDES, 2008). O Diagrama de Classes é a principal técnica de modelagem da UML, assim vamos explorar nesta seção os principais componentes do Diagrama de Classes, tratando-o como um diagrama da atividade Análise. Posteriormente, recomendo evoluir o Diagrama de Classes em várias visões até obter um grau de refinamento com
  65. 65. detalhes de implementação, sendo considerado um Diagrama de Classes da atividade Projeto. A seguir apresentamos os principais elementos do Diagrama de Classes. Classe: uma Classe é representada por um retângulo com, no máximo, três partes. Na primeira parte (de cima para baixo) é exibido o nome da Classe. Por convenção, o nome é apresentado no singular e com as palavras compostas começando por letra maiúscula. Na segunda parte são declarados os atributos que correspondem aos dados que um objeto armazena. Para cada atributo está associado um valor que esse atributo pode assumir. E na terceira parte, são declaradas as operações que correspondem às ações que um objeto sabe realizar, sendo que os objetos de uma classe compartilham as mesmas operações. O nome de um atributo é declarado por um substantivo ou expressão que representa alguma propriedade da classe, tipicamente, em letra minúscula e, para palavras compostas, usa-se concatená-las, sendo que a partir da segunda palavra inicia-se com letra maiúscula, por exemplo,dataNascimento. O nome de uma operação é declarado por um verbo ou uma locução verbal breve, usando a mesma convenção de letras minúsculas e maiúsculas dos atributos. A Figura 16 ilustra a notação de Classe e a Figura 17 ilustra alguns exemplos de representação de Classes. Figura 16 – Notação de Classe. Fonte: Do autor (2012). Figura 17 – Exemplos de Classes com Notações Diferentes. Fonte: Do autor (2012). 5 Relacionamentos: na UML, os modos pelos quais os itens podem estar conectados a outros, isto é, logicamente ou fisicamente, são modelados como relacionamentos,
  66. 66. que permitem compartilhar informações e colaboram para a execução dos processos pelo sistema (GUEDES, 2008). Existem 4 tipos de relacionamentos: a) Associações: são relacionamentos estruturais entre instâncias. Tipos de associações: Unária (autoassociação ou reflexiva), binária, ternária, classe associativa e agregação. b) Generalizações: conectam classes generalizadas a outras mais especializadas, o que é conhecido como relacionamento Generalização e Especialização; c) Dependências: são relacionamentos de utilização entre casos de uso, classes, pacotes e anotações; d) Realizações: são relacionamentos que especificam um contrato de execução entre classes e interfaces. O relacionamento do tipo Associação é representado por uma reta, ligando as classes envolvidas, podendo também possuir setas em suas extremidades para indicar a navegabilidade da associação, o que representa o sentido em que as informações são transmitidas entre os objetos das classes envolvidas. As Associações podem também possuirnomes (títulos). A Figura 18 ilustra a notação de Associação. Figura 18 – Notação de Associação Fonte: Do autor (2012). O atributo a ser transmitido na Associação é um atributo implícito, não sendo apresentado na classe para a qual foi transmitido. Em cada extremidade da associação deve ser definida a multiplicidade da associação. A multiplicidade procura determinar o número mínimo e máximo de objetos envolvidos em cada extremidade da Associação, especificando quantas instâncias de uma classe relacionam-se a uma única instância de uma classe associada. A multiplicidade depende de pressupostos e de como são definidas as fronteiras de um problema, conforme as regras de negócio. O quadro a seguir ilustra os tipos de multiplicidade. Quadro 1 – Tipos de Multiplicidades. Multiplicidade Significado 0..1 No mínimo zero (nenhum e no máximo um). Indica que os obje classes associadas não precisam obrigatoriamente estar relacio se houver relacionamento indica que apenas uma instância da relaciona com as instâncias da outra classe. 1..1 Um e somente um. Indica que apenas um objeto da classe se r com os objetos de outra classe.
  67. 67. 0..* No mínimo nenhum e no máximo muitos. Indica que pode ou n instâncias da classe participando do relacionamento. * Muitos. Indica que muitos objetos da classe estão envolvidos n relacionamento. 1..* No mínimo 1 e no máximo muitos. Indica que há pelo menos u envolvido no relacionamento, podendo haver muitos objetos en Intervalo específico Define-se um intervalo inicial e final, indicando que existem pe um número específico inicial de instância envolvidas no relacion com um número limite de instâncias. Fonte: Do autor (2012). 6 A Associação Unária ou Reflexiva ocorre quando existe um relacionamento de um objeto de uma classe com objetos da mesma classe. Cada objeto tem um papel distinto nessa associação. A associação reflexiva é representada por uma linha, iniciando e terminando na mesma classe. A Figura 19 ilustra um exemplo de Associação Unária. Figura 19 – Notação e Exemplo de Associação Unária. Fonte: Do autor (2012). A Associação Binária ocorre quando são identificados relacionamentos entre objetos de duas classes.A existência de uma associação entre dois objetos possibilita a troca de mensagens entre eles. Uma associação é representada por uma linha reta, ligando as classes às quais pertencem os objetos relacionados. A Figura 20 ilustra um exemplo de Associação Binária. Figura 20 – Notação e Exemplo de Associação Binária. Fonte: Do autor (2012). A Associação Ternária ou N-ária ocorre quando conectam objetos de mais de duas classes, ou seja, uma associação pode ter grau maior que dois. São representadas por um losango para onde convergem todas as ligações da Associação. A Figura 21 ilustra um exemplo de Associação Ternária. Figura 21 – Notação e Exemplo de Associação Ternária.

×