International Conference on Software Engineering (ICSE) 2010, 2-8 May in Cape Town. Paper submission was 6 September 2009.
Previous conferences had for example workshops on Automotive Software Engineering, Sharing and Reusing Architectural Knowledge and Leadership and Management in Software Architecture .
Workshop program is not yet published but preliminary deadline for workshop submissions are January 2010.
International Conference Series on the Quality of Software Architectures (QoSA), June 23-25, 2010, Prague, Czech Republic
Paper submission in February, I guess...
European Conference on Software Architecture (ECSA), IT-University Copenhagen, 23-26 August 2010
Submission deadline March 15, 2010
Anybody knows of other conferences on software architecture or on automotive software engineering?
Thursday, October 8, 2009
Wednesday, October 7, 2009
Agile and Architecture
I have read and heard several "observations" on how to incorporate a guiding architecture in the current trend of having agile S/W development. There seem to be a lot of smoke but not so much substance, but I will try to summarise a few points which I have concluded through the smoke.
Caveat: My background is in automotive software, and there seems to be no business domain which is less agile than automotive...
Architecture is up-front design, so if no upfront design is important in you agile practice, then I claim the architecture will rather be manifested by your code than the result of making concious decisions between architectural alternatives. The question is if you could have a light architecture so that you avoid a big upfront design (BUD) and allow the architecture to evolve in parallel with the software while it still guides and controls the software development.
Most agile practices focus on delivering the functional behaviour (use cases, user stories, or whatever), which drives the software. Contrary to this architecture focuses on satisfying the non-functional properties as well, i.e. quality attributes which usually are system-wide. I think deciding between these two focuses is really a business decision on how you want the team to work. If the former is more important then you don't have the same need of someone preforming the role of an architect. If the latter is important it will be difficult to succeed if you don't empower them.
I have heard studies of agile practitioners that claim that non-functional properties are solved in re-factoring (for example one study by M.A. Babar at the experience track at the WICSA 2009 conference). I claim that some properties cannot be solved by re-factoring, for example in the development of safety-critical systems. But agile practices should perhaps never be used for development of those?
There seem to be a trend to use agile synonymous with no or little documentation. I don't mind having small architecture descriptions (AD). A possible problem: If the rationale is omitted to make the AD smaller, I think the value of the AD will be significantly less.
If I read the Agile Manifesto there is nothing that says you should de-emphasise a guiding architecture...
Some texts, blogs and presentations can be found with a little googling:
Software Architecture and Agile Software Development —An Oxymoron? by P Kruchten
Agile Architecture: Strategies for Scaling Agile Development by Scott W Ambler
Software Architecture-Centric Methods and Agile Development by Nord and Tomayko
The Formal Goodness of Agile Software Architecture, part 1 and part 2 by Dave Langer
Architecture Meets Agility by Hakan Erdogmus in IEEE Software
There is also a forthcoming book with the title "Lean Software Architecture" by Coplien and Bjørnvig, forthcoming in May 2010. They have some interesting links and excerpts on their website.
Caveat: My background is in automotive software, and there seems to be no business domain which is less agile than automotive...
Architecture is up-front design, so if no upfront design is important in you agile practice, then I claim the architecture will rather be manifested by your code than the result of making concious decisions between architectural alternatives. The question is if you could have a light architecture so that you avoid a big upfront design (BUD) and allow the architecture to evolve in parallel with the software while it still guides and controls the software development.
Most agile practices focus on delivering the functional behaviour (use cases, user stories, or whatever), which drives the software. Contrary to this architecture focuses on satisfying the non-functional properties as well, i.e. quality attributes which usually are system-wide. I think deciding between these two focuses is really a business decision on how you want the team to work. If the former is more important then you don't have the same need of someone preforming the role of an architect. If the latter is important it will be difficult to succeed if you don't empower them.
I have heard studies of agile practitioners that claim that non-functional properties are solved in re-factoring (for example one study by M.A. Babar at the experience track at the WICSA 2009 conference). I claim that some properties cannot be solved by re-factoring, for example in the development of safety-critical systems. But agile practices should perhaps never be used for development of those?
There seem to be a trend to use agile synonymous with no or little documentation. I don't mind having small architecture descriptions (AD). A possible problem: If the rationale is omitted to make the AD smaller, I think the value of the AD will be significantly less.
If I read the Agile Manifesto there is nothing that says you should de-emphasise a guiding architecture...
Some texts, blogs and presentations can be found with a little googling:
Software Architecture and Agile Software Development —An Oxymoron? by P Kruchten
Agile Architecture: Strategies for Scaling Agile Development by Scott W Ambler
Software Architecture-Centric Methods and Agile Development by Nord and Tomayko
The Formal Goodness of Agile Software Architecture, part 1 and part 2 by Dave Langer
Architecture Meets Agility by Hakan Erdogmus in IEEE Software
There is also a forthcoming book with the title "Lean Software Architecture" by Coplien and Bjørnvig, forthcoming in May 2010. They have some interesting links and excerpts on their website.
Wednesday, September 23, 2009
Software architecture book reviews
Some comments on textbooks on software architecture:
As a student text I think the main strengths is it's treatment of terminology and concepts, which also makes it useful as a reference.
A potential problem with this text is that the examples are vey high level. You need experience based in actual programming projects to see the connection between the examples in the book and actual implementations. It is also comparably weak in teaching how to design a top-level desing as part of an architecture. I would say this book is suitable for students at the end of their education.
A Software Architecture Primer is targeted directly to a student audience. I would say it is better if the knowledge in an architecture course should be used in later courses, e.g. a larger project course with co-operating teams, since it is more pragmatic and hands-on in defining a top-level design. Likewise I would guess it could suit a professinal who wants to start creating "simple architectures".
The Process of Software Architecting is the best (and may be the only one) that actually defines the process elements and tasks of architecting and how they would fit in a larger software development process. I would say this book is the best one for the professional architect that wants to more formally define or improve what they do; what inputs to use, what tasks to perform and what should be delivered. It may be suitable for students, but the process focus may make it harder to relate to, e.g. it would give very little help as a preparation for a student project course.
I like all three books and they all have their (different) purpose. Which book to get depends on who you are and what you intend to do or to learn. For a student in the first course on architecture I would suggest the Primer. As a S/W professional who wants to understand what an architect is talking about and why, go with SAiP. For a working architect who wants inspiration for improvement, go with the Process book.
Background: I got the opportunity to take a sabbatical semester from Volvo to teach an undergraduate course on software architecture and design of complex systems at the IT University in 2006. For various reasons I redesigned the entire course from scratch, with a few constraints; the teaching methodology should be a light version of problem-based learning (PBL) already established at the IT University, and the course book was already ordered by the university bookstore "Software Architecture in Practice" by Bass, Clements and Kazman.
I had no real problem with the choice of textbook, and it suited my intended course content quite well. I also thought the PBL methodology fitted very well with the topic of software archtiecture after the course.
I think the course was a success, it received praise form the students as one of the most interesting courses they had taken during their program, and I was very satisifed with the level of knowledge the students showed on the final exam.
- Software Architecture in Practice by Bass, Clements and Kazman
- A Software Architecture Primer by Reekie and McAdam
- The Process of Software Architecting by Eeles and Cripps
As a student text I think the main strengths is it's treatment of terminology and concepts, which also makes it useful as a reference.
A potential problem with this text is that the examples are vey high level. You need experience based in actual programming projects to see the connection between the examples in the book and actual implementations. It is also comparably weak in teaching how to design a top-level desing as part of an architecture. I would say this book is suitable for students at the end of their education.
A Software Architecture Primer is targeted directly to a student audience. I would say it is better if the knowledge in an architecture course should be used in later courses, e.g. a larger project course with co-operating teams, since it is more pragmatic and hands-on in defining a top-level design. Likewise I would guess it could suit a professinal who wants to start creating "simple architectures".
The Process of Software Architecting is the best (and may be the only one) that actually defines the process elements and tasks of architecting and how they would fit in a larger software development process. I would say this book is the best one for the professional architect that wants to more formally define or improve what they do; what inputs to use, what tasks to perform and what should be delivered. It may be suitable for students, but the process focus may make it harder to relate to, e.g. it would give very little help as a preparation for a student project course.
I like all three books and they all have their (different) purpose. Which book to get depends on who you are and what you intend to do or to learn. For a student in the first course on architecture I would suggest the Primer. As a S/W professional who wants to understand what an architect is talking about and why, go with SAiP. For a working architect who wants inspiration for improvement, go with the Process book.
Background: I got the opportunity to take a sabbatical semester from Volvo to teach an undergraduate course on software architecture and design of complex systems at the IT University in 2006. For various reasons I redesigned the entire course from scratch, with a few constraints; the teaching methodology should be a light version of problem-based learning (PBL) already established at the IT University, and the course book was already ordered by the university bookstore "Software Architecture in Practice" by Bass, Clements and Kazman.
I had no real problem with the choice of textbook, and it suited my intended course content quite well. I also thought the PBL methodology fitted very well with the topic of software archtiecture after the course.
I think the course was a success, it received praise form the students as one of the most interesting courses they had taken during their program, and I was very satisifed with the level of knowledge the students showed on the final exam.
Wednesday, September 16, 2009
Presentation on the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture
Here are the slides I used at my presentation at the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture in Cambridge 2009.
The presentation went well, but the questions showed that the audience was more interested in how the organisation perceived the role of it's own software architecture rather than the methodology and scientific conclusions. And the role of architecture was one thing that was not possible to generalise to other organisations...
The presentation went well, but the questions showed that the audience was more interested in how the organisation perceived the role of it's own software architecture rather than the methodology and scientific conclusions. And the role of architecture was one thing that was not possible to generalise to other organisations...
Thursday, September 10, 2009
Accurate numbers
I am going to present my paper at the Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture on Wednesday. If I get a question where somebody wants me to quantify my qualitative research I need to refrain from doing this...
Friday, August 21, 2009
Yet another article on Ethernet, Firewire and MOST...
Yet another article on what communication technology will be used in future infotainment systems. Read it fast since the articles in Automotive Engineering tends to be removed from the on-line edition after a while...
ETHERNET and 1394 spar with MOST for infotainment openings
Most interesting to read that Toyota starts using MOST now in two vehicles (new Prius and Lexus RX). I have the impression that they would not "commit" to such a change in technology if they did not belive it would stay.
ETHERNET and 1394 spar with MOST for infotainment openings
Most interesting to read that Toyota starts using MOST now in two vehicles (new Prius and Lexus RX). I have the impression that they would not "commit" to such a change in technology if they did not belive it would stay.
Tuesday, August 4, 2009
Review of the vehicle’s electrical and electronic architecture
Just being back from my summer vacation hiatus I found a good summary of present challenges for a vehicle’s electrical and electronic architecture from just-auto. I haven't figured out if the news archive is available forever so read it fast if you are interested...
A second interesting article was about the use of firewire (1394) in automotive applications: 1394 Automotive network enables powerful, cost-efficient in-vehicle networks for infotainment, navigation, cameras from Automotive DesignLine.
A second interesting article was about the use of firewire (1394) in automotive applications: 1394 Automotive network enables powerful, cost-efficient in-vehicle networks for infotainment, navigation, cameras from Automotive DesignLine.
Subscribe to:
Posts (Atom)