[4] Julie Yu-Chih Liu, Victor J. Chen, Chien-Lung Chan, Ting Lie, (2008) The Impact of Software Process Standardization on Software Flexibility and Project Management Performance: Control Theory Perspective, Information & Software Technology, Vol. 50, No. 9-10, pp. 889-896, 2008 (SCI,EI, IF=0.726) Emmerich, W. (1998) Software process: standards, assessments and improvements. In: Derniame, J.C. and Kaba, B.A. and Wastell, D., (eds.) Software Process: Principles, Methodology, Technology. Lecture Notes in Computer Science (Vol. 1500). Springer Verlag, pp. 15-25. http://eprints.ucl.ac.uk/937/1/10.6_chapter2v2.pdf many process decision advocated by wolfagan are above the level that we will conisder. e.g. set goals, determine measure methods that collect data relative to this goals, apply a perosnal software process et. the kind of changes we are exploring are more the dramtic fix for an ailing project http://www.flickr.com/photos/timmenzies/1051509149/in/set-72157601236129433/ Editoiral IEEE SOftware jan/feb 2007, Guest Editors' Introduction: Why are Small Software Organizations Different? I. Richardson, University of Limerick Christiane Gresse von Wangenheim, Universidade do Vale do Itajaí Why Are Small Software Organizations Different? Ita Richardson, University of Limerick Christiane Gresse von Wangenheim, Universidade do Vale do Itajaí January/February 2007 IEEE SOFTWARE . In the US, Brazil, Canada, China, India, Finland, Ireland, Hungary, and many other countries, small companies (50 people or less) represent up to 85 percent of all software organizations.1 [SE Challenges in Small Software Companies, Point/Counterpoint], Jan./Feb., pp. 54¿57. ------------------- more options that commonly recongized. for example, in Using the Software CMM¿ With Good Judgment MARK C. PAULK Published in ASQ Software Quality Professional, Vol. 1, No. 3, June 1999, pp. 19-29. stresses that CMM is not one monotlithic entity. Rather, a closer look shows that CMM is a large tree of key practices and developers : Maturity levels (5 levels) ¿ Key process areas (18 KPAs) ¿ Goals (52 goals) ¿ Key practices (316 key practices) ¿ Subpractices and examples (> 316 examples) He offers some notes on when parts of the CMM can be filtered out: In general, key process areas and goals are always relevant to any environment, with the exception of Software Subcontract Management, which may be ¿not applicable¿ if there is no subcontracting. In contrast, there are no circumstances under which Peer Reviews could be reasonably tailored out for a Level 3 organization. Deciding what is ¿not applicable¿ or an ¿alternate implementation¿ is a matter of competent professional judgment, implying a need for trained, experienced assessors and process definers, even for small organizations. He even offers a minimal set of practices for small organizations (50 developers or less) to achieve CMM level 3 and prepare them selves for the push to level 5: ß document the requirements ß define a work breakdown structure and plan the work ß track significant accomplishments (no more than 2 or 3 per week) ß build the SQA function into the process (as a ¿buddy system¿ or part of peer reviews, with an escalation mechanism to resolve conflicts) ß determine how changes to work products will be identified and approved ß establish a configuration management system ß assign responsibility for defining and improving specific processes ß concisely document both management and engineering processes and standardize them ß document commitments and systematically resolve conflicts within the project ß install a peer review process, with a preference for inspections while a useful list, not every organization has access to process gurus as skilled and as experienced as MARK C. PAULK The challenges in interpreting the CMM appropriately for different environments differ in degree rather than in kind. The bottom line is that software process improvement should be done to help the business ¿ not for its own sake. The best advice comes from Sanjiv Ahuja, President of Bellcore: ¿Let common sense prevail!¿ The CMM is a proven tool to support process appraisal and software process improvement in a wide range of environments3, but it must be used with professional judgment and common sense to be truly effective. problem is that common sense is not common Given the different char- acteristics of small and large organizations, can they apply the same software engineering techniques? we generalize the question to given two business units with characteristics A,B,C (which include business unit size, and up to 25 other features), when should they apply different or same techniquecs larry lumsden says "yes" argueing that predictability and adaptability are the key determiniers of approapriate softare process, not the size of the development team, iEEE softare han/feb 2007, p54-57 wolfgans strigel argues no. he agrees with lumden that there are similar high level business goals that all oragnizations share (quality service to a custormer) but at a lower level, there are a vast range of software engineering techniques that may or may not be better for smaller or larger organizations. in the debate, lumsden tries to be a diplomat, arguing that organizational units have much to learn from each other. e,g. small organizations confounded by chaos and lack of structure might elect to impose (some) big organization project management methods. strigl willhave none of that, argumeing that different kinds of company select for the kinds of application they work for (very small agile organizations usually dont build mission crital softawre for aircraft control) and large organizations dont build one-time use software. within this debate, we can see both authors arguing for the appropriate tuning of software process to the oragnization and taks at hand. how? =================== above the process not all at the strategic level most at the tactical level raffo early in the p process and strategy raffo: new tools at nasa. - structure of the process provides some level of predictability but local variance as well process can be standard acual injections many eb decided by local params can supersede the global structure. e.g. where to insert a rquiemtns anaysis tool- where is the sweat spot. e.g. the defect removal may be useful; - locaol aprams drive whether or not a process change is effective rather than a global structure two levels of randlimnzation: - one level what do we do (how we change a process.. behavouroal change). - the other level is the performance when this is implemented. hard to approach this second layer for many reasons; e.g. sometimes companies dont let us in local effects can and often worst expected best case 7 out of 100 The impact of software process standardization on software flexibility and project management performance: Control theory perspective