sábado, 26 de abril de 2014

Projeto brModelo 2.0

brModelo 2.0



Site Oficial: http://sis4.com/brModelo/

Versão 2.0
Durante a fase de elaboração da monografia, o foco eram os conceitos e a implementação da ferramenta era resultante do trabalho de pesquisa.

Depois disso, decidi expandi a ferramenta. Mantendo o modelo conceitual fiel ao proposto na versão 1.0, expandi o modelo lógico e cheguei até a criação do modelo de implementação (físico) - ainda não efetivamente testado.

Todo o projeto esteve stand-by por um longo tempo, até que recebi alguns e-mails parabenizando-me pela ferramenta e informando de seu uso em faculdades. Então decidi aprimorá-la e disponibilizá-la juntamente com seu código fonte.

Evidentemente não forneço nenhum tipo de suporte, mas sugestões são bem vidas.

Base para pesquisa:
Livro Heuser


Observação: As marcas aqui citadas são de propriedade de suas respectivas firmas. O nome brModelo é uma invenção livre (br: Brasil, Modelo: modelagem de dados), qualquer semelhança a qualquer marca comercial é mera coincidência.

Índice:
DER: Diagrama de Entidade e Relacionamento.
MER: Modelo de Entidade e Relacionamento.
BD: Banco de Dados (DB - Data Base).
Modelo: Conceitual, Lógico, Físico 
 

terça-feira, 22 de abril de 2014

Técnicas de Teste - Verificação e Testes de Programas



Técnicas de teste - Básico

Verificação e Testes de Programas
A  etapa de design (projeto) de software (do modelo conceitual, da interface e da arquitetura) tem por objetivo encontrar as soluções que satisfaçam os requisitos do software. No design as  soluções são especificadas através de formas e modelos que possibilitam diferentes visões do software. Todavia  para que o software funcione é essencial que as ideias produzidas durante o projeto seja codificadas em uma linguagem de programação para que possam ser traduzidas e executadas num computador.
O código produzido durante esta etapa pode conter falhas ou erros. Visto que os erros podem ser ocasionados por diversos fatores., onde um deles pode ser a interpretação errada dos modelos produzidos durante o projeto. A complexidade de um programa, seja pela complexidade de um algoritmo ou pelo seu tamanho, pode levar ao programador a gerar um software com muitos  erros de funcionamento. Assim sendo, definir o que é um erro ou falha num software não é uma tarefa simples.
Inicialmente, precisamos conhecer a diferença entre Defeitos, Erros e Falhas.
  • Defeito é um to inconsciente cometido por um indivíduo ao tentar entender uma determinada informação, resolver um problema ou utilizar um método ou uma ferramenta. Por exemplo, uma instrução ou comando incorreto.
  • Erro é uma manifestação concreta de um defeito num artefato de software. Diferença entre o valor obtido e o valor esperado, ou seja, qualquer estado intermediário incorreto ou resultado inesperado na execução de um programa constitui um erro.
  • Falha é o comportamento operacional do software diferente do esperado pelo usuário. Uma falha pode ter sido causada por diversos erros e alguns erros podem nunca causar uma falha.

Figura 1 expressa a diferença entre esses conceitos. Defeitos fazem parte do universo físico (a aplicação propriamente dita) e são causados por pessoas, por exemplo, através do mal uso de uma tecnologia. Defeitos podem ocasionar a manifestação de erros em um produto, ou seja, a construção de um software de forma diferente ao que foi especificado (universo de informação). Por fim, os erros geram falhas, que são comportamentos inesperados em um software que afetam diretamente o usuário final da aplicação (universo do usuário) e pode inviabilizar a utilização de um software.
Podemos simplificar dizendo que um erro é quando o software não se comporta conforme foi especificado. Isto pode ocorrer quando o software não realiza um função esperada, fornece resultados não esperados, não consegue terminar quando esperado, etc. Para se avaliar o funcionamento do teste é preciso definir quais os critérios necessários para consideramos que o mesmo está correto ou não, isto é, o que pode ser considerado um erro ou falha. Além disso, é preciso determinar quais métodos ou técnicas para verificação do funcionamento serão empregadas.
Dessa forma, ressaltamos que teste de software revela simplesmente falhas em um produto. Após a execução dos testes é necessária a execução de um processo de depuração para a identificação e correção dos defeitos que originaram essa falha, ou seja, Depurar não é Testar!
 Defeito - Erro - Falha
  VERIFICAÇÃO E VALIDAÇÃO (V&V)
Logo após finalizar o processo de implementação, o programa deve ser verificado para termos a certeza de que ele atende a sua especificação e entrega a funcionalidade solicitada pelos clientes. O processo de Verificação e Validação (V&V) é o nome dado a esse processo de verificação e analise, onde as atividades de V&V ocorrem em cada fase do processo de software, iniciando com as revisões de requisitos , continuando com o projeto e das inspeções de código até os testes de produtos.
O processo de Verificação e Validação não são a mesma coisa, uma vez que a validação se preocupa se “estamos construindo o produto certo?” e a verificação tem o foco se“estamos construindo o produto da forma correta?”.  Desta maneira o papel da verificação nos faz ver se o software esta de acordo com as especificações, se atende ou não os requisitos funcionais e não-funcionais. Já a validação é um processo mais amplo, cuja finalidade é garantir que o software atenda as expectativas do cliente. O maior objetivo do processo de V&V é estabelecer a confiança de que o software esteja adequado ao proposito ao qual foi desenvolvido, porém o nível de confiabilidade depende do fim a que se presta o software,  das expectativas dos usuários do sistema e do atual ambiente de mercado.
Dentro do processo de V&V podemos verificar duas abordagens para a verificação e analise de sistema, onde a primeira seria a inspeção de software ou revisões por pares também chamado de técnica de V&V estática, onde analisam e verificam as representações do sistema como um documento de requisitos, diagramas de projeto, código-fonte do programas, etc.  e a segunda abordagem seria a de testes de softwaretambém conhecida com técnica de V&V dinâmica, que envolvem a execução do software com dados de testes  a fim de checar as saídas do software, o comportamento operacional  no intuito de verificar se o seu desempenho está conforme o desejado.
As técnicas de inspeções incluem inspeções de programa e de analise de código-fonte, porem não podem demonstrar que o software é operacionalmente útil. Embora as inspeções de  software  sejam amplamente usadas, os testes de programas será sempre a técnica principal de V&V do software, uma vez que exercita o programa utilizando dados reais processados pelo programa, onde descobre erros e defeitos nos programas. Há dois tipos de testes que podem ser utilizados no processo de software  o teste de validação que tem a finalidade de mostrar que o software é o que o cliente deseja e teste de defeitos que é destinado a revelar defeitos no sistema em vez de simular o seu uso operacional, tendo como objetivo encontrar inconsistências entre um programa e sua especificação.
Os processos de V&V e de depuração (debugging) geralmente são intercalados, na medida em            que descobre os defeitos no programa, você deve alterar o programa para corrigir esses defeitos. Porem o teste e o debugging tem finalidades diferentes, onde os testes são dedicados a estabelecer a existência de defeitos no sistema e o debugging é um processo que localiza e corrige esses defeitos.
Planejar  a verificação e validação é um processo caro, pois para alguns sistemas de tempo real com  restrições não-funcionais complexas, boa parte do orçamento pode ser gasto em  processos de V&V. Como parte do processo de planejamento de V&V há necessidade de decidir sobre o equilíbrio  entre as abordagens estática e dinâmica para os processos de V&V, especificar os padrões e procedimentos para inspeções e testes de software e por fim estabelecer o checklists para direcionar as inspeções nos programas.
O planejamento de teste concentra-se no estabelecimento de padrões para o processo de teste e não apenas  na descrição dos testes. Os principais componentes de um plano de teste são:
  • Processo de teste
  • Rastreabilidade de requisitos
  • Itens testados
  • Cronograma de testes
  • Procedimentos de registro de testes
  • Requisitos de hardware e software
  • Restrições
Os planos de testes não são documentos estáticos, pois evoluem durante o processo de desenvolvimento, ou seja, mudam devido a atrasos em outros estágios do processo de desenvolvimento.
As inspeções de software é um processo de V&V estática, onde um sistema de software é revisto para encontrar erros, omissões e anomalias. Geralmente tem o foco no código-fonte, mas em qualquer  representação legível do software pode ser inspecionado (requisitos, algoritmos, etc). Quando realizamos a inspeção de um sistema, nos usamos o conhecimento do sistema, seu domínio de aplicação, a linguagem de programação ou o modelo de projeto para descobrir erros.
Inspeções é uma ideias antiga, visto que as inspeções são mais eficientes para descobrir defeitos do que testes de programas. Dentre as vantagens dos processos de inspeção podemos citar:
  • Durante os testes, os erros podem ocultar outros erros, pois, uma vez que um erro é descoberto não podemos ficar seguros de se outros erros descobertos são devidos a um novo erro ou se são efeitos colaterais dos erros descobertos originalmente. Por ser um processo estático, em uma única sessão de inspeção pode-se descobrir muitos erros de um sistema.
  • Versões incompletas podem ser inspecionadas, se um programa esta incompleto é necessário desenvolver um conjunto de testes especializados para essas partes disponíveis, acrescentando assim os custos do projeto.
  • A inspeção deve considerar atributos de qualidade mais abrangentes de um programa tais como a conformidade com padrões, portabilidade, facilidade de manutenção, etc.
Revisões e testes tem vantagens e desvantagens que devem ser usadas em conjunto no processo de V&V. Uma das aplicações mais eficientes das revisões é revisar os casos de testes para um sistema. As revisões podem  descobrir problemas  com esses testes e auxiliar a projetar  caminhos mais eficientes  para testar um sistema. Inicialmente o V&V do sistema deve começar inspeções no inicio do processo de desenvolvimento e se este for sistema integrado, é preciso testá-lo para verificar as propriedades emergentes e se a funcionalidade  do sistema é a que o cliente realmente deseja.  
Na há duvidas de que as inspeções que começam no inicio os custos  de V&V do sistemas e resultam em economia de custos somente depois que as equipes de desenvolvedores se tornam experientes em seu uso. Além disso as inspeções levam tempo para serem organizadas  e parecem diminuir a velocidade do processo de desenvolvimento, sendo difícil  de convencer um gerente com projetos em atraso  de que esse tempo pode ser recuperado mais tarde pelo fato de que menos tempo será dispendido no processo de debugging.

quinta-feira, 17 de abril de 2014

Gerenciamento de tempo com o Gantt

Meu esboço com o gerenciamento de tempo

O programa gantt e uma ótima opção.

Aqui esta o gerenciamento de tempo de cada pessoa.


Aqui esta o gerenciamento de tempo do projeto.



um gerenciando, desenvolvendo, e outro analizando. todos entregando o protótipo juntos.

Como fazer para uma empresa crescer com gerenciamento de projetos

Bom dia!




     Segue aqui como fazer para uma empresa crescer com gerenciamento de projetos.
segue abaixo leia e fique atento que verá o resultado.



Qual é o problema?

Eu tenho autonomia sobre o projeto e recursos?

De onde e como terei recursos financeiros e recursos humanos?

Qual é o escopo do meu projeto?

Como será a gestão do projeto, prioridade e tempo de dedicação?

Quais são os marcos para validação e avaliação com os stakeholders (interessados)?

Qual é prazo de entrega?

segunda-feira, 14 de abril de 2014

Planejamento e acompanhamento de projeto de software!


Fatores do Gerenciamento de projeto
Para definir as atividades é importante que o Objetivo e o Produto estejam bem definidos, o que significa que as pessoas envolvidas já sabem onde e quando começa (tempo); que o final desejado (escopo) esteja claro. Como vimos também, algumas Metas estejam estabelecidas, estas que são as subdivisões com objetivos intermediários que são parciais até alcançar o objetivo do projeto (VALERIANO, 2009).
Todo projeto concebe uma característica diferente pela complexidade, extensão, natureza, entre outros detalhes. As variáveis são determinadas pelo grau de importância de cada projeto. Cada uma destas variáveis tem maior relevância em função da abundância ou da escassez em determinada época em que o projeto acontece. Por isso, na maioria dos casos, a experiência dos envolvidos é determinante para o bom andamento e para o sucesso do desenvolvimento de um software. 
(Vavassori, p.2) A ênfase é dada para os três fatores (Figura 3) fundamentais no gerenciamento de um projeto: tempo (prazo), tarefa (escopo) e recursos (pessoal, infraestrutura, entre outros). Ver o link, cujo documento explicita estes fatores.

escopo
Figura 3 - Tripla restrição no gerenciamento de projetos

2.1.        Tempo: considerado um componente com a menor flexibilidade.
Em função da falta de domínio sobre o tempo, este fator requer uma atenção especial. Vejamos! Um minuto de trabalho numa determinada atividade é indivisível, serão transcorridos 60 segundos sem nenhuma intervenção para iniciar ou finalizar. Depende apenas do responsável pela tarefa na execução em utilizar adequadamente este tempo que nunca mais retornará. Nestes 60 segundos, poderão ocorrer outras variações de escopo ou de falta de recurso, porém o intervalo de tempo não se altera.
Em função de um projeto transcorrer sempre um prazo determinado para começar e terminar. Jamais podemos ignorar o fator Tempo.
Cuidado com o fator TEMPO! Mais adiante falaremos sobre a estimativa. Porém, para facilitar o entendimento de que o tempo é um fator muito importante, assistam ao vídeo do link: nem sempre acertam na primeira vez.
Como vocês podem ver neste vídeo (acessado em 03.mar.2010): <http://www.youtube.com/watch?v=BV1eWgJ6Uzs&feature=player_embedded>
2.2.        Escopo: tudo aquilo que o usuário final quer em no sistema depois de desenvolvido.
Atenção! Quanto maior o tamanho do projeto (BERKUN, 2008), mais complexo ficará o gerenciamento, o cronograma de atividades será mais denso e extenso, os recursos envolvidos serão maiores. Uma forma de resolver este problema é estabelecendo em fases o projeto proposto. Lembrando que esta FASE não se é a fase do ciclo de vida de software e sim do projeto.
Como mostra a Figura 4 (divisão do projeto em fases), na qual ilustra esta uma divisão para facilitar o gerenciamento de projetos em tamanhos ideais. Não existe um tamanho ideal para um projeto, ou fase do projeto. Este tamanho dependerá da experiência da equipe envolvida com o segmento do projeto a ser desenvolvido; principalmente da habilidade do gerente de projeto quanto ao desenvolvimento desta atividade frente à equipe e domínio do escopo. Outro fator importante, nesta divisão de fases do projeto é quanto ao envolvimento dos usuários e/ou patrocinadores do futuro software.

 divisaoprojeto
Figura 4 - divisão do projeto em fases
Fonte: Berkun (2008)

Ciclos menores de desenvolvimento de produtos pode ser verificado neste link, consultado no dia 03.mar.2014, durante o planejamento da aula: <http://onca.st/blog/?p=217>.
2.3.        Recursos: para atender ao escopo desejado necessitamos do terceiro fator
Quando se trata de recursos entende-se que existem vários itens envolvidos. Todos os valores do orçamento para o desenvolvimento de um software estará baseado na estimativa em horas das pessoas envolvidas no projeto. Sem dúvidas, o custo da mão-de-obra num projeto de software é muito significativo, senão o maior custo. Embora, devemos prever os gastos com materiais, hardwares, infraestrutura, internet, viagens entre outros.
Para exemplificar quanto à dimensão de um projeto quanto a custo (recursos), vamos assistir ao vídeo do link (acessado em 03.mar.2014):
Como pode perceber neste vídeo, os materiais envolvidos são de grande valor financeiro. Cada parte da aeronave que está sendo montada requer uma competência (recursos humanos e técnicos) para estarem no lugar e na hora certa.
Todos estes recursos devem estar devidamente programados e prontos para serem utilizados. Se uma das peças se atrasa, todo o processo sofre atraso e assim poderá comprometer todo projeto.

Arquitetura de Software e Padrões de Projeto!




Uma arquitetura define a estrutura

Se você pedir a pessoa para descrever "arquitetura", nove em cada dez vão fazer alguma referência à estrutura. Essas estruturas na maioria das vezes vão fazer referencia a um edifício ou qualquer outra estrutura de engenharia civil como uma ponte por exemplo. Embora existam outras características da arquitetura de software como o comportamento, adequação à finalidade, e até mesmo a estética, é a característica estrutural que é frequentemente mencionados.
Portanto quando você pedir a alguém para descrever a arquitetura de um sistema de software que ele está trabalhando, provavelmente ele te mostrará um diagrama que mostra os aspectos estruturais do sistema.
Muitas definições de arquitetura também reconhece não só os próprios elementos estruturais, mas também a composição de elementos estruturais, seus relacionamentos (e todos os conectores necessários para apoiar essas relações).


Uma arquitetura define o comportamento
Além de definir os elementos estruturais, uma arquitetura define as interações entre esses elementos estruturais. São essas interações que fornecem o comportamento do sistema desejado. 

Uma arquitetura concentra-se em elementos significativos
Enquanto se define a estrutura e comportamento, ela não está preocupado com a definição de toda a estrutura e de todos os comportamentos. Ela só se preocupa com os elementos que são considerados significativos. Elementos significativos são aqueles que têm um efeito longo e duradouro, tais como os principais elementos estruturais, os elementos associados com o comportamento essencial, e os elementos que abordam qualidades importantes, como confiabilidade e escalabilidade. Em geral, a arquitetura não está preocupado com os detalhes de granulação fina desses elementos. 
Também é interessante notar que o conjunto de elementos significativos não é estática e pode mudar ao longo do tempo. Em consequência das exigências sendo refinada, os riscos identificados, software executável e as lições aprendidas, o conjunto de elementos significativos podem mudar. No entanto, a relativa estabilidade da arquitetura em face da mudança é um sinal de uma boa arquitetura, e o fato de executar bem um processo de arquitetura, é o sinal de um bom arquiteto. Se a arquitetura precisa ser continuamente revista devido a mudanças relativamente pequenas, então este não é um bom sinal. 

Uma arquitetura incorpora decisões baseadas em lógica
Um aspecto importante de uma arquitetura não é apenas o resultado final, a própria arquitetura, mas a razão por ela ser do jeito que é. Assim, uma consideração importante documentar as decisões que levaram a esta arquitetura e as razões para tais decisões.
Esta informação é relevante para muitas partes interessadas, especialmente os que devem manter o sistema. Esta informação é muitas vezes valiosa para o arquiteto, quando ele precisa de revisar o raciocínio por trás das decisões que foram tomadas. Por exemplo, esta informação é utilizada quando a arquitetura precisa revisar e justificar as decisões que foram tomadas.

Uma arquitetura pode estar de acordo com um estilo arquitetônico
A maioria das arquiteturas são derivadas de sistemas que compartilham um conjunto semelhante de preocupações. Esta semelhança pode ser descrita como um modelo de arquitetura, que pode ser pensado como um tipo particular de padrão. Como um padrão, um estilo arquitetônico representa uma codificação da experiência, e é uma boa prática para arquitetos para procurar oportunidades para reutilizar tal experiência. Exemplos de estilos arquitetônicos incluem um estilo distribuído, um estilo centrado em dados, um estilo baseado em regras, e assim por diante. Um sistema dado pode apresentar mais do que um estilo arquitetônico. 
Como Shaw e Garlan descreve:
[Um estilo arquitetônico] define uma família de sistemas em termos de um padrão de organização estrutural. Mais especificamente, um estilo arquitetônico define um vocabulário de componentes e tipos de conectores, e um conjunto de restrições sobre como eles podem ser combinados. 9

Ou em termos de UML:
[Um padrão é] uma solução comum para um problema comum em um dado contexto.
Além da experiência em reuso, a aplicação de um estilo arquitetônico (ou padrão) torna a nossa vida um pouco mais fácil, já que um estilo é normalmente documentado em termos da razão para usá-lo e em termos de sua estrutura e comportamento (e por isso há menos documentação arquitetura a ser produzida, uma vez que pode simplesmente se referir ao estilo em seu lugar).


Projeto Orientado a Objetos com UML!


Projeto Orientado a Objetos com UML



Orientação a Objetos
            A programação orientada a objetos é uma técnica de programação baseada em modelos ou objetos do mundo real. Isto que dizer que dentro do programa (executável) deve ter um objeto representando os objetos do mundo real de acordo com a área a qual foi projetado o sistema.
            Por exemplo, se o sistema foi projetado para atender um consultório médico, onde este sistema deve gerenciar a agenda de consultas dos médicos da clinica, então eu preciso criar dentro deste sistema objetos que representem os médicos, os pacientes, os funcionários etc.
            Para isso precisamos entender melhor o que significa estes“objetos”. Se pensarmos em um grupo de pessoas unidas a um bem comum (uma sociedade, por exemplo) vamos verificar claro que este grupo é formado por varias pessoas onde cada uma assume uma função dentro do grupo para atingir o tal bem comum. Cada pessoa do grupo é especialista em alguma coisa que pode ajudar o grupo a andar ao encontro do objetivo traçado. Cada elemento deste grupo executa a sua tarefa e ao mesmo tempo se comunicando com outros elementos do grupo. Ao se comunicar uns com os outros, ele estabelece um relacionamento entre si que vai auxiliar na conclusão de suas tarefas. Esta comunicação serve para simplesmente avisar que a sua tarefa foi concluída ou para pedir auxilio na conclusão da tarefa, pois a casos em que algumas atividades das tarefas delegadas ao elemento não são de total domínio dele, sendo assim ele precisa da ajuda de um elemento mais especializado naquele momento.
Da mesma forma, é um programa orientado a objetos. Onde ogrupo é o programa (executável), os elementos do grupo são osobjetos do programa.
Cada objeto dentro do programa é como um elemento do grupo (sociedade) que possui funções especifica dentro do programa. Cada objeto desempenha uma função dentro do programa para que o programa atinja o seu objetivo. Estes objetos também se relacionam entre si da mesma forma que os elementos de um grupo também se relacionam.
Dentro do paradigma orientado a objeto, existem algumas regras para que o cenário exemplificado acima possa ser implementado como um projeto orientado a objetos. Para que um objeto possa ser criado dentro de um POO (Programa Orientado a Objeto), é preciso descrevê-lo de uma forma que fique bem detalhado como será este objeto, suas características e como ele vai se comportar dentro do POO ou seja, o que exatamente ele vai fazer dentro do sistema. Para isso existe o conceito de Classe. A classe é a maneira adotada na POO para descrever os objetos, é dentro de uma classe que definimos tudo o que o objeto pode fazer quais os dados ele vai poder manipular e com quem ele pode se relacionar.
Por exemplo, vamos imaginar uma receita de bolo. Para fazer um bolo, é preciso conhecer a receita do mesmo, pois lá estão definidos os ingredientes que vamos usar e o modo de preparar. Quando usamos esta receita, estamos nos baseando nela para criar um bolo. Desta forma fica claro que vamos comer o bolo e não a receita, então usamos uma descrição de como se deve fazer um bolo, e o resultado é o bolo assado. O bolo só existe por que tem uma receita dizendo como deve ser um bolo e alguém foi lá e o criou com base nesta descrição.
            Para projetarmos sistemas orientado a objetos precisamos conhecer e aprender a usar ferramentas de modelagem que utilizem uma linguagem padrão para descrevermos os objetos do projeto. Ésta linguagem é a UML.


Noções sobre modelagem de processos de negócios!

Noções sobre modelagem de processos de negócios

Apresentação:
A partir dos modelos de negócios, os gestores e a alta administração podem decidir como os processos estão funcionando e criando resultados satisfatórios para tomadas decisões.Os processos de negócios são bases fundamentais para o desenvolvimento e-ou implantação de um sistema de informação. Toda organização que pretende utilizar os recursos da T.I.C. – Tecnologia da Informação e Comunicação deve iniciar os estudos dos seus negócios, priorizando os mais importantes para maximizar resultados.
Vamos ver a seguir o que é e como podemos utilizar os modelos de processos de negócios numa organização, trazendo benefícios aos sistemas de informações.

Seja bem-vindo a nossa primeira webaula !!!
Eu sou a professor Hisatomi e estarei junto com vocês no estudo da Modelagem de Processos de Negócios.
O segmento de desenvolvimento de software tem demonstrado por várias décadas um grande avanço, juntamente com crescimento da demanda em todos os setores do mercado. Em quase trinta anos atuando, como profissional de tecnologia, e há dez anos como professor, percebi que ser profissional desta área é bastante gratificante.
Antes a demanda era somente em sistemas de grande porte, com grande volume de dados, e pouco interação com usuários finais. Atualmente, o volume de informações aumentou tanto quanto a interação com usuários finais, acrescentado aos diversos recursos acessos através da Internet.
Em função deste diversificado cenário, exige-se que o profissional tenha maior habilidade em tomar conhecimento, estudar e propor alternativas cada vez mais rápidas e certeiras.
Portanto, estamos aqui expondo o conceito da Modelagem de Negócios, com foco ao melhor entendimento das necessidades de uma organização. Também, no uso de Processos de Negócios para alavancar o máximo de resultados a partir do fluxo de informações entre os procedimentos dos sistemas de informações.

CONCEITOS BÁSICOS

Palavras chaves: Processos de Negócio e Software, Profissional de Software e Ética em Engenharia de Software.
Caros alunos, antes de irmos direto ao conteúdo “Processos de Negócio”, é um importante saber que a palavra “Processo” pode nos remeter a situações corriqueiras de nossa vida, então vamos definir processo.
Na engenharia de software, segundo Sommerville [8], é um conjunto de atividades relacionadas que levam a produção de produto de software. Dependem de pessoas para a execução das atividades e uma regra para esta realização. Leia também sobre Processo no link “http://www.macoratti.net/proc_sw1.htm” (acessado em 09.fev.2014).
Na administração de empresas um processo é o conjunto de atividades realizadas na geração de resultados para o cliente, desde o início do pedido até a entrega do produto.
Segundo o PMBOK [4], é um conjunto de ações e atividades interrelacionadas que são executadas para alcançar um objetivo. Cada processo é caracterizado por suas entradas, as ferramentas e as técnicas que podem ser aplicadas e as saídas resultantes. Vejamos a figura 1 abaixo.
sistemainformacao
Figura 1 – Sistemas de Informação (Laudon, Laudon)

Na gestão de processos negócio (BPM – Business Process Management), processo é uma sequência de tarefas ou atividades, que ao serem executadas transformam insumos em umresultadocom valor agregado. 
Agora, “trocando em miúdo”, vamos imaginar que você deseja montar uma bicicleta,
 qual seria o processo?

  • Entrada (insumos):  os pneus, as rodas, as porcas, parafusos, correntes, etc.
  • Atividades (processamento): montagem do pedal, a inserção das rodas e o ajuste das engrenagem, etc.
  • Saídas (resultado – Produto final): Bicicleta montada.
Esse é um simples exemplo, mas podemos falar em: Processo para “Implantação de um software aplicativo numa empresa”, “Criação de um site de Internet”, “Abertura de uma conta bancária”, “Criação de um conta numa rede social”, “Fazermos um Bolo”, “Trocarmos um pneu do carro”, “Formatarmos uma computador”, “Tirar carteira de motorista”, etc 
Veja abaixo um “Processo de Entrega” de um produto onde a compra foi online.
lojaonline
Figura 2 – Processo de Entrega


Agora que já sabem o que é um Processo, vamos entender melhor o que é um Negócio. Segundo prof. Peter Drucker, sempre insistiu em dizer que Negócio numa empresa deve ser “A questão é que tão raramente perguntamos de forma clara e direta e tão raramente dedicamos tempo a uma reflexão sobre o assunto, que esta talvez seja a mais importante causa do fracasso das empresas.” 
O que este renomado professor sempre quis mostrar com esta afirmação foi que uma organização deve ter uma resposta completa para a seguinte pergunta: “Qual é o Negócio da Nossa Empresa?”. Desta forma, arremetendo aos gestores da empresa a responsabilidade de definir claramente o objetivo da organização.
Como um exemplo que poderá ser conferido no link
acessado em 10.fev.2014), o Negócio de uma empresa deve estar relacionado a um benefício que o produto ou serviço proporciona ao cliente. De acordo com a empresa Kopenhagem, a melhor resposta para a pergunta é “Estamos no Negócio de Presentes”, e não somente “Chocolate”.
Vejam que o cliente perceberá maior valor para um Presente que somente um Chocolate. O serviço ou o produto ofertado pela organização deve ter um valor agregado perceptível e que satisfaça pelo preço pago. Este valor deve beneficiar uma pessoa ou uma comunidade.


Projeto de Interface - Intermediário


Projeto de Interface - Intermediário




Segundo ISO (2007), no campo de usabilidade, é necessário ter as medidas de eficácia, eficiência e satisfação, de acordo com o contexto de uso e das propostas. O nível de detalhes de cada medida dependem dos objetivos das partes envolvidas na medição, devendo ser considerada a importância relativa de cada medida para os objetivos. Essas medidas podem ser especificadas para objetivos globais ou para objetivos menores. Um exemplo de objetivos globais é ilustrado na Tabela 2.
Tabela 2. Exemplo de Medidas de Usabilidade
Medidas de Usabilidade

Objetivos de
Usabilidade

Medidas de
Eficácia

Medidas de
Eficiência

Medidas de
satisfação

Usabilidade global



Porcentagem de objetivos alcançados;


Porcentagem de usuários que completam a tarefa com sucesso;

Média da acurácia de tarefas completadas.


Tempo para completar uma tarefa;

Tarefas completadas por unidade de tempo;

Custo monetário de realização da tarefa.


Escala de satisfação;



Freqüência de uso;



Freqüência de reclamações

Fonte: ISO (2007)
Usabilidade e a interação Homem-Computador: Este link nos complementa um pouco mais a usabilidae:
 Porém, podem ser necessárias algumas medidas adicionais para propriedades particulares do produto que contribuam para a usabilidade, conforme a Tabela 3:

Tabela 3. Exemplo de Medidas para Propriedades Desejáveis do Produto.
Medidas para Propriedades Desejáveis do Produto

Objetivos de
Usabilidade

Medidas de
Eficácia

Medidas de
Eficiência

Medidas de
satisfação
Adequados às necessidades de usuários treinados
Número de tarefas importantes realizadas;
Porcentagem de funções relevantes usadas
Eficiência relativa comparada com um usuário experiente
Escala para satisfação com características importantes
Adequados às necessidades para usar facilmente
Porcentagem de tarefas completadas com sucesso na primeira tentativa
Tempo gasto na primeira tentativa 1) ;
Eficiência relativa na primeira tentativa
Taxa de uso voluntário
Adequados às necessidades para uso não-freqüente ou intermitente
Porcentagem de tarefas completadas com sucesso depois de um período específico sem uso
Tempo gasto reaprendendo funções 1) ;
Número de erros persistentes
Freqüência de reuso
Redução de necessidade de suporte
Número de referências para documentação;
Número de chamadas ao suporte;
Número de acessos para obter ajuda
Tempo produtivo 1) ;
Tempo para aprender por critério 1)
Escala para satisfação com recursos de apoio
Facilidade de Aprender
Número de funções aprendidas;
Porcentagem de usuários que conseguem aprender por critério
Tempo para aprender por critério 1) ;
Tempo para reaprender por critério 1) ;

Escala para facilidade de aprendizado
Tolerância a erros
Porcentagem de erros corrigidos ou apresentados pelo sistema;
Número tolerado de erros do usuário
Tempo gasto na correção de erros
Escala para verificar erros
Legibilidade
Porcentagem de palavras lidas corretamente em uma distância normal de visualização
Tempo para ler corretamente um número especificado de caracteres
Escala para desconforto visual
1) Convém que nesses exemplos os recursos sejam medidos em relação a um nível especificado de eficácia.
Fonte: ISO (2007)
 De acordo com ISO (2007), as medidas de usabilidade dependem dos requisitos do produto e das necessidades da organização. Os objetivos de usabilidade podem ser: primários, menores, ou secundários, em que, determinar objetivos menores pode permitir uma avaliação antecipada no processo de desenvolvimento. Emrelação aos critérios, estes podem reduzir-se ao menor nível aceitável, ou para o nível esperado de usabilidade, e seus valores para um grupo de usuários podem ser uma média, para todos indivíduos ou para uma porcentagem de usuários, tomando-se cuidado para que seja dado o peso apropriado para cada item de medida.

Diretrizes WEB e Desktop
Segundo Chak (2004), o site pode ser projetado para quatro tipos de usuários. Eles representam necessidades de quem navega, e principalmente de quem toma as decisões. São estes: Navegadores, Avaliadores, Realizadores de Transações e Clientes.
Os navegadores procuram por informações para atender suas necessidades, especialmente aquelas que forneçam um contexto para a tomada de decisão. E, os avaliadores procuram por informações detalhadas sobre produtos e serviços oferecidos pelo site em questão. Podendo selecionar produtos ou serviços, este tipo de usuário realiza as avaliações dessas funcionalidades.
Já, os realizadores de transações tomam as decisões de compra pelo site. Podendo oferecer segurança durante o processo, este tipo de usuário realiza as transações. Agora, os clientes são aqueles que já compraram e o interesse neste momento é criar a fidelização destes, a fim de proporcionar outras compras.

Elementos da Interação

Os elementos da interação evoluíram conforme houve o crescimento da tecnologia envolvendo computadores e seus dispositivos interativos. Segundo Pressman (2007), nos primórdios da era do computador o único modo realístico de IHC era a interface de comando e consulta. A comunicação era puramente textual e impulsionada mediante comandos, e respostas a consultas geradas pelo sistema.Esta evolução dos elementos da interação foi inevitável, principalmente quando pensamos que esta depende do usuário. Sendo centrada no usuário a interação tende a ser mais direta e menos restrita, inserindo elementos visuais mais fáceis e amigáveis. A seguir veremos alguns exemplos desses elementos da interação, a maioria deles esta baseada nas diretrizes de Cybis, Betiol e Faust (2007).

Projeto de Interface - Básico




Projeto de Interface - Básico



     Vamos conhecer algumas dicas para construir interfaces homem-computador em sistema desktop e web. As diretrizes para estes sistemas levam em consideração detalhes como o equilíbrio na distribuição dos elementos em tela, cores, menus, ícones e letras apropriadas, entre outras. Tudo isso, torna-se importante na interação com o usuário, pois estamos pensando em alguém que usará as nossas telas aproximadamente oito horas por dia. Segundo Nielsen e Loranger (2007) as interações fundamentais da web não mudam com o passar do tempo. As pessoas continuam clicando em links para navegar pelas páginas, e sua capacidade cognitiva na mudou.
A Web tinha menos de 10 milhões de sites em 2000. E, em 2007, a Web tinha 80 milhões de sites. Hoje a situação é esta: as pessoas simplesmente pressupõem que a Web tem o que elas querem (NIELSEN; LORANGER, 2007).
Então, é essencial possuirmos bom senso na escolha dos elementos que estarão nas telas, também procurando seguir padrões entre essas. Para criar dessa maneira, uma forma de comunicação direta com o usuário, convidando-o para navegar entre as facetas do sistema. Projetar interfaces por modelos conceituais resultam em melhor condução dos caminhos que os usuários utilizarão nos sistemas. Aplicação de diretrizes torna o software tão amigável quanto possível.
 Vamos fundamentar alguns conceitos sobre desenvolvimento de interfaces. Estes servirão de base para as aplicações e testes das diretrizes. Podemos destacar alguns, como:
a)       Interface: “é uma superfície de contato que reflete as propriedades físicas das partes que interagem, as funções a serem executadas e o balanço entre poder e controle” (LAUREL, 1993 apud ROCHA; BARANAUSKAS, 2000, p. 8).
b)       Interface Amigável: São elementos que estão dispostos na interface deixando-a mais agradável do ponto de vista estético;
c)        Interação: É como as pessoas utilizam o computador;
d)       Usabilidade: [...] é a qualidade que caracteriza o uso dos programas e aplicações. Segundo a ISO 9241 usabilidade é a capacidade que um sistema interativo oferece a seu usuário, em determinado contexto da operação, para a realização de tarefas de maneira eficaz, eficiente e agradável (CYBIS; BETIOL; FAUST, 2007, p. 2).
 e)       Design de interação: “significa criar experiências que melhorem e estendam a maneira como as pessoas trabalham, se comunicam e interagem” (PREECE; ROGERS; SHARP, 2005, p. 35).
f)         Modelo mental (MM): “representação dinâmica sobre qualquer sistema ou objeto, que evolui naturalmente na mente de um sujeito” (NORMAN, 1985, p. 94 apud ROCHA; BARANAUSKAS, 2000, p. 91-92).
g)       Modelo Conceitual: “tem haver com a análise das dificuldades no aprendizado de programação, e propõe modelos mentais para auxiliar no contexto das representações computacionais” (ROCHA; BARANAUSKAS, 2000, p. 97).
h)       Ergonomia: visa eficácia e eficiência, bem-estar e saúde do usuário, através da adaptação do trabalho ao homem.
i)          Guidelines: recomendações para assegurar que produtos sejam utilizáveis (PREECE; ROGERS; SHARP, 2005).
j)          Heurística: refere-se a como determinar o que os usuários devem ver e fazer quando realizam tarefas utilizando um produto interativo.
k)        Semiótica:[...] explica a relação entre o objeto, seu representante e o processo de interpretação, no plano dos signos que encontramos ao nosso redor. Na perspectiva semiótica o papel do computador é basicamente o de um medium – uma substância na qual signos podem ser manifestados para uso em comunicação (ANDERSEN, 1997, p. 333).
 l)          Cognição: é o que acontece em nossas mentes quando realizamos nossas atividades diárias, envolvendo processos cognitivos, tais como: pensar, lembrar, aprender, fantasiar, tomar decisões, ver, ler, escrever e falar (PREECE; ROGERS; SHARP, 2005).
m)     Percepção: atividades diárias envolvendo processos, tais como pensar, lembrar, aprender, fantasiar, ver, ler, escrever e falar (PREECE; ROGERS; SHARP, 2005).
n)       Feedback: É a forma de retornar ao usuário informações sobre ação que foram tomadas.
o)       Metáfora de Interface: este conceito provê às pessoas um esquema de funcionamento da interface, prevendo desentendimentos. “Funcionam como modelos naturais, permitindo usar conhecimento familiar de objetos concretos e experiências para dar estrutura a conceitos mais abstratos” (CARROLL et al., 1988 apud ROCHA; BARANAUSKAS, 2000, p. 12).
Segundo Rocha e Baranauskas (2000), interface e interação são conceitos que não podem ser estabelecidos ou analisados independentemente, pois isso seria uma perspectiva simplista desta realidade do desenvolvimento.
Segundo Chak (2004), o site pode ser projetado para quatro tipos de usuários. Eles representam necessidades de quem navega, e principalmente de quem toma as decisões. São estes: Navegadores, Avaliadores, Realizadores de Transações e Clientes.
Os navegadores procuram por informações para atender suas necessidades, especialmente aquelas que forneçam um contexto para a tomada de decisão. E, os avaliadores procuram por informações detalhadas sobre produtos e serviços oferecidos pelo site em questão. Podendo selecionar produtos ou serviços, este tipo de usuário realiza as avaliações dessas funcionalidades.
Já, os realizadores de transações tomam as decisões de compra pelo site. Podendo oferecer segurança durante o processo, este tipo de usuário realiza as transações. Agora, os clientes são aqueles que já compraram e o interesse neste momento é criar a fidelização destes, a fim de proporcionar outras compras.