Micro audio system project sketchup

Micro Audio system


Left: 130 x 130 mm

Right: 180 x 130 mm

Speaker 2 X fullrange Monacor 80mm 40w max

Integrated amplifier 20w in the left box, with integrated power supplier. Pre amplifier optional.

In R+L rca, Bluethoot optional.

If you want you can download the original project made with Google SketchUp here, it’s free and you can modify it, enjoy!  https://www.dropbox.com/s/dyii2vsc0nt2jl4/q%403.skp








Agile Scrum methodology

Why use AGILE?

Agile methodologies have emerged to solve some common faults which are defined in the traditional methods , for example the involvement of all stakeholders in the process, or for example to have a constant overview of the cyclical state of the project.
Take for example a methodology Waterfall based project, with a duration of, let me say, six to eight months, is extremely complex at the fourth or fifth month to realize that you have a blocking problem, for which a huge part of the project should be changed!

You will say, “yes, but the Waterfall methodology provides that part of analysis is very thorough, and you shoud contemplate this kind of problems at the beginning!”.
Sure, I say, but the fact is that in this methodology, just to take into account any issues that “could” meet, the estimates must always be a bit larger, otherwise the  the project could sink into chaos, which means … wasting time and of course money!
Overestimation is the first project bug that you could have! And.. otherwise you could fall in chaos and customer disappointment.

Agile was bort to avoid these behaviours, everithing is cyclic na you could have the time to analize, let me say, time to time, little project “steps”, to manage it.

In other words, also the involvment of all stakeholders, and with stakeholder I mean customers, developers, and your boss (!), you could be sure that also the responsibility is not only yours but it is a real team work.

What is SCRUM?

Wikipedia for SCRUM says:

SCRUM is an iterative and incremental agile software development method for managing software projects and product or application development.

SCRUM has not only reinforced the interest in project management, but also challenged the conventional ideas about such management.

SCRUM focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control oriented management.

It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.

The SCRUM Process

The SCRUM process is quite simple to explain, it is absolutely iterative and cyclic, there are some keywords you should know in particular:

  • Sprint – an iteration that is more or less 2-4 weeks
  • Stakeholders – all people involved in the process
  • SCRUM Master – an hi level developer, who is directly involved in development, but he has a higher level overview of the entire project
  • Product Owner – the company internal product manager / project manager
  • Product Backlog – the specification document with requirements (user stories) priorized and ordered following the Sprint / iterations organization
  • Iteration – a cycle, an iteration that is identifiable with a Sprint or a complete cycle before the omelet release
  • Priorization – the action taken by the Product Owner and the SCRUM Master to obtain the Product Backlog

Flow description

Basically the flow is quite simple to explain, it can be splitted in seveal logical sections:

  1. The requirement document, that contains the description of the project result don with the customer will be splitter into atomic elements, basically these elements should be a kind of the atomic requests / requirement (in SCRUM these requirements are called “user stories”)
  2. First meeting: Customer, Project Owner, SCRUM Master
  3. The Product Owner with the customer and the SCRUM Master, have a meeting to reorder the single user story, this task is the prioritization. This meeting is intended to re order all customer requirements / user stories, to obtain a list of priority to be delivered.
  4. Second Meeting: SCRUM Master and development team
  5. The SCRUM Master assigns the tasks to the development team, each developer must read the user stories, ordered by priority, than they can assign to themselves the user story, add some comments as a “task” description (for example how to develop, impression, questions and so on) and then they must add a time estimation, for each task.
  6. When the team ends this estimation task, the SCRUM Master, can create the iterations, the Sprints: the SCRUM Master can decide how long a Sprint must be (usually 2-4 week), and he can immediately take the ordered list of user stories and task associated, and he can split those element as a macro list of Sprints, 1, 2, 3 etcetera.
  7. Third Meeting: Project Start – Sprint meeting.
  8. Once the iterations end the SCRUM Master and development team should have another meeting before to start the follow Sprint: the Sprint meeting.
  9. After this task, the dev team can start to work on the project!
SCRUM methodology needs communication: SCRUM Master and the dev team should have another kind of meeting, it is called “standup daily meeting”, that is very useful to a daily overview about eventual blocker issues or problems!

The best way to take a look at the project progress is identified with the Burndown chart:

How to migrate an SVN repository

Waiting a customer’s server snapshot – the third since 9am 🙂 … I would like to share a way to fast migrate SVN repo.

In the current server where is the repo to migrate:

$ svnadmin dump /<path>/repo > dumpfile.dump

Then in the second server:

$ svnadmin load reponame > dumpfile.dump

If you would like to filter some project, preventing the export:

svndumpfilter include projA < repo.dump > projA.dump

or to exclude something:

svndumpfilter exclude projB < repo.dump >> projA.dump
svndumpfilter exclude projC < repo.dump >> projA.dump

Requirements Based Testing

An italian free webinar, I will be the speaker!

Data: 27 June 2012
Ora: 17:00 Europe Time (Rome, GMT +01:00)
Durata: 60 minuti
Dove: dal tuo PC o Desktop Computer
Lingua: Italiano

A chi è rivolto

Business Analysts, Requirements Engineers, Compliance Managers, Project Managers, Risk Managers, Quality Assurance, Testers and Senior Developers

Il webinar fornirà utili consigli su:

  • Metodi di definizione e gestione dei requisiti
  • Tracciare e valutare l´impatto dei cambiamenti sui requisiti
  • Essere compliant con l´Audit sapendo “Chi, cosa, quando e perchè di qualsiasi modifica” in qualsiasi momento
  • Incoraggiare la Collaboration grazie a Commenti, Voti e Notifiche
  • Implementare un cambiamento e pianificare le modifiche relative
  • Quanto sia importante condurre test che siano collegati ai requisiti per garantire una completa test coverage dei requisiti
  • Sarà infine possibile porre delle domande nella sessione Q&A


  • RBT (Requirement Based Testing), cos´è, perchè adottarlo
  • Perché è critico avere buoni requisiti
  • Polarion Requirement + Polarion QA
  • Testing session:
    • Definire requisiti e test cases in Polarion
    • Definire i criteri di test di completamento
    • Disegnare i test cases
    • Creare i test cases
    • Esecuzione dei test
    • Verificare i risultati dei test
    • Verificare la test coverage
    • Gestire e tracciare i task e i difetti
    • Gestire la test library
  • Q&A