物件導向軟體之架構(Object-Oriented Software Construction)探討

National Institute of Standards and Technology における超伝導研究及び生活

Resena de la obra de Don A. Dillman, Jolene D. Smyth y Leah Melani Christian: Internet, Phone, Mail and Mixed-Mode Surveys. The Tailored Design Method. New Jersey: John Wiley and Sons

https://dialnet.unirioja.es/descarga/articulo/7287796.pdf

Internet, phone, mail and mixed-mode surveys: the tailored design method: reseña

https://onlinelibrary.wiley.com/doi/pdf/10.1002/stvr.247

Problem frames: analyzing and structuring software development problems. By Michael Jackson. Published by Addison‐Wesley, Boston, Massachusetts, U.S.A., ACM Press Series, 2001. ISBN: 0‐201‐59627‐X, 390 pages. Price: U.K. ?32.95, U.S.A. $49.99, soft cover.

Dictionary of Statistics and Methodology.

Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.

/pdf/how-do-software-architects-consider-non-functional-2n4dda8nyg.pdf

How do software architects consider non-functional requirements: An exploratory study

The impact of non-functional requirements (NFRs) over software systems has been widely documented. Consequently, cost-effective software production method shall provide means to integrate this type of requirements into the development process. In this vision paper we analyze this assumption over a particular type of software production paradigm: model-driven development (MDD). We report first the current state of MDD approaches with respect to NFRs and remark that, in general, NFRs are not addressed in MDD methods and processes, and we discuss the effects of this situation. Next, we outline a general framework that integrates NFRs into the core of the MDD process and provide a detailed comparison among all the MDD approaches considered. Last, we identify some research issues related to this framework.

/pdf/dealing-with-non-functional-requirements-in-model-driven-51wahb43g5.pdf

Dealing with Non-Functional Requirements in Model-Driven Development

Software architects often must work with incomplete or ill-specified non-functional requirements (NFRs) and use them to make decisions. Through this process, existing NFRs are refined or modified and new ones emerge. Although much research has centered on how software architects treat NFRs, no empirical studies have investigated the state of the practice. A survey based on interviews with 13 software architects addressed two fundamental issues: how do architects face NFRs from an engineering perspective, and how do NFRs influence their decision-making? The survey revealed that architects usually elicit NFRs themselves in an iterative process; they usually don't document the NFRs and only partially validate them.

Non-functional Requirements in Architectural Decision Making

Context: Open source software (OSS) and software ecosystems (SECOs) are two consolidated research areas in software engineering. OSS influences the way organizations develop, acquire, use and commercialize software. SECOs have emerged as a paradigm to understand dynamics and heterogeneity in collaborative software development. For this reason, SECOs appear as a valid instrument to analyze OSS systems. However, there are few studies that blend both topics together. Objective: The purpose of this study is to evaluate the current state of the art in OSS ecosystems (OSSECOs) research, specifically: (a) what the most relevant definitions related to OSSECOs are; (b) what the particularities of this type of SECO are; and (c) how the knowledge about OSSECO is represented. Method: We conducted a systematic mapping following recommended practices. We applied automatic and manual searches on different sources and used a rigorous method to elicit the keywords from the research questions and selection criteria to retrieve the final papers. As a result, 82 papers were selected and evaluated. Threats to validity were identified and mitigated whenever possible. Results: The analysis allowed us to answer the research questions. Most notably, we did the following: (a) identified 64 terms related to the OSSECO and arranged them into a taxonomy; (b) built a genealogical tree to understand the genesis of the OSSECO term from related definitions; (c) analyzed the available definitions of SECO in the context of OSS; and (d) classified the existing modelling and analysis techniques of OSSECOs. Conclusion: As a summary of the systematic mapping, we conclude that existing research on several topics related to OSSECOs is still scarce (e.g., modelling and analysis techniques, quality models, standard definitions, etc.). This situation calls for further investigation efforts on how organizations and OSS communities actually understand OSSECOs.

/pdf/open-source-software-ecosystems-a-systematic-mapping-1pab6ryz0q.pdf

Open source software ecosystems: A Systematic mapping

One of the most successful architectural styles nowadays is service oriented architecture (SOA). In this type of architecture there are a lot of dependencies between services, but each service is an independent element of the system. In this situation we need some way to ensure that every service is working correctly and to take actions when something goes wrong to evolve the architecture as fast as we can. For example, if one of the lower level services of the service composition stops working, it could lead to a total or partial system malfunction. In this situation there is a need to be able to build reliable SOA systems. Our proposal, SALMon, is based on monitoring the services for service level agreement (SLA) violations. The SALMon architecture is composed of three types of components: Monitors that are composed of measure instruments, the measured quality attributes being taken from an ISO/IEC 9126-1-based service oriented quality model; analyzers that check the SLA rules; and decision makers that perform corrective actions to satisfy SLA rules again. These 3 types of components are mostly technology-independent and they act as services inside of a SOA system making our architecture very scalable and comfortable for its purpose.

/pdf/service-level-agreement-monitor-salmon-2cyahowc3c.pdf

David Ameller

Papers

How do software architects consider non-functional requirements: An exploratory study

Dealing with Non-Functional Requirements in Model-Driven Development

Non-functional Requirements in Architectural Decision Making

Open source software ecosystems: A Systematic mapping

Service Level Agreement Monitor (SALMon)