Made available in DSpace on 2016-12-01T19:11:32Z (GMT). No. of bitstreams: 1 115825.pdf: 377095 bytes, checksum: 3f6965e330641919a238073a8190da6c (MD5) Previous issue date: 2013-12-16 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / More than ever organizations are linking themselves in networks, and governments, aware of what can be gained with those connections, are developing incentives to foster its development. In Florianópolis, the promulgation of the Law of Innovation defined incentives to the formation of organizational networks, called Arranjos Promotores de Inovação (API). With that, the city s first API, the API.nano, started to be developed by CERTI, which invited LabGes/ESAG/UDESC to define the API s management and governance system, containing the system s business process mapping. In this context, this thesis details the development of a stakeholders requirement engineering of ICT systems capable of supporting the collaborative activities of the API.nano s organizations based in the process mapping developed. Supported by the literature about clusters of innovation, computer-supported cooperative work and requirement engineering, the research is divided in two phases. The first one constituted in the coding of the activities of the process mapping, which allowed their classification in 11 collaborative characteristics. Afterwards, a interpretative requirement analysis of the relationships exposed by the coding ensued. As a result, 30 stakeholders requirements were elicited. These requirements can the base for the definition of a ICT systems ecology capable of satisfying the collaborative work support technological needs of the API. / Cada vez mais organizações vem se ligando em redes, e os governantes, cientes dos ganhos obtidos com estas ligações, criam incentivos para fomentar seu desenvolvimento. Em Florianópolis, a promulgação da Lei da Inovação criou incentivos para a formação de redes organizacionais chamadas pela lei de Arranjos Promotores de Inovação (API). Com isso, o primeiro API da cidade, o API.nano, começou a ser desenvolvido pela Fundação CERTI, que convidou o LabGes/ESAG/UDESC a definir o sistema de gestão e governança do API, contendo um mapeamento de processos de negócio do sistema. Neste contexto, esta dissertação detalha o desenvolvimento de uma engenharia de requisitos de stakeholder de sistemas de TIC capazes de auxiliar as atividades colaborativas das organizações do API.nano com base no mapeamento de processos desenvolvido. Fundamentada pela literatura sobre clusters de inovação, sistemas de TIC no trabalho colaborativo e engenharia de requisitos, a pesquisa se dividiu em duas etapas. A primeira consistiu numa codificação das atividades do mapeamento de processos, que permitiu a classificação das atividades em 11 características colaborativas. Em seguida, uma análise de requisitos interpretativa foi realizada nas relações expostas pela codificação. Como resultado, 30 requisitos de stakeholders foram propostos. Estes requisitos podem servir de base para a definição de uma ecologia de sistemas de TIC capaz de satisfazer as necessidades tecnológicas de suporte do trabalho colaborativo do API.

O avanço tecnológico recente tem atraído tanto a comunidade acadêmica quanto o mercado para a investigação de novos métodos, técnicas e linguagens formais para a área de Projeto de Engenharia. A principal motivação é o atendimento à demanda para desenvolver produtos e sistemas cada vez mais completos e que satisfaçam as necessidades do usuário final. Necessidades estas que podem estar ligadas, por exemplo, à análise e reconhecimento de objetos que compõe uma imagem pela sua textura, um processo essencial na automação de uma enorme gama de aplicações como: visão robótica, monitoração industrial, sensoriamento remoto, segurança e diagnóstico médico assistido. Em vista da relevância das inúmeras aplicações envolvidas e pelo fato do domínio de aplicação ser muito próximo do contexto do desenvolvedor, é apresentada uma proposta de um processo de design baseado no Projeto Axiomático como sendo o mais indicado para esta situação. Especificamente, se espera que no estudo de caso da análise de textura haja uma convergência mais rápida para a solução - se esta existir. No estudo de caso, se desenvolve uma nova concepção de arquitetura de rede neural artificial (RNA), auto-organizável, com a estrutura espacial bidimensional da imagem de entrada preservada, tendo a extração e reconhecimento/classificação de textura em uma única fase de aprendizado. Um novo conceito para o paradigma da competição entre os neurônios também é estabelecida. O processo é original por permitir que o desenvolvedor assuma concomitantemente o papel do cliente no projeto, e especificamente por estabelecer o processo de sistematização e estruturação do raciocínio lógico do projetista para a solução do problema a ser desenvolvido e implementado em RNA. / The recent technological advance has attracted the industry and the academic community to research and propose methods, seek for new techniques, and formal languages for engineering design in order to respond to the growing demand for sophisticated product and systems that fully satisfy customers needs. It can be associated, for instance, with an application of object recognition using texture features, essential to a variety of applications domains, such as robotic vision, industrial inspection, remote sensing, security and medical image diagnosis. Considering the importance of the large number of applications mentioned before, and due to their characteristic where both application and developer domain are very close to each other, this work aims to present a design process based on ideas extracted from axiomatic design to accelerate the development for the classical approach to texture analysis. Thus, a case study is accomplished where a new conception of neural network architecture is specially designed for the following proposal: preserving the two-dimensional spatial structure of the input image, and performing texture feature extraction and classification within the same architecture. As a result, a new mechanism for neuronal competition is also developed as specific knowledge for the domain. In fact, the process proposed has some originality because it does take into account that the developer assumes also the customers role on the project, and establishes the systematization process and structure of logical reasoning of the developer in order to develop and implement the solution in neural network domain.

A globalização força cada vez mais a união entre empresas através de acordos e parcerias, fazendo do desenvolvimento colaborativo de novos produtos um requisito básico para a competitividade e sobrevivência. A gestão de projetos (GP), essencial para o desenvolvimento de produtos (DP), é uma área complexa, e, portanto, é difícil estruturar todos os elementos necessários para garantir o sucesso de sua aplicação prática. Um dos fatores mais importantes para a boa gestão de projetos é a gestão da comunicação e do conhecimento gerado durante o projeto. Neste contexto, este trabalho visa o levantamento de requisitos de software para gestão de projetos, contendo métodos, práticas e ferramentas relevantes à indústria e focado no processo de desenvolvimento colaborativo de produtos. Estes requisitos devem apoiar conceitos de colaboração e gestão de conhecimento, baseando-se em conceitos retirados da literatura; resultados de trabalhos passados dentro do grupo de engenharia integrada do Núcleo de Manufatura Avançada (NUMA) e requisitos provenientes das análises de softwares livres para gestão de projetos, complementando assim o desenvolvimento científico do grupo de pesquisa e as melhores práticas encontradas na indústria em geral. Esta pesquisa tem caráter qualitativo e descritivo e, como métodos de procedimento de pesquisa, a pesquisa descritiva do tipo participante-observador, pesquisa bibliográfica e documental. / Everyday, the globalization forces even more the joining of companies through business agreements and partnerships, making of the collaborative product development of new products a basic requirement to the competitiveness or even survival. The project management, essential to product development, is a complex area of knowledge and, therefore difficult to structuralize all the elements needed to ensure the success of its practical application inside different industries. One of the most important factors necessary to a good project management is managing the communication and the knowledge created along the project. Within this context, this work aims the develop a list of requirements for a project management software focused at the product development process. These requirements must include concepts of geographically distributed collaboration and knowledge management. The main sources for this work are the general literature; work results from past projects inside the engineering integration group of the Nucleus of Advanced Manufacturing of the University of São Paulo and requirements from analysis of open-source project management softwares, adding up to the scientific development of the research group and best practices found in the industry in general. This research is qualitative and descriptive. It makes use of the research methods of participant-observer, bibliographical research and documental research.

Made available in DSpace on 2016-12-23T14:33:38Z (GMT). No. of bitstreams: 1 dissertacao.pdf: 2000193 bytes, checksum: 7b0d1bbfbe14616b4ce8e7a9cf5a9d4f (MD5) Previous issue date: 2009-06-24 / Nowadays, it is acknowledged that reuse offers an important opportunity to achieve improvements in software development. Greater benefits, however, are achieved by reusing knowledge. Concerning knowledge reuse, two major kinds of knowledge should be considered: domain and task knowledge. For developing knowledge for reuse, models are needed to capture both, and ontologies can be used for this purpose. Domain ontologies describe the vocabulary related to a generic domain, while task ontologies describe the vocabulary related to a generic task. Domain ontologies have been extensively used in several areas in Computer Science, however, the same does not occur with task ontologies. There are few works presenting task ontologies, and there is no uniformity in representing them. Task knowledge involves two different facets: task decomposition and knowledge roles involved in the fulfillment of the subtasks. This work proposes the use of UFO (Unified Foundational Ontology) based UML profiles for representing task knowledge: OntoUML (that concerns class diagrams) modeling the knowledge roles involved and their properties and relations, and E-OntoUML (that concerns activity diagrams) capturing task decomposition and how knowledge roles act in their fulfillment. OntoUML is currently used to represent several domain ontologies. E-OntoUML is a new profile that is proposed here. This work also discusses how task ontologies can be combined with domain ontologies in order to describe the knowledge involved in a class of applications. Finally, since the main goal for capturing knowledge is to allow its reuse and sharing, an approach is proposed for reusing task ontologies in the Requirements Engineering process. / Atualmente, reconhece-se que a reutilização oferece uma importante oportunidade para alcançar melhorias no desenvolvimento de software. Maiores benefícios, no entanto, são obtidos pela reutilização em níveis mais altos de abstração, sobretudo pelo reúso de conhecimento. Em relação à reutilização de conhecimento, dois grandes tipos de conhecimento devem ser considerados: conhecimento de domínio e de tarefa. Para desenvolver o conhecimento para a reutilização, necessita-se de modelos para capturar ambos e ontologias podem ser utilizadas para este fim. Ontologias de domínio descrevem o vocabulário relacionado a um domínio genérico, enquanto ontologias de tarefa descrevem o vocabulário relacionado a uma tarefa genérica. Ontologias de domínio têm sido amplamente utilizadas nas mais diversas áreas da Ciência da Computação, entretanto o mesmo não ocorre com ontologias de tarefa. Existem poucos trabalhos apresentando ontologias de tarefa e não há uniformidade na representação das mesmas. O conhecimento de tarefa envolve dois aspectos principais: a decomposição em subtarefas e os papéis de conhecimento que as entidades do domínio irão exercer na realização da tarefa. Este trabalho propõe o uso de perfis UML baseados na Ontologia de Fundamentação Unificada (Unified Foundational Ontology UFO) para representar ontologias de tarefa: OntoUML (com base em diagramas de classes), para a modelagem dos papéis de conhecimento envolvidos e suas propriedades e relações, e E-OntoUML (com base em diagramas de atividades), para capturar a decomposição de tarefa e a participação dos papéis de conhecimento nas mesmas. O primeiro tem sido bastante utilizado para representar ontologias de domínio, enquanto o segundo é um novo perfil, proposto neste trabalho. Discute-se, também, como ontologias de tarefa podem ser combinadas com ontologias de domínio, a fim de descrever o conhecimento relativo a uma classe de aplicações. Por fim, uma vez que o principal objetivo para a captura do conhecimento é permitir o seu reuso e compartilhamento, propõe-se uma abordagem para reutilização de ontologias de tarefa no processo de Engenharia de Requisitos.

Globalization and innovation are revolutionizing the higher education forcing to create new market trends.Different nations have their own pattern and framework of education in delivering the educational services.Educational institutions are also seeking different organizational and behavioural changes for their better future as they hunt for new financial resources, face new competition and seek greater prestige domestically and internationally. The coming future will decide which universities would survive the market trends, competition and expectations of the students (Clients). The survival-of-the-fittest paradigm framework plays a prominent role in ideas of how the higher education would be delivered to the students in future with the Instruction Technology and distance education. According to us the education trend has changed its phase of delivery of services form the management point of view to student’s point of view.Leading to delivery of educational service’s which would have more impact on student’s education, knowledge and experience within the institution. In our thesis we try to provide some information about how to support and manage the information in Virtual Organizations. We also explore the frameworks of the university and discussed a case study about the different ways of providing better support for information management resulting in delivery of best students driven services and unique facilities. We would be looking at the different aspects of the university work flows and procedures and gain an insight on the student’s expectation from the organization. This investigation would be helpful for the students to know what are the services they should expect from the universities and also helpful for management to know better the needs of the students and their needs and to develop a framework for proper execution of these services. / In an educational environment students should be the first priority. Trusting students is we feel the most important aspect of an educational institution also providing the best possible support to students.after being through the total framework of an organization and different Non- Functional requirements, we conclude that the primary task for better information management and service delivery in any organization is to get the better understanding of the requirements engineering. An organization should have clearly defined stakeholders who would be qualified and filled with commitment to manage their responsibilities with higher priority; also they have to take up the responsibilities for the students.So to achieve a balance among stakeholders there should be a proper negotiation and communication between the stakeholders. In order to achieve that there should be common set of defined rules (say services) through which they could correspond with each other. The stakeholder should be well equipped with the technical nature used to develop and maintain the system.In short the management is the key player in understanding and validating the system and determine whether or not the existing system/process is in control. The most powerful designs are always the result of a continuous process of simplification and refinement. The system could be validated by taking regular feedback from students by handing out a paper for evaluation at various occasions of the different courses. An online, end-of-course plus the experiences of students questions should be designed and should be made a part of students work to fill it in order to get their right perception on the system. These feedbacks could lead to proper student dialogue evaluation. Therefore, eventually controlling and smoothly managing the stakeholders and the services could provide efficient support for the information management in virtual organizations.BTH has the staffs who are concerned about student problems but there is no person responsible for the students whom the students could approach. So BTH should have defined stakeholders who are responsible for the students and to whom the students could approach with their difficulties and problems. The university should show the students that they care for them, this is only possible by the university to go an extra mile for the sake of students and providing better facilities and future prospects for the students. / Kosuri Naga Krishna Kalyan C/O Achanta Srinivas Kungsmarksvagen 69-1412 Karlskrona 37144 Sweden Phone::0046-0704521463 B.B.Pavan Kumar Yadav C/O Achanta Srinivas Kungsmarksvagen 69-1412 Karlskrona 37144 Sweden Phone:0046-0737726964

Kunskapsöverföring är en nödvändig förutsättning för att säkerställa organisationers existens och framåtskridande. Utgångspunkt för denna uppsats är förstudiens roll i mjukvaruprojekt och dess betydelse för den fortsatta systemutvecklingsprocessen. Fokus liggerpå kunskap som genereras under förstudien, samt hur och i vilken omfattning kunskapen förs vidare till analysfasen i systemutvecklingsprocessen. Resultatet visar att förstudien utgör ett viktigt beslutsunderlag och är en nödvändig förutsättning för att gå vidare i systemutvecklingsprocessen. Kunskapsöverföring genom dokumentation och via muntliga föredragningar är otillräcklig, eftersom det finns ett ”filter” som innebär att erfarenhetsbaserad kunskap inte överförs mellan förstudie och analys via dokument eller via muntliga föredragningar. Därför måste personer som deltar i förstudien finnas med senare i utvecklingsprocessen, för att artikulera den ”tysta” erfarenhetsbaserade kunskapen till explicita former. Vi drar slutsatserna att kunskapsöverföring via dokument är bra, men räcker inte enligt vår mening. Då det mesta av kunskapen är implicit, det vill säga tyst och/eller ordlös, kommer den inte med i en skriftlig rapport. Kompletteras rapporten med muntliga föredragningar, kommer man ytterligare ett steg närmare en optimal kunskapsöverföring, men det räcker fortfarande inte, då den tysta kunskapen alltjämt utgör ett hinder. Kunskapsöverföring måste ske genom personer, som finns med både i förstudie- och analysfasen, men det måste tillskapas arenor för kunskapsomvandling och kommunikation. Genom en arena för kunskapsomvandling kan den tysta kunskapen göras kommunicerbar. En arena för kommunikation utgör sen den sista byggstenen på väg mot en effektiv kunskapsöverföring. Kunskapsöverföring måste "organiseras". Vi lämnar därför ett förslag till en kunskapsöverföringsmodell. / Knowledge transfer is necessary condition to guarantee the existence and progress of organisations. The starting-point for this paper is the role of the feasibility study in a software project and it’s significance for the subsequent system development process. The focus is on knowledge, which is generated under the feasibility study, and how and in which dimension knowledge is bringing on to the analysis in the system development process. The result shows that the feasibility study is an important base of decision and a necessary condition of the future system development process. Knowledge transfer by documentation and by oral presentation of reports is insufficient, because there is a"filter"which means that knowledge of experience not will be transferred between feasibility study and analysis by documentation and by oral presentation. Furthermore must persons who are involved in the feasibility study occur even later in the development process, to articulate the "silence" knowledge of experience into explicit forms. We draw the conclusions that knowledge transfer by documents is good, but not enough in our opinion. Because most of the knowledge is implicit, which means silent and/or without words, it will not been in the report. If the report will be completed with oral presentations, you will came further one step near an optimal knowledge transfer, but it’s still not enough, because the silent knowledge still is an obstruction. Knowledge transfer must be done by persons, who’s in both the feasibility study and analysis, but there must be an arena for knowledge transformation and communication. Through an arena for knowledge transformation the silent knowledge can be communicative. An arena for communication is then the last stone of building an effective knowledge transfer. Knowledge transfer must be "organised". We therefore present a proposal to a model of knowledge transfer.

Requirement engineering is the most important phase within the software development phases since it is used to extract requirements from the customers which are used by the next phases for designing and implementation of the system. Because of its importance, this thesis focuses on the term aspect oriented requirement engineering, which is the first phase in aspect oriented software development used for the identification and representation of requirements gathered in the form of concerns. Besides the overall explanation of aspect oriented requirement engineering phase, detail attention is given to a specific activity within AORE phase called conflict resolution. Several techniques proposed for conflict resolution between aspects is discussed along with an attempt to give a new idea in the form of an extension of the already proposed model for conflict resolution. The need for extension to the already proposed model is justified by the use of a case study which is applied on both the models i.e. on the original model and on the extended model to compare the results. / Krav engineering är den viktigaste fasen inom mjukvaruutveckling faser eftersom det är användas för utvinning av krav från kunder som används av de följande faserna för utformning och genomförandet av systemet. På grund av dess betydelse, denna avhandling fokuserar på sikt aspekt orienterade krav på teknik, som är den första fasen i aspekt Orienten mjukvaran utveckling används för identifiering och representation krav som samlats in i form av oro. Förutom det övergripande förklaring av aspekt oriented Kravet tekniska fasen, detalj uppmärksamhet ges till en specifik verksamhet inom AORE fasen kallas konfliktlösning. Flera metoder som föreslås för konfliktlösning mellan aspekter diskuteras tillsammans med ett försök att ge en ny idé i form av en utvidgning av redan föreslagna modellen för konflikt resolution. Behovet av förlängning av redan föreslagna modellen är motiverad av att använda en fallstudie som appliceras på båda modellerna dvs i den ursprungliga modellen och om den utvidgade modell för att jämföra resultat. / faysal_hameed@hotmail.com, ijazbutt1@hotmail.com

Requirement elicitation is a critical activity in the requirement development process and it explores the requirements of stakeholders. The success or failure of this process is based on identifying the relevant stakeholders and discovering their needs as well as the quality of requirements. The quality of the requirements is greatly influenced by methods applied during requirements elicitation process. Only complete and structured requirements make these projects more reliable. The common challenges that analysts face during elicitation process are to ensure effective communication between stakeholders as well as the acquisition of tacit knowledge. Mostly errors in the systems are due to poor communication between user and analyst, and these errors require more resources (time and money) to correct them. The understandability problems during elicitation process of large web projects can lead to requirements ambiguous, inconsistent, incorrect and unusable. Different methods (Conversational, Observational, Analytical and Synthetic) are available to deal with the problems during requirement elicitation process. The challenge for analysts is to select an appropriate method or set of methods and apply them for the clear, consistent and correct requirement gathering. This study based on the results of interviews conducted to the professionals, who have industrial experience in development of web systems. The elicitation problems that are identified in literature and interview along with applicability of elicitation methods for requirement gathering in large web projects development are documented in this report. / Umar Sajjad Charhoi, Kotli, Azad Kashmir, Pakistan Muhammad Qaisar Hanif Bhimber, Azad Kashmir, Pakistan

Use cases are textual artifacts used to define the expected behavior of a system. However, use cases become more complicated when applied in a product line context since they need to define the behavior of several systems. Product line use cases require knowledge of commonality and variability concepts, which all involved stakeholders do not necessarily possess. Product-specific use cases are more understandable since they do not include variability information. Therefore, it would be beneficial to derive product-specific use cases from the product line use cases once the variability has been bound. This derivation could alleviate communication and help create a shared understanding of the product's expected behavior amongst diverse stakeholders.  In this thesis work, we have implemented a tool that can perform this type of derivation. The tool is divided into two collaborating parts. The first part is an extension to DOORS, which is responsible for creating and maintaining product line use cases. The second part is a third-party application responsible for binding the variability and deriving product-specific use cases. This tool was evaluated using a questionnaire with participants from Alstom, a company within the railway transportation domain. The evaluation showed that the tool has potential as a vehicle for communication amongst diverse stakeholders. / Use cases är textuella artefakter vilka används för att definiera det förväntade beteendet hos system. Dock så blir use cases mer komplicerade när de appliceras inom en produktionslinje-kontext, eftersom de då behöver definiera beteendet av flera olika system. Användandet av produktionslinje use cases kräver kännedom av kommonalitet och variabilitet koncept, vilket alla inblandade delägare inte nödvändigtvis behärskar. Därför skulle det vara gynnsamt om man kunde derivera produktspecifika use cases från produktionslinje use cases när dess variabilitet har bundits. Denna derivation skulle kunna underlätta kommunikation och skapa en gemensam förståelse av produktens förväntande beteende bland delägare med olika bakgrunder.    I detta avhandlingsarbete har vi implementerat ett verktyg som kan utföra denna typ av derivation. Verktyget är uppdelat i två samarbetande delar. Den första delen är ett tilläggsprogram till DOORS, vilken är ansvarigt för att skapa och underhålla produktionslinje use cases. Den andra delen är en tredjeparts applikation vilken är ansvarig för att binda variabiliteten och derivera fram produktspecifika use cases. Verktyget evaluerades med ett frågeformulär med tio deltagare från Alstom, ett företag inom järnvägstransport området. Denna evaluering visade att verktyget har potential att användas som ett fordon för kommunikation mellan delägare med olika bakgrunder.

Requirements analysis is an essential part of the System Development Life Cycle (SDLC) in order to achieve success in a software development project. There are several methods, techniques and frameworks used when expressing, prioritizing and managing requirements in IT projects. It is widely established that it is difficult to determine requirements for traditional systems, so a question naturally arises on how the requirements analysis is executed as AI solutions (that even fewer individuals can grasp) are being developed. Little research has been made on how the vital requirements phase is executed during development of AI solutions. This research aims to investigate the requirements analysis phase during the development of AI solutions. To explore this topic, an extensive literature review was made, and in order to collect new information, a number of interviews were performed with five suitable organizations (i.e, organizations that develop AI solutions). The results from the research concludes that the requirements analysis does not differ between development of AI solutions in comparison to development of traditional systems. However, the research showed that there were some deviations that can be deemed to be particularly unique for the development of AI solutions that affects the requirements analysis. These are: (1) the need for an iterative and agile systems development process, with an associated iterative and agile requirements analysis, (2) the importance of having a large set of quality data, (3) the relative deprioritization of user involvement, and (4) the difficulty of establishing timeframe, results/feasibility and the behavior of the AI solution beforehand.