![]() |
Telelogic Rhapsody (steve huntington) | ![]() |
Topic Title: Open Space Discussion - Introducing Process change to the organization Topic Summary: Created On: 13-Jun-2006 14:58 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Discussion Topic: Introducing Process change to the organization
Leader Name: Simon Morrish Attendees: Stefan Moock Christoph Schmidt Matthew Thomas Michael Braun Thomas Nyffenegger Matthias ReiBmann Andreas Lyncker Christian Martens Tim Shaw Session Notes: Who do we need to sell to? Developers, Managers (lack of understanding) Managers Cost If you don't understand software or modelling, you don't see the need to obtain the tools. Suggest using the analogy of CAD vs Software modelling. Many organisations would never consider electrical or mechanical design without CAD and simulation; it's anomalous to have a software team using only an IDE and compiler! Benchmarking performance Difficult to compare performance between modelled and non-modelled developments; measurements may not exist for the non-modelled case, and in any case it's difficult to ensure a true comparison. Toolset consistency across an organisation Different depts may have their own reasons for choosing certain tools. It's easy to end up with (for instance) Requirements Management, CASE and Testing solutions which do not integrate. Overall coordination is required. Pilot project Running a pilot project is a very powerful way to convince management of benefits. Perhaps rewrite one area of an existing product. Quick turnaround is essential, as is measurement. You need to be evangelistic! Link with CMMI Highlighting the synergy between a modelling process and CMMI is a useful way to influence. Cross-discipline communication A good argument is the benefit of other engineering disciplines being able to view and review the software design. Persuade other disciplines to adopt UML if possible. "Are you going to draw diagrams? Then let's all use a common notation!" Developers Moving a team from hand-coding C to modelling C++ Many embedded software engineers have experience with C functional programming. Is it better to move developers from C to C++ then UML, or straight to UML/C++? There was a view was that it is better switch both at once, but there was some disagreement on this topic. Some of the argument for making the leap direct to UML were: - It's not effective to switch to C++ without modelling and code generation, because it doesn't help to improve documentation, or keep the model and code aligned - Developing in C++ is not the same is developing object-oriented; developers can write C code using C++! - Addressing UML first promotes an object-oriented approach/mindset, and helps with subsequent transition to C++. There was a view that it takes 3 years to use C++ effectively, but perhaps a year to become competent with UML; therefore it make sense to address UML training first. If possible, using Java as the implementation language (if only initially) might help to avoid some of the poor practices that users may be prone to with C++. "Working around" the tool Users that think in a code-centric sometimes solve the problem in C++, then work out how to make Rhapsody generate the code. This is the "wrong way around". (Interestingly, successive releases of Rhapsody are making it easier to work in the "wrong" way.) Need to mentor and monitor; model reviews are a useful tool. Beware that developers may be using Rhapsody against their will They may hand-write code and reverse-engineer it into Rhapsody! And analysis sequence diagrams may be done after the code is written!! Don't ignore the need for training and mentoring. Preparing, training and mentoring Sending users on Rhapsody and C++ courses is not enough. They must also (first?) have training in object-oriented design and analysis. Also consider what attitudes developers carry into the training and mentoring sessions, and whether they are "receptive to change". Ask "Do you think that software is increasingly complex?" "Do you think there are problems with our current development methods?" ...etc, etc... "Do you agree we need to change?" It can be easier to "catch them young." Beware that developers may consider the change to be a threat to their jobs; perhaps they fear being unable to cope. Structuring the team What is your team structure? Some C/C++ developers may be more effective, and happier, to work only at the design/implementation stage of the project. Not everyone is an analyst; could tailor roles to the team's strengths. Demonstrating capability Demonstrating the tool in action is a very powerful way to sway developers. Take care though, in one example the demonstration was successful but left an impression that Rhapsody was "for Statecharts", which took some effort to correct. Ensure you provide a rounded picture of the tool's capabilities. For instance, the ability to easily rename a class or type seems a "trivial" feature of Rhapsody, but can be a real eye-opener to hand-coders. Dealing with user "niggles" Users may be put off by small problems with the toolset. (eg. A poll of around 50 users uncovered 114 issues.) Individually they may be trivial (and I-Logix may assign them a low priority for resolution) but they can accumulate to form a significant barrier to adoption. One way to address this is to group smaller issues and negotiate with I-Logix to treat the group as a single large issue! Feel free to discuss further... ------------------------- Simon Morrish simon.morrish@eu.panasonic.com http://panasonic.co.uk Panasonic ideas for life |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.