There has been some turmoil in the world of infotainment platforms. Intel has left Meego and have partnered with Samsung in Tizen. This just a few months after Meego 1.2 vas deemed GENIVI compliant. I have no idea if Tizen aims to be GENIVI compliant as well. But there are already some commercial platforms that are GENIVI compliant.
I have been involved in the Open Infotainment Labs, a project patially funded by VINNOVA aiming att evaluating radically different work methods compared to standard practice at most car manufacturers. We integrated the system in a car this week, 16 weeks after start of development.
Showing posts with label My research. Show all posts
Showing posts with label My research. Show all posts
Friday, November 18, 2011
Wednesday, May 25, 2011
Architectural views in practice
My research is not really focused on identifying the “best” architectural views for in-vehicle software. But as a side effect to the studies I am presently doing I got to think about three views that could actually make a difference in how well large projects succeeds (or fails). I have thought about the need of addiitonal views, but cannot think of an immediate need of more.
Integration is always an in issue in large projects that has some form of iterative development. With the increasing inter-dependencies between various parts of the system it is almost impossible to know what should be integrated when, for example what can actually be tested. There actually is already an architectural view defined that addresses this concern, the anatomy. I would describe the anatomy as visualisation of the complete system seen from an integration perspective, for example if a feature depends on a MOST interface it is no use to test it if the interface is not implemented. The visual picture means everybody should have the same understanding of the “.
The anatomy should dictate the order of development, delivery schedules and integration order. And the progress should be measured in how much of the anatomy is implemented, not in customer features. There is a relationship between customer features and the anatomy, but it is not one-to-one. you can read more about “Integration Centric Development and Anatomies” in a PowerPoint presentation or the article “Manifesting Shared Affordances in System Development – the System Anatomy” by L. Taxén and J. Lilliesköld.
The second view is the systems view, i.e. how the complete system is decomposed in smaller parts. I prefer to see this view as equivalent to the development view in Kruchten’s 4+1 views, i.e. it is aligned with the development teams. One can discuss if the system decomposition follows the organisation, as predicted by Conway’s law. The other extreme is that the development teams follow the most “logical” decomposition, i.e. ECUs, which is the most common unit to be outsourced to suppliers in the automotive domain.
The functional content of a vehicle is often defined by a list of customer features, which can be quite long, and this in itself can be considered an architectural view that concerns for example the business project, the marketing department and the end customer.
What is important for the development project is the relationship between this feature list and the two other views, i.e. what systems/development teams are responsible to implement the features and how the features relate to the anatomy. I don't know if these two relationships/mapping between views should be considered as separate views, which would make the total number of views 3+2.
Integration is always an in issue in large projects that has some form of iterative development. With the increasing inter-dependencies between various parts of the system it is almost impossible to know what should be integrated when, for example what can actually be tested. There actually is already an architectural view defined that addresses this concern, the anatomy. I would describe the anatomy as visualisation of the complete system seen from an integration perspective, for example if a feature depends on a MOST interface it is no use to test it if the interface is not implemented. The visual picture means everybody should have the same understanding of the “.
The anatomy should dictate the order of development, delivery schedules and integration order. And the progress should be measured in how much of the anatomy is implemented, not in customer features. There is a relationship between customer features and the anatomy, but it is not one-to-one. you can read more about “Integration Centric Development and Anatomies” in a PowerPoint presentation or the article “Manifesting Shared Affordances in System Development – the System Anatomy” by L. Taxén and J. Lilliesköld.
The second view is the systems view, i.e. how the complete system is decomposed in smaller parts. I prefer to see this view as equivalent to the development view in Kruchten’s 4+1 views, i.e. it is aligned with the development teams. One can discuss if the system decomposition follows the organisation, as predicted by Conway’s law. The other extreme is that the development teams follow the most “logical” decomposition, i.e. ECUs, which is the most common unit to be outsourced to suppliers in the automotive domain.
The functional content of a vehicle is often defined by a list of customer features, which can be quite long, and this in itself can be considered an architectural view that concerns for example the business project, the marketing department and the end customer.
What is important for the development project is the relationship between this feature list and the two other views, i.e. what systems/development teams are responsible to implement the features and how the features relate to the anatomy. I don't know if these two relationships/mapping between views should be considered as separate views, which would make the total number of views 3+2.
Tuesday, February 1, 2011
Research in software engineering
Researching software engineering is to study the artificial. Other engineering disciplines have "truths" that exist even if no humans are involved. The laws of physics that determine what is possible in mechanical and civil engineering are there regardless if applied when constructing a particular building.
Because of this I strongly believe that research in software engineering must be based on what practitioners do. I started to write professionals, but realised that a lot of important stuff in the world of software are actually made by amateurs (in the sense they are not getting paid to do it). And I also think research methods from the social sciences can provide great insights into software engineering.
A colleague of mine said that a good researcher in software engineering should have three base pillars to stand on:
A short litmus test to discern if a researcher has enough experience of practical problems:
Describe the difference between a software process and a software project.
Because of this I strongly believe that research in software engineering must be based on what practitioners do. I started to write professionals, but realised that a lot of important stuff in the world of software are actually made by amateurs (in the sense they are not getting paid to do it). And I also think research methods from the social sciences can provide great insights into software engineering.
A colleague of mine said that a good researcher in software engineering should have three base pillars to stand on:
- A good knowledge of real problems that practitioners have
- An interest in developing solutions to these problems
- Knowledge and experience in evaluating the solutions in practical (real) settings
A short litmus test to discern if a researcher has enough experience of practical problems:
Describe the difference between a software process and a software project.
Friday, November 19, 2010
Ranking of Software Engineering Journals
I got a link to a ranking of the top Software Engineering Journals from my colleague Robert Feldt.
This is based on how prestigious these journals are in the scientific community based on some bibliometric index. But I would also like to see a similar ranking of how prestigious a journal is in the community of practitioners. Would it be possible to identify an index for that?
This is based on how prestigious these journals are in the scientific community based on some bibliometric index. But I would also like to see a similar ranking of how prestigious a journal is in the community of practitioners. Would it be possible to identify an index for that?
Tuesday, October 19, 2010
Project presentation
I presented my project at the yearly Volvo Industrial PhD program conference last week.
Thursday, September 16, 2010
Why I don't like formal methods...
I know the title of this port is a bit controversial and with it I alienate a lot of researchers, even at my own department. But I will try to clarify my arguments and hope that someone can prove them to be wrong.
- To be more precise; it is not the formal methods in itself I dislike, but the prominence they seem to have at prestigious software engineering conferences. I think it is not at all in proportion to how well-used formal methods are among professional development.
- Formal methods are really attractive from a researchers perspective. You can use concepts as theorem, proof and deduction and other nice things. But nice is not the same as relevant.
- Even though I have heard about formal methods as one of the enablers to establish software engineering as a "real" engineering discipline for almost ten years I still don't think they are nearer being well-established now than then.
- Some claim that you can never be sure of the software unless you can prove properties about it, and I agree that presently formal methods are the only technique that promises to do so. But there is a lot of successful software out there which have not been proven.
- Specifications that fulfil the requirement of being interpreted formally are hard to write. Compare it to learn a new programming language and be proficient enough to use it without any side effects.
- I don't know if formal methods scale well. It is one thing to use it on a nice prototype system with 30 entities developed in your lab. It is another thing to use it on a system with 500 entities, many of these with quite varying quality in requirements and code.
- I still don't know of any that uses formal methods for real; i.e. as part of the normal way in products shipped to customers in business intent on making money. Not in one-shot attempts, pilot projects or by non-profit organisations.
A search on google skolar of industrial+software+formal+methods list papers from the 90s as the top results. And these seem more to be arguments against what I claim above rather than actual reports of usage. I really would welcome examples.
Tuesday, September 14, 2010
Software product line engineering
Software product line engineering is apparently about modelling variants and achieving formalism in feature descriptions. This is the conclusion I make after attending some workshops and the first morning sessions at the 14th International Software Product Line Conference in Jeju, Korea.
I presented an interesting paper together with Håkan from Scania of how architects work with maintaining and updating existing architectures over time in the automotive industry. And we did not get a single question!
Last year when I presented another case study everybody was interested in the case and wanted to hear more from industry, but this time it didn't seem to interest the audience.
I find it quite difficult to find venues to present research based on industrial experience and not theoretical examples.
Besides that, I find the notion of feature used in many presentations different from what I am used to. To me a feature is something which is discernible for the end user, same as the definition found in the original work here. For example an adaptive cruise control is a marketable feature in a vehicle. But if I would model that similar to feature modelling prevailing here the model would consist of an optional radar, a compulsory engine, compulsory brake, etc.This means a much higher degree of knowledge about the realisation of features.
I presented an interesting paper together with Håkan from Scania of how architects work with maintaining and updating existing architectures over time in the automotive industry. And we did not get a single question!
Last year when I presented another case study everybody was interested in the case and wanted to hear more from industry, but this time it didn't seem to interest the audience.
I find it quite difficult to find venues to present research based on industrial experience and not theoretical examples.
Besides that, I find the notion of feature used in many presentations different from what I am used to. To me a feature is something which is discernible for the end user, same as the definition found in the original work here. For example an adaptive cruise control is a marketable feature in a vehicle. But if I would model that similar to feature modelling prevailing here the model would consist of an optional radar, a compulsory engine, compulsory brake, etc.This means a much higher degree of knowledge about the realisation of features.
Thursday, September 2, 2010
Tacit knowledge
At the ECSA conference there was a lot of talk about tacit knowledge and the importance of tacit knowledge when architecting systems.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.
I completely agree that one thing that differs an experienced (and productive) architect from a fresh graduate is is the amount of tacit knowledge the former possess. However I thought that in the discussions at the conference there was some confusion of what is exactly meant by tacit knowledge.
On one hand there was the view that tacit knowledge was simply the architectural knowledge that was not documented, i.e. stuff that only resided in the peoples' heads. To improve the management of this is mostly a question of capturing it in the right form and with the best tools.
On the other hand one sees tacit knowledge is such knowledge which is difficult to express using language, which is the tradition I'm used to.
In order to capture the latter type of tacit knowledge it is not just a question of having the time to do so or the right tools. The difficult part is for the person having this knowledge to be able to formulate in in such a manner that he can express it.
Sunday, August 29, 2010
The future of software architecture research?
There are two areas which I judge to be of great interest to the industry regarding architecture, and I see very little interest from academia
First, how much effort should be put into architecting? In industry there never are unlimited man-power and indefinite time plans. So how do you know that you have done enough architecting? Or did too many people working with the architecture for a too long time? Or when are the gains in putting another man-hour too small to make it worthwhile?
Second, how to define an architecture based on imperfect premises? In practice the architects never have the full picture. There might be requirements missing, stakeholders unavailable or implicit constraints. Similarly the architects themselves are no super-humans, there will be inconsistencies in what they do, things forgotten, lack of crucial knowledge or personal biases, all which cause an imperfect architecture.
Personally I think that these two areas are more important from an industrial viewpoint than further software architecture research on Architecture Description Languages, formal methods or Service Oriented Architectures (the latter may be contested, but I think I am not alone).
At the 4th European Conference on Software Architecture the workshop in imperfect architecture was cancelled, probably due to too little interest (I heard only 3 papers were submitted). On the other hand I found 7 papers when I scanned the LNCS proceedings which in their title relates to the subjects above.
I don't find this very promising. Eoin Woods had a similar conclusion on the state of software architecture research at his ECSA talk when talking about the relationship between code and other design information, such as architecture, where he thought the academic research and the industrial needs are diverging and not converging.
You can also read this related column from IEEE Software: The Top 10 Burning Research Questions from Practitioners. Especially #4 "Architecture and agile—how much design is enough for different classes of problem?" should get more attention at software architecture conferences.
A colleague of mine at Volvo had an interesting proposition: Since software engineering as a dsiciplin comes from the practitioners the research community wants to keep some distance, in contrast to the "fundamental" researchers in e.g. physics who would be enthusiastic if somebody is interested in applying their theories.
First, how much effort should be put into architecting? In industry there never are unlimited man-power and indefinite time plans. So how do you know that you have done enough architecting? Or did too many people working with the architecture for a too long time? Or when are the gains in putting another man-hour too small to make it worthwhile?
Second, how to define an architecture based on imperfect premises? In practice the architects never have the full picture. There might be requirements missing, stakeholders unavailable or implicit constraints. Similarly the architects themselves are no super-humans, there will be inconsistencies in what they do, things forgotten, lack of crucial knowledge or personal biases, all which cause an imperfect architecture.
Personally I think that these two areas are more important from an industrial viewpoint than further software architecture research on Architecture Description Languages, formal methods or Service Oriented Architectures (the latter may be contested, but I think I am not alone).
At the 4th European Conference on Software Architecture the workshop in imperfect architecture was cancelled, probably due to too little interest (I heard only 3 papers were submitted). On the other hand I found 7 papers when I scanned the LNCS proceedings which in their title relates to the subjects above.
I don't find this very promising. Eoin Woods had a similar conclusion on the state of software architecture research at his ECSA talk when talking about the relationship between code and other design information, such as architecture, where he thought the academic research and the industrial needs are diverging and not converging.
You can also read this related column from IEEE Software: The Top 10 Burning Research Questions from Practitioners. Especially #4 "Architecture and agile—how much design is enough for different classes of problem?" should get more attention at software architecture conferences.
A colleague of mine at Volvo had an interesting proposition: Since software engineering as a dsiciplin comes from the practitioners the research community wants to keep some distance, in contrast to the "fundamental" researchers in e.g. physics who would be enthusiastic if somebody is interested in applying their theories.
Monday, August 2, 2010
Exploring variation mechanisms in the automotive industry: a case study
I supervised a thesis project on run-time variability in an AUTOSAR architecture.
You can read about the project, and download the thesis report, at the student's web site: quandoo.
You can read about the project, and download the thesis report, at the student's web site: quandoo.
Friday, June 18, 2010
Swedsoft meeting
Last week I attended a meeting between DICE and ABB with additional participants from Volvo Cars and Ericsson as well as some from academia. The meeting was arranged by Swedsoft.
I know nothing of the game industry so it was especially interesting to listen to the presenters from DICE, who all worked with the development of their game engine Frostbite. Some things were of particular interest:
I hope I didn't misunderstood anything...
I know nothing of the game industry so it was especially interesting to listen to the presenters from DICE, who all worked with the development of their game engine Frostbite. Some things were of particular interest:
- There is a fairly strong architecture for the Frostbite engine. Both for the runtime architecture (client-server) and even more important for the development architecture where the runtime architecture is just a "small" part besides e.g. the FrostEd editor for game objects and the build database(s).
- They use extensive knowledge about the game (domain knowledge) to minimise necessary information sent to/from the server and the clients (the latter being the software you buy at a gaming store and run on your Xbox360/PS3/PC).
- The run-time architecture uses parallel processing in multiple cores and distributes "jobs" between the cores dynamically.
- They use continuous builds, i.e. as soon as a programmer checks in new code it is built into a working program. This for the game developers always to have something to run.
- They only do positive testing, e.g. the program shall have this feature. No test on the program shall not...
- The Frostbite team consists of 19 developers and they update and maintain 1.5 MLOC for all 3 platforms (Xbox 360, PS3 and Windows). It is like we would maintain the entire in-vehicle software with 20 people.
I hope I didn't misunderstood anything...
Wednesday, June 16, 2010
Lindholmen Software Development Day 2010
Lindholmen Software Development Day is a yearly free get-together for local "software developers, managers, project managers and business developers" here at the north river shore in Göteborg. The theme for this year is
I was asked by some people at Volvo Cars to present something relevant to us, and after some thought the topic of my talk would be "The future of automotive software engineering". Not pretentious at all...
Here is the outline I proposed. Any acceptance notification will come in August.
- Perspectives on and analyses of the changing market situation
- Software development philosophies supporting the changed situation
- Discipline Integration challenges and solutions, e.g., in H/W-S/W codesign
- Processes, Methods or tools to improve speed, efficiency, or quality
- Experience reports from new ways of working
I was asked by some people at Volvo Cars to present something relevant to us, and after some thought the topic of my talk would be "The future of automotive software engineering". Not pretentious at all...
Here is the outline I proposed. Any acceptance notification will come in August.
- General briefing on current and future trends in automotive software engineering
- Exponential increase in size, complexity, innovations, …
- Cycle times are dictated by what?
- Industry-wide ways to cope
- Standardisation
- Model-based development
- Architecture
- Soft issues
- Knowledge and maturity in the industry
- How to earn money?
- Some examples (from Sweden)
Wednesday, May 26, 2010
Yet another article
The blog is updated on a very irregular basis. the main reason is that I presently have 3 articles in the pipeline and this takes priority over anything else. The latest article which I need to update is to ECSA 2010:
Dear AUTHORS,
Unfortunately your paper has not been accepted 'as it is' for inclusion in the program of the 4th European Conference on Software Architecture 2010 (ECSA 2010), which will be held on August 23-26 in Copenhagen, Denmark.
However, the program committee felt that the work reported in your paper has a number of interesting ideas, hence, I would like to invite you to prepare a shortened version of your paper for inclusion as "Emerging research" category Paper in the ECSA 2010 proceedings. As noted on the conference website, the "Emerging research" papers (8 pages of Springer formating) present promising achievements from work-in-progress and are intended to stimulate discussion related to ideas and experiences. For further details about the "Emerging research" papers, plesae visit ECSA 2010 website (http://www.ecsa2010.org). To accommodate publication schedules, final papers must be submitted by June 11, 2010.
... snip ...
4. The camera ready copy of your paper is due by June 11, 2010 (This is a hard deadline!).
... snip ...
Once again, congratulations on having your paper accepted as an "Emerging research" paper. We look forward to receiving your final camera ready paper, and to seeing you in Copenhagen, Denmark.
If you have any question or comment, please email me.
Regards,
Ali
ECSA 2010 Program Chair.
Tuesday, May 4, 2010
Time to plan a trip to Korea...
The paper Architecting Automotive Product Lines: Industrial Practice by Håkan Gustavsson from Scania and myself have been accepted to the 14th Software Product Line Conference.
"Dear authors,
Thank you for your submission to SPLC 2010.
We are pleased to inform you that your paper has been accepted for inclusion in the SPLC full paper program.
Due to strong competition, we could only accept 28 full papers out of 90 submissions, giving an acceptance rate of 31%.
Congratulations on being included in this select group.
... snip ...
Once again, congratulations on having your paper accepted.
We look forward to receiving your final revised paper, and to seeing you in September in Juju Island, South Korea.
Sincerely,
Jan Bosch and Jaejoon Lee
PC Co-chairs
SPLC 2010"
Monday, April 26, 2010
On variants...
During my research I gained some inside information into how various automotive manufacturers work. One very interesting observation is to see how different companies approach variants.
I know of two high-end companies having as a general architectural strategy not to have variants of systems or ECUs. Note that the electrical system as a whole may me different due to e.g. feature content, but if the system has a body control module there only exist one variant of that module both in development and manufacturing. To my understanding they are only using the optional variant in F. Bachmann and L. Bass, "Managing variability in software architectures," SIGSOFT Software Engineering Notes, vol. 26, 2001, pp. 126-132, and not any of the other types.
Personally I think that this is very beneficial for a company, both from an engineering and from a manufacturing perspective, even if it seems wasteful not to cost-optimise an ECU.
But this strategy is probably not for everyone. There are some common characteristics between these two companies:
The question is how you "dare" to go for such an architectural strategy if you are not already doing it? I think developing a business case to show that you would earn more $$$ with such a strategy would be extremely difficult.
I know of two high-end companies having as a general architectural strategy not to have variants of systems or ECUs. Note that the electrical system as a whole may me different due to e.g. feature content, but if the system has a body control module there only exist one variant of that module both in development and manufacturing. To my understanding they are only using the optional variant in F. Bachmann and L. Bass, "Managing variability in software architectures," SIGSOFT Software Engineering Notes, vol. 26, 2001, pp. 126-132, and not any of the other types.
Personally I think that this is very beneficial for a company, both from an engineering and from a manufacturing perspective, even if it seems wasteful not to cost-optimise an ECU.
But this strategy is probably not for everyone. There are some common characteristics between these two companies:
- The are both high-end brands and have customers that can afford to buy the best.
- They are not mass producers, only in the order of 100k vehicles per year. This means that development costs are not negligible to article cost, even if they are smaller.
- Tailoring to the customer needs is an important business strategy.
- The have unusually high ROI compared to the average for the automotive industry. Being successful is another way of describing it.
The question is how you "dare" to go for such an architectural strategy if you are not already doing it? I think developing a business case to show that you would earn more $$$ with such a strategy would be extremely difficult.
Saturday, March 27, 2010
Authors of the top papers...
Good news, but more work...
Dear Ulrik and Carl,
We are pleased to inform you that your research paper,
"A Case Study of the Architecture Business Cycle for an In-Vehicle Software Architecture",
has been selected to be extended and submitted to a Special Issue of the Journal of Systems and Software (JSS).
This JSS Special Issue will include the extended and revised best papers selected from the 2009 Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture (WICSA/ECSA 2009).
Indeed, we announced at WICSA/ECSA 2009 that extended versions of best papers of WICSA/ECSA 2009 would be selected to be submitted to JSS.
We have better news: our cooperation with JSS was upgraded to have this year a JSS Special Issue including the best papers of WICSA/ECSA 2009, instead of submitting papers that would be included in different issues.
Based on review scores and reviewer comments, we are inviting authors of the top papers to substantially extend (at least 30% of new material) their papers and submit them to this Special Issue. Congratulations on being included in this select group.
...snip...
Looking forward to hearing from you and hoping that you will accept our invitation to contribute to this Journal Special Issue.
Yours Sincerely,
Flavio Oquendo, Eltjo Poort, Judith Stafford
JSS Guest Editors (Program Chairs of IEEE/IFIP WICSA/ECSA 2009)
Wednesday, January 20, 2010
Publications in the pipeline
The blog originally had the intention to cover topics I'm intersted to research. So here is a short status update of what I am doing right now in my research project.
Together with a fellow researcher I made an extensive interview series with architects at two major automotive companies. So far the data from these interviews is used for 3 papers which will be submitted this spring:
Last year I made extensive observations of architectural decisions for the architecture of the next generation electrical system at Volvo Cars. So far the data from these observed decisions will be used for 2 papers:
I also have an idea about an interesting AUTOSAR-paper which partly will use information from a student thesis project I will supervise later this spring.
Together with a fellow researcher I made an extensive interview series with architects at two major automotive companies. So far the data from these interviews is used for 3 papers which will be submitted this spring:
- A compararative case study on how two similar companies work with maintaining architctures.
- A short paper describing how archtiects view themselves in terms of skills, experience, attitudes, etc.
- Another paper which I'm not authoring
Last year I made extensive observations of architectural decisions for the architecture of the next generation electrical system at Volvo Cars. So far the data from these observed decisions will be used for 2 papers:
- A new classification scheme for archtiecture decsions, based on empirical data
- A case study of the 80 decisions observed at Volvo Cars
I also have an idea about an interesting AUTOSAR-paper which partly will use information from a student thesis project I will supervise later this spring.
Tuesday, January 5, 2010
Empowered architects
In the course on project management and leadership for PhD students we are talking about the role of the project leader. The lecturer Max Rapp Ricciardi writes in an article by about empowerment and refers to an article by Quinn & Spreitzer.
Anyway, he mentions four characteristics of empowered people:
An architect which works in an organisation where he or she is not empowered have probably little chance of doing a successful job. I would even go so far to ask why such an organisation would even bother with having such a role?
Anyway, he mentions four characteristics of empowered people:
- They feel they are masters of their own destiny (they can do the work without management interference)
- The understand the totality of the business they are operating in
- They have confidence and a feeling of doing a good job
- They are convinced they can influence others, which is the opposite of learned helplessness
An architect which works in an organisation where he or she is not empowered have probably little chance of doing a successful job. I would even go so far to ask why such an organisation would even bother with having such a role?
Monday, December 28, 2009
Volvo Cars will become Chinese...
It is now official that Ford will sell Volvo Car Corporation to the Chinese auto manufacturer Geely. To be more precise this is what Stephen Odell (Volvo CEO) wrote:
The information was sent out to us employees by e-mail in the afternoon before Christmas Eve, the biggest holiday in Sweden, so most people had already gone on vacation and probably first saw the announcement in the newspapers. Personally I think the timing should have been better for informing all the people working at Volvo Cars.
I have not found a lot of information in English speaking newspapers, but here is a short notice in Detroit News.
On a personal level I don't think this will affect my research project or my PhD studies at all.
"Later today, Ford will confirm that all substantive commercial terms relating to the sale of Volvo Cars have been settled between Ford and Geely.
...while some work still remains to be completed before signing – including final documentation, financing and government approvals – Ford and Geely anticipate that a definitive sale agreement will be signed in the first quarter of 2010, with closing of the sale likely to occur in the second quarter, subject to appropriate regulatory approvals."
The information was sent out to us employees by e-mail in the afternoon before Christmas Eve, the biggest holiday in Sweden, so most people had already gone on vacation and probably first saw the announcement in the newspapers. Personally I think the timing should have been better for informing all the people working at Volvo Cars.
I have not found a lot of information in English speaking newspapers, but here is a short notice in Detroit News.
On a personal level I don't think this will affect my research project or my PhD studies at all.
Thursday, December 17, 2009
Organisational changes
There will be some changes to my research group. I don't know how this will affect me in detail, but in general I think it will strengthen software research in Göteborg.
In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.
In short there wil be a new software research center (at Lindholmen?) which will be a merger with software resarchers from the departments of Applied IT and of Computer Science and Engineering. Software engineering will organisationally belong to the latter department, so I will change department.
The two masters' programs Software Engineering & Management and Software Engineering & Technology will be one, which makes sense since they have a lot in common (e.g. course in software achitecture). It does not seem efficient to give two different master level programs in the same area.
Subscribe to:
Posts (Atom)