Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Transcrição

1 Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

2 Cronograma das Aulas. Hoje você está na aula Semana Tema 01 Apresentação da disciplina. O conceito e os objetivos da gerência de projetos 02 Escopo do projeto 03 Escopo do projeto 04 Metodologias, técnicas e ferramentas da gerência de projetos 05 Metodologias, técnicas e ferramentas da gerência de projetos 06 Engenharia de software. Conceitos básicos 07 Processo de software 08 Processo de software 09 Atividades de Avaliação 10 Processo de software 11 Processos de engenharia de requisitos 12 Processos de engenharia de requisitos 13 Modelos de sistemas 14 Prototipação de software 15 Projeto e arquitetura de software 16 Projeto de interface com o usuário 17 Projeto de interface com o usuário 18 Prova escrita oficial 19 Revisão 20 Prova substitutiva 2

3 Aula 16 e 17 Projeto de Interface com o Usuário Conteúdo: Referências para a aula: No seu PLT, essa aula está localizada/baseada no conteúdo do capítulo 7. Bibliografia complementar 3

4 Tópicos de estudo Projeto orientado a objetos com UML Padrões de projeto Questões de implementação Desenvolvimento open source 4

5 Projeto e implementação O projeto e implementação de software é o estágio no processo de engenharia de software no qual um sistema de software executável é desenvolvido. As atividades de projeto e implementação de software são invariavelmente intercaladas. O projeto de software é uma atividade criativa na qual você identifica os componentes de software e seus relacionamentos baseando-se nos requisitos do cliente. Aimplementaçãoéoprocessoderealizaçãodoprojetoemumprograma. 5

6 Construir ou comprar Nas mais variadas áreas, já é possível comprar sistemas de prateleira (COTS Commercial Off-The-Shelf) que podem ser adaptados aos requisitos dos usuários. Por exemplo, se você quer implementar um sistema de prontuário médico, você podecomprarumpacotequejáéusadoemhospitais.podesermaisbaratoemais rápido usar essa abordagem ao invés de desenvolver um sistema em uma linguagem de programa convencional. Quando você desenvolve uma aplicação dessa forma, o processo de projeto passa a se preocupar em como usar os recursos de configuração deste sistema para cumprir os requisitos desse. 6

7 O processo de projeto orientado a objetos Os processos de projeto orientados a objetos envolvem o desenvolvimento de vários modelos diferentes de sistema. Eles precisam de muito esforço no desenvolvimento e na manutenção desses modelos e, para sistemas pequenos, talvez não tenham um bom custo-benefício. No entanto, para sistemas de grande porte, desenvolvidos por diferentes grupos, os modelos de projeto são um importante mecanismo de comunicação. 7

8 Estágios do processo Existe uma grande variedade de diferentes processos de projeto orientados a objetos, essa escolha dependerá da organização que está usando o processo. As atividades comuns nesses processos incluem: A definição do contexto e interações do sistema; O projeto de arquitetura do sistema; A identificação dos principais objetos de classe do sistema; O desenvolvimento dos modelos de projeto; As especificações de interface de objetos. O processo ilustrado, usa um projeto para uma estação meteorológica no deserto. 8

9 Contexto e interações de sistema Entender os relacionamentos entre o software que está sendo desenvolvido e seu ambiente externo é essencial na decisão de como prover a funcionalidade requerida parao sistemaecomoestruturarosistemaparasecomunicarcomseuambiente. Entender o contexto também lhe permite estabelecer os limites do sistema. Estabelecer os limites do sistema ajuda a decidir quais recursos serão implementados no sistema que está sendo desenvolvido e quais serão implementados em outros sistemas associados. 9

10 Modelos de contexto e de interação Um modelo de contexto de sistema é um modelo estrutural que mostra outros sistemas no ambiente do sistema que está sendo desenvolvido. Um modelo de interação é um modelo dinâmico que mostra como o sistema interage comseuambiente,duranteoseuuso. 10

11 Contexto de sistema estação meteorológica 11

12 Caso de Uso Estação Meteorológica 12

13 Identificação das classes e objetos Geralmente, a identificação das classes de objetos é uma parte difícil do projeto orientado a objetos. Não existe uma fórmula mágica para a identificação dos objetos. Isso depende do conhecimento, da experiência e habilidade dos projetistas de sistema. A identificação de objetos é um processo iterativo. Você provavelmente não conseguirá acertá-lo na primeira tentativa. 13

14 Abordagens de identificação Use uma abordagem gramatical baseada em uma descrição em linguagem natural do sistema(usada no método Hood de projeto orientado a objetos, Hood OOD). Baseie a identificação em entidades tangíveis no domínio da aplicação. Use uma abordagem comportamental e identifique os objetos baseando-se em o quê participa de qual comportamento. Use uma análise baseada em cenários. Os objetos, atributos e métodos em cada cenário são identificados. 14

15 Exemplos de classes 15

16 Modelos de Projetos Os modelos de projeto mostram os objetos e classes de objeto, e os relacionamentos entre essas entidades. Os modelos estáticos descrevem a estrutura estática do sistema nos termos das classes de objetos e suas relações. Os modelos dinâmicos descrevem as interações dinâmicas entre os objetos. 16

17 Modelos de sequência Os modelos de sequência mostram a sequência das interações dos objetos que ocorrem. Os objetos são organizados horizontalmente no topo; O tempo é representado verticalmente para que os modelos sejam lidos de cima para baixo; As interações são representadas por setas com rótulos. Diferentes estilos de setas representam diferentes tipos de interação; Umretângulofinona linha devidadeum objetorepresentaomomentoemque o objeto é o objeto controlador do sistema. 17

18 Exemplo diagrama de sequência 18

19 Diagrama de estado O diagrama de estado é usado para mostrar como os objetos respondem a diferentes pedidos de serviços e as transições de estado acionadas por esses pedidos. Os diagramas de estado são modelos úteis, de alto nível, de um sistema, ou do comportamento de um objeto em execução. Geralmente não é necessário um diagrama de estado para todos os objetos do sistema. Vários dos objetos em um sistema são relativamente simples e um modelo de estado adiciona detalhes desnecessários ao projeto. 19

20 Exemplo diagrama de estado 20

21 Especificações de Interface As interfaces de objeto precisam ser especificadas para que se possa fazer paralelamente o projeto dos objetos e de outros componentes. Os projetistas devem evitar projetar a representação da interface, devem escondê-la no próprio objeto. Os objetos podem ter várias interfaces, as quais são pontos de vista dos métodos oferecidos. A UML usa diagramas de classes para a especificação da interface, mas a linguagem Java também pode ser usada. 21

22 Modelos de especificações de interface 22

23 Pontos importantes O projeto e a implementação de softwares são atividades intercaladas. Onívelde detalhamentonoprojetodependedotipode sistema,eseestásendousada uma abordagem orientada a planos ou ágil. O processo de projeto orientado a objetos inclui atividades para projetar da arquitetura de sistema, identificar os objetos no sistema, descrever o projeto usando diferentes modelos de objetos e documentar as interfaces de componentes. 23

24 Pontos importantes Uma série de diferentes modelos pode ser produzida durante um processo de projeto orientado a objetos. Inclusive os modelos estáticos (modelos de classes, modelos de generalização, modelos de associação) e os modelos dinâmicos(modelos de sequência, modelos de máquina de estados). As interfaces de componentes devem ser definidas com exatidão para que os outros objetos possam usá-las. Um estereótipo de interface da UML pode ser usado para definir as interfaces. 24

25 Padrões de projeto Um padrão de projeto é uma forma de reusar conhecimento abstrato sobre um problema e sua solução. Umpadrãoéumadescriçãodoproblemaeaessênciadasuasolução. Esse precisa ser abstrato o suficiente para ser reusado em configurações diferentes. Geralmente, as descrições do padrão fazem uso de características orientadas a objetos, como herança e polimorfismo. 25

26 Elementos do padrão Nome Um identificador significativo do padrão. Descrição do problema Descrição da solução Não um projeto concreto mas um template, uma solução de projeto que pode ser instanciada de diferentes maneiras. Consequências Os resultados e os compromissos da aplicação desse padrão. 26

27 O padrão Observer Nome Observer. Descrição Separaoestadododisplaydoestadodoobjetodopróprioobjeto. Descrição do problema Usada quando vários displays de estado são necessárias. Descrição da solução VerslidecomdescriçãoemUML. Consequências Otimizações para melhorias do desempenho do display são impraticáveis. 27

28 O padrão Observer 28

29 Ferramentas de plataforma de desenvolvimento Um compilador integrado é um sistema de edição orientado a sintaxe, que permita a criação, edição e compilação de códigos. Um sistema de depuração de linguagem. Ferramentas de edição gráfica, como por exemplo ferramentas para edição de modelos da UML. Ferramentas de teste, como o Junit, que podem executar, automaticamente, um conjuntodetestesemumanovaversãodeumprograma. Ferramentas de apoio a projetos que podem auxiliar na organização do código para diferentes projetos de desenvolvimento. 29

30 Ambientes de Desenvolvimento Integrado (IDE) Geralmente, as ferramentas de desenvolvimento de software são agrupadas para criarem um ambiente de desenvolvimento integrado (IDE Integrated Development Environment). Um IDE é um conjunto de ferramentas de software que dá apoio a diferentes aspectos do desenvolvimento de software em um framework comum e em uma interface de usuário. Os IDEs são criados para dar apoio ao desenvolvimento em linguagens de programação específicas como o Java. O IDE da linguagem pode ser desenvolvido especialmente, ou pode ser uma instância deumidedeusogeralcomferramentasdeapoioaumalinguagemespecífica. 30

31 Fatores de implantação de componentes / sistemas Se um componente for destinado a uma arquitetura de hardware específica ou se depender de outros sistemas de software, obviamente, esse precisa ser implantado em uma plataforma que forneça suporte ao hardware e software necessários. Os sistemas de alta disponibilidade podem necessitar que os componentes sejam implantados em mais de uma plataforma. O que significa que, no evento de falha de uma plataforma, uma implementação alternativa do componente estará disponível. No caso de alto nível de tráfego de comunicação entre os componentes, geralmente, faz sentido implantá-los na mesma plataforma ou em plataformas fisicamente próximas.oquereduzoatrasoentreoenviodeumamensagemporumcomponentee a recepção pelo outro. 31

32 Desenvolvimento open source O desenvolvimento open source é uma abordagem de desenvolvimento de software na qual o código fonte de um sistema de software é publicado e os voluntários são convidados a participar no processo de desenvolvimento. Suas raízes estão no Free Software Foundation ( que advoga que o código fonte não deveria ser proprietário, mas, deveria estar sempre disponível para que os usuários possam examiná-lo e modificá-lo como quiserem. O software open source estendeu essa ideia usando-se a Internet para recrutar uma população muito maior de desenvolvedores voluntários. Vários deles também são usuários do código. 32

33 Sistemas open source O produto open source mais conhecido é, sem dúvida, o sistema operacional Linux, o qual é amplamente usado como sistema servidor e cada vez mais, como um ambiente desktop. Outros importantes produtos open source são o Java, o Apache web server e o sistema de gerenciamento de banco de dados mysql. 33

34 Negócios open source Cada vez mais, empresas estão usando uma abordagem open source para o desenvolvimento. Seu modelo de negócios não é bom na venda de um produto de software, mas são bons no fornecimento de suporte para esse produto. Acreditam que envolver a comunidade open source permitirá o desenvolvimento mais barato e mais rápido de softwares, e criará uma comunidade de usuários para o software. 34

35 Licenciamento open source Um princípio fundamental do desenvolvimento open source é que o código fonte deve ser disponibilizado gratuitamente, o que não significa que qualquer um possa fazer o quequisercomocódigo. Legalmente, o desenvolvedor do código (tanto uma empresa, quanto um indivíduo) ainda é o proprietário do código. Ele pode colocar restrições em como esse deve ser usado, incluindo condições vinculadas legalmente, em uma licença de software open source. Alguns desenvolvedores open source acreditam que se um componente open source é usado para desenvolver um novo sistema, esse sistema também deve ser open source. Outros querem permitir que seu código seja usado sem essa restrição. Os sistemas desenvolvidos podem ser proprietários e vendidos como sistemas de código fechado. 35

36 Avaliações de Design e Interface Que fatores podem ser considerados ao avaliar a funcionalidade e usabilidade de um determinado produto? Como qualificá-lo como sendo bom ou não? Esse tema vem se tornando objeto de estudo de vários profissionais de várias áreas, como desenvolvedores, projetistas, analistas de sistemas e de design, além de profissionais de IHC (Interação Humana Computador). 36

37 Princípios de desing de interação Design de interação pode ser definido como um conjunto de soluções que tem como objetivo facilitar a forma como as pessoas trabalham, se comunicam e interagem. A aplicação de princípios de design em um software visa tornar o ambiente de trabalho mais funcional, objetivo e com isso, mais simples. 37

38 Diferença entre design de interação e engenharia software A diferença entre design e engenharia de software pode ser melhor compreendida com essa simples comparação. O design está interessado em tornar o ambiente do software agradável, de forma que o usuário se sinta bem ao utilizá-lo, não encontre grandes obstáculos e que os recursos estejam sempre a sua disposição de maneira clara e simples. Já os engenheiros de softwares estão preocupados com a estrutura interna do software e seus processos correlatos, como qual linguagem será usada, padrões de aplicativos, dentre outros quesitos. 38

39 Uma visão mais abrangente do design de interação A correta aplicação dos princípios de design de interação, somente poderão ser satisfatórios se correlacionados a outras áreas do conhecimento humano, tais como: Psicologia, Informática, Engenharia, Ciência da Computação, Fatores Humanos, Engenharia Cognitiva, Interação Homem Computador (IHC), Ergonomia Cognitiva, Sistemas de Informação e Designers. O ser humano possui uma capacidade nata para entender, aprender e se adaptar, contudo, nos sistemas onde isso ocorra de forma natural, esse processo é bem mais simples. A palavra sistemas nesse contexto não deve ser somente entendida como um sistema computacional mas sim, numa aplicação mais ampla dentro dos sistemas humanos. 39

40 Fatores que envolvem o design de interação Existem alguns fatores que devem ser considerados no processo de design de interação, tais como: - Identificar os requisitos do sistema a ser desenvolvido sendo essa atividade, básica e primordial em qualquer situação, além de constituir a fase inicial de qualquer processo. No livro Design e avaliação de interfaces humano-computador, as autoras Heloísa V. da Rocha e Maria C.C. Baranauskas (2000, p.31), fazem o seguinte comentário: [...] conhecer o usuário é fundamental para se fazer o design de um sistema usável. 40

41 Fatores que envolvem o design de interação Com base nos requisitos acima levantados, elaborar designs alternativos de forma que satisfaçam completamente as especificações do sistema; Elaborar versões interativas dos designs, de forma que possam se comunicar e também que sejam analisadas. Avaliação constante durante todo o processo de desenvolvimento daquilo que está sendo produzido, pois é somente dessa forma que poderemos dizer que o produto é usável. Essa avaliação pode ocorrer de várias formas, como conversas com os usuários, testes da interface e desempenho e até mesmo questionários. 41

42 Usabilidade A usabilidade de um software pode ser entendida como sendo o esforço necessário e realizado pelo usuário para conseguir utilizar o sistema e também como as técnicas usadas no sentido de facilitar a interação do usuário com o sistema através da interface do software. 42

43 Usabilidade Alguns indicadores podem dar uma boa visão sobre a usabilidade de um software. Um software pode ser classificado como sendo de boa usabilidade quando os seus usuários aprendem a utilizá-lo com facilidade (learnability), quando se lembram facilmente de tarefas anteriormente já realizadas (memorability), ou quando conseguem associar padrões entre as diversas telas de um mesmo sistema, através da ordem de disposição dos itens, rapidez no desenvolvimento de tarefas, o que leva a conclusão lógica de que a manipulação do software é bastante fácil e que por sua vez, essa facilidade eleve a produtividade do usuário (eficiência), e também, quando a taxa de erros durante a utilização do produto for baixa (erros). 43

44 Princípios de usabilidade e design Existem alguns padrões de princípios, tais como: visibilidade, feedback, restrições, mapeamento, consistência e affordance. Visibilidade: consiste em deixar disponível ao usuário um determinado objeto até que este seja necessário. Também é importante que haja um relacionamento entre o objeto e a ação que ele desempenha, pois isso facilita o entendimento de como os processos ocorrem. Feedback: o feedback está também relacionado ao princípio da visibilidade e diz respeito ao retorno fornecido pelo sistema a uma determinada ação executada. Existem vários exemplos para essa situação, como por exemplo, o click do mouse, que ao ser pressionado produz o efeito sonoro do click. Com isso, temos certeza de que a ação foi efetuada. 44

45 Restrições: estas podem ser entendidas como uma forma de inibir possíveis erros durante a realização de uma tarefa. Exemplos comuns de restrições são encontrados em menus de programas, onde quando uma tarefa não puder ser executada naquele momento, a opção que a usuário. executa estará inacessível ao Mapeamento: o mapeamento está relacionado entre o controle e o efeito que este produzirá no mundo real. Exemplos de mapeamentos também são encontrados nos mais variados locais, sendo um deles o controle de um vídeo game. 45

46 Consistência: o conceito de consistência está relacionado à disposição coerente dos objetos na tela, procurando manter sempre um mesmo padrão na realização de operações semelhantes. Affordance: refere-se a forma como um determinado objeto deverá ser utilizado através das suas propriedades, de forma intuitiva, ou seja, o simples fato de observar o objeto já fornece uma indicação de como se deve usá-lo. 46

47 Heurística e princípios de usabilidade O termo Avaliação Heurística, é utilizado quando há uma inspeção de interface, realizada por um especialista, utilizando os princípios de usabilidade. Visibilidade do status do sistema: o sistema emite ao usuário um feedback do que está acontecendo, dentro de um tempo razoável. Compatibilidade do sistema com o mundo real: o sistema deve interagir com o usuário de uma forma simples, usando uma linguagem mais próxima do mundo real. Controle do usuário e liberdade: fornecer ao usuário saídas de emergência de lugares e/ou situações indesejadas ou inesperadas, como escolher uma função por engano ou errar uma operação. 47

48 Consistência e padrões: manter um padrão no acesso às funções e na maneira como essas funções são descritas e indicadas, sem que o usuário fique em dúvida quanto a isso. Prevenção de erros: sempre que for possível, evitar que um erro ocorra. Reconhecimento ao invés de memorização: objetos, instruções, ações e opções devem estar visíveis ao usuário, sem que ele tenha que guardar o caminho toda a vez que quiser acessar uma opção do sistema. Flexibilidade e eficiência no uso: permitir aos usuários iniciantes a possibilidade de aumentar, com o tempo de uso, sua velocidade na interação com o sistema, ao mesmo tempo permitindo aos usuários experientes realizar tarefas com mais rapidez. 48

49 Estética e design minimalista: evitar em diálogos o uso de informações irrelevantes ou raramente necessárias, pois elas concorreriam com as informações realmente importantes ao usuário. Ajudar o usuário a reconhecer, diagnosticar e corrigir erros: mostrar erros ao usuário em uma linguagem clara e simples de ser interpretada, sugerindo, se possível, uma maneira de solucionar o problema. Help e documentação: informações dessa natureza devem ser de fácil localização, claras e objetivas, indicando soluções de maneira concreta. 49

50 Dúvidas? Perguntas? Angústias? Aflições? 50

51 Prof. André Luís Belini Blog: