The paper presents a series of techniques which goal is to detect the presence of RF signal from different devices such as bluetooth, Zigbee, etc. They main contributions is the use of commodity WiFi adapters which allows anyone to use the solution proposed.

The image below show an schematic view of the process of fingerprinting RF Signals and the pattern matching stage:

airshark modules

The detection rate is pretty awesome as shown in the next table:

• Embedded Multicore [PDF Version]

This paper is pretty long paper by Freescale describing several features of MultiCore Systems from a developer point of view both Operating Systems and application programmers. It covers basic techniques when dealing with MultiCore systems but provides some good aspects to state-of-the-art on this area and where the industry is heading.

Freescale's QorIQ(tm)

 It also describes how virtual platforms allow developers to make better use of these kind of systems for example running a dedicated RTOS in a core a having a general purpose OS in another.

It is a good reading to brush up some concepts and get a better picture since MultiCore System will become the standard in the near future.

• Verification: Check whether we are building the product right
• Validation: Whether we are building the right product

Some authors propose several strategies to improve software testing results:

• Quantify Requirements long before the testing begins: So testers can measure how close the product is to the client’s idea.
• Specify testing goals: Time between failures, cost of fixing a failure, etc
• Understand the client’s behaviour and develop a profile:  Focus software testing on its real usage
• Testing plan featuring ‘Quick Testing Cycles’
• Self-ControlProduct: Failure detection
• Formal Testing Techniques: (Alright, they might be cool but too expensive)
• Continuous Integration

 Strategies for Testing Software

Unit Testing:

• Verification of each module to check whether it implements the contract it relays on.
• Since some other components it depends on might not be yet available, some interface simulation must be developed.

Integration Testing:

• The goal of this process is to test the interaction between modules and prevent any problema when interconecting interfaces
• Top-Botton Aproach needs to generate simulators for no yet available modules
• Bottom-Up Approach tests first low-level modules and keeps adding higher-level ones so no simulation is needed
• Regression Tests are needed to be sure that when some modules has been modified all other keeps working ok
• Smoke Testing is a lightweight tests which aims to detect problem in a early stage. It must be tested daily

Validation

• Focuses to check whether the product stays close to the requirements
• Uses Alpha (developer + user) and Beta (only user) tests

Introduction to the PSP

The book is written in a pretty informal way, the author seems to talk to his son or someone really close, which I don’t really mind but, from my point of view, adds extra literature not necessary at all to explain the PSP.

The author focuses in two aspects along the book, measuring / planning and defects. The most valuable part and which I found more interesting is the one dealing with personal planning since it can help you not only when dealing with software projects but in your real life.

I really think that applying techniques such as registering tasks durations, interruptions management and creating week summary can help you become more productive and eliminate those periods of the day you think you are working but your not.

I also agree with the author that using his techniques you can become more realistic when planning a new project I think it is not because of the whole planning stuff but you can know exactly how many time are you really working in your projects without all that bloat of interruptions.

The part I don’t really like is the second half of the book which focuses in dealing with defects. The author ideas are only applicable when dealing with beginners defects and I don’t find useful any of the metrics he proposes.

In few words, this books is worth reading if you feel you are wasting your time and want to become more productive and/or want to make sure you can make realistic project plans.

• A design must present an architecture built using known pattern designs, components with the right characteristics and that can be implemented in an incremental way.
• Must be modular, divided in subsystems
• Must lead to interfaces which reduce the complexity when connecting components
• Must be generated from a reproducible method and the information produced during the analysis
• Must use notation to express its meaning correctly

COQ takes into account the following costs:

• Failure costs: All costs of fixing a defect e.g. Patching a deployed product, using the debugger, reviewing code, etc
• Appraisal costs: Work done evaluating whether a product has defects, excluding time spend on fixing them.
• Prevention costs: Resources used to improve the process to reduce the number of defects.

Following I will describe the PSP approximation to COQ a simplified way of calculating this measurement. The author states than this version of COQ shows the same effectiveness as the long COQ version.

• Failure costs: all compiling time, all testing time.
• Appraisal cost: All review time

Cost of Quality is calculated as a percentage of total development time:

• Appraisal COQ: Sum of all review time as percentage of total development time.
• Failure COQ: Sum of all compile and test time as percentage of total development time.

Product: Something produced for a company or client

Project: Used to produce a Product

Task: Element of work

Process: Way to do projects

Phase: Steps proposed in a process (e.g. Planning, development, testing). Each phase is composed of tasks

Definitions from “Introduction to PSP” by Watts S. Humphrey