Uma Reflexão sobre a Qualidade na Engenharia de Software e na Interação Humano-Computador
|
|
- Tiago Minho Bandeira
- 7 Há anos
- Visualizações:
Transcrição
1 Uma Reflexão sobre a Qualidade na Engenharia de Software e na Interação Humano-Computador Resumo: A área de Interação Humano-Computador (IHC) objetiva projetar e desenvolver sistemas com alta usabilidade. Do mesmo modo, a área de Engenharia de Software (ES) objetiva projetar e desenvolver sistemas com alta qualidade. A fim de se ter um processo de desenvolvimento de software com qualidade bem como o produto desenvolvido com usabilidade, é importante se discutir o que qualidade representa em cada uma destas áreas. Mais especificamente, este artigo visa mostrar que é necessário integrar os princípios, técnicas de ES e IHC em um integrado processo de desenvolvimento de sistemas. Palavras-chaves: Princípios de desenvolvimento de sistemas. Qualidade em ES. Qualidade em IHC. Abstract: Human-Computer Interaction (HCI) aims to design and develop highusability software. Analogously, Software Engineering (SE) aims to design and develop highquality systems. In order to achieve both software usability and software process quality, it is paramount to discuss what quality is for each area. More specifically, this work aims to show that it is necessary to integrate HCI and ES principles and techniques into a same development process of systems. Key words: Principles of software development; Quality in ES; Quality in HCI. Tipo do artigo : trabalho técnico 1. Introdução Na comunidade profissional de desenvolvedores de software, estudos realizados na área de Engenharia de Software (ES) (como: os processos e linguagens unificados com diretrizes de acompanhamento) auxiliam a garantir a qualidade de um processo de desenvolvimento de um sistema. Porém, estudos realizados na área de Interação Humano-Computador (IHC) (como: fatores humanos, que ajudam a definir o contexto de uso de um sistema pelo usuário, recomendações ergonômicas, que permitem determinar formas adequadas de apresentação de informação nas telas, etc.) e as práticas existentes (como: projeto participativo, centrado no uso (Constantine et al, 2003)) vêm atraindo cada vez mais atenção da comunidade acadêmica. Isto é devido ao fato da área de IHC objetivar projetar, avaliar e implementar sistemas interativos para uso humano com foco na usabilidade qualidade de uso tal como percebida pelo usuário, e.g. facilidade de uso e aprendizado (Furtado & Barbosa, 2003). Enquanto que, a área de ES objetiva projetar, avaliar e implementar sistemas interativos com qualidade, concentrando-se em cronograma, orçamento, comunicação e produtividade (Boggs, 1999). Para se atingir estes dois objetivos, as comunidades envolvidas estão consciente de que métodos, modelos e ferramentas específicos de cada área deveriam ser integrados. Diversas iniciativas (UPi (Sousa & Furtado, 2003), (Xerre 2003), (Paula & Barbosa, 2003)) são voltadas à integração destes estudos e práticas em um processo integrado de
2 desenvolvimento de software, que atinja não apenas a qualidade do ponto de vista do sistema, mas a qualidade de uso deste sistema do ponto de vista de seus usuários. O objetivo deste trabalho não é de mostrar mais uma solução de um processo integrado de desenvolvimento de software. O objetivo é mostrar o que significa desenvolver um produto com sucesso, para as duas áreas, respeitando a conceituação de cada uma. Além disto, se quer mostrar que é possível haver esta integração através da aceitação dos princípios adotados em cada área, mas que os desafios ainda são grandes. Este texto está organizado da seguinte maneira: após uma breve conceituação sobre sistemas interativos e sobre as duas áreas em estudo, será feita uma reflexão sobre a integração de ES e IHC para se obter sistemas com mais qualidade e mais usáveis. 2. Conceituação 2.1. Software e Sistema Interativo Um software é um conjunto de programas de computador e a documentação associada (Sommerville, 2003). A noção de Sistema Interativo (SI), comumente usada em IHC, abrange este conceito, mas dar ênfase no fato de que os programas são manipulados pelo usuário, havendo assim interação entre o ser humano e o computador. O sucesso desta interação depende da forma como os componentes de um SI são modelados. Estes componentes são: a aplicação e interface. A aplicação se refere à parte não interativa do sistema (como os dados e as funções que regem as regras de negócio do sistema sendo modelado). A Interface se refere à parte interativa do sistema (como os dados e as funções responsáveis de permitir a interação entre o usuário e o sistema) Engenharia de Software Engenharia de software é a disciplina da engenharia que se ocupa dos aspectos da produção de um software, principalmente aqueles obtidos durante o desenvolvimento sistemático do software (como as características de um software que satisfariam às necessidades de um usuário) e o gerenciamento do processo de desenvolvimento (como o controle de mudanças de requisitos). Esta disciplina disponibiliza modelos, técnicas e ferramentas para dar apoio à produção de software. Estes recursos devem ser disponibilizados, de maneira organizada, para facilitar sua aplicação e utilização. Diante desta necessidade, surgem os processos de software. Um Processo de Desenvolvimento de Software (PDS) é um conjunto de atividades descritas com o objetivo de desenvolver ou manter um software. As atividades devem ser desempenhadas por uma equipe, que aplica técnicas e faz uso de modelos e ferramentas, quando disponíveis. Um método de desenvolvimento de software aplicado em uma empresa, por exemplo, pode ser visto como uma instância de um PDS, fornecendo uma estruturação própria que envolve um conjunto de tarefas, tais como: análise de requisitos, projeto, construção de programa,
3 teste, e manutenção. Além disto, um método inclui um conjunto de princípios básicos, regras, recomendações de projeto e diretrizes de processos, que ajudam a bem definir os requisitos para um software. Alguns requisitos não-funcionais que contribuem para a qualidade de um software construído são os seguintes: confiabilidade, funcionalidade, usabilidade, manutenibilidade, desempenho e portabilidade. As ferramentas que promovem um suporte automático ou semi-automático para processos e métodos são conhecidas como ferramentas CASE (Computer-aided software engineering) e combinam software, hardware e base de dados para a geração de um ambiente de engenharia de software. De uma forma geral, durante um PDS, algumas questões devem ser respondidas: - Qual o problema a ser resolvido? - Quais as características do produto (técnicas ou de outra ordem), que são utilizadas para resolver o problema? - Como esse produto será construído de forma a garantir qualidade no processo? - Como descobrir erros, que foram cometidos no projeto e na construção do produto, sem ultrapassar o cronograma e orçamentos pré-estabelecidos? O Rational Unified Process (RUP) (Kruchten, 2000) é um exemplo de processo voltado para a qualidade de software, que auxilia desenvolvedores a responderem estas questões. Este processo se baseia nas melhores práticas de desenvolvimento de software (tais como: desenvolver software de forma iterativa, gerenciar requisitos, utilizar arquiteturas baseadas em componentes) consideradas como tal por serem utilizadas comumente em organizações bem sucedidas. Entretanto, seguir estas práticas e estratégias não garante a usabilidade. Práticas devem ser adotadas que integrem métodos, modelos e técnicas estudados em IHC com aqueles estudados em ES Interação Humano-Computador É a disciplina preocupada com o projeto, avaliação e implementação de um SI para o uso humano e com o estudo dos principais fenômenos ao redor dele, como a área de aplicação, o contexto de uso do usuário, etc. (Rocha & Baranauskas, 2003). A qualidade do uso de um SI está ligada a três conceitos: Utilidade, capacidade e usabilidade (Constantine & Lockwood, 1999). Utilidade significa que o sistema realiza algo de valor para o usuário, ou seja, algo que justifica o investimento no desenvolvimento do sistema. Vale ressaltar que pesquisas em ES,
4 mais especificamente na engenharia reversa, têm sido feitas aplicando métricas de usabilidade a um SI para verificar se justifica o investimento no reprojeto deste sistema (Silva et al, 2003). Capacidade significa que o sistema realiza o que o usuário espera que ele realize, ou seja, as funcionalidades do sistema devem estar de acordo com as tarefas que o usuário precisa realizar. Na ES, este conceito é atingido através de um processo contínuo de verificação e validação das funcionalidades do sistema (Sutcliffe, 2002). Usabilidade significa que o sistema dispõe de funcionalidades que são fáceis de aprender, usar e também significa que o sistema é agradável de forma que o usuário fica satisfeito ao usá-lo. Tal conceito é definido na ISO , que descreve uma maneira para medir o desejado nível de usabilidade. A maioria das técnicas existentes em IHC (como prototipagem, cenários) e princípios (como princípios ergonômicos) tem ênfase na obtenção deste conceito. Como por exemplo, a utilização de cenários durante o desenvolvimento de um SI objetiva captar com realismo os detalhes da interação do usuário com o sistema em desenvolvimento, como: o contexto de uso deste. Os trabalhos realizados em ES quase que ignoram esta percepção. Em geral, estes três conceitos agem diretamente sobre a aceitabilidade de um SI pelo usuário e/ou cliente. Eles são importantes para que os desenvolvedores percebam que projetar sistemas com qualidade, é antes de tudo, considerar os usuários, o uso que eles farão dos sistemas (as tarefas) e o contexto de uso (condições ambientais) e não somente as funcionalidades dos sistemas. Para as aplicações mais modernas, como as móveis, a aceitabilidade depende também da avaliação da mobilidade do equipamento, como o peso e resistência a choques. Quanto às ferramentas que apóiam o processo automático ou semi-automático de geração de interfaces de usuário, destacam-se: Geradores de interface - que apóiam a especificação gráfica das interfaces e o tratamento dos eventos sobre os objetos, como por exemplo, módulos contidos nos ambientes de programação, como Delphi. Tecnologias open-source dentre elas, destacam-se os frameworks da linguagem Java: struts, que apóia a especificação conceitual das interfaces (sem detalhes de visualização), e suas relações de navegação e composição fazendo uso de padrões de projeto, e o Java server Faces, que apóia a seleção dos objetos interativos das interfaces, o tratamento dos eventos sobre os objetos, e o suporte à internacionalização e acessibilidade do sistema sendo construído. Para se obter a qualidade em IHC, do ponto de vista dos três conceitos acima, durante a realização de um PDS, algumas questões devem ser respondidas, como: - Quais as necessidades do usuário e/ou cliente? Dentre elas se incluem as necessidades de usabilidade, que se referem às user experience goals (como
5 a necessidade que o usuário tem que o sistema seja agradável, divertido, etc.) (Preece, 2002). - Quais as características do SI, que são utilizadas para atender os requisitos de usabilidade? - Como as possibilidades de interação do SI serão construídas de forma a garantir a usabilidade? Que modelos de IHC podem ser usados para esta construção? - Como descobrir erros de usabilidade, que foram cometidos no projeto e na construção do produto? Que técnicas de avaliação de IHC podem ser usadas? 2.4. Análise Comparativa A tabela 1 ilustra uma comparação que abrange as duas áreas citadas. A necessidade de se estudar aspectos relativos ao desenvolvimento sistemático de um software e o gerenciamento do seu processo de desenvolvimento surgiu na década de 70. Enquanto que a disciplina de IHC surgiu uma década depois, objetivando resolver problemas de usabilidade. A qualidade para ES está diretamente ligada ao gerenciamento do processo para que se obtenha produtos com mais qualidade. No entanto, um processo com qualidade não garante a qualidade do produto gerado. Para IHC, o foco está na qualidade de uso. Os modelos desenvolvidos em ES dizem respeito à modelagem das entidades e funções da aplicação, enquanto que em IHC, os modelos são mais concretos, representando características pertinentes à interação entre um usuário e um SI (tais como: suas tarefas, estrutura navegacional entre as telas, etc.). Isto porque, usuários preferem modelos que possam ser capazes de fazê-los entender o impacto que o novo sistema terá sobre eles. Enquanto em ES, desenvolvedores requerem modelos abstratos que possam ajudá-los a saber o que implementar. Quanto às características do produto, na ES pretende-se desenvolver um produto que atenda todos os requisitos estabelecidos, enquanto que em IHC, deve-se atender os requisitos de usabilidade levando-se em consideração os padrões de usabilidade préexistentes. Quanto aos modelos de ciclo de vida, na ES destacam-se os modelos em cascata (Royce, 1970), que evidencia a seqüência em cascata de uma fase para outra e o espiral (Boehm, 1988), que representa um PDS em muitos loops permitindo a avaliação e redução de riscos. Em IHC, existem dois modelos: modelo em estrela (Hix & Hartson, 1993), cuja atividade central é a avaliação e o início de um PDS pode acontecer por qualquer uma das demais atividades (projeto, implementação, etc.) e o modelo de engenharia da usabilidade (Mayhew, 1999), que é composto de três fases: iniciação, desenvolvimento e transição. Na primeira fase, um guia de estilo já é definido. Durante as diversas iterações na fase de desenvolvimento, este
6 guia de estilo é melhorado e validado, através de protótipos. Na última fase, o produto é entregue ao usuário final. Ambas as áreas têm em comum o uso de padrões, que representam soluções já bem aceitas na comunidade para resolver um certo problema. Para IHC, os padrões são de projeto da interação, e objetivam mostrar, por exemplo, como definir os objetos de uma tela destinada para a realização de tarefas de manutenção (Pribeanu & Vanderdonckt, 2003). Estes padrões são definidos de acordo com diversos tipos de recomendações ergonômicas expressas em padrões ou normas (como a ISO (International Standards Organization) na Europa e a HFES (Human Factors and Ergonomics Society) nos Estados Unidos) e em guias de estilo, que são documentos que normalmente são produzidos por uma organização e disponibilizados comercialmente (Vanderdonckt, 1999). Em ES, os padrões são de projeto de sistemas (chamados design patterns (Gamma et al, 1995)). Eles objetivam mostrar soluções para realizar a modelagem da aplicação de forma a garantir sua flexibilidade, portabilidade e extensibilidade. O uso de design patterns está bem difundido porque ferramentas de modelagem, como o ROSE, permitem a integração de classes, que descrevem um padrão de projeto, em um diagrama de classes da aplicação descrito em UML. No entanto, os padrões de IHC ainda não possuem uma única terminologia nem ferramentas capazes de permitirem seu uso. Tabela 1 - Comparação entre ES e IHC Fatores Engenharia de software Interação Humano- Computador Origem Década de 70 Década de 80 Foco A modelagem recai sobre Qualidade do processo e do produto as entidades e funções da aplicação Qualidade do uso (Utilidade, capacidade e usabilidade) as tarefas, a navegação, a interação Modelos de ciclos de vida Cascata, espiral Estrela e de Usabilidade Características do produto Uso de Padrões Devem atender requisitos funcionais e não-funcionais De Projeto (apoio à modelagem e implementação da aplicação) Devem atender requisitos de usabilidade De Usabilidade (apoio ergonômico à modelagem das interfaces)
7 A seguir, será feita uma reflexão sobre a integração de princípios de ES e IHC para se obter sistemas com mais qualidade e mais usáveis. 3. Reflexão sobre a Integração da Engenharia de Software e Interação Humano- Computador 3.1. Princípios aplicados ao Processo Existem princípios em ES e em IHC que regem as pesquisas e estudos para se desenvolver sistemas mais confiáveis e mais usáveis, como: princípio da independência do diálogo, projeto centrado no uso e no usuário, geração do software baseado em modelos e processo interativo, incremental e evolutivo. Princípio de independência do diálogo Geralmente, problemas de desenvolvimento e de manutenção de um SI são, em grande parte, devido à má estruturação da modelagem das especificações (dados e funções de um sistema). Para atenuar estes problemas, vários métodos de desenvolvimento apóiam esta modelagem, como a modelagem CRC (Ambler, 1997). No entanto, esses métodos falham por não especificarem claramente como respeitar o princípio da independência do diálogo humanocomputador, isto é, como modelar a aplicação de forma independente da interface. O objetivo deste princípio é garantir, por exemplo, que uma função da aplicação associada a um objeto interativo não realize cálculos relevantes à aplicação e à interface. Assim, se uma estrutura da aplicação ou da interface for modificada somente os aspectos interativos ou não interativos associados a esta estrutura respectivamente, devem ser modificados. A utilização de modelos de arquitetura auxilia desenvolvedores a respeitarem este princípio, pois tais modelos permitem a organização dos sistemas segundo um determinado padrão. O modelo de arquitetura PAC (Coutaz, 1994), oriundo de IHC, auxilia na estruturação de um SI através de agentes, garantindo sua modularidade. A adoção de processos centrados na arquitetura, como o RUP, favorece a utilização destes tipos de modelos de arquitetura, evidenciando oportunidades de integração de IHC em ES. Projeto centrado no usuário e Projeto centrado no uso O projeto centrado no usuário enfatiza que o propósito do sistema é atender as necessidades do usuário através da participação. O PDS é iterativo e dirigido pelas características do usuário, suas tarefas e de seu contexto de uso, que são usadas para guiar o projeto de um SI. Depois do projeto definido, os usuários avaliam o protótipo fornecendo sugestões. Este princípio está descrito na ISO O projeto centrado no uso representa uma mudança deste foco, pois não é o usuário que precisa ser conhecido, mas o uso que ele faz do SI que interage (Constantine & Lockwood,
8 1999). Neste princípio, o envolvimento dos usuários é seletivo, ou seja, existe a necessidade de comunicação entre usuários e projetistas, que precisam entender os usuários para definirem como acontecerá o uso do sistema. Depois, os projetistas, e não os usuários, fazem a validação dos modelos e a inspeção de usabilidade através da aplicação de métricas de qualidade. O PDS possui uma abordagem sistemática, iterativa e dirigida por modelos. A escolha entre estes princípios depende dos tipos de usuários em questão e da habilidade dos projetistas de envolverem os usuários durante um PDS e/ou para modelarem um SI. Existem problemas com relação à participação do usuário (tais como: usuários podem não ser conhecidos e/ou acessíveis, eles podem ter dificuldade de comunicação com os projetistas, etc.). Mas existem também dificuldades na aplicação do projeto centrado no uso. As métricas de qualidade devem ser baseadas em princípios ergonômicos, muitos projetistas não verificam facilmente a aplicação destes princípios e preferem que os usuários, eles mesmos, testem o protótipo. Geração de um SI baseada em modelos Existem algumas formas de se gerar um SI, as quais destacam-se a geração baseada em código e a geração baseada em modelos. No primeiro caso, distinguem-se duas épocas. A época dos anos 70, em que um PDS era dirigido pela experiência e talento do desenvolvedor tendo como foco a implementação, e a época atual, em que se destacam os processos ágeis. Num processo ágil, como Extreme Programming - XP (Beck, 1999), se privilegia a fase de projeto depois da realização das fases de levantamento de requisitos, teste e codificação, onde é gerada uma versão ou protótipo do sistema. Enfim, primeiro se testa e valida com o cliente o que foi levantado e depois se faz o projeto, verificando o que tem a ser acrescentado à versão anterior. Não existe a prática de realizar modelos. Mesmo que existam na literatura, iniciativas bem sucedidas de processo ágil, verifica-se que elas não têm foco na usabilidade. O foco está na visão pragmática de colaboração com diversos stakeholders (equipe de desenvolvimento, cliente, usuário), a fim de atender as necessidades do cliente dentro de prazos e orçamento que vão se definindo à medida que um PDS vai sendo realizado. Fazer um projeto iterativo e incremental (ver próx. item), bem como usar protótipos podem melhorar esta situação. Outra característica que dificulta a adoção desses processos diz respeito à dificuldade de equipes, que não participaram da construção de um SI, em suportarem a evolução deste sistema, devido à pouca especificação formal das decisões de projeto. A adoção de modelos (como modelo de casos de uso e diagrama de colaboração) ajuda desenvolvedores a representarem especificações genéricas (como as necessidades dos usuários) e especificações detalhadas (como a troca de mensagem entre objetos que colaboram), respectivamente. Uma vez representadas as especificações, é possível fazer a integração entre elas. No próximo item, serão mostrados os modelos de ES que podem ser
9 integrados aos modelos de IHC, para a descrição de requisitos. Outra vantagem de se usar modelos, é a possibilidade de se fazer matrizes de rastreabilidade, auxiliando na realização de testes, implementação e manutenção de um SI. Existem na literatura de IHC várias ferramentas que geram interfaces de forma automática a partir de modelos (tal como: ARTStudio (Thevenin 2001)), porém ainda não existe nenhuma ferramenta comercial disponível. A ferramenta CASE ROSE permite a geração de scripts de classes a partir dos modelos de dados. Processo iterativo, incremental e evolutivo Já é consenso nas áreas em estudo, que um PDS deve ser iterativo (com ciclos, compostos de fases de um PDS, sendo realizados diversas vezes) e incremental (a cada ciclo, novas funcionalidades são acrescidas à versão anterior). Diante disto, estes tipos de modelos de ciclos de vida (como espiral, cone (Furtado & Soares, 2003)) têm influenciado na descrição de processos, como RUP e UPi (Sousa & Furtado, 2003) respectivamente. Além disto, os processos devem garantir a possibilidade de se realizar mudanças de forma contínua, em tempo hábil e mantendo a coerência com as outras decisões já tomadas. Isto porque existe atualmente uma necessidade para se assegurar continuamente a qualidade de um SI já entregue ao cliente, devido às mudanças tecnológicas e do contexto organizacional e devido à evolução das necessidades do usuário. A evolução das necessidades do usuário (como uma mudança de prática e método de trabalho) pode envolver modificações das características do sistema, como por exemplo, de decisões de projeto. No próximo item, serão mostradas iniciativas que integram artefatos e técnicas de IHC e ES durante somente as atividades de modelagem e de validação de requisitos para gerar interfaces. Esta restrição se deu devido às limitações de tamanho deste artigo Uma reflexão sobre a integração de IHC e ES para gerar interfaces considerando requisitos funcionais Definição de Requisitos Funcionais Durante o levantamento de requisitos, as necessidades dos usuários são levantadas (como suas razões para requerer o projeto). Em seguida, elas são associadas a um ou mais requisitos, os quais se referem a fatores, que especificam o que será o produto desejado (de acordo com um requisito de usabilidade, que especifica por exemplo que um SI tem que ser agradável) e como ele funcionará (de acordo com os requisitos funcionais). Estes requisitos funcionais devem ser analisados e documentados usando diferentes técnicas (modelagem de tarefas, de casos de uso, etc.) e artefatos vindas de IHC e ES. A seguir, serão analisados os artefatos mais usados e que são capazes de expressarem os objetivos do usuário e suas tarefas. São eles: cenários, storyboards, casos de uso e tarefas.
10 cenário, que se refere a uma narrativa que descreve situações sobre as pessoas (seu papel, características) realizando atividades dentro de um ambiente para alcançarem seus objetivos. O uso de cenários se trata de uma metáfora facilmente aceita pelos usuários que os encoraja a participar de um PDS. Assim, facilitando a validação de suas necessidades; storyboard, que é um esquema ilustrativo para representar uma seqüência de comportamentos de um sistema em desenvolvimento com uma descrição contextual. Isto permite a exploração e discussão de diferentes escolhas de projeto das interfaces conceituais (Furtado, 1999); caso de uso; dentre as definições existentes em ES, destaca-se que um caso de uso representa a funcionalidade que um SI tem que realizar para retornar um resultado de valor para um ator (tais como: um usuário, ou outro sistema) e; tarefa; na concepção de interfaces, uma tarefa especifica o conjunto de atividades que o usuário e/ou o SI deve executar para que um determinado objetivo seja alcançado. A estrutura organizacional hierárquica dos modelos de tarefa permite acompanhar claramente a seqüencialidade e concorrência entre as tarefas Iniciativas que integram IHC e ES para gerar interfaces considerando requisitos funcionais Iniciativas existentes de geração de interfaces considerando requisitos funcionais descrevem formas diferentes de se usar cenários, storyboards, casos de uso e tarefas. Estas formas dizem respeito à como estes artefatos são integrados, especificando que informações de um são mapeadas em outro artefato e em que atividades de um PDS eles são usados. A seguir, serão descritas algumas iniciativas. Sutcliffe (2002) descreve um método para fazer a modelagem e validação de requisitos baseada em cenários. O objetivo desta fase é identificar os requisitos com a participação do usuário, numa abordagem de projeto centrado no usuário. Os requisitos identificados através dos cenários são discutidos e expressos em storyboards. O próximo passo é analisar a viabilidade dos requisitos de usabilidade fazendo um estudo sobre as opções de projeto usando árvores de decisão. Em seguida, protótipos são usados para facilitar na validação dos requisitos. Numa abordagem centrada no uso, Constantine e seus colegas (2003) propõem um método ágil com o objetivo de gerar rapidamente a interface a partir de requisitos modelados em task case ou caso de uso essencial Este conceito se refere, principalmente, a uma simplificação do conceito de caso de uso, no que diz respeito à descrição do fluxo de eventos. Nesta descrição, expressas em cartões, devem constar, de forma sucinta, as intenções do usuário com as
11 responsabilidades do sistema associadas. Uma vez validadas estas descrições, usuários, clientes e projetistas devem construir juntos um protótipo abstrato da interface (protótipos não operacionais) usando post-id e um quadro branco. Só então os protótipos interativos são construídos. Suarez (2004) descreve um método de desenvolvimento de SI baseado em modelos, em que o objetivo é gerar um protótipo abstrato da interface (modelo de interação) a partir de requisitos modelados em tarefas, precedidos ou não por uma modelagem de caso de uso. Durante a passagem de um modelo de tarefa para um modelo de interação, este trabalho faz uso do conceito de cenários, que são compostos de cenas, que por sua vez, são compostas de ações. Através da modelagem de cenários foi possível para os autores organizarem as tarefas que irão ser realizadas dentro de uma tela, por exemplo. A partir desta análise, percebeu-se que estes tipos de técnicas e artefatos podem ser usados através de diferentes combinações, pois cada técnica é mais apropriada para um certo tipo de modelagem. Como cenários não são apropriados para capturarem todos os conjuntos de requisitos, mas de oferecerem visões particulares de certas situações, o uso de storyboard poderia ser útil, dada sua capacidade de explorar diferentes opções de projeto. Embora casos de uso sejam focados nos objetivos de usuários, sua ênfase está na interação entre usuário e sistema antes que nas tarefas do usuário em si (Preece at al, 2002). Isto é porque eles contêm certas especificações sobre a interface e o tipo de interação para ser projetado incluindo aspectos tecnológicos. Casos de uso essenciais (Constantine and Lockwood, 1999) tentam evitar estas especificações, definindo somente que usuários são responsáveis (suas intenções) e o que o sistema tem que fazer. Representando casos de uso genéricos, estas especificações poderiam ser expressas em modelos de tarefas, que são mais estruturados. A combinação entre estas técnicas é também importante porque inexiste uma mesma terminologia envolvendo os conceitos usados nos artefatos das duas áreas. Isto se deve em parte devido à dificuldade em integrar conceitos de IHC, que são embasados em diversas disciplinas como a comunicação, ergonomia, com os modelos abstratos da ES, centrados na implementação de um SI. A reflexão realizada foi limitada à modelagem de requisitos, mas são necessárias ainda outras iniciativas para se refletir sobre alternativas para elaborar todo um processo integrado de desenvolvimento de sistemas interativos. Enquanto isto, a autora deste artigo concorda com a seguinte afirmação de Sutcliffe (2002): o sucesso de um SI depende da complexa relação entre os requisitos modelados sendo validados no projeto, requisitos estes que podem evoluir, e o grau de satisfação do usuário em adquirir o produto desejado.
12 4. Conclusão Este artigo objetivou iniciar uma discussão sobre a qualidade na Engenharia de Software e na Interação Humano-Computador considerando os conceitos, princípios, técnicas e artefatos usados em cada área. Mostrou-se que a integração destas áreas vem acontecendo, mesmo que ainda de forma tão restrita, devido à falta de ferramentas e de envolvimento entre as equipes, às formas diferentes de se modelar informações, à não convergência de princípios, etc. Propôs-se que iniciativas sejam realizadas para se pensar sobre um PDS totalmente integrado. Estas iniciativas poderiam se manifestar de diversas formas, como através de workshops e de artigos científicos publicados, havendo a apresentação de exemplos práticos e com resultados concretos para a qualidade e usabilidade, bem como o envolvimento de empresas e da academia Estas iniciativas poderiam ajudar desenvolvedores a tirarem suas próprias conclusões, em função das especificidades de cada projeto a ser desenvolvido, sobre as seguintes questões: Que tipos de modelos e técnicas de IHC e ES podem ser considerados num processo integrado de desenvolvimento de software? Quando e como pode ser realizada esta integração? Como esta integração pode contribuir para se obter softwares mais usáveis e um processo com mais qualidade? Quais são as vantagens e desvantagens deste processo integrado de desenvolvimento de software? Como fazer com que os envolvidos (analistas, ergonômos, web designers) participem mais e integrem suas atividades? Referências Bibliográficas Ambler, S.W. (1997). Análise e projeto Orientados a objeto. IBPI Press. BECK, K. C. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Pub Co; 1st edition. Boehm, B.W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5). Boggs W., (1999). Mastering UML with rational Rose, Sybex. Constantine L., Windls, H., Nolbe, J., Lockwood. L. (2003). From abstraction to realization in User Interface Designs: Abstract Prototype Based on Canonical Abstract Components. Working paper on Tutorial Usage-centered Software Engineering. ICSE 03. Portland. Oregon. Coutaz J., (1994). A reference model for the software design of interactive systems. Ferre X., (2003). Integration of Usability Techniques into the Software Development Process. In ICSE 03 (International Conference on Software Engineering). Portland, Oregon. May. Furtado, E., Barbosa S., (2003). Reflexão sobre a Integração de Modelos, Técnicas e Métodos de IHC e ES em um Processo de Desenvolvimento de Software. In WIHC-ES 2003.
13 Furtado, E., Soares, S. K., (2003). Furtado, Elizabeth; Sousa, Kenia. A User Interface Generation Process Based on the RUP and Represented in a New Spatial Organization. Available in: < Accessed in: October 15, Gamma et al, (1995). Gamma, E; Helm, R; Johnson, R; Vlissides, J. Design Patterns Elements of Reusable Object-Oriented Software. London: Addison-Wesley, Hix D., Hartson, R. (1993). Developing User Interfaces. Wiley. Kruchten, P. (2000). The Rational Unified Process: An Introduction. 2 ed. New Jersey: Addison-Wesley, Mayhew D.J. (1999). The usability engineering lifecycle. San Francisco: Morgan Kaufmann. Paula, M. Barbosa, S.D. J., (2003). Interaction Modeling as a Resource for Software Specification. In WIHC-ES Rio de janeiro. Agosto. Pimenta, M.S. Vedoato R., (2003). Use cases and Scenarios: a teleological approach aiming the integration of HCI and SE perspectives. In WIHC-ES Rio de janeiro. Agosto. Preece J., Interaction Design: Beyond Human-computer interaction Pribeanu, Costin; Vanderdonckt, Jean. A Pattern-Based Approach to User Interface Development. In: Proc. Of 9th Conf. On Human-Computer Interaction HCI International 2003, Vol. 4, Lawrence Erlbaum Associates, 2003, pp Rocha H. V., Baranauskas, C., (2003). Design e Avaliação de Interfaces Humano- Computador. Unicamp SP. Royce, W.W. (1970). Managing the development of lage software systems: concepts and tecnhiques. Proc. IEEE Weston, Los Angeles, CA. Silva J., Olher M., Júnior, S. (2003). Virtual reality and Reengineering: Challenges for the software process based on a single vision of SE and HCI. In WIHC-ES Rio de janeiro. Agosto. Soares, S. K., Furtado, E.. (2003). A Unified Process for Interactive Systems. In WIHC- ES Rio de janeiro. Agosto. Sommerville I.,(2003). Engenharia de Software, 6ª edição. Addison Wesley. Suarez P. R. (2004). Gestão do conhecimento no processo de concepção de IHC e uma nova abordagem para a obtenção de uma especificação conceitual da interação. Dissertação de mestrado. UFCg. Sutcliffe, A, (2002). User-Centred requirements engineering. Theory and Practice. Springer- Verlag. London. Thevenin D. (2001). Adaptation en Interaction Homme-machine: le cas de la plasticité. Phd Thesis of the University Joseph-Foureier Grenoble I. Vanderdonckt J., (1999). Developing Milestones toward a Tool For Working With Guidelines. Interacting with Computers 12, 2. (pp ).
Capítulo 2. Processos de Software. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1
Capítulo 2 Processos de Software slide 1 Tópicos apresentados Modelos de processo de software. Atividades de processo. Lidando com mudanças. Rational Unified Process (RUP). Um exemplo de um processo de
Leia maisEngenharia 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
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 Cronograma das Aulas. Hoje você está na aula Semana
Leia maisProcessos de Software
Processos de Software Prof. Márcio Lopes Cornélio Slides originais elaborados por Ian Sommerville O autor permite o uso e a modificação dos slides para fins didáticos O processo de Um conjunto estruturado
Leia mais3. Fase de Planejamento dos Ciclos de Construção do Software
3. Fase de Planejamento dos Ciclos de Construção do Software A tarefa de planejar os ciclos de construção do software pode partir de diretrizes básicas. Estas diretrizes visam orientar que os ciclos de
Leia mais3 Qualidade de Software
3 Qualidade de Software Este capítulo tem como objetivo esclarecer conceitos relacionados à qualidade de software; conceitos estes muito importantes para o entendimento do presente trabalho, cujo objetivo
Leia maisAula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW
Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto
Leia maisMetodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr
Metodologia de Desenvolvimento de Software Prof. M.Sc. Sílvio Bacalá Jr Objetivos Discutir aspectos de Engenharia de Software Aplicar um método de desenvolvimento para especificação e projeto de software
Leia maisIntrodução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004
Introdução ao RUP Rational Unified Process por Denize Terra Pimenta Outubro/2004 1 Contexto Não é suficiente apenas a presença de desenvolvedores altamente treinados: Precisamos de uma linguagem para a
Leia maisUnidade II MODELAGEM DE PROCESSOS
Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que
Leia maisnatureza do projeto e da aplicação métodos e ferramentas a serem usados controles e produtos que precisam ser entregues
Modelo De Desenvolvimento De Software É uma representação abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software serão conduzidas e interrelacionadas
Leia maisUNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT
UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO DEPARTAMENTO DE ESTATÍSTICA E INFORMÁTICA BACHARELADO EM SISTEMAS DE INFORMAÇÃO RAPID APPLICATION DEVELOPMENT Disciplina: Modelagem a Programação Orientada a Objetos
Leia maisA construção de um manual sobre a utilização dos modelos também poderá alavancar o uso das representações. Este conteria a explicação detalhada da
6 Conclusões No âmbito do framework teórico da Engenharia Semiótica, este trabalho faz parte de um esforço conjunto para desenvolver ferramentas epistêmicas que apóiem a reflexão do designer durante o
Leia maisOS BENEFÍCIOS DA INTEGRAÇÃO DA ENGENHARIA DE SOFTWARE E DA INTERAÇÃO HUMANO-COMPUTADOR NO DESENVOLVIMENTO DO SOFTWARE CATALÓG RESUMO
OS BENEFÍCIOS DA INTEGRAÇÃO DA ENGENHARIA DE SOFTWARE E DA INTERAÇÃO HUMANO-COMPUTADOR NO DESENVOLVIMENTO DO SOFTWARE CATALÓG THE BENEFITS OF INTEGRATION OF SOFTWARE ENGINEERING AND HUMAN- -COMPUTER INTERACTION
Leia maisRequisitos do usuário, do sistema e do software [Sommerville, 2004]
Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que
Leia maisRUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP
RUP Rational Unified Process ( Unificado de Desenvolvimento da Rational) Conjunto de passos que tem como objetivo atingir uma meta de software na ES, processo que visa a produzir o software - de modo eficiente
Leia maisEngenharia de Software
Engenharia de Software Conceitos e Metodologias para Desenvolvimento de Software Cascata, Prototipação, Espiral e RUP Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br
Leia maisGuia de utilização da notação BPMN
1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação
Leia maisEduardo Bezerra. Editora Campus/Elsevier. Princípios de Análise e Projeto de Sistemas com UML - 2ª edição
Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier 1 Capítulo 2 Processo de Desenvolvimento de Software Quanto mais livros você leu (ou escreveu), mais
Leia maisProfessor: Curso: Disciplina: Aula 4-5-6
Professor: Curso: Disciplina: Aula 4-5-6 Turma: Esp. Marcos Morais de Sousa Sistemas de informação Engenharia de Software I Engenharia de Requisitos 03º semestre 1 Engenharia de Requisitos Prof. Marcos
Leia maisIntrodução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento de 4ª geração Terceirização
Prof. Ricardo José Pfitscher Material elaborado com base em: José Luiz Mendes Gerson Volney Lagemann Introdução Ciclo de vida tradicional de desenvolvimento Prototipagem Pacotes de software Desenvolvimento
Leia maisO Processo Unificado
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA O Processo Unificado 879SCC Projeto e Desenvolvimento de Sistemas
Leia maisO Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no
1.1 RATIONAL UNIFIED PROCESS (RUP) O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no processo que atende pelo nome de Processo Unificado (ou UP do inglês Unified
Leia maisCurso: Engenharia de Software com Ênfase em Padrões de Software (UECE Universidade Estadual do Ceará) RUP
Conceitos RUP RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo de Engenharia de software criado pela Rational Software Corporation(a qual foi incorporada pela
Leia maisEngenharia de Software II
Engenharia de Software II Aula 14 Revisão http://www.ic.uff.br/~bianca/engsoft2/ Aula 14-07/05/2006 1 Processo de Software Qual é a diferença entre uma atividade de arcabouço e uma atividade guarda chuva?
Leia maisUM ESTUDO SOBRE A INTEGRAÇÃO DE ASPECTOS DA INTERAÇÃO HUMANO-COMPUTADOR NOS MÉTODOS DE DESENVOLVIMENTO DE SISTEMAS INTERATIVOS
UM ESTUDO SOBRE A INTEGRAÇÃO DE ASPECTOS DA INTERAÇÃO HUMANO-COMPUTADOR NOS MÉTODOS DE DESENVOLVIMENTO DE SISTEMAS INTERATIVOS Sarah Sther Chagas de Aquino MONOGRAFIA APRESENTADA AO CENTRO DE CIÊNCIAS
Leia maisESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE
ESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE Fabiana Gomes Marinho Faculdade Lourenço Filho Resumo: Na UML, a modelagem conceitual dos dados é descrita pelo diagrama de classes, que através
Leia maisApresentar os conceitos básicos da metodologia de desenvolvimento Processo Unificado, utilizando como aporte o Processo Unificado Rational RUP
Fábio Lúcio Meira Objetivos Gerais Apresentar os conceitos básicos da metodologia de desenvolvimento Processo Unificado, utilizando como aporte o Processo Unificado Rational RUP Específicos Apresentar
Leia maisIntrodução à. Engenharia de Software. Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.
"Antes de imprimir pense em sua responsabilidade e compromisso com o MEIO AMBIENTE." Engenharia de Software Introdução à Engenharia de Software Givanaldo Rocha de Souza givanaldo.rocha@ifrn.edu.br http://docente.ifrn.edu.br/givanaldorocha
Leia maisUnidade I Conceitos BásicosB. Conceitos BásicosB
à Engenharia de Software Unidade I Conceitos BásicosB Pedro de Alcântara dos Santos Neto pasn@ufpi.edu.br 1961 a 1963 Surgimento de novos Hardwares 1963-1968 Crise do Software! Incapacidade de se utilizar
Leia maisMauricio Barbosa e Castro
Mauricio Barbosa e Castro A interação homem-computador está muito relacionada com o processo de projeto, provendo soluções que levam em consideração todas as restrições e requisitos. O aspecto de projeto
Leia maisAnálise de Sistemas. Contextualização. O Sucesso. Aula 4. Instrumentalização. Aula 4. Prof. Emerson Klisiewicz. Clientes satisfeitos
Análise de Sistemas Aula 4 Contextualização Prof. Emerson Klisiewicz Aula 4 Gerenciamento de Requisitos Refinamento de Requisitos Aprovação de Requisitos Matriz de Rastreabilidade O Sucesso Clientes satisfeitos
Leia maisModelos de Processo (métodos)
Modelos de Processo (métodos) Um modelo de processo ou método define um conjunto de atividades específicas. Principais modelos: Cascata (Waterfall) Espiral (Spiral) Evolutivo Incremental Processo Unificado
Leia maisEngenharia de Software II
Engenharia de Software II Aula 28 Revisão para a Prova 2 http://www.ic.uff.br/~bianca/engsoft2/ Aula 28-28/07/2006 1 Matéria para a Prova 2 Gestão de projetos de software Conceitos (Cap. 21) Métricas (Cap.
Leia maisEMENTAS DAS DISCIPLINAS
EMENTAS DAS DISCIPLINAS CURSO DE GRADUAÇÃO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS INTRODUÇÃO À COMPUTAÇÃO A disciplina aborda o estudo da área de Informática como um todo, e dos conceitos fundamentais,
Leia maisPROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às
Leia maisMetadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados
1. Introdução O governo é um dos maiores detentores de recursos da informação. Consequentemente, tem sido o responsável por assegurar que tais recursos estejam agregando valor para os cidadãos, as empresas,
Leia mais2 Engenharia de Software
20 2 Engenharia de Software 2.1 Design de Sistemas Orientados a Objetos Os Sistemas Orientados a Objetos não são mais novidade hoje em dia já estando há muitos anos no mercado. A orientação a objetos permite
Leia maisUML e a Ferramenta Astah. Profa. Reane Franco Goulart
UML e a Ferramenta Astah Profa. Reane Franco Goulart História da UML o Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. o Alguns esforços nesse
Leia maisQualidade de Software
Qualidade de Software Projeto e Desenvolvimento de Sistemas Dr. Fábio Levy Siqueira levy.siqueira@gmail.com Aula 2: Garantia da Qualidade e Padrões Qualidade de software Quais são as atividades de Gestão
Leia maisAutoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia maisUNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br
UNEMAT SISTEMA DE INFORMAÇÃO (SI) Professora: Priscila Pelegrini priscila_pelegrini@unemat-net.br SINOP MT 2015-1 COMO SÃO DESENVOLVIDOS OS SISTEMAS DE INFORMAÇÃO? São desenvolvimento como uma estrutura
Leia maisTópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619
Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o
Leia maisTeste de Software: Um Breve Estudo do Importante Processo no Desenvolvimento de Softwares
Teste de Software: Um Breve Estudo do Importante Processo no Desenvolvimento de Softwares André Assis Lôbo de Oliveira Francisco Guerra Fernandes Júnior Faculdades Alves Faria, 74445190, Brasil andrelobin@hotmail.com,
Leia maisIdeal para que tipo de empresa (equipe): pequena, média, grande? Em software onde os requisitos não são conhecidos é recomendado o uso do XP? Por quê?
Significado de XP? Extreme Programming (Programação Extrema). Ideal para que tipo de empresa (equipe): pequena, média, grande? Pequenas e Médias. Em software onde os requisitos não são conhecidos é recomendado
Leia mais18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB
18º Congresso de Iniciação Científica IMPLEMENTAÇÃO DE UM MODELO DE TESTE DE APLICAÇÕES WEB Autor(es) HARLEI MIGUEL DE ARRUDA LEITE Orientador(es) PLÍNIO ROBERTO SOUZA VILELA Apoio Financeiro PIBIC/CNPQ
Leia maisUtilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF
Utilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF Ben-Hur de Sousa Lopes¹, Jaime William Dias¹ ¹Universidade Paranaense (UNIPAR) Paranavaí Paraná Brasil
Leia maisGerenciamento de Requisitos Gerenciamento de Requisitos
Gerenciamento de Requisitos Objetivos da disciplina Descrever o processo de Gerenciamento e Engenharia de Requisitos para projetos Treinar alunos no Gerenciamento de Requisitos Apresentar estudos de caso
Leia maisc. Técnica de Estrutura de Controle Teste do Caminho Básico
1) Defina: a. Fluxo de controle A análise de fluxo de controle é a técnica estática em que o fluxo de controle através de um programa é analisado, quer com um gráfico, quer com uma ferramenta de fluxo
Leia maisPOLÍTICA DE GESTÃO DE RISCO - PGR
POLÍTICA DE GESTÃO DE RISCO - PGR DATASUS Maio 2013 Arquivo: Política de Gestão de Riscos Modelo: DOC-PGR Pág.: 1/12 SUMÁRIO 1. APRESENTAÇÃO...3 1.1. Justificativa...3 1.2. Objetivo...3 1.3. Aplicabilidade...4
Leia maisEngenharia de Software
Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo
Leia maisTópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.
Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo
Leia maisEngenharia de Software
Engenharia de Software Slide 05 Modelos de Processos Maurício Archanjo Nunes Coelho mauricio.coelho@ifsudestemg.edu.br Instituto Federal Análise de Sistemas Por que surgiu a Engenharia de Software? Resposta
Leia maisCurso Superior de Tecnologia em Gestão de Recursos Humanos. Professora Mestranda Elaine Araújo
Curso Superior de Tecnologia em Gestão de Recursos Humanos Professora Mestranda Elaine Araújo E o profissional de RH... Como deve mergulhar na abordagem da Gestão do Conhecimento? Qual sua contribuição
Leia maisPROVA DISCURSIVA (P )
PROVA DISCURSIVA (P ) 2 Nesta prova que vale dez pontos, faça o que se pede, usando os espaços indicados no presente caderno para rascunho. Em seguida, transcreva os textos para as folhas de TEXTOS DEFINITIVOS
Leia maisIntrodução ao Processo Unificado (PU)
Universidade Federal de Mato Grosso do Sul Sistemas de Informação - CPCX Introdução ao Processo Unificado (PU) Prof. Fernando Maia da Mota Slides gentilmente cedidos por Profa. Dra. Maria Istela Cagnin
Leia maisQuestionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP
DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo PRADO-MMGP Versão 1.6.4 Setembro 2009 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 2ª Edição (a publicar) Autor: Darci
Leia maisProcessos de gerenciamento de projetos em um projeto
Processos de gerenciamento de projetos em um projeto O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos.
Leia maisUNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO
UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO Santa Maria, 01 de Novembro de 2013. Revisão aula passada Projeto de Arquitetura Decisões de projeto de Arquitetura
Leia maisProf. Vitório Bruno Mazzola INE/CTC/UFSC 1. INTRODUÇÃO
Capítulo 6 ENGENHARIA DE SOFTWARE CONCEITOS BÁSICOS Prof. Vitório Bruno Mazzola INE/CTC/UFSC 1. INTRODUÇÃO Nos anos 40, quando se iniciou a evolução dos sistemas computadorizados, grande parte dos esforços,
Leia maisREVISÃO ENGENHARIA DO SOFTWARE. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com
REVISÃO ENGENHARIA DO SOFTWARE Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Software Sequencia de Instruções a serem seguidas ou executadas Dados e rotinas desenvolvidos por computadores Programas
Leia maisCiência da Computação ENGENHARIA DE SOFTWARE. UML-Unified Modeling Language Linguagem de Modelagem Unificada
Ciência da Computação ENGENHARIA DE SOFTWARE UML-Unified Modeling Language Linguagem de Modelagem Unificada Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução a linguagem UML
Leia maisAnálise e Projeto de Software
Análise e Projeto de Software 1 Mundo Real Modelagem Elicitação Análise Problemas Soluções Gap Semântico Mundo Computacional Elicitação de Requisitos Análise de Requisitos Modelagem dos Requisitos 2 Projeto
Leia maisCopyright Proibida Reprodução. Prof. Éder Clementino dos Santos
NOÇÕES DE OHSAS 18001:2007 CONCEITOS ELEMENTARES SISTEMA DE GESTÃO DE SSO OHSAS 18001:2007? FERRAMENTA ELEMENTAR CICLO DE PDCA (OHSAS 18001:2007) 4.6 ANÁLISE CRÍTICA 4.3 PLANEJAMENTO A P C D 4.5 VERIFICAÇÃO
Leia maisMODELAGEM DE SISTEMAS DE INFORMAÇÃO
Unidade III MODELAGEM DE SISTEMAS DE INFORMAÇÃO Prof. Daniel Arthur Gennari Junior Sobre esta aula Ciclo de Vida de Sistemas Engenharia de Software Aplicações de Software Diagramação de Software Ciclo
Leia maisCasos de uso Objetivo:
Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de
Leia maisagility made possible
RESUMO DA SOLUÇÃO Utilitário ConfigXpress no CA IdentityMinder a minha solução de gerenciamento de identidades pode se adaptar rapidamente aos requisitos e processos de negócio em constante mudança? agility
Leia maisGerenciamento da Integração (PMBoK 5ª ed.)
Gerenciamento da Integração (PMBoK 5ª ed.) O PMBoK diz que: O gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar
Leia maissendo bastante acessível e compreendido pelos usuários que o utilizarem.
APLICATIVO WEB PARA O SETOR DE EXTENSÃO IFC VIDEIRA Claudiléia Gaio Bandt 1 ; Tiago Heineck 2 ; Patrick Kochan 3 ; Leila Lisiane Rossi 4 ; Angela Maria Crotti da Rosa 5 INTRODUÇÃO Este artigo descreve
Leia mais1 Um guia para este livro
PARTE 1 A estrutura A Parte I constitui-se de uma estrutura para o procedimento da pesquisa qualitativa e para a compreensão dos capítulos posteriores. O Capítulo 1 serve como um guia para o livro, apresentando
Leia maisPrincípios do teste de software
Teste de Software Princípios do teste de software Conforme a Lei de Pareto, 80% dos erros podem ser localizados em 20% do projeto, geralmente nos módulos principais do sistema; A atividade de teste não
Leia maisA abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário
A abordagem da Engenharia Semiótica para o desenvolvimento de software centrado no usuário Jair Cavalcanti Leite Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do
Leia maisCurso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan
Faculdade INED Curso Superior de Tecnologia em Banco de Dados e Sistemas para Internet Disciplina: Projeto Integrador III Prof.: Fernando Hadad Zaidan Ago-2008 1 Gestão de requisitos 2 Bibliografia: PAULA
Leia maisQualidade e Teste de Software. QTS - Norma ISO 9001-9126(NBR13596) 1
Qualidade e Teste de Software 2010 1 ISO A ISO ( International Organization for Standardization) nasceu de uma conferência em Londres, em Outubro de 1946. O evento contou com a Participação de 65 delegados
Leia maisCURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008/1 4º PERÍODO 7º MÓDULO AVALIAÇÃO A3 DATA 15/10/2009 ENGENHARIA DE SOFTWARE 2009/2 GABARITO COMENTADO QUESTÃO 1: Analise as afirmações
Leia maisAS CONTRIBUIÇÕES DAS VÍDEO AULAS NA FORMAÇÃO DO EDUCANDO.
AS CONTRIBUIÇÕES DAS VÍDEO AULAS NA FORMAÇÃO DO EDUCANDO. Autor: José Marcos da Silva Instituição: UFF/CMIDS E-mail: mzosilva@yahoo.com.br RESUMO A presente pesquisa tem como proposta investigar a visão
Leia maisVisão Geral Parte 1. O que é engenharia de software?
Visão Geral Parte 1 Jair C Leite DIMAp/UFRN O que é engenharia de software? É uma disciplina da engenharia dedicada a todos os aspectos da produção de software. Engenheiros de software devem adotar uma
Leia maisNa medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.
1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade
Leia maisRequisitos de Software
Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,
Leia maisFundamentos da Administração Estratégica AULA 2
Fundamentos da Administração Estratégica AULA 2 Fundamentos da Administração Vem do latim: ad (direção para, tendência para) e minister (subordinação ou obediência), e significa aquele que realiza uma
Leia maisDesenvolve Minas. Modelo de Excelência da Gestão
Desenvolve Minas Modelo de Excelência da Gestão O que é o MEG? O Modelo de Excelência da Gestão (MEG) possibilita a avaliação do grau de maturidade da gestão, pontuando processos gerenciais e resultados
Leia maisATENAS: Um Sistema Gerenciador de Regras de Negócio
1. Introdução ATENAS: Um Sistema Gerenciador de Regras de Negócio Geraldo Zimbrão da Silva (IM/UFRJ) Victor Teixeira de Almeida (COPPE/UFRJ) Jano Moreira de Souza (COPPE/UFRJ) Francisco Gonçalves Pereira
Leia maisMODELOS DE PROCESSO. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com
MODELOS DE PROCESSO Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com Objetivo Apresentar os modelos de processos de desenvolvimento de software Permitir uma melhor compreensão do processo de desenvolvimento
Leia maisENGENHARIA DE SOFTWARE I
ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis
Leia maisObservações. Referência Título / Campo de Aplicação Emissor Data de adoção
NP 4239:1994 Bases para a quantificação dos custos da qualidade CT 80 1995-01-01 NP 4397:2008 Sistemas de gestão da segurança e saúde do trabalho. Requisitos CT 42 2008-12-31 NP 4410:2004 Sistemas de gestão
Leia maisNecessidade e construção de uma Base Nacional Comum
Necessidade e construção de uma Base Nacional Comum 1. O direito constitucional à educação é concretizado, primeiramente, com uma trajetória regular do estudante, isto é, acesso das crianças e jovens a
Leia mais08/05/2009. Cursos Superiores de. Prof.: Fernando Hadad Zaidan. Disciplina: PIP - Projeto Integrador de Pesquisa. Objetivos gerais e específicos
Faculdade INED Cursos Superiores de Tecnologia Disciplina: PIP - Projeto Integrador de Pesquisa Objetivos gerais e específicos Objetivo resultado a alcançar; Geral dá resposta ao problema; Específicos
Leia maisMDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI
MDMS- Metodologia de Desenvolvimento e Manutenção de Sistemas da Superintendência de Tecnologia da Informação - STI Metodologia de Desenvolvimento e Manutenção de Sistemas da Histórico de Alterações Versão
Leia maiso(a) engenheiro(a) Projeto é a essência da engenharia 07/02/2011 - v8 dá vazão
empíricos ou vulgar ou senso comum filosófico exige raciocínio reflexões racional e objetivo produto precede a construção conjunto de atividades o(a) engenheiro(a) aplica conhecimentos científicos ligado
Leia maisBUSCANDO UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PARA AUXILIAR A GESTÃO DE PRODUÇÃO DO PBL-VE E DO PBL-VS
973 BUSCANDO UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PARA AUXILIAR A GESTÃO DE PRODUÇÃO DO PBL-VE E DO PBL-VS Jéssica Magally de Jesus Santos 1 ; Gabriela Ribeiro Peixoto Rezende Pinto 2 1. Bolsista
Leia maisPlanejamento - 7. Planejamento do Gerenciamento do Risco Identificação dos riscos. Mauricio Lyra, PMP
Planejamento - 7 Planejamento do Gerenciamento do Risco Identificação dos riscos 1 O que é risco? Evento que representa uma ameaça ou uma oportunidade em potencial Plano de gerenciamento do risco Especifica
Leia maisProf. Antonio Almeida de Barros Jr. Prof. Antonio Almeida de Barros Junior
Prof. Antonio Almeida de Barros Jr. Introdução Dados Informações Banco de Dados Conceitos Básicos em Bancos de Dados Definição BD - Banco de Dados SGBD - Sistema de Gerenciamento de BD Programa de Aplicação
Leia maisADMINISTRAÇÃO I. Família Pai, mãe, filhos. Criar condições para a perpetuação da espécie
1 INTRODUÇÃO 1.1 ORGANIZAÇÃO E PROCESSOS A administração está diretamente ligada às organizações e aos processos existentes nas mesmas. Portanto, para a melhor compreensão da Administração e sua importância
Leia maisClassificação de Sistemas: Sistemas Empresariais
Universidade do Contestado Campus Concórdia Curso de Ciências Contábeis Prof.: Maico Petry Classificação de Sistemas: Sistemas Empresariais DISCIPLINA: Sistemas de Informação Gerencial O QI da empresa
Leia maisESTRUTURA DE GERENCIAMENTO DO RISCO OPERACIONAL DO BANCO COOPERATIVO SICREDI E EMPRESAS CONTROLADAS
ESTRUTURA DE GERENCIAMENTO DO RISCO OPERACIONAL DO BANCO COOPERATIVO SICREDI E EMPRESAS CONTROLADAS Versão : 31 de dezembro de 2008 CONTEÚDO 1. INTRODUÇÃO...3 2. ORGANIZAÇÃO DA GESTÃO DE RISCO OPERACIONAL...3
Leia mais4.1. UML Diagramas de casos de uso
Engenharia de Software 4.1. UML Diagramas de casos de uso Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Utilizados para ajudar na análise de requisitos Através da forma como o utilizador usa o sistema
Leia maisMETODOLOGIA PARA PROJETO DE INTERFACES E EQUIPAMENTOS NUCLEARES COM ABORDAGEM CENTRADA NOS USUÁRIOS E NA SUA ATIVIDADE
6 Disponibilizado no endereço http://www.acaoergonomica.ergonomia.ufrj.br Ação Ergonômica vol 3 nº. 1 (2007) pp. 01-06 METODOLOGIA PARA PROJETO DE INTERFACES E EQUIPAMENTOS NUCLEARES COM ABORDAGEM CENTRADA
Leia mais