experience in software development · 2013. 11. 29. · applications platform (moap)*3, operator...

1
NTT DOCOMO Technical Journal Vol. 15 No. 1 1 Experience in Software Development Experience in Software Development Since joining NTT DOCOMO, I have been constantly engaged in the development of systems and software. I first worked on the development of mobile radio control systems. I then tackled the development of customer information management systems (e.g. ALl Around DOCOMO INformation systems (ALADIN) *1 ) and network operation systems. All of these systems were composed of massive UNIX servers and databases. I then moved to the development of terminals after having worked on servers for terminal software updates (Air DownLoad (ADL): current version of Firmware On-The-Air (FOTA) *2 ) and i-mode My Box servers. At the Communication Device Development Department, I have undertaken the development of communication protocol stacks, the Mobile-phone Oriented Applications Platform (MOAP) *3 , OPerator Pack (OPP) *4 and applications for launching smartphone services. Currently, I oversee terminal-related technologies in their entirety. Through these various development projects, I have experienced many successes and failures and have learned key points of management. Among other things, I have keenly learned many valuable lessons from failures. The lessons of risk management can probably only be gained from experiences of failure. Actually, an effort we tackled two years ago was the development of an application service for smartphones. This was quite an undisciplined project due to the amount of development required against a demanding deadline. However, thanks to the project manager, who had many years of experience in risk management, we were able to somehow maintain the schedule for completing the project. Therefore, I want to say to young engineers at the R&D Center: “I want you to challenge yourself with difficult goals without fearing defeat. It is difficult to pick yourself up after a failure, whether small or large. But I want you to learn from your experience precisely the lesson that will bear fruit next time.” In the projects where I experienced rebuilding from failure, I received help from the participation of “rebuilding pros” from the development vendor side, and we worked together on rebuilding the projects. By working with these pros, I was able to learn important points concerning project risk management. For example, comments from onsite customers are important for sales and post-sale services. Their voices are also important for development. Communication with managers on the development vendor side is essential for advancing efficient development. The bigger the project, the more it must proceed according to plan; therefore we must work hard to do everything to maintain its schedule. Whether or not we should keep expending energy to meet a deadline up to the last minute is an important decision that depends on the input of the leader class onsite. As we enter an era of open OS, short development periods and efficient development costs are being demanded. Developing a product to the point of satisfying everything, including quality, is difficult. However, I believe that a structural transformation in development is mandatory. We are trying out “agile development” as one of the methods to achieve this transformation. While agile development is still at the stage of trial and error, it is being assumed that communication within the project is a key to its success. This is a reason why engineers here have also thought that agile development is difficult to apply to large projects. Also, we are trying the trump card of making “offshore development” and “near-shore development” more efficient and reducing their development costs. The risk of these approaches is that it is hard to directly listen to onsite development vendors. We must overcome the problem of distance and language barriers. We must spare no expenses in visiting development vendors frequently. We are seeking to further reduce development time and make development costs more efficient in FY2013. We are not shrinking our goals, but rather, we are seeking to create new solutions that are not bound by conventional wisdom or experience, so that NTT DOCOMO’s value can be maximally demonstrated. Managing Director of Communication Device Development Department Kazuaki Terunuma *1 ALADIN: A customer management system. *2 FOTA: System for distributing and updating firmware, e.g. for smartphones, through radio communication. *3 MOAP: Middleware platform for creating operator services for feature phones. *4 OPP: Software platform for feature phones that converts operator services to packets.

Upload: others

Post on 01-Oct-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Experience in Software Development · 2013. 11. 29. · Applications Platform (MOAP)*3, OPerator Pack (OPP)*4 and applications for launching smartphone services. Currently, I oversee

NTT DOCOMO Technical Journal Vol. 15 No. 1 1

Experience in Software DevelopmentExperience in Software Development

Since joining NTT DOCOMO, I have been constantly engaged inthe development of systems and software. I first worked on thedevelopment of mobile radio control systems. I then tackled thedevelopment of customer information management systems (e.g. ALlAround DOCOMO INformation systems (ALADIN)

*1) and network

operation systems. All of these systems were composed of massiveUNIX servers and databases. I then moved to the development ofterminals after having worked on servers for terminal software updates(Air DownLoad (ADL): current version of Firmware On-The-Air(FOTA)

*2) and i-mode My Box servers. At the Communication Device

Development Department, I have undertaken the development ofcommunication protocol stacks, the Mobile-phone OrientedApplications Platform (MOAP)

*3, OPerator Pack (OPP)

*4and

applications for launching smartphone services. Currently, I overseeterminal-related technologies in their entirety.

Through these various development projects, I have experiencedmany successes and failures and have learned key points ofmanagement. Among other things, I have keenly learned many valuablelessons from failures. The lessons of risk management can probably onlybe gained from experiences of failure. Actually, an effort we tackled twoyears ago was the development of an application service forsmartphones. This was quite an undisciplined project due to the amountof development required against a demanding deadline. However,thanks to the project manager, who had many years of experience in riskmanagement, we were able to somehow maintain the schedule for

completing the project. Therefore, I want to say to young engineers at the R&D Center: “I

want you to challenge yourself with difficult goals without fearingdefeat. It is difficult to pick yourself up after a failure, whether small orlarge. But I want you to learn from your experience precisely the lessonthat will bear fruit next time.”

In the projects where I experienced rebuilding from failure, Ireceived help from the participation of “rebuilding pros” from thedevelopment vendor side, and we worked together on rebuilding theprojects. By working with these pros, I was able to learn importantpoints concerning project risk management.

For example, comments from onsite customers are important forsales and post-sale services. Their voices are also important fordevelopment. Communication with managers on the developmentvendor side is essential for advancing efficient development. The biggerthe project, the more it must proceed according to plan; therefore wemust work hard to do everything to maintain its schedule. Whether ornot we should keep expending energy to meet a deadline up to the lastminute is an important decision that depends on the input of the leaderclass onsite.

As we enter an era of open OS, short development periods andefficient development costs are being demanded. Developing a productto the point of satisfying everything, including quality, is difficult.However, I believe that a structural transformation in development ismandatory. We are trying out “agile development” as one of themethods to achieve this transformation. While agile development is stillat the stage of trial and error, it is being assumed that communicationwithin the project is a key to its success. This is a reason why engineershere have also thought that agile development is difficult to apply tolarge projects.

Also, we are trying the trump card of making “offshoredevelopment” and “near-shore development” more efficient andreducing their development costs. The risk of these approaches is that itis hard to directly listen to onsite development vendors. We mustovercome the problem of distance and language barriers. We must spareno expenses in visiting development vendors frequently.

We are seeking to further reduce development time and makedevelopment costs more efficient in FY2013. We are not shrinking ourgoals, but rather, we are seeking to create new solutions that are notbound by conventional wisdom or experience, so that NTT DOCOMO’svalue can be maximally demonstrated.

Managing Director of Communication Device DevelopmentDepartment

Kazuaki Terunuma

*1 ALADIN: A customer management system.*2 FOTA: System for distributing and updating firmware, e.g. for smartphones,

through radio communication.*3 MOAP: Middleware platform for creating operator services for feature phones.*4 OPP: Software platform for feature phones that converts operator services to

packets.

NTT

DO

CO

MO

Tec

hnic

al J

ourn

al