1 / 31

Case Example of Applying BridgePoint to OO Development Training

This case study highlights the journey of Shohei Kuki at Ricoh, where he applies BridgePoint for effective object-oriented development training. The background, tools used, challenges faced, and improvements made over the years are detailed. The focus is on enhancing software modeling skills and achieving quality software outputs.

alaughter
Download Presentation

Case Example of Applying BridgePoint to OO Development Training

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Case Example of Applying BridgePoint to OO Development Training Shohei KUKI Ricoh Company, LTD.

  2. KUKI, Shohei • Started working as an embedded system engineer at Ricoh in 1999. • First project was UI (User Interface) common component development, where he gained experience and skills on object-oriented software modeling. • Has been training new engineers to improve their abilities and skills in object-oriented software modeling, as well as creating a system of skill development in object-oriented software modeling since 2003.

  3. Contents Case Example of Applying BridgePoint to OO Development Training • Background • Introductory OO Development Training • Road to the effective training • Use BridgePoint • Lecture the concept of domain • Iteration evaluation review • Conclusion

  4. Background History Practical OO Development Training Initial skill level of trainees

  5. History 2000 2001 2002 2003 2004 1996 Model based OO development(the differential development) Rose was chosenas the major tool. Practical OO development training for newly hired employees Modeling technique was learned from SMM at the beginning. developed a part of printer engine controller by Bridge Point with a consultant. Bridge Point was one of the proposed tools. Then,proposed MDD to a production side. Trying to adopt MDD again but, stillautomatic code generation was promising. MDD was not adopted. Bridge Point was not chosen as the major tool. OMG began advocating MDA.

  6. Practical OO Development Training • Purpose • Developing software modeling engineers • Making constitution of building the quality into software at upper process • Making a set of software as outputs • Trainees • Newly hired employees who assigned as software engineers • Period • About 1 year

  7. Initial skill level of trainees • Academic background • University or master course graduates • Programming experience • Some have development experience, some have no knowledge of programming language example in 2004: • Experience of OO development • Nobody has

  8. Introductory OO Development Training Positioning and purpose Spec of Training Spec of Subject Development plan Training style and System

  9. Positioning and purpose • Positioning • Initial training of “practical OO development training” • purpose • Aware of the fun in developing embedded software • Aware of the base of OO thinking

  10. Spec of Training ※This subject is the same as the one used for UML robot contest. (requested spec is simplified) URL of UML robot contest: http://www.otij.org/umlforum2004/robocon/(Japanese Version Only)

  11. Spec of Subject • Pathfinder • Self-steering vehicle • running along the line • Proceed • Stop • Pause for 2 seconds • Detect line • Detect out-of-track • Maintenance • Correct threshold level of sensors • Check motors

  12. Development plan • Achieving functions incrementally

  13. Training style and system • Training style • Lecture + exercise(group work) • Promote understanding by many exercises • Training system • lecturer • Give lectures • advisers • Support reviews • 2 advisers for about 3 groups • trainees • Form a group with 4 to 6 members

  14. Road to the effective training

  15. We did various kaizen rate of achievement of total groups UP! UP! UP! Not good progress Little time for analysis Not best progress Kaizen2: Lecture the concept of domain Kaizen3: Iteration evaluation review Kaizen1: use BridgePoint

  16. Result in 2002 • No group could achieve additional func. 2 rate of achievement of total groups No group could achieve additional function2 despite my efforts in preparing this function!

  17. Problem in 2002 • problem • Not good progress • Many trainees deadlocked at design and implementation • Some trainees didn’t have experience of programming • Little time for analysis • cause • Mismatching between training level and trainee’s skill level • Especially, design and implementation were difficult for the trainees We used Rose as development tool, with which implementation is necessary

  18. Kaizen1 in 2003: using BridgePoint • Changed development tool • Switched from Rose to BridgePoint • With BridgePoint, design and implementation is not necessary

  19. Result in 2003 • Speed up of development rate of achievement of total groups • Had a lot of time for analysis UP! UP! But some groups could not achieve additional function2

  20. Problem in 2003 • problem • Not best progress • Couldn’t separate semantics • pathfinder and device • Model quality varied depending on each group • cause • Didn’t lecture the concept of domain • Concept of domain and bridge was not understood well • Lack of quality management • Couldn’t take hold of each group

  21. Example：mixed semantics

  22. Kaizen2 in 2004: lecture the concept of domain • Added the concept of domain lecture to program • Increased training days, lecture and exercise

  23. Example: separated semantics

  24. Problem in 2003 • problem • Not best progress • Couldn’t separate semantics • pathfinder and device • Model quality varied depending on each group • cause • Didn’t lecture the concept of domain • Concept of domain and bridge was not understood well • Lack of quality management • Couldn’t take hold of each group

  25. Kaizen3 in 2004: Iteration evaluation review • Iteration evaluation review • Review for outputs in each iteration • We can take hold of each group’s status and quality of outputs. • Late group can increase the speed by doing some review intensively

  26. Result in 2004 • All groups achieved all functions! • Could shift the semantics • Developed the models in excess of a certain level rate of achievement of total groups

  27. Comments from trainee • Satisfaction level No data

  28. We accomplished the purpose • Aware of the fun in developing embedded software • All groups achieved all functions • Aware of the base of OO thinking • Focused on analysis • Could shift the semantics • Developed the models in excess of a certain level

  29. Conclusion

  30. What we learned about education • Take care of trainee’s skill level ! • Newly hired employees may not have implementation skill • Focus OO thinking ! • Take a lot of time to analyze • Beginners cannot separate semantics • Make trainees be fun to develop software ! • Rapid development BridgePoint is an excellent tool for education and future development

  31. Thank you for listening!Case Example of Applying BridgePoint to OO Development Training Shohei KUKI Ricoh Company, LTD.

More Related