Skill har skickat ut enkäten till studenter vid samtliga svenska lärosäten som har IT-utbildningar. 1140 IT-talanger har besvarat enkäten och det är deras svar som ligger till grund för denna rapport. Av de som har svarat är 20% kvinnor och 80% män. IT-talangerna är 27 år i snitt och åldersspridningen är mellan 19 och 54 år.
Wednesday, December 22, 2010
Thursday, December 9, 2010
Improving quality with well-written requirements
I discussed with a colleague about how to improve specifications and we agreed that one of the actions that would yield quality improvements with very little investment was to educate people in our organisation on how to write good requirements.
Unfortunately such a course is not available internally at Volvo Cars (don't ask me why). But a search found some useful pages that could serve as an introduction:
Unfortunately such a course is not available internally at Volvo Cars (don't ask me why). But a search found some useful pages that could serve as an introduction:
- The Story of the Paperclip: Writing Good Functional Requirements from StartupCTO
- Writing Good Requirements – The Big Ten Rules from Tyner Blain
- Writing good requirements is a lot like writing good code by Jim Heumann, IBM
- Writing Good Requirements (A Requirements Working Group Information Report)
- SMART Requirements by Mike Mannion and Barry Keepence
Friday, December 3, 2010
Is software engineering immature?
Is software engineering an "immature" engineering discipline? I have often heard this both in presentations and in reading, for example SEMAT states on the homepage:
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?
"Software engineering is gravely hampered today by immature practices."If I draw parallels between software engineering and civil engineering (arguably the most mature engineering discipline) my spontaneous conclusion was: Yes, software engineering seems to be more like how cathedrals were built in medieval times. The construction of them were based on rules of thumb and the practical skills and experience of architects and stone masons instead of the type of engineering practices taught at universities today. Interestingly enough, one can still see the "successful" cathedrals still standing several centuries later. But it would have been impossible for the architect of Lund Cathedral to build something like the nearby Turning Torso. So the engineering in civil engineering has certainly "matured".
But where is software engineering failing? Everyone has heard of software projects running over time, over budget or have not been used as intended (or not used at all). But wait a minute! Exactly the same thing is common within civil engineering as well. There are many examples from a single contractor renovating a small house up to world known buildings such as the Sydney Opera House:
"The original cost estimate in 1957 was £3,500,000 ($7 million). The original completion date set by the government was 26 January 1963 (Australia Day).[16] Thus, the project was completed ten years late and over-budget by more than fourteen times."So in this respect software engineering is as immature as other engineering disciplines.
So what is the fuss about? I agree that there is no consensus in the software community on how to do the equivalence of structural mechanics calculations or stress tests. Are we more hampered by this lack of consensus on how to do engineering tasks than by the difficulty to run large projects, which seem to be common to other engineering disciplines?
Thursday, December 2, 2010
Available infotainment platforms
I have previously written about various platforms for infotainment systems. I also had a slide about it in my presentation on Lindholmen Software Development day, where my point was to say that it is possible to use either a commercial platform, such as Windows Embedded Automotive or an open source such as Meego. It is a business decisions which way an OEM wants to go, not a technical.
I have probaly missed some, but here is a list of infotainment platforms available today for an OEM to build an in-vehicle infotainment system on:
I have probaly missed some, but here is a list of infotainment platforms available today for an OEM to build an in-vehicle infotainment system on:
- Windows Embedded Automotive, used for example in Ford's Sync.
- QNX Aviage
- Mecel Betula Suite - Automotive Bluetooth Platform
- Meego
- GENIVI, but there is little informaiton about the techical solition on the webiste. They will most likely utilise the Meego platform.
- Harman has an infotainment platform. They recenlty acquired AHA Mobile which probably will be integrated.
- There are alot of notices on using Android for in-vehicle infotainment if one searches the web, but I have not been able to find any open source software based on Android for in-vehicle use.
- Continental's Autolinq seems to be Android-based, but is not open source in the same sense as e.g. Meego, and apps must be approved (by Continental?) to be downloaded.
- Luxoft offers LUXnet, which is also Android-based, but I cannot find any information besides a press release on their homepage.
Subscribe to:
Posts (Atom)