M-applcatons Development usng Hgh Performance Project Management Technques PAUL POCATILU, MARIUS VETRICI Economc Informatcs Department Academy of Economc Studes 6 Pata Romana, Sector, Bucharest ROMANIA ppaul@ase.ro, marusvetrc@softmentor.ro Abstract: Ths paper analyses the specfcs of m-applcatons development projects. Even though m-applcaton development projects have ther partcular features and need customzed approaches, stll we fnd that legacy and proven best practces project management technques can be successfully employed. We present two proven software project management technques that were successfully adapted to the development of m-applcatons. One s the estmaton of m-applcaton project duraton usng top-down and bottom-up approaches. The other s the use of a set of performance metrcs for project qualty assessment. Key-Words: Moble applcatons, Moble devces, Project management, Performance metrcs Introducton The total number of moble phone subscrbers n the world was estmated at 2.4 bllon n 2005 [], 3.3 bllon n 2007 [2] and the fgure s expected to ncrease to 90% by the year 200. The numbers are even more mpressve f we look at the moble phone penetraton rates, the hghest from Asa beng n Hong Kong wth.4 moble phones per person [3] and n Europe, Luxembourg, Lthuana and Italy httng as hgh as 50 moble phone subscrptons per 00 people [4]. Gven the crcumstances, m-applcaton software development s and wll be an emergng feld of the software ndustry. An m-applcaton s a specal type of software applcaton partcularly desgned to be used on moble processng unts wth lmted processng power, storage memory and nput capabltes such as moble phones, smartphones, PDAs, navgaton assstants, moble gudes, etc. Even though m-applcaton development s a relatvely new doman, stll legacy project management technques can be successfully appled for delverng hgh performance n the new feld. Ths paper analyses the specfcs of the m-applcatons development projects and presents two proven software project management technques that can be successfully adapted to the development of m-applcatons. Frst technque, the estmaton of project duraton, s of utmost mportance for all project stakeholders. More specfcally, the duraton of the project s needed before the project has started. Ths s because other mportant estmatons are grounded on the former metrc. For example no nvestor wll go wth a gven project unless the delvery date s clearly agreed upon and a commtment has been entered nto. Further to ths, we go nto great detal about the mportance of project duraton estmaton, the dffcultes of estmatng duraton and the exstng duraton estmaton technques. The second project management technque reles on the use of specfc m-applcatons development performance metrcs. The performance metrcs are based on customer satsfacton, the degree of objectve completon and the cost of the resources nvolved. 2 M-applcatons Development Projects M-applcaton development s smlar to the development of personal computer applcatons, but there are also dfferences that nfluence the way the project s managed. Dependng on the applcaton type, m-applcatons development projects nclude not only the moble devce software, but also the other components of the system (applcaton server, database, content management etc.). We wll focus mostly on the development of the moble applcatons. From the data processng pont of vew, m- applcatons can be dvded nto standalone applcatons and dstrbuted applcatons. Standalone moble applcatons are desgned to perform specfc tasks wthout the need of a network connecton. Mostly moble applcatons made for PDAs are such examples of stand-alone applcatons. Every operatng system (Wndows Moble, Symban) exposes specfc APIs wth varyng degrees of complexty and archtectures whch are more or less well documented. In order to ncrease the development productvty, hgher level classes lbrares were developed on top of system s APIs. Usually, every ISSN: 790-509 23 ISBN: 978-960-474-063-5
lbrary comes wth a specfc run-tme envronment. Dstrbuted m-applcatons nstead need a network connecton n order to operate. Ths type of applcatons may rely upon a permanent or a temporary connecton. WAP (Wreless Access Protocol) based applcatons for moble phones that connect to a server va Internet are an example of dstrbuted applcatons. The most used dstrbuted applcatons are Web-based. Fgure depcts the archtecture of such an applcaton. Moble phone Bnary WML xhtml Moble phone Wreless Gateway HTTP/TCP/IP Web server Applcaton server Database Fg.. Moble Web applcatons archtecture The request from the WAP enabled phone s sent to the WAP gateway that makes the converson from the WAP stack (for WAP.0) or from the optmzed wreless or optmzed HTTP/TCP/IP (WAP 2.0) to the HTTP/TCP/IP stack and encodes the network packets that wll further be sent to the Web server as an HTTP request. The request s processed by the Web server, and then a response s send back to the moble phone browser through the WAP gateway that decodes the packets. The type of applcaton has an mportant nfluence on the sze and the complexty of the m-applcaton development project: Database access Table. M-applcaton types comparson Applcaton Type/ Features User Interface Memory Processng power Network Lmted Hgh Medum access /Hgh Standalone Lmted Medum Medum /Hgh /Hgh Web-based Web- Medum Low based /Medum Lmted Hgh Medum /Hgh Complex ty Hgh Medum /Hgh Low Hgh As t can be seen from the table [5], moble applcatons that requre network access and those that use databases usually have a hgher complexty. Ths s rather obvous because ths type of m-applcatons wll have greater complexty, more classes and chances are that the demand for specfc knowledge wll be hgher. The sze, complexty and productvty are nfluenced by the applcaton s operatng system. Usng Java ME technology there s a hgh degree of portablty between operatng systems, but there are devce specfc nfluences. The use of natve APIs to wrte applcatons requres more effort, and the sze of applcaton (expressed as KLOC) s hgher than usng classes lbrares. Most of the development process s made usng devce software emulators that run on personal computers. Stll there are dfferences between real-lfe devces and emulators. That s why there s an addtonal effort n testng the applcaton even after t s consdered done on the emulator. 3 Tme/Duraton Management Models 3. Defntons A project s a temporary endeavor undertaken to create a unque product, servce, or result [6]. By adaptng the defnton from [7] we state that an m-applcaton software development project s a temporary endeavour undertaken to create a unque m-applcaton. Hgh qualty m-applcaton software development projects delver the requred product wthn scope, on tme and wthn budget. It s the project manager s duty to sklfully balance the competng demands for project qualty, project duraton and cost of resources n order to be able to delver the software as planned. Lke any other type of project, software development projects need: clearly defned requrements and scope establshed achevable objectves controlled resource allocaton good effort and schedule management The expectatons of stakeholders are focused on the software to be delvered, on the budged consumpton and on the project duraton. The duraton of a project s the tme elapsed between the project start and the project delvery date, when the software s delvered to the customer. The project duraton s an essental ndcator that should be well estmated, agreed upon wth the stakeholders and thoroughly montored, up to the project completon. Project duraton and sze reflect the manager s own understandng of the requrements. It s not possble to correctly sze and estmate duraton for a project that s not completely understood. Further, project duraton provdes an mportant check for scope creep throughout the project. Falng to pay attenton to project duraton one could agree to add new functonalty wthout approprately updatng project sze and effort needed. 3.2 The dffcultes of estmatng software project duraton There are several reasons that make m-applcaton project duraton estmaton a dffcult problem. Frst of ISSN: 790-509 24 ISBN: 978-960-474-063-5
all, the very essence of software buldng process makes t dffcult to measure. It s a tough endeavour to try to measure how much software s there n a software project because the software s nvsble and unvsualzable [8]. Ths especally dffcult f we try to make such forecasts before a detaled software desgn. The software s pure thought-stuff, nfntely malleable [8]. Unlke cars and buldngs, the software s constantly subject to pressures for change because the costs of modfcatons are dffcult to understand. Many of the classc problems of developng software products derve from ths essental complexty and ts nonlnear ncreases wth sze. From the complexty comes the dffculty of communcaton among team members, whch leads to product flaws, cost overruns and schedule delays. From the complexty comes the dffculty of enumeratng, much less understandng, all the possble states of the program, and from that comes the unrelablty [9]. 3.3 Duraton estmaton technques The grand majorty of technques for m-applcaton project development duraton estmaton can be found ether n bottom-up or top-down category. The dfference between the two comes from the approach used to estmate project duraton. The technques n the frst category start at the task-level vew of the project and aggregate the work to be performed on hgher levels, up to the project as a whole. The top-down way offers duraton predctons based on propertes of the workproduct, the project team, and the project envronment, fgure 2. Fg. 2. Bottom-up vs. top-down technques 3.3. Bottom-up technques Ths type of duraton estmaton technques start wth developng a work breakdown structure of the work and then contnue wth task dentfcaton and task duraton estmaton. Every task should be smple enough so as one could easly answer the queston regardng the task duraton three parameter estmates: best duraton estmaton most lkely worst duraton Also for every task one should know: what's nvolved n gettng started how wll resources be allocated what exactly are the condtons to be met n order the project to be consdered done. The next step s dentfyng the predecessor-successor relatonshps and the crtcal path through the actvty graph. In order to forecast the completon tme, three dfferent approaches can be used. a) The smple approach conssts n addng-up the most lkely estmates for each task on the crtcal path. It s not the best method, but t s the smplest one. b) The second approach means to calculate the expected task duraton ED as a weghted mean of the three gven estmatons usng PERT equaton: BD + 4 * MD + WD ED = 6 () BD best duraton estmaton; ths s the most optmstc expectaton, the best case scenaro that assumes no nfluence s gong to negatvely mpact the project duraton; MD most lkely; the duraton of actvty gven the resources, ther productvty and realstc expectatons of avalablty; WD worst duraton; the duraton of actvty based on a worst case scenaro of what s descrbed n most lkely estmate. c) The thrd approach reles on a Monte Carlo smulaton over the task estmaton data. The result wll be a probablstc dstrbuton of the project duraton [0] 3.3.2 Top-down technques Top-down technques use nstead some hgh level attrbutes of the project (related to ts complexty, functonalty or sze) and of the organzaton capablty to delver the project. Top-down estmaton begns wth an assessment of the sze of the work-product beng planned. Ths dea comes from the constructon projects, where the projectmanager wouldn't magne commttng to a deadlne wthout establshng and trackng some good sze estmates, lke the number of square feet, number of wndows, doors, etc. to be desgned and bult. Up to date there are four software project szng legacy methods. See table 2 []: Table 2. Project szng technques pros and cons Szng Method Pros Cons Lnes of Codes Easy to measure Cannot be done ISSN: 790-509 25 ISBN: 978-960-474-063-5
Functon Ponts Use-Case Countng Web Applcaton Proxes n many development envronments (after there s code). Can be measured durng requrements stage. Can be measured durng requrements stage. Easy to count startng wth early web applcaton prototypes. before there are lnes of code. Requres some tranng, calbraton and perhaps talorng to specfc applcaton domans. New method. Small experence base at ths tme. New method. Requres development of countng rules and calbraton for specfc applcaton types. The next step n top-down estmaton s to use a project duraton estmaton model. Lawrence Putnam proposed a wdely used model for project duraton estmaton usng data on sze, effort, and hstorc duraton for thousands of other software projects. The model bulds up the organzaton's delvery capablty ndex usng PP - Productvty Parameter and lnks t to sze, effort and duraton dynamcs. 3.4 Choosng a project duraton estmaton technque Both top-down and bottom-up approaches proved to be good at estmatng project duraton. A good software project manager wll probably use both methods, plus hs own estmaton, based on pror experence. Bottom-up estmates use work-breakdown structure, crtcal path method and task estmates; they provde crucal detals regardng the duraton of smaller project parts and they roll up to a global duraton and effort estmaton. Topdown estmates rely on hstory of other real projects. One's cumulatve experence n smlar projects can provde estmates that deserve some consderaton n balance wth the bottom-up and top-down vews. 4 M-applcatons Development Performance Metrcs Poor project management s the number one factor of the IT projects falure, ncludng m-applcatons development. Upon completon, a project can meet all the objectves and stll t can be a fnancally unproftable project. Hgh qualty project delverables cannot be obtaned wthout hgh qualty development processes, but a qualty process does not guarantee qualty products. The the process s certfed through qualty qualty of standards. Also good traned personnel do not guarantee the qualty of delverables. In order to obtan qualty results, the organzaton has to have traned and educated personnel, and standardzed project management and technologcal processes. PS PP = E / 3 4 / 3 ( ) * D β (2) PP Putnam s productvty ndex. Ths tem shows the organzaton s project delvery capablty; PS project sze, counted usng one of the above szng methods; E effort (n man-years). The work needed n order to fulfll the project; D the project duraton (years). Proft P 4 P P P 2 3 Rsk Low Hgh Fg. 3. Projects chart by rsk and proft The followng thngs are notable n regard to ths model: a) an organzaton wth hgher PP can delver more sze wth less effort and n shorter duraton than one wth a lower PP; b) the /3 and 4/3 exponents n equaton 2 express the non-lnearty n effort-duraton relatonshp. Equlbrum has to be obtaned between: resource allocaton for projects, rsk and proft, long term and short term projects, research and development projects, nternal or external projects. In fgure 3 s depcted a stuaton from an organzaton wth some projects showng the assocated rsks, value and proft. In [2] ISSN: 790-509 26 ISBN: 978-960-474-063-5
several ndcators were proposed for IT project performance measurement. These ndcators can be appled to measure the performance of m-applcatons development projects. The degree of objectves achevement s calculated as: OA GA = (3) TO OA the number of acheved objectves TO the total number of establshed objectves If the ndcator value s greater than one, s consdered that the project acheved more objectves than were planed ntally. The rato between the acheved delverables and the planned delverables can be also calculated for each project phase, where delverables from one phase are nputs for the next phase. The degree of satsfacton can be computed as: p DSR DS = (4) TR DSR the degree of satsfacton for the requrement TR total number of requrements p the number of requrements The degree of satsfacton for a customer requrements s a value from 0 (no satsfacton) to (fully satsfed) or usng a smlar scale. The degree of clent satsfacton wth an m-applcaton can vary wth the moble devces the applcaton s run on. Work productvty based on nputs s gven by: n O W = m (5) Ij j= O the output ; (delverables, results) Ij the nput j (work, resources per tme unt) n the number of outputs m the number of nputs Work productvty based on tme: n O W = 2 T (6) T perod of tme The cost of resources takes nto account the category of resources and the cost per unt for eac h category: C = w NR d (7) NR number of resource from the category p prce per unt for the resource category d unts of usage for the resource category The total cost of a project can be defned as: k C T = c (8) where k the number of project phases c, - the cost of all resources from the phase The number of reworks because of no concordances between the specfcatons and the results measure the team performance n dong ther work. For the executves, t s mportant to know the value of all runnng projects. A project portfolo value at a gven moment of tme s computed as: PPV s ( t) = k s PPV s (t) project portfolo s value at the gven moment of tme t s VP the value of project from the portfolo s k s the number of projects n the portfolo s. Other ndcators are developed to measure the performances of IT projects, havng n mnd the m- applcatons characterstcs. In order to use them, data have to be collected from varous projects and they have to be valdated [3]. p s VP ( t) (9) 5 Conclusons and Future Work M-applcaton software development s an emergng feld of the software ndustry. Despte beng a relatvely new feld, best practces project management technques can be successfully used to delver hgh performance. The development of moble applcatons nvolves some dffcultes engendered by reduced capabltes of moble devces. Due to moble devces lmtatons, n partcular lmted nternal memory and reduced processng power, the source code of moble applcatons needs addtonal optmzaton whch wll result n less testablty. ISSN: 790-509 27 ISBN: 978-960-474-063-5
M-applcaton project development mples the usage of specfc development envronments lke emulators that are not 00% compatble wth the hardware devce. Ths dfference requres a slghtly dfferent approach both for development and testng. M-applcaton project duraton can be successfully estmated usng top-down and bottom-up approaches that have successfully been used over the last decades. In order for the m-applcaton to be evaluated as successful, a quanttatve approach can be employed by the use of a set of performance metrcs. Further research wll be focusng on the use of prepackaged m-components as a means of speedng up the development process. Also, m-applcaton project development success wll be measured by assessng the qualty of the m-applcaton user nterface. [2] Paul Pocatlu, IT Projects Performance Indcators, Economy Informatcs, EISSN 842-8088, vol. VII, No -4, 2007, pp. 3-7 [3] Ivan Ion, Andre Sandu, 22nd IPMA World Congress Proceedngs - "Project Management to Run", Roma, Italy, 9- November 2008, CD format, Projects Herarchy Based on Duraton and Complexty, References: [] ***, Total moble subscrbers top.8 bllon, Informa Telecoms & Meda Research Report http://www.mobletracker.net/archves/2005/05/8/m oble-subcrbers-worldwde [2] ***, Global cellphone penetraton reaches 50 pct, Reuters, http://www.reuters.com/artcle/marketsnews/dinl2 972095200729?rpc=44m [3] ***, Key Telecommuncatons Statstcs, Offce of the Telecommuncatons Authorty n Hong Kong [4] ***, Europeans hang up on fxed lnes, BBC News, http://news.bbc.co.uk/2/h/technology/76599.stm [5] Paul Pocatlu, Moble Applcatons Qualty Metrcs, Proceedngs of Internatonal Conference on Busness Informaton Systems, InfoBUSINESS, Alexandru Ioan Cuza Unversty, 26-27 October 2006, ISBN 978-973-703-207-2, pp. 4-2 [6] *** - A Gude to Project Management Body of Knowledge Thrd Edton, Project Management Insttute, 2003 [7] Vetrc Marus, Reducng Software Projects Duraton usng C#, Informatca Economca Journal, Vol. VII/No., 2007, pg. 9-95. [8] Frederck P. Brooks, Jr., Essence and Accdents of Software Engneerng, Computer Magazne, Vol. 20, No. 4, 987, pg. 0-9. [9] Steve McConnel, Rapd Development, Mcrosoft Press, 996 [0] Vetrc Marus, Project schedule usng Monte Carlo smulaton wth dscreet probablty dstrbuton, Proceedngs of the 4 th Internatonal Conference for Appled Statstcs, Bucharest, Romana, 2008 [] Davd L. Hallowell, Software Project Management Meets Sx Sgma, http://software.sxsgma.com ISSN: 790-509 28 ISBN: 978-960-474-063-5