Forum for Academic Software Engineering Volume 4, Number 21, Fri Dec 2 15:50:20 CST 1994 Topics: David Eichmann, FASE Archivist Salary Survey CFP: JSS Special Issue on SE for Distributed Computing CFP: Conference on Concurrent Engineering SPI Successes and Barriers - from the Pittsburgh SPIN A------------------------------------------------------- From: kpierce@d.umn.edu Subject: David Eichmann, FASE Archivist FASE is now available by anonymous ftp and via www (see footer for details). Thanks go to David Eichmann at the University of Houston-Clear Lake for setting this up. He's been added to the footer as official FASE Archivist. A------------------------------------------------------- From: "Candice Case, Harrisburg Area Commu" Subject: Salary Survey I am trying to locate a survey of salary data for Information Technology Personnel. Can anyone help me? Please send your replies to: case@hslc.org. Thank you. Candice Case Harrisburg Area Community College A------------------------------------------------------- From: srimani@CS.ColoState.EDU (Pradip Srimani) Subject: CFP:JSS Special Issue on SE for Distributed Computing NOTE: For postscript versions, use the URL http://www.cs.colostate.edu/~srimani Call for Papers Special Issue of The Journal of Systems and Software Tentative Publication Date: June 1996 Software Engineering for Distributed Computing Distributed computing systems or multiprocessors consisting of hundreds of processors are now commercially available. These parallel computing systems provide orders of magnitude more raw computing power than tra- ditional supercomputers at lower cost. Many opportunities for new kinds of applications will be possible if these machines can be fully exploited previously infeasible systems can now be developed. The difficult technical challenge is programming these machines. The development of correct, reliable, maintainable and verifiable distributed software is one of the most significant problems faced by distributed systems developers. While the properties of deterministic sequential software are relatively well understood, software engineering for advanced parallel and distributed computers is still in its infancy. Very few structured techniques, principles and tools are available for parallel programming. Practitioners as well as researchers need to be well informed about requirement analysis techniques, design, implementation and testing issues in distributed software development. In addition to papers that describe different technical and managerial processes for planning, specification, modeling, design, validation, and testing we are looking for material on new tools, new approaches to designing development environments and new algorithms and techniques that are needed to accommodate the new complexities introduced by the asynchronous operations of distributed systems. The special issue will focus on the following topics (not necessarily an exhaustive list) in the context of distributed systems: o Requirement Specification Models for Concurrent Software. o Software Design Techniques. o Petri Nets and Temporal Logic. o Task Partitioning and Task Scheduling. o Distributed Programming Languages. o Testing and Debugging. o Prototyping. o Management of Distributed Software Development. o Measurement (Metrics) for Distributed Software Products and Processes o Object Oriented Methods Applied to Distributed Systems. o Validation and Verification Techniques. o Experience Reports: Success and Failure Stories. Papers should emphasize results that can potentially be applied in real world software engineering environments. They should include a thorough evaluation, through either experimentation, simulation, analysis, and/or experience. Please submit six copies of your manuscript to either guest editor by March 1, 1995; Professor James M. Bieman Professor Pradip K. Srimani Department of Computer Science Department of Computer Science Colorado State University Colorado State University Ft. Collins, CO 80523 Ft. Collins, CO 80523 Tel: (303) 491-7096 Tel: (303) 491-7097 Fax: (303) 491-2466 Fax: (303) 491-2466 Email: bieman@CS.ColoState.Edu Email: srimani@CS.ColoState.Edu Instructions for submitting papers: Papers should not exceed 30 double spaced pages. Papers should not have been previously published, nor currently submitted elsewhere for publication. Papers should include a title page containing title, authors' names and affiliations, postal and email addresses, telephone numbers and Fax numbers. Papers should include a 300 word abstract and 5-10 keywords and be written in general in JSS style. [Note: If you are willing to referee papers for this special issue, please send a note with research interest to Professor Bieman or Professor Srimani.] A------------------------------------------------------- From: Keith Pierce Subject: CFP: Conference on Concurrent Engineering CALL FOR PAPERS Second International Conference on Concurrent Engineering: Research and Applications (CE95) August 23-25, 1995 Washington DC area, USA CE95 is a major forum for the international scientific exchange and presentation of multi-disciplinary and inter-organizational aspects of Concurrent Engineering. Topics of interest for CE95 include: --enterprise integration --cooperative work --information sharing --communication tools --integrated frameworks and tools --life cycle engineering --practical applications of Concurrent Engineering in the industry Time-table and deadlines: Authors should submit a full draft paper, not exceeding 16 single spaced pages (preferably by e-mail in plain ASCII or PostScript), to the Program Chair. Submit full draft paper January 1, 1995 Notification of acceptance or rejection February 28, 1995 Receipt of camera-ready papers April 15, 1995 A current version of the CE95 Call For Papers (and other pertinent information) is available at http://ce-toolkit.crd.ge.com/~sobol/CE95.html Information about CE94 and the proceedings for last year's conference is available at http://ce-toolkit.crd.ge.com/~sobol/CE94.html For more information contact: Anand J. Paul Conference General Chair Concurrent Technologies Corporation 11605 Bedfordshire Avenue Potomac, MD 20854 USA Voice: (301) 762-6190 Fax: (301) 762-6191 E-mail: paul@ctc.com A------------------------------------------------------- Subject: SPI Successes and Barriers - from the Pittsburgh SPIN From: Linda Ibrahim Hi Keith, Don't know if you'd consider this of general interest for FASE or other channels, but I think the top 2 barriers are important to note for software engineering educators! Linda Subject: SPI Successes and Barriers - from the Pittsburgh SPIN The Pittsburgh SPIN met on October 25 for an interactive brainstorming - problem solving - lesson sharing session. The topic was Successes and Barriers in Software Process Improvement. We used the following process: Regarding Successes: 1. SPIN members responded to the following statement: "One major success that I have experienced in implementing improvement in my software organization is _____________" 2. Responses were scribed 3. SPIN members were asked how they can know if a change has been successful or not (indications of successful process improvement efforts) 4. Responses were scribed Regarding Barriers: 1. SPIN members responded to the following statement: "The largest barrier that I have not been able to overcome is ______________" 2. Responses were scribed 3. Similar responses were grouped together 4. SPIN members then voted on their choices as to the most serious barriers. (Our group came up with 32 barriers and each person received 5 votes (sticky dots) to distribute as desired on the topics that were listed on the flip charts). 5. The top 5 barriers were then discussed in priority order, as SPIN members offered suggestions regarding how that barrier could be removed or dealt with based on their experiences. Attendees provided feedback indicating that they had gained useful and practical information in this session. Here are the results that we came up with. Linda Ibrahim and Mary Merrill SEI - - -------------------------------------------------------------------------------- REGARDING SUCCESSES =================== IMPROVEMENT SUCCESSES EXPERIENCED BY THOSE IN ATTENDANCE - - - Requirements Case Tool was implemented that resulted in improved accuracy for products developed - - - PC Tools for Project Management implemented - got experience myself; then trained others (first level management 1st) - now institutionalized - - - Formal inspectations installed and saved a lot of work - - - Formalized process for interface changes introduced and developed tools (procedures were enacted via tools) - - - Process appraisal helped get sponsorship for process improvement. - - - Process certified against ISO9001 criteria - - - Defect tracking and responsibilities put into place. - - - Just in time training (JIT) implemented. (Learning Institute staff facilitates this) (We phase training to selected modules) - - - Team formed to plan and implement culture change - - - Some organizations I worked with moved from maturity level 1 to 2 and from level 1 to 3. - - - Implemented Metrics Program at project level - showed how data could be used, got people to ask for it. INDICATIONS OF SUCCESSFUL PROCESS IMPROVEMENT EFFORTS - - - Doesn't go away when resources get scarce. - - - Done subconsiciously. - - - Gets improved by people who are actually using it. - - - Changes the culture (people speak from completely different perspective) - - - People apply it to something else - - - People talk about customer issues (not process issues, which are no longer the #1 priority ) - - - Practitioners did it! (NOT imposed by management). - - - People following it see its benefits. - - - There are clear measures of the change (ROI, capability improvement, cost, schedule) REGARDING BARRIERS ================== BARRIERS EXPERIENCED BY THOSE IN ATTENDANCE (# votes received for each is in () next to the barrier) - - - No belief that "process" applies to software (i.e., the "art" of software) (2) - - - No belief that software is an engineering discipline (by practitioners and managers) (4) - - - "No time" (8) - - - "Too small an organization to do this" (2) - - - "Can't do it now" (1) - - - Rewarding crisis management (2) - - - Rewarding firefighters, hackers, cowboys (6) - - - "Just get more people" (1) Corollary: "just use more beta testers" - - - Lack of understanding and knowledge of how to use quality management principles for software (17) - - - Belief TQM doesn't apply (1) - - - Concepts aren't taught at universities (10) - - - Aversion to keeping records (5) - - - Fear of being less than perfect (0) - - - Misuses of data (0) - - - Fear of misuses of data (5) - - - Perceptions vs. reality (communication through rumor)/ decisions not based on fact (0) - - - "Steps are too big, processes too large" (5) - - - Goals too aggressive (0) - - - SPI viewed as extra expense or luxury (2) - - - "Quality (zero defects) is a luxury" (1) - - - Silver bullet - there IS a consultant there to solve this (1) - - - Can't cross corporate lines (Political - N.I.H.) (1) - - - Too much, too fast (0) - - - Lack of constancy of purpose (1) - - - Too little, too slow (0) - - - Fear that disciplined process will stifle creativity (1) - - - SEPG (process group) perceived as not doing real work. (3) - - - Organizational changes (reorgs) (0) - - - Short term fixes, not long term changes (to make things look good) (5) - - - Lack of high level buy-in (7) - - - Lack of money (1) - - - Lack of people to work on it (3) - - ------------------------------------------------------------------------------ TOP 5 BARRIERS Number of votes 1 Lack of understanding and knowledge about SPI 17 2. Concepts aren't taught at universities 10 3. "No time" 8 4. Lack of high level buy-in 7 5. Rewarding firefighters, hackers, cowboys 6 HOW TO OVERCOME, MITIGATE THESE BARRIERS 1&2 Lack of understanding and knowledge about SPI * emphasize training for everyone * make learning non-threatening - figure out a way * initial education - make it: - not mandatory - just for learning about the topic - offer it early before commitment and THEN have them tell you what they think * learning as part of a culture - ask person from organization to research and present - ask outsider to present - key is a credible champion (internal or external) * create a terrorist club! (with process improvement terrorist kit); (use tools as appropriate but have support system for people in those roles) * just do it!; don't insist on everyone's buy in at once; but be careful views are consistent; (offer consensus training to help people to reach group decisions) * education through lessons learned from the practitioners * multiple strategies blossoming is best (rather than just one) - capitalize on success; concentrate on early adopters 3 No time for SPI * decide what you value * show the benefits - ie. literature shows; ROI on peer reviews but still not done * allocate small amount of time at first, then grow the window * start with a small problem - mix education with it, as a first step * find right problem (what's most important right now) and turn it into a success 4. Lack of high level buy-in * go and talk to CEO directly/face to face; show numbers and case histories (may get resistance with statements like "but they aren't like us" - not always different) * "buy-in" means: - you have the go ahead - go try it - not necessarily a big huge deal! - get small buy-in successes to start with * emphasize the problems and lack of quality that will be addressed through the improvement efforts 5. Rewarding firefighters * fire the firefighters that cannot adapt to prevention * set up reward system and reward risks/risk takers * externally imposed conditions * improve supplier-customer relations * fire prevention needs greater reward/attention than fire fighting * better management planning * institute risk management * balance and include reward for process improvement * consider intrinsic vs entrinsic rewards * reward for using the process * balance groups * "spi is not part of my job"; must be on performance reviews (caveats) - need education - need realistic goal setting * emphasize that documenting what they are doing gives them a way to review and improve what they are doing. - - -------------------------------------------------------------------------------- - ------- End of Forwarded Message ------- End of Forwarded Message E------------------------------------------------------------------- FASE Volume 4 Number 21 Send newsletter articles to fase-submit@d.umn.edu or fase@d.umn.edu Send requests to add, delete, or modify a subscription to fase-request@d.umn.edu Send problem reports, returned mail, or other correspondence about this newsletter to fase-owner@d.umn.edu or kpierce@d.umn.edu You can retrieve back issues by anonymous FTP from from ricis.cl.uh.edu. You can access them through WWW at URL http://ricis.cl.uh.edu/FASE/ Keith Pierce, Editor Laurie Werth, Advisory Committee Department of Computer Science Dept. of Computer Science University of Minnesota, Duluth Taylor Hall 2.124 Duluth, MN 55812-2496 University of Texas at Austin Telephone: (218) 726-7194 Austin, Texas 78712 Fax: (218) 726-6360 Telephone: (512) 471-9535 Email: kpierce@d.umn.edu Fax: (512)471-8885 Email: lwerth@cs.utexas.edu David Eichmann, FASE Archivist Asst. Prof. / RBSE Director of R & D Web: http://ricis.cl.uh.edu/eichmann/ Software Engineering Program Phone: (713) 283-3875 University of Houston - Clear Lake fax: (713) 283-3810 Box 113, 2700 Bay Area Blvd. Email: eichmann@rbse.jsc.nasa.gov Houston, TX 77058 or: eichmann@cl.uh.edu RBSE on the Web: http://rbse.jsc.nasa.gov/eichmann/rbse.html