998 resultados para Processo de desenvolvimento do software


Relevância:

100.00% 100.00%

Publicador:

Resumo:

A presente pesquisa consiste num trabalho exploratório de análise dos aspetos específicos da gestão de projetos de desenvolvimento de software de Patient Relationship Management (PRM), tendo em vista contribuir para a definição, no futuro, de um framework específico. Uma revisão de literatura sistemática permitiu concluir a inexistência de referências neste âmbito inseridas, tendo-se procurado suprir esta lacuna através da realização de um estudo de caso suportado em três entrevistas a peritos de reconhecida competência. As conclusões remetem para a necessidade e pertinência de um framework de gestão de projetos de desenvolvimento de software de PRM, evidenciando também um controlo do projeto de reduzida complexidade. Propõe-se e discute-se, neste aspeto, a utilização do sistema de controlo Balanced Scorecard. Esta pesquisa fornece um importante contributo para o conhecimento, compreensão e orientação da gestão e da tomada de decisão subjacentes a projetos de PRM no setor da saúde.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Abstract – Background – The software effort estimation research area aims to improve the accuracy of this estimation in software projects and activities. Aims – This study describes the development and usage of a web application tocollect data generated from the Planning Poker estimation process and the analysis of the collected data to investigate the impact of revising previous estimates when conducting similar estimates in a Planning Poker context. Method – Software activities were estimated by Universidade Tecnológica Federal do Paraná (UTFPR) computer students, using Planning Poker, with and without revising previous similar activities, storing data regarding the decision-making process. And the collected data was used to investigate the impact that revising similar executed activities have in the software effort estimates' accuracy.Obtained Results – The UTFPR computer students were divided into 14 groups. Eight of them showed accuracy increase in more than half of their estimates. Three of them had almost the same accuracy in more than half of their estimates. And only three of them had loss of accuracy in more than half of their estimates. Conclusion – Reviewing the similar executed software activities, when using Planning Poker, led to more accurate software estimates in most cases, and, because of that, can improve the software development process.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

De forma a auxiliar ações de transferência de tecnologia, no Estado do Amazonas, foi desenvolvido um aplicativo para dispositivos móveis com o sistema operacional Google Android, cujo propósito é ajudar na nutrição do solo, de forma a obter melhor produtividade e fornecer dicas e ferramentas necessárias para um bom plantio de citros.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Dissertação apresentada na Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa para obtenção do grau de Mestre em Engenharia Informática

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Dissertação para obtenção do Grau de Mestre em Engenharia Informática

Relevância:

100.00% 100.00%

Publicador:

Resumo:

No processo de desenvolvimento de software, um dos problemas recorrentes é garantir que as expectativas das partes interessadas (stakeholders) estão a ser satisfeitas. Expectativas essas que correspondem ao comportamento do sistema. A disciplina de Engenharia de Requisitos estuda a melhor forma de capturar, especificar, validar e gerir requisitos. No entanto, os modelos utilizados que expressam os comportamentos, muitas das vezes, não são entendidos por parte dos stakeholders. Com a introdução das metodologias ágeis, que se baseiam no princípio de uma colaboração ativa e contínua dos stakeholders durante o desenvolvimento de software, os pressupostos da disciplina de Engenharia de Requisitos foram questionados e fizeram nascer novas práticas. Uma prática que emergiu foi o Desenvolvimento Orientado ao Comportamento (BDD). Surgiu com a finalidade de dar a capacidade aos stakeholders de expressarem, sob a forma textual, o comportamento que desejam para o seu software, de forma simples e sucinta. No entanto, não existindo restrições nem validações automáticas na escrita dos stakeholders, é criada a possibilidade de introdução de ambiguidade e perda de informação quando a equipa de desenvolvimento utiliza os cenários descritos. Dado este problema, propomos uma abordagem em que os stakeholders consigam especificar cenários comportamentais, de forma cognitiva, com uma representação simples, clara e mais precisa. Criamos duas linguagens, o DomainMap e o BehaviorMap, que estão relacionadas entre si: uma para representar modelos de domínio e outra para representar cenários BDD, respetivamente. Foi executada uma experiência com 15 indivíduos para comparar o esforço cognitivo na compreensão entre cenários BehaviorMap e cenários textuais e os resultados mostraram que o BehaviorMap teve melhor desempenho.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

O processo de desenvolvimento de software implica na necessidade constante de tomadas de decisão. A cada etapa do processo, torna-se necessário estabelecer a comunicação e interação entre usuários, gerentes, analistas, programadores e mantenedores numa constante troca de informações. O registro dos artefatos produzidos durante todo o processo é uma questão que norteia as pesquisas em ambiente de desenvolvimento de software. Quando se fala em suporte ao processo de colaboração entre os elementos de uma equipe de desenvolvimento, este registro torna-se ainda mais necessário. Neste contexto, a modelagem dos dados a serem armazenados se amplia para comportar outras informações provenientes da interação do grupo além dos artefatos gerados. As informações trocadas durante este processo interativo que incluem fatos, hipóteses, restrições, decisões e suas razões, o significado de conceitos e, os documentos formais formam o que é denominado pela literatura especializada como memória de grupo. A proposta da arquitetura SaDg PROSOFT visa fornecer suporte a memória de grupo, no que diz respeito ao registro das justificativas de projeto(Design Rationale), através de uma integração com o gerenciador de processos (GP) provido pelo ADS PROSOFT. Esta integração se dá através das ferramentas inseridas no modelo, assim desenhadas: Editor de Norma, Editor de Argumentação, Extrator de Alternativas, Editor de Votação. O ADS PROSOFT integra ferramentas para desenvolvimento de software. Este ADS foi escolhido para o desenvolvimento do modelo SADG, pois baseia-se na construção formal de software, mas particularmente no método algébrico, por ser um ambiente estendível, possibilitando a inclusão do modelo SaDg PROSOFT ao seu conjunto de ferramentas, por ter características de um ambiente distribuído e cooperativo e por não dispor de nenhum suporte à discussões e decisões em grupos. São apresentados os fundamentos de modelos SADG e algumas ferramentas. Alguns dos principais requisitos desses ambientes foram coletados e são apresentados a fim de embasar a proposta do trabalho. O modelo SADG é apresentado na forma de ferramentas PROSOFT(chamadas ATOs) e permite a definição de atividades como: Atividade de argumentação, atividade de extração e a atividade de votação. Além disso, permite a coordenação destas atividades através de um facilitador e do próprio GP, e também, possui um mecanismo para a configuração do processo decisório.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

A atividade de teste constitui uma fase de grande importância no processo de desenvolvimento de software, tendo como objetivo garantir um alto grau de confiabilidade nos produtos desenvolvidos. O paradigma da Orientação a Objetos (OO) surgiu com o objetivo de melhorar a qualidade bem como a produtividade no desenvolvimento de aplicações. Entretanto, apesar do aumento constante de aceitação do paradigma OO pela indústria de software, a presença de algumas de suas características torna a atividade de teste de programas neste paradigma mais complexa do que o teste de sistemas tradicionais. Entre estas características cita-se a herança, o encapsulamento, o polimorfismo e a ligação dinâmica [EIS 97] [PRE 95] [UNG 97]. Algumas técnicas estão sendo implementadas para auxiliarem a atividade de teste através do uso da tecnologia de reflexão computacional [HER 99]. Estas técnicas permitem a realização de análises de aspectos dinâmicos dos programas, sem a necessidade de instrumentar o código-fonte das aplicações que estão sendo monitoradas. Com o objetivo de auxiliar o processo de teste de programas orientados a objetos, este trabalho aborda o desenvolvimento de uma ferramenta, a qual automatiza parcialmente o teste de programas escritos em Java. A ferramenta evidencia o teste de estados fazendo uso da tecnologia de reflexão computacional. Através da especificação de asserções, feitas pelo usuário da ferramenta, na forma de invariantes de classe, pré e pós-condições de métodos, é possível verificar a integridade dos estados dos objetos durante a execução do programa em teste. A ferramenta possibilita também, armazenar a seqüência de métodos chamados pelos objetos da aplicação em teste, tornando possível ao testador, visualizar o histórico das interações entre os objetos criados no nível-base.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Os requisitos direcionam o desenvolvimento de software porque são cruciais para a sua qualidade. Como conseqüência tanto requisitos funcionais quanto não funcionais devem ser identificados o mais cedo possível e sua elicitação deve ser precisa e completa. Os requisitos funcionais exercem um papel importante uma vez que expressam os serviços esperados pela aplicação. Por outro lado, os requisitos não funcionais estão relacionados com as restrições e propriedades aplicadas ao software. Este trabalho descreve como identificar requisitos não funcionais e seu mapeamento para aspectos. O desenvolvimento de software orientado a aspectos é apontado como a solução para os problemas envolvidos na elicitação e modelagem dos requisitos não funcionais. No modelo orientado a aspectos, o aspecto é considerado o elemento de primeira ordem, onde o software pode ser modelado com classes e aspectos. As classes são comumente usadas para modelar e implementar os requisitos funcionais, já os aspectos são adotados para a modelagem e implementação dos requisitos não funcionais. Desse modo, é proposta a modelagem dos requisitos não funcionais através das fases do ciclo de vida do software, desde as primeiras etapas do processo de desenvolvimento. Este trabalho apresenta o método chamado FRIDA – From RequIrements to Design using Aspects, cujo objetivo é determinar uma forma sistemática para elicitar e modelar tanto os requisitos funcionais quanto os não funcionais, desde as fases iniciais do ciclo de desenvolvimento. Em FRIDA, a elicitação dos requisitos não funcionais é realizada usando-se checklists e léxicos, os quais auxiliam o desenvolvedor a descobrir os aspectos globais – utilizados por toda a aplicação – bem como, os aspectos parciais que podem ser empregados somente a algumas partes da aplicação. O próximo passo consiste na identificação dos possíveis conflitos gerados entre aspectos e como resolvê-los. No método FRIDA, a identificação e resolução de conflitos é tão importante quanto a elicitação de requisitos não funcionais, nas primeiras fases do ciclo de vida do software. Além disso, é descrito como usar a matriz de conflitos para automatizar esse processo sempre que possível. A extração dos aspectos e sua modelagem visual são características muito importantes, suportadas pelo método, porque elas possibilitam a criação de modelos que podem ser reutilizados no futuro. Em FRIDA, é demonstrado como transformar os requisitos em elementos da fase de projeto (classes e aspectos) e como traduzir esses elementos em código. Outra característica do método FRIDA é que a conexão entre diagramas, que pertencem a diferentes fases do processo de desenvolvimento do software, permite um alto nível de rastreabilidade. Em resumo, FRIDA requer que o desenvolvedor migre de uma visão puramente funcional para outra que contemple também os requisitos não funcionais.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Em vista da maior complexidade da programação paralela e distribuída em relação à programação de ambientes centralizados, novas ferramentas vêm sendo construídas com o objetivo de auxiliar o programador desses ambientes a desempenhar sua tarefa de formas mais eficazes e produtivas. Uma das ferramentas que há algum tempo tem sido usada na programação centralizada e aos poucos está sendo empregada também na programação concorrente é a programação visual. A programação visual se vale da presença de elementos visuais na especificação dos programas como peças chaves do processo de desenvolvimento de software. No caso específico da programação concorrente, a programação visual é especialmente útil pela capacidade que os gráficos têm de representar de forma mais adequada estruturas bidimensionais. Um programa concorrente, por relacionar no espaço diversos elementos com seus próprios fluxos de execução, faz surgir duas dimensões de análise que são mais difíceis de serem observadas através de programas textuais. Atualmente existem ferramentas de programação visual paralela e distribuída, mas a ênfase é dada na programação paralela, sem muita atenção a aplicações de sistemas abertos ou cliente-servidor. Além disso, tais ferramentas sofrem da falta de apoio à engenharia do software. Considerando essas deficiências, este trabalho apresenta uma ferramenta de programação visual para o desenvolvimento de aplicações compostas por objetos distribuídos que ofereça também a possibilidade de aplicar os principais conceitos da engenharia de software, como reutilização e orientação a objeto. Nesta ferramenta, o programador especifica de maneira visual a estrutura do seu programa, insere o código textual para a lógica da aplicação e o ambiente se encarrega do tratamento da distribuição e da comunicação de mais baixo nível. A aplicação é representada como um grafo dirigido, onde os nodos representam os objetos distribuídos e os arcos indicam os relacionamentos existentes entre esses objetos. A especificação dos programas é modular, baseando-se na reunião de componentes reutilizáveis, o que torna o sistema altamente configurável e extensível. Tanto a implementação da ferramenta quanto o código das aplicações geradas usam a linguagem de programação Java. A linguagem de programação visual projetada não especifica detalhes a respeito de como irá funcionar a comunicação e distribuição dos objetos. Portanto, foram implementados componentes para comunicação e outros recursos de programação distribuída, como locks e dados globais para serem usados nas aplicações. Para validar os principais objetivos da ferramenta, foram implementados alguns exemplos de aplicações distribuídas, como um pequeno sistema de bate-papo.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Nesta dissertação defendemos uma forma nova de medir o produto de software com base nas medidas usadas na teoria dos sistemas complexos. Consideramos o uso dessas medidas vantajoso em relação ao uso das medidas tradicionais da engenharia de software. A inovação desta dissertação sintetiza-se em considerar o produto de software como um sistema complexo, dotado de uma estrutura que comporta vários níveis e na proposta da correlação de gama longa como medida da complexidade de estrutura de programas fontes. Essa medida, invariante para a escala de cada nível da estrutura, pode ser calculada automaticamente. Na dissertação, primeiro descrevemos o processo de desenvolvimento do software e as medidas existentes para medir o referido processo e produto e introduzimos a teoria dos sistemas complexos. Concluímos que o processo tem características de sistema complexo e propomos que seja medido como tal. Seguidamente, estudamos a estrutura do produto e a dinâmica do seu. processo de desenvolvimento. Apresentamos um estudo experimental sobre algoritmos codificados em C, que usamos para validar hipóteses sobre a complexidade da estrutura do produto. Propomos a correlação de gama longa como medida da complexidade da estrutura. Estendemos essa medida a uma amostra codificada em Java. Concluímos, evidenciando as limitações e as potencialidades dessa medida e a sua aplicação em Engenharia de Software.

Relevância:

100.00% 100.00%

Publicador:

Resumo:

The nature of this thesis is interventionist and aims to create an alternative on how to control and evaluate the public policies implementation developed at the Institute for Technical Assistance and Rural Extension of Rio Grande do Norte State. The cenarium takes place in a public institution , classified as a municipality that belongs to the Rio Grande do Norte government and adopts the design science research methodology , where it generates a set of artifacts that guide the development of a computerized information system . To ensure the decisions, the literature was reviewed aiming to bring and highlight concepts that will be used as base to build the intervention. The use of an effective methodology called Iconix systems analysis , provides a software development process in a short time . As a result of many artifacts created by the methodology there is a software computer able of running on the Internet environment with G2C behavior, it is suggested as a management tool for monitoring artifacts generated by the various methods. Moreover, it reveals barriers faced in the public companies environment such as lack of infrastructure , the strength of the workforce and the executives behavior

Relevância:

100.00% 100.00%

Publicador:

Resumo:

Aspect Oriented approaches associated to different activities of the software development process are, in general, independent and their models and artifacts are not aligned and inserted in a coherent process. In the model driven development, the various models and the correspondence between them are rigorously specified. With the integration of aspect oriented software development (DSOA) and model driven development (MDD) it is possible to automatically propagate models from one activity to another, avoiding the loss of information and important decisions established in each activity. This work presents MARISA-MDD, a strategy based on models that integrate aspect-oriented requirements, architecture and detailed design, using the languages AOV-graph, AspectualACME and aSideML, respectively. MARISA-MDD defines, for each activity, representative models (and corresponding metamodels) and a number of transformations between the models of each language. These transformations have been specified and implemented in ATL (Atlas Definition Language), in the Eclipse environment. MARISA-MDD allows the automatic propagation between AOV-graph, AspectualACME, and aSideML models. To validate the proposed approach two case studies, the Health Watcher and the Mobile Media have been used in the MARISA-MDD environment for the automatic generation of AspectualACME and aSideML models, from the AOV-graph model