Nesta unidade tem por objetivo conceituar e posicionar o papel do projeto de arquitetura dentro da engenharia de sistemas e tambm dicas

com relao aos critrios ergonmicos no desenvolvimento do projeto de interface de software e culminando debatendo a importncia de trabalharmos com a evoluo do software Web Aula 3 UNIDADE 2 GERENCIAMENTO DE QUALIDADE DE SOFTWARE PROJETO DE ARQUITETURA Sumrio: Dando continuidade a unidade I, iniciaremos abordando conceitos e caractersticas sobre projeto de arquitetura e, logo em seguida, veremos a importncia da evoluo do software dentro de um processo de engenharia de software. Por fim, trabalharemos alguns quesitos de ergonomia relacionados mais diretamente a criao do projeto de interface.

Caro aluno, nesta Web aula abordaremos assuntos relacionados ao tema Projeto de Arquitetura, na qual enfatizaremos a parde de projeto de arquitetura, arquitetura de sistemas distribudos e arqjuitetura de aplicaes. Alm disso, vamos explorar os seus conceitos, com algumas sugestes de leitura. Prof. Perini Projeto de Arquitetura O projeto de arquitetura preocupa-se com a compreenso, com a organizao de um sistema e com a sua estrutura geral. No modelo de processo de desenvolvimento de software, o projeto de arquitetura o primeiro estgio do processo de projeto. Ele o elo crtico entre o projeto e a engenharia de requisitos, uma vez que identifica os principais componentes estruturais de um sistema e os relacionamentos entre eles. O resultado do processo de projeto de arquitetura um modelo que descreve como o sistema esta organizado em um conjunto de componentes de comunicao.

Idealmente, uma especificao de sistema no deve incluir todas as informaes do projeto, porm esta realizada, exceto para projetos muito pequenos. A decomposio de arquitetura necessria, geralmente, para estruturar e organizar a especificao. Como parte da engenharia de requisitos, podemos propor uma arquitetura abstrata de sistema em que seja possvel associar grupos de funes ou recursos de sistemas aos componentes em larga escala ou subsistemas. Podemos projetar arquitetura de software em dois nveis: Pequena escala, na qual h a preocupao com a arquitetura de programas individuais e; Grande escala, em que nos preocupamos com a arquitetura de sistemas corporativos complexos que incluem outros sistemas, programas e componentes de programas. A arquitetura de software importante, pois afeta o desempenho e a robustez, bem como a capacidade e distribuio e manuteno de sistemas. Abaixo, podemos verificar trs vantagens em projetar e documentar a arquitetura de software: Comunicao de stakeholders Uma apresentao de alto nvel dos sistemas que pode ser usada como foco de discusso entre os stakeholders. Anlise de Sistemas Torna explicita a arquitetura de um sistema. Reuso em larga escala uma descrio compacta e gerencivel de como um sistema organizado e como os seus componentes interoperam, por isso pode apoiar o reuso de software em grande escala.

Decises de Projeto de Arquitetura

O projeto de arquitetura algo criativo, no qual projetamos uma organizao de sistema para satisfazer aos requisitos funcionais e no funcionais de um sistema. Durante o processo, os arquitetos do sistema precisam tomar uma srie de decises estruturais que afetam profundamente o sistema e seu processo de desenvolvimento. Com base em seus conhecimentos e experincia, os arquitetos de sistema precisam considerar as seguintes questes: Existe uma arquitetura genrica de aplicao que pode atuar como um modelo para o sistema projetado? Como o sistema ser distribudo? Que padres ou estilos de arquitetura podem ser usados? Qual ser a abordagem fundamental para se estruturar o sistema? Como os componentes estruturais do sistema sero decompostos em subcomponentes? Que estratgia ser usada para controlar o funcionamento dos componentes do sistema? Qual a melhor organizao de arquitetura para satisfazer os requisitos no funcionais do sistema? Como o projeto de arquitetura ser avaliado? Como a arquitetura do sistema deve ser documentada? A arquitetura de um sistema pode se basear em um documento padro ou estilo de arquitetura. Um padro de arquitetura uma descrio de uma organizao clienteservidor ou uma arquitetura em camadas. Devido estreita relao entre requisitos no funcionais e a arquitetura do software, o estilo e a arquitetura que voc escolhe para um sistema devem depender dos seguintes requisitos no funcionais se for um requisito crtico: Desempenho A arquitetura deve ser projetada para localizar as operaes crticas dentro de um pequeno nmero de componentes, com todos esses componentes implantados no mesmo computador, em vez de distribudos pela rede. Proteo Deve ser usada uma estrutura em camadas para a arquitetura com os ativos mais crticos protegidos nas camadas mais internas, com alto nvel de validao de proteo aplicado a essas camadas. Segurana

A arquitetura deve ser concebida de modo que as operaes relacionadas com a segurana estejam localizadas em um nico componente ou em um pequeno nmero de componentes. Disponibilidade A arquitetura deve ser projetada para incluir componentes redundantes, de modo que seja possvel substituir e atualizar componentes sem parar o sistema. Manuteno A arquitetura deve ser projetada a partir de componentes autocontidos de baixa granularidade que podem ser alterados rapidamente. Organizao de Sistema Reflete a estratgia usada para estruturar o sistema, sendo necessrio tomar decises sobre o modelo organizacional com antecedncia e no com o processo de projeto de arquitetura. Modelo Repositrio um modelo cujos subsistemas que constituem um sistema devem trocar informaes de modo que possam trabalhar juntos eficientemente. Isso pode ser feito da seguinte forma: 1. Todos os dados compartilhados so mantidos em um banco de dados que pode ser acessado por todos os subsistemas. 2. Cada subsistema mantm seu prprio banco de dados, onde os dados so trocados com outros subsistemas por meio da passagem de mensagens entre eles. A maioria dos sistemas que usam grande quantidades de dados organizada com base em um BD ou repositrio compartilhado. Este modelo adequado para aplicaes onde os dados so gerados por um subsistema e usado por outros. As vantagens e desvantagens deste modelo so: uma maneira eficiente de compartilhar grande quantidade de dados. Os sistemas devem estar de acordo com o modelo de dados repositrio. O desempenho pode ser afetado por esse compromisso e desta forma pode ser difcil ou impossvel integrar novos sistemas se os modelos de dados no se adequarem ao modelo estabelecido.

Os sistemas que produzem dados no precisam saber como esses dados so usados por outro subsistema. A evoluo pode ser difcil quando um grande volume de informaes gerado de acordo com o modelo estabelecido. As atividades tais como backup, proteo, controle de acesso e recuperao de erros so centralizadas, sendo de responsabilidade do gerenciador de repositrio. O modelo impe a mesma poltica a todos os subsistemas integrados neste modelo. O modelo de compartilhamento visvel por meio do esquema repositrio, onde novas ferramentas podem ser integradas, considerando que sejam compatveis com o modelo de dados estabelecido. Pode ser difcil distribuir o repositrio por uma srie de mquinas. Modelo Cliente-Servidor um modelo em que o sistema organizado como um conjunto de servios, servidores e clientes associados que acessam e usam estes servios. Os principais componentes desse modelo so:

Um conjunto de servidores que oferecem servios para outros sistemas, tais como servidores de impresso, servidores de arquivos, servidor de compiladores. Um conjunto de clientes que solicita os servios oferecidos pelos servidores. Uma rede que permita aos clientes acessarem esses servios. Na prtica, a maioria dos sistemas cliente-servidor implementada como sistemas distribudos. Os clientes talvez necessitem saber os nomes dos servidores disponveis e os servios que eles fornecem. No entanto, os servidores no precisam saber o nome dos clientes ou quantos deles existem. Os clientes acessam os servios fornecidos pelo servidor por meio de chamadas remotas de procedimento interno usando um protocolo usado na Web. Essencialmente um cliente faz um pedido a um servidor e espera at ter uma resposta. A vantagem mais importante deste modelo que ele uma arquitetura distribuda. O uso efetivo em rede pode ser feito com muitos processadores distribudos. fcil adicionar um novo servidor e fazer a integrao do mesmo com o restante do sistema ou atualizar servidores de forma transparente sem afetar outras partes do sistema. Modelo em Camadas O modelo em camadas, tambm chamado de modelo de mquina abstrata, organiza um sistema em camadas, cada uma das quais fornecendo um conjunto de servios, onde cada camada pode ser imaginada como uma mquina abstrata cuja

linguagem

de mquina definida pelos servios fornecidos pela camada. Um

exemplo de modelo em camadas o modelo OSI. A abordagem em camadas d suporte ao desenvolvimento incremental de sistemas. medida que uma camada desenvolvida, alguns servios fornecidos por essa camada podem ser disponibilizados para os usurios. Uma desvantagem desta abordagem em camadas que a estruturao de sistemas dessa maneira pode ser difcil de realizar. O desempenho tambm pode ser um problema devido aos vrios nveis de interpretao dos comandos algumas vezes exigidos. Caso tenha vrias camadas, um pedido de servio de uma camada

superior precisa ser interpretado vrias vezes em camadas diferentes antes de ser processado. Arquitetura de Sistemas Distribudos Praticamente todos os sistemas baseados em grandes computadores so, na atualidade, sistemas distribudos. Um sistema distribudo aquele em que as informaes em fase de processamento so distribudas por vrios computadores, em vez de ficarem confinadas em uma nica mquina. Como vantagem no uso de sistemas distribudos de sistemas podemos destacar: 1. Compartilhamento de Recursos Um sistema distribudo permite o compartilhamento de recursos de hardware e software, como discos, impressoras, arquivos e compiladores, que esto associados a diferentes computadores em uma rede. 2. Abertura Geralmente sistemas distribudos so sistemas abertos, pois so projetados com base em protocolos-padro que permitem a equipamentos e software de

fabricantes diferentes serem combinados. 3. Concorrncia

Vrios processos podem operar ao mesmo tempo em diferentes computadores na rede. 4. Escalabilidade Os sistemas distribudos so em princpio escalonveis de modo que as capacidades de um sistema possam ser ampliadas pela adio de novos recursos para atender s novas demandas do sistema 5. Tolerncia a defeitos A disponibilidade de vrios computadores e o potencial de duplicao de informaes significam que os sistemas distribudos podem ser tolerantes a algumas falhas de hardware e software. O grande desafio hoje projetar o software e o hardware para fornecer os recursos de sistemas distribudos desejveis e ao mesmo tempo minimizar os problemas inerentes destes sistemas. Podemos classificar dois tipos de arquiteturas de sistemas distribudos, arquitetura de cliente-servidor, onde pensamos no

sistema como um conjunto de servios fornecidos aos clientes que usam estes servios e arquitetura de objetos distribudos, o qual no faz distino entre cliente e servidor, considerando um conjunto de objetos que interagem e

cuja localizao torna-se irrelevante. Middleware um termo usado para nos referir a um software usado em sistemas distribudos para gerenciar modelos de dados, representao de informaes e protocolos de comunicao, assegurando a comunicao e a troca de dados. Arquitetura de Multiprocessadores O modelo mais simples de um sistema distribudo um multiprocessador, no qual o sistema de software consiste de uma srie de processos que podem, porm no precisam, ser executados em processadores separados, sendo muito comum em computadores de grande porte. O uso de vrios processadores aprimora o desempenho e a capacidade de recuperao do sistema. Sendo que a distribuio dos processos em processadores

pode ser predeterminada ou pode estar sob controle de um controlador que decide qual processo deve ser alocado em cada processador. A abordagem de projeto para este tipo de sistema essencialmente a de sistemas de tempo real. Arquitetura de Cliente-Servidor Neste tipo de arquitetura, uma aplicao modelada como um conjunto de servios pelos servidores e um conjunto de clientes que usam esses servios, em que os clientes precisam estar informados sobre os servidores disponveis, porm desconhecem a existncia de outros clientes. O projeto de sistemas cliente-servidor deve refletir a estrutura lgica da aplicao que est sendo desenvolvida. A camada de apresentao se encarrega da apresentao de informaes para o usurio e de toda a interao com ele; a camada de processamento de aplicao se encarrega da implementao lgica; e a camada de gerenciamento de dados se encarrega de todas as operaes de banco de dados. A arquitetura cliente-servidor mais simples chamada de arquitetura de duas camadas, na qual uma aplicao organizada como um servidor e um conjunto de clientes, na qual podem ter dois modelos: Cliente-magro, no qual todo o processamento da aplicao e o gerenciamento de dados so realizados no servidor, sendo o cliente responsvel apenas por executar o software de apresentao. Cliente-gordo, em que o servidor somente responsvel pelo gerenciamento de dados, no qual o software-cliente implementa a lgica da aplicao e as interaes com o usurio do sistema. A abordagem de cliente magro muito usada em sistemas legados centralizados que evoluem para uma arquitetura cliente-servidor. Uma desvantagem desta abordagem que ela impe uma grande carga de processamento sobre o servidor e a rede. O modelo cliente-gordo faz o uso dessa capacidade de processamento disponvel e distribui o processamento lgico de aplicao e apresentao ao cliente. Um exemplo deste tipo de arquitetura so os sistemas de caixas eletrnicos, cujo caixa

eletrnico o cliente e o servidor um computador que realiza operaes sobre o banco de dados de contas de cliente. Enquanto o modelo cliente-gordo distribui o processamento mais eficiente do que um modelo cliente-magro, o gerenciamento do sistema mais complexo, cuja funcionalidade da aplicao dividida entre vrios computadores. rquitetura de Aplicaes Sistemas de aplicaes so criados para atender algumas necessidades de negcio ou organizacionais, em que todos os negcios tem muito em comum (pois necessitam contratar pessoas, emitir faturas, administrar contas etc...), e isso especialmente verdadeiro em negcios que so do mesmo setor (tipo). Essas semelhanas levam ao desenvolvimento de arquiteturas de softwares que descrevem a estrutura e organizao dos diferentes tipos de sistemas de software. Arquiteturas de aplicao encapsulam as principais caractersticas de uma classe de sistemas, podendo ser reimplementada no desenvolvimento de novos sistemas, mas para sistemas de muitas empresas, o reuso de aplicaes possvel sem a reimplementao. Como um projetista de software voc pode usar arquiteturas genricas de diversas maneiras como: Um ponto de partida para o processo de projeto de arquitetura, que caso no esteja familiarizado com o tipo de aplicao , baseie seus projetos em arquiteturas genricas. Um checklist do projeto, ou seja, voc desenvolveu um projeto de arquitetura e agora pode checar se falta algum componente importante a considerar no projeto. Uma maneira de organizao do trabalho da equipe de desenvolvimento , em que voc pode atribuir para os membros do projeto para implementar subsistemas diferentes dentro da arquitetura. Um meio de avaliao dos componentes para reuso , no qual voc pode comparar os componentes que podem ser reutilizados (reusados) na aplicao em desenvolvimento. Vocabulrio para conversar sobre os tipos de aplicao, ou seja, voc poder usar os conceitos utilizados na arquitetura genrica para falar sobre as aplicaes. Existem muitos tipos de sistemas de aplicaes sendo que podem parecer muito diferentes, desta forma descreveremos abaixo os quatro tipos mais abrangentes de aplicaes.

Aplicaes de Processamento de Dados So aplicaes voltadas a dados. Elas processam dados em lotes sem intervenes explcitas do usurio durante o processamento, em que aes especficas tomadas pela aplicao dependem dos dados que so processados. Geralmente so usadas em aplicaes de negcios, cujas operaes similares so realizadas sobre uma grande quantidade de dados. Aplicaes de Processamento de Transaes So aplicaes centradas em banco de dados que processam as solicitaes de informaes provenientes de usurios e que atualizam as informaes no banco de dados. Este o tipo mais comum de sistemas de negcios interativos. Essas

aplicaes so organizadas de tal maneira que as aes do usurio no podem interferir uma nas outras e a integridade do banco de dados mantida. Exemplo de aplicaes: sistema de reservas, de e-commerce, bancrios, etc... Sistemas de Processamento de Eventos uma classe muito grande de aplicaes, na qual as aes de sistema dependem da interpretao de eventos no ambiente do sistema. Esses eventos podem ser a entrada de um comando do usurio ou a mudana de variveis monitoradas pelo sistema. Muitas aplicaes baseadas em PC so sistemas de processamento de eventos, como, por exemplo, jogos, processadores de texto, planilhas, editor de imagens, sistemas de tempo real, etc... Sistema de Processamento de Linguagens So sistemas em que as intenes do usurio so expressas em uma linguagem formal e o sistema processa a linguagem em formato interno e em seguida interpreta a representao. Tambm so conhecidos como compiladores.

Web Aula 2 EVOLUO DE SOFTWARE E ERGONOMIA Caro aluno, nesta Web aula abordaremos assuntos relacionados ao tema Evoluo de Software com nfase nos processos de evoluo, dinmica da evolua, manuteno de software e gerenciamento de sistemas legados. J em Ergonomia, com nfase em projeto de interface, exploraremos os conceitos, com algumas sugestes de leitura. Prof. Perini Evoluo do Software O objetivo deste tpico explicar por que a evoluo uma parte importante da engenharia de software, e descrever os processos de evoluo de software. O desenvolvimento de software no interrompido quando o sistema entregue, mas continua por toda a sua vida til e depois que o sistema implantado. Para que ele se mantenha til inevitvel que ocorram mudanas guiando-se nos negcios e nas expectativas dos usurios que geram novos requisitos para o software. A evoluo do software importante, pois as organizaes investem grandes somas de dinheiro em seus softwares e so dependentes desses sistemas. Eles so ativos crticos de negcios, e as organizaes devem investir nas mudanas de sistemas para manter o valor desses ativos. A maioria das grandes empresas gasta mais na manuteno dos sistemas existentes do que no desenvolvimento de novos sistemas, traduzindo em nmeros, gastam entre 85 a 90% em processos de evoluo de sistemas. A evoluo do software pode ser desencadeada por necessidades empresariais em constante mutao, por relatos de defeitos de software ou por alteraes de outros sistemas em uma ambiente de software. Levando-nos a considerar que a evoluo de um sistema de software raramente pode ser considerada de forma isolada.

Sistemas de software teis muitas vezes tm uma vida muito longa e como eles custam muito s empresas a tendncia de serem usados por muito tempo para ter o retorno no investimento realizado. Portanto, novos releases do sistema que incorporam as alteraes e atualizaes so geralmente criados em intervalos regulares. Processos de Evoluo A evoluo dos processos de software pode variar dependendo do tipo de software que esteja sendo mantido, dos processos de desenvolvimento usados em uma organizao e das habilidades das pessoas envolvidas, sendo que em algumas organizaes, a evoluo pode ser um processo informal em que as solicitaes de mudanas resultam em maior parte das conversas entre os usurios do sistema e os desenvolvedores. J em outras empresas, um processo formal com documentao estruturada produzida em cada estgio do processo. Nota-se que em todas as organizaes as propostas de mudanas so acionadores para a evoluo. As propostas de mudanas devem ser relacionadas aos componentes do sistema que necessitam ser mudados para a implementao da proposta, o que permite que o custo e o impacto da alterao sejam avaliados. Idealmente, o estgio de implementao desse processo deve modificar a especificao, o projeto e a implementao do sistema para refletir as alteraes do sistema. Novos requisitos que refletem mudanas do sistema so propostos, analisados e validados. Componentes do sistema so reprojetados e implementados e o sistema novamente testado, conforme figura abaixo: Figura 1 - Implementao de mudana de software

s vezes, as solicitaes de mudanas esto relacionadas a problemas de sistemas que devem ser resolvidos com urgncia. Essas mudanas urgentes podem surgir por trs motivos: 1. Se ocorrer um defeito grave no sistema, precisar ser corrigido para permitir a continuidade do funcionamento normal. 2. Se as alteraes no ambiente operacional dos sistemas tiverem efeitos inesperados que interrompam o funcionamento normal. 3. Se houver mudanas inesperadas no funcionamento do negcio que executa o sistema, como o surgimento de novos concorrentes ou a introduo de nova legislao que afete o sistema Dinmica da Evoluo de Programas A dinmica da evoluo de programas o estudo da mudana no sistema. Na dcada de 70 a 80, Lehman realizou uma pesquisa sobre a mudana de sistemas com a inteno de compreender mais sobre as caractersticas da evoluo do

software. A partir desses estudos, o mesmo props a Leis de Lehman, relativas s mudanas de sistema (Tabela 1). Tabela 1. Leis de Lehman

Leis

Descrio

Mudana contnua

Um programa usado em um ambiente do mundo real deve necessariamente mudar, ou se torna progressivamente menos til neste ambiente

Aumento da complexidade

Como um programa em evoluo muda, sua estrutura tende a tornar-se mais complexa. Recursos extras devem ser dedicados a preservar e simplificar a estrutura.

Evoluo de programa de grande porte

A evoluo de programa um processo de autoregulacao. Atributos de sistema como tamanho, tempo entre releases e nmero de erros relatados so aproximadamente invariveis para cada release do sistema

Estabilidade organizacional

Ao

longo

da

vida

de

um

programa,

sua

taxa

de

desenvolvimento independentemente

dos

aproximadamente recursos

constante, ao

destinados

desenvolvimento do sistema.

Conservao da familiaridade

Durante a vigncia de um sistema, a mudana incremental em cada release aproximadamente constante.

Crescimento contnuo

A funcionalidade oferecida pelos sistemas tem de aumentar continuamente para manter a satisfao do usurio

Declnio da qualidade

A qualidade dos sistemas cair, a menos que eles sejam modificados operacional para refletir mudanas em seu ambiente

Os processos de evoluo incorporam sistemas de feedback multiagentes, multi loop, e voc deve trat-los como sistemas de feedback para alcanar significativa melhoria no produto

Fonte: Sommerville (2011 p.169) Manuteno de Software A manuteno de software o processo geral de mudana em um sistema depois que ele liberado para uso. O termo geralmente se aplica ao software customizado em que grupos de desenvolvimento separados esto envolvidos antes e depois da liberao. As alteraes feitas no software podem ser simples mudanas para correo de erros de codificao, at mudanas mais extensas para correo de erros de projeto, ou melhorias para corrigir os erros de especificao ou ento par acomodar novos requisitos. Podemos segmentar a manuteno em trs tipos diferentes: Correo de erros (Corretiva)

Reengenharia de Software Envolve a compreenso do programa que tem que ser mudado e em seguida a implementao dessas mudanas. Para fazer com que os sistemas legados de software sejam mais fceis de serem mantidos, preciso aplicar a reengenharia nesses sistemas, visando a melhoria de sua estrutura e inteligibilidade. A reengenharia pode envolver a redocumentao de sistema, a refatoraao da arquitetura de sistema, a mudana de linguagem de programao para uma linguagem moderna e modificaes e atualizaes da estrutura e dos dados do sistema, sendo que a funcionalidade do software permanece inalterada. Existem dois benefcios importantes na reengenharia: 1. Risco reduzido: existe um alto risco em desenvolver novamente um novo software; 2. Custo reduzido: o custo da reengenharia muito menor do que o desenvolvimento de um novo software. O problema com a reengenharia que existem limites prticos para o quanto voc pode melhorar um sistema por meio da reengenharia, no sendo possvel, por exemplo, converter um sistema escrito por meio de uma abordagem funcional para um sistema orientado a objetos. Embora a reengenharia possa melhorar a manutenibilidade, o sistema reconstrudo provavelmente no ser to manutenvel como um novo sistema, desenvolvido por meio dos mtodos modernos de reengenharia de software. Gerenciamento de sistemas legados Geralmente, as organizaes tem um portfolio dos sistemas legados que usam, com um oramento limitado para a manuteno e modernizao desses sistemas. Elas precisam decidir como obter o melhor retorno de seus investimentos, o que envolve fazer uma avaliao realista de seus sistemas legados e em seguida decidir sobre a estratgia mais adequada para a evoluo desses sistemas. Existem quatro opes estratgicas: 1. Descartar completamente o sistema: deve ser escolhido quando o sistema no contribuir mais para os processos de negcios e ter baixa qualidade de sistema.

2. Deixar o sistema inalterado e continuar com a manuteno regular: deve-se optar por esta estratgia quando o sistema ainda necessrio, mas bastante estvel e os usurios fazem poucas solicitaes de modificaes. 3. Reestruturar o sistema para melhorar a manutenibilidade: deve escolher esta opo quando a qualidade do sistema foi degradada pelas mudanas, e novas mudanas para o novo sistema ainda esto sendo propostas. 4. Substituir a totalidade ou parte do sistema por um novo sistema: deve ser escolhida quando fatores como hardware novos significarem que o sistema antigo no pode continuar em operao ou quando os sistemas de prateleira podem permitir o desenvolvimento do novo sistema a um custo razovel. Quando voc est avaliando um sistema legado, precisa olhar para isso de uma perspectiva de negcio e de uma perspectiva tcnica. Do lado do negcio, necessrio decidir se ele realmente necessita do sistema. Do lado tcnico, torna-se necessrio avaliar a qualidade do software de aplicao e apoio de software e hardware do sistema. Logo em seguida deve usar uma combinao do valor do negcio e da qualidade do sistema para informar sua deciso sobre o que deve ser feito com o sistema legado. Para avaliar o valor do negcio de um sistema, voc precisa identificar os stakeholders do sistema, como os usurios finais do sistema e seus gerentes, ee fazer uma srie de perguntas sobre eles. Existem quatro questes a discutir: 1. 2. 3. 4. Uso do sistema; Os processos de negcios que so apoiados; Confiana do sistema; As sadas do sistema. Projeto de Interface de Software Design Ao iniciarmos o estudo do hoje projeto as de interface de do software, cabe-nos que as

primeiramente

constatar

estratgias

competio

empresas desenvolvedoras de software impem nos produtos disponibilizados no mercado, o qual os mesmos devem possuir; Inovao Funcional, pois os clientes buscam novas funcionalidades, ou uso de novos dispositivos, ou novas tecnologias que facilitem sua utilizao; Inovao no Uso, em que destaca-se a facilidade no uso do software; Inovao Esttico-funcional, cujo foco est na interface disponibilizada ao cliente; Poltica de suporte ao cliente, focalizando o atendimento/suporte ao produto dado pelo fornecedor do software e; Preo, fator ainda muito importante para a deciso de compra por parte dos clientes.

Com a evoluo do software, podemos verificar que os produtos desenvolvidos at o inicio do sculo XXI (2000) possuam um enfoque baseado na eficincia da mquina, priorizando o funcionamento e a eficincia fsica da mquina, porm atualmente este foco mudou, passando agora a dar nfase ao usurio, procurando evidenciar a eficincia da ao e a funo que o software executa, assim priorizando o design da interface.

Hoje, o design trabalha num campo de ao profissional no algoritimizvel, onde design no significa ter ideias ou apenas arte ou decorao e sim trabalhar com a estruturao de espaos e apontar distines visuais e auditivas, com isto buscando a qualidade da visualidade.

Hoje o design tem seu foco no usurio, buscando seu envolvimento e participao ativa no projeto de desenvolvimento do software, procurando, assim, a unio da praticidade, funcionalidade operativa e esttica.

Na estruturao da interface, devemos incluir o design de telas, janelas, controles, menus, help, etc., ou seja, a parte da aplicao visvel ao usurio, aquela que ele v e interage, pois do ponto de vista do usurio a INTERFACE o software.

Para o desenvolvimento da interface, so consumidos cerca de 45% dos recursos dispendidos no projeto, que vem sendo desenvolvido ainda hoje com base em opinies e gostos pessoais, muitas vezes esquecendo das tcnicas para o desenvolvimento da interface. A seguir, listamos algumas diretrizes que podem nos nortear na construo de uma interface de software: Conhecer os usurios; Conhecer o trabalho dos usurios; Adaptar a interface para os padres de trabalho do usurio; Tornar as tarefas frequentes fceis de usar; Desenvolver a interface consistente e clara; Utilizar a base de conhecimento existente sobre os objetos da interface para a sua construo; Obter feedback. Ergonomia Conceitos Bsicos Na literatura, encontramos vrias definies sobre Ergonomia, como: Leplat, J. - A Ergonomia pode ser definida como o estudo cientfico das relaes entre o homem e o seu ambiente de trabalho (1965).

Self - A Ergonomia rene os conhecimentos da fisiologia e psicologia, e das cincias vizinhas aplicadas ao trabalho humano, na perspectiva de uma melhor adaptao do homem aos mtodos, meios e ambientes de trabalho. Wisner - A Ergonomia o conjunto de conhecimentos cientficos relativos ao homem e necessrios a concepo de instrumentos, mquinas e dispositivos que possam ser utilizados com o mximo de conforto e eficcia (1972) (ERGONOMIA..., 2012).Mas de um modo geral, podemos simplificar o conceito de Ergonomia relacionando-o com a facilidade de uso em uma determinada tarefa, vinculado ao conforto e a eficcia. O software condiciona totalmente a tarefa do operador e seu desempenho, na medida em que estabelece quais as informaes estaro disponveis em tela, as relaes visuais entre elas e a sequncia das aes. Na computao, uma rea que est ligada diretamente a este tema a da Interao Humano-Computador (IHC). Nesse contexto, a partir das funcionalidades das aplicaes, o foco geralmente est direcionado satisfao do usurio. Essa satisfao pode ser definida por meio da qualidade de uma interao entre o ser humano e o computador. A atividade atual de concepo de interfaces homemcomputador est mais baseada em opinies e julgamentos individuais, do que em aplicao sistemtica de conhecimentos.

Em um projeto de software ergonmico, devemos sempre por um lado buscar a participao efetiva do usurio, onde devemos levantar os objetivos e se necessrio utilizarmos da prototipao no auxlio na definio destes objetivos e, por outro lado, fazer a aplicao de uma avaliao ergonmica do software a fim de garantir que o mesmo se comporte como esperado e atenda as expectativas dos usurios. Para esta avaliao ergonmica podemos utilizar tcnicas empricas, ou seja, tcnicas baseadas em ensaios de interao com a participao efetiva dos usurios e analticas que dispensam a participao dos usurios, visto que so baseadas no conhecimento dos analistas ou em conhecimentos ergonmicos agregados a uma ferramenta utilizada no projeto.

Para uma melhor eficincia, podemos contar com tcnicas formalizadas em estudos de vrios autores. Nesta seo, conheceremos alguns tipos de avaliaes.Como exemplo, temos a tcnica baseada em critrios ergonmicos dos autores Bastien e

Scapin: http://www.labiutil.inf.ufsc.br/CriteriosErgonomicos/Abertura.html Tambm, o ergolist que apresenta um questionrio

denominado checklist:http://www.labiutil.inf.ufsc.br/ergolist/

Aprofundando conhecimento Ao iniciarmos o estudo sobre projeto de interface de software, leia o artigo:http://www.dimap.ufrn.br/~jair/piu/JAI_Apostila.pdf

Como qualquer atividade realizada em um projeto de desenvolvimento de software, a interface tambm possui algumas fases que devem ser seguidas:

Figura 2 - Fases do Processo

Fonte: Perini (2012)

Erros de codificao so relativamente baratos para serem corrigidos; erros de projetos so mais caros, visto que podem implicar em reescrever vrios programas. J os erros de requisitos so mais caros para se corrigir devido ao extenso reprojeto de sistema que pode ser necessrio. Adaptao ambiental (Adaptativa) Esse tipo de manuteno necessrio quando algum aspecto do ambiente do sistema, como hardware, a plataforma do sistema operacional ou outro software de

apoio sofre uma mudana, neste caso o sistema de aplicao deve ser modificado para se adaptar a essas mudanas de ambiente. Adio de Funcionalidade (Perfectiva ou Evolutiva) Este tipo de manuteno necessrio quando os requisitos de sistema mudam em resposta s mudanas organizacionais ou de negcios. A escala de mudanas necessrias para o software frequentemente muito maior do que para outros tipos de manuteno. Geralmente, mais caro adicionar funcionalidades depois que um sistema est em operao do que implementar a mesma funcionalidade durante o desenvolvimento. As razes para isso so: 1. Estabilidade da equipe: depois de liberado o pessoal da equipe de desenvolvimento desmobilizada, sendo remanejados para outros projetos. 2. Ms prticas de desenvolvimento: o contrato para a manuteno de um sistema geralmente separado do contrato de desenvolvimento de sistema. O contrato de manuteno pode ser dado a uma empresa terceirizada para realizar o trabalho de manuteno. 3. Qualificaes pessoais: A equipe de manuteno relativamente inexperiente e no familiarizada com o domnio da aplicao, ento a manuteno tem uma imagem pobre entre os engenheiros de software, sendo vista como um processo menos qualificado. 4. Idade do programa e estrutura: Com as alteraes feitas nos programas, sua estrutura tende a degradar, e tambm os programas envelhecem tornando-se mais difceis de serem manutenidos. Os trs primeiros problemas decorrem do fato de que muitas organizaes ainda consideram o desenvolvimento e manuteno atividades separadas, sendo a manuteno vista como uma atividade de segunda classe, no tendo incentivo na alocao de recursos financeiros durante o desenvolvimento, justamente para reduzir custos na alterao do sistema. O quarto item o problema mais fcil de ser resolvido, usando tcnicas de reengenharia para melhorar a estrutura do sistema e sua inteligibilidade. ANLISE A fase de Anlise consiste no levantamento de informaes sobre os usurios do sistema e suas respectivas atividades, objetivando definir os requisitos para o desenvolvimento da interface.

So analisados: O perfil dos usurios; Como eles trabalham atualmente; Como eles devero trabalhar no futuro com o software cuja interface est sendo desenvolvida. Participantes: O projetista da interface; Um a dois usurios experientes; Um analista de sistemas; Um usurio de nvel gerencial. Atividades Levantamento preliminar; Elaborao do perfil dos usurios; Levantamento complementar das atividades dos usurios; Documentao das atividades atuais; Identificao de problemas e oportunidades de alterao; Documentao das atividades futuras. PROJETO A fase de Projeto desenvolvida com base nas informaes levantadas na anlise. A estrutura da interface do software compe: Metforas e modelos da interface; Aparncia e organizao geral; Documentao e maquetes do projeto; Participantes: O projetista da interface; Um a dois usurios experientes; Um analista de sistemas; Uma pessoa da rea de treinamento (opcional). Sesses: A Documentao das Atividades Futuras a principal fonte para os trabalhos da fase de projeto; No inicie projetando a estrutura de menus; Antes de ser elaborado um modelo conceitual e o esboo das diversas atividades, no se saber como estas atividades devem ser integradas e organizadas em uma estrutura de menus. Atividades

Identificao dos principais objetos; Elaborao das metforas e representaes; Storyboard dos principais objetos/metforas; Criao da maquete do projeto; Teste; Plano de suporte ao usurio. CONSTRUO A fase de Construo consiste no desenvolvimento do prottipo da interface do software, utilizando uma ferramenta de prototipao. Os documentos gerados na fase de projeto servem de base para a construo do prottipo, que representam uma verso mais detalhada e realstica da interface. Participantes:

O projetista da interface; Um a dois usurios experientes; Um analista de sistemas; Uma pessoa da rea de treinamento (opcional). ATIVIDADES

Desenvolvimento do prottipo; Teste.