Effectiveness of Code Reading and Functional Testing with Event-Driven Object-Oriented Software

Cantone, Giovanni; Abdulnabi, Zeiad A.; Lomartire, Anna; Calavaro, G.

doi:10.1007/978-3-540-45143-3_10

Cited by 4 publications

(4 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This was mainly aimed at mitigating the possibility that subjects would not search systematically for defects or not consider all defect types. Using a checklist is also consistent with how inspections are conducted in an industrial setting, where practitioners know the possible types of defects they are looking for beforehand, either based on a checklist or through experience [Cantone et al 2003;Thelin et al 2003]. …”

Section: Design Of Experimentsmentioning

confidence: 99%

Traceability and SysML design slices to support safety inspections

Briand

Falessi

Nejati

et al. 2014

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

Certifying safety-critical software and ensuring its safety requires checking the conformance between safety requirements and design. Increasingly, the development of safety-critical software relies on modeling, and the System Modeling Language (SysML) is now commonly used in many industry sectors. Inspecting safety conformance by comparing design models against safety requirements requires safety inspectors to browse through large models and is consequently time consuming and error-prone. To address this, we have devised a mechanism to establish traceability between (functional) safety requirements and SysML design models to extract design slices (model fragments) that filter out irrelevant details but keep enough context information for the slices to be easy to inspect and understand. In this article, we report on a controlled experiment assessing the impact of the traceability and slicing mechanism on inspectors' conformance decisions and effort. Results show a significant decrease in effort and an increase in decisions' correctness and level of certainty.

show abstract

Section: Design Of Experimentsmentioning

confidence: 99%

Traceability and SysML design slices to support safety inspections

Briand

Falessi

Nejati

et al. 2014

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

show abstract

“…Khaled El Emam and Isabella Wieczorek (1960), and Kennet Henningsson and Claes Wohlin (2004) investigated ODC empirically by focusing on subjectivity of defect classification. In order to evaluate the level of cohesion among classifications that different subjects enacted, both studies used "Kappa statistics" (Cohen, 1960), and worked on their own variations of ODC. In particular, El Emam and Wieczorek involved various combinations of three subjects who performed in the role of defect categorizers on an actual software artifact, during the development process; they hence collected and eventually analyzed "real inspection data" (El Emam & Wieczorek, 1960).…”

Section: Related Workmentioning

confidence: 99%

“…We can count a significant number of empirical works from many authors worldwide, whose conclusions are based on categorization of software defects. A common assumption of all those works (see Section 8 for few samples of them: (Basili & Selby, 1987;Cantone et al, 2003;Juristo and Vegas, 2003;Myers, 1978)) is that in large extent defects can be classified objectively, whatever the classification model might be. In the absence of enough evidence for such an assumption, all those empirical results could be questioned.…”

Section: Study Motivations and Viewmentioning

confidence: 99%

See 1 more Smart Citation

An Application of the 5-S Activity Theoretic Requirements Method

Brown¹,

Hyland²,

Piper³

2006

Proceedings of the First International Conference on Software and Data Technologies

View full text Add to dashboard Cite

Whether application integration is internal to the enterprise or takes the form of external Business-to-Business (B2B) automation, the main integration challenge is similar -how to ensure that the integration solution has the quality of adaptiveness (i.e. it is understandable, maintainable, and scalable)? This question is hard enough for stand-alone application developments, let alone integration developments in which the developers may have little control over participating applications. This paper identifies main strategic (architectural), tactical (engineering), and operational (managerial) imperatives for building adaptiveness into solutions resulting from integration projects.IS-6 more aligned with (better suited for) loosely coupled integration. This is because data can be easily put aside for later use. Conversely, process integration is more aligned with tightly couple integration. Data replication, portal sharing, and messaging are the three integration solutions listed in Table 2 but missing in Table 1. Data replication is classified as synchronous integration because replication servers of databases can be programmed to perform replications continuously and replicate data as the primary data is changing. Probably slightly controversially, portal sharing is classified in Table 2 as synchronous data integration. Portals are web sites or applications that provide access to a number of sources of information and facilities (portlets). They aggregate information from multiple sources into a single display. The display of information is synchronous but no any sophisticated process-level communication between portlets is normally assumed -hence, data integration. Messaging is the primary technology for asynchronous process integration (Hohpe and Woolf, 2003). Based on the Publish/Subscribe model, messaging frameworks guarantee reliable delivery of messages in program-to-program communication while recognizing that synchronous communication with remote applications is difficult to achieve (yet asynchronous communication is frequently acceptable). ASSURING ADAPTIVE INTEGRATIONBuilding adaptiveness into enterprise and e-business systems engages all three traditional levels of management -strategic, tactical and operational.From the system's development perspective, the strategic level refers to the architectural solutions, the tactical level to the engineering decisions, and the operational level to the project controlling tasks. These three levels of management are used in the conventional top-down fashion when software is developed. We can say that system architecture defines adaptiveness, engineering activities deliver adaptiveness, and controlling tasks verify the existence of adaptiveness in an implemented system. IS-7Figure 2: PCBMER-A meta architecture.architecture PCBMER-A (where A signifies an application-centric integration). Figure 2 shows a high-level view of the PCBMER-A metaarchitecture.The second integration meta-architecture applies to process-level integrations, providing support for inter-app...

show abstract