>> [Comp Sci Dept]
>> [R J Botting]
>> [New Bibliographic Items]
|| [Site Search]
|| [Bibliography Search]
Mon Jul 18 08:01:44 PDT 2005
- Tore Dyba
- An Empirical investigation of the Key Factors for success in Software Process Improvement
- IEEE Trans Software Engineering V31n5(May 2005)pp341-424
- =POLL 120 ORGANIZATIONS IMPROVEMENT SPI STATISTICS
- p421: "organizational issues are at least as important in SPI as technology, if not more so."
- Results suggest the following,
- Align improvement goals with business. Share knowledge between business and software experts.
- Management provides resources not leadership in SPI.
- Involve the developers/workers in creating the proposed changes and metrics.
- Focus on the measurement of success.
- Look for existing knowledge to exploit and/or explore for new knowledge
- Encourage workers/developers to explore new ideas because this involves them in the process.
- Andreas Gregoriades & Alexander Sutcliffe
- Scenario-Based Assessment of Nonfunctional Requirements
- IEEE Trans Software Engineering V31n5(May 2005)pp392-409
- =DEMO TOOL SRA BAYES BN MODEL SYSTEM PERFORMANCE QUALITIES NFR REQUIREMENTS TESTING
- Allows for human unreliability in system.
- Bayesian network allows the back propagation of high failure rates to likely root causes.
- Compare with NASA operational profiles.
- Ingun Myrtveit & Erik Stensrud & Martin Shepperd
- Reliability and Validity in Comparative Studies of Software Prediction Models
- IEEE Trans Software Engineering V31n5(May 2005)pp380-391
- =SIMULATION =SURVEY RESEARCH EFFORT ESTIMATION COST PREDICTION
- Shows that there is no consistent recommendation's in the literature for estimating cost/effort
- Simulated the typical research procedure for evaluating and/or comparing ways of predicting the effort needed to produce software.
- Shows that the particular measure of goodness of fit chosen determines the "best" model.
- Shows that the particular sample of data also determines the "best" model.
- Cormac Flanagan & Stephen N Freund & Shaz Qadeer
- Exploiting Purity for Atomicity
- IEEE Trans Software Engineering V31n4(Apr 2005)pp275-291
- =THEORY NONSEQUENTIAL PURE ATOMIC REDUCTION
- Thomas J Ostrand & Elaine J Weyuker & Robert M Bell
- Predicting the location and number of faults in large software systems
- IEEE Trans Software Engineering V31n4(Apr 2005)pp340-355
- =EMPIRICAL SQA DEFECTS negative binomial
- Erik Putrycz & Murray Woodside & Xiuping Wu
- IEEE Software Magazine V22n3(Jul/Aug 2005)pp36-43
- =ADVERT COMPONENTS PERFORMANCE ARCHITECTURE METHOD LOAD QUEUING MODEL
- Not unlike the 1980s Physical Design Control step in SSADM!
- Philip M Johnson & Hongbin Kou & Michael Palding & Qin Zhang & Aaron Kagawa & Takuya Yamashita
- Improving Software development management through Software project Telemetry
- IEEE Software Magazine V22n3(Jul/Aug 2005)pp76-85
- =DEMO TOOL METRICS AUTOMATION DISPLAY Hackystat
- Hackystat::= See http://hackystat.ics.hawaii.edu/.
- Neil Maiden
- What has requirements Research ever done for us?
- IEEE Software Magazine V22n3(Jul/Aug 2005)pp104-105
- =SURVEY requirements KAOS i* Tropos Use-case maps LTSA CREWS ART-SCENE
- Sidebar has URLs.
- Wilfried Lemahieu & Monique Snoeck & Frank Goethala &Manu De Backer & Raf Haesen & Jacques Vandenbulke & Guido Dedene
- Coordinating COTS Applications via a Business Event Layer
- IEEE Software Magazine V22n3(Jul/Aug 2005)pp28-35
- =DEMO ARCHITECTURE BUSINESS PROCESS COTS COMPONENTS MODULES
- Proposes coordinating components by using two layers on top of the components.
One layer describes a business processing terms of business events.
The second layer defines the different business events and notifies various subsets of application components in turn.
- Compare with
- Peter J Denning
- The Locality Principle
- Commun ACM V48n7(Jul 2005)pp19-24
- =SURVEY =HISTORY LOCALITY
- Michael A Jackson
- Problem Frames: Analyzing and structuring software development problems
- Addison Wesley 2001 ISBN 0-201-59627-X QA76.76 D47 J32 2001
- =ESSAY PROBLEM ANALYSIS REQUIREMENTS REALITIES SYSTEMS METHODS
- An in depth attempt at deconfusing a critical part of software development: understanding the problems and planning how to tackle them. Includes detailed references to several methods and some classic examples from the literature,
- Five basic problem frames: Required Behavior. Commanded Behavior, Information Display, Simple Workpieces, Transformation.
- Plus many variants and compositions,
- Good discussion of the concerns that arise with different types of problems and domains.
- Many examples. New Glossary, Careful definitions of what the diagrams mean,
- Distinguishes: the machine, the parts of reality, the requirements, the existence of parts of reality that a symbolic descriptions, ...
- Some advice for decomposing a problem into subproblems -- for example introducing a designed model of a part of reality and a machine to keep it synchronized, plus other machines to meet other requirments.
- Yaofei Chen & Rose Dios & Ali Mili & Lan Wu & Kefei Wang
- An Empirical Study of Programming Language Trends
- IEEE Software Magazine V22n3(May/Jun 2005)pp72-79
- =POLL =HISTORY PROGRAMMING LANGUAGES
- Gathered data on what developers used, schools taught, and the primary language in companies. Dates: 1993, 1998, 2003
- Java is becoming the top language.
- Developers appear to value machine independence and extensibility mosts, and dislike simplicity and ease of implementation.
- Mark Keil & Amrit Tiwana
- Beyond Cost: The Drivers of COTS Application Value
- IEEE Software Magazine V22n3(May/Jun 2005)pp64-69
- =POLL MARKET COMPONENTS PURPOSE QUALITIES COST CUSTOMIZATION USER
- MIS Managers tend to treat functionality and reliability as more important than cost, ease of customization, and ease of use.
- Robert L Glass
- IT Failure Rates -- 79% or 10..15%
- IEEE Software Magazine V22n3(May/Jun 2005)pp112+110-111
- =SURVEY Standish considered harmful
- Evidence that the 70% failure rate is mythical. Invites Standish to respond.
- Bojan Cukic
- The virtues of assessing reliability early
- IEEE Software Magazine V22n3(May/Jun 2005)pp51-53
- =ADVERT COMPONENTS QUALITIES RELIABILITY PREDICTION UML MODEL USE CASES SEQUENCE DEPLOYMENT TOOL beta-distribution Monte Carlo ECRA
- ECRA::= "extended component-based reliability assessment".
- See email@example.com.
- Daniel Karlstrom & Per Runeson
- Combining agile methods with Stage--Gate Project Management
- IEEE Software Magazine V22n3(May/Jun 2005)pp43-49
- =EXPERIENCES SD SDLC+XP AGILE PROCESS MANAGEMENT ABB Ericsson Vodafone
- Engineers are ready for agile processes but managers fear them. Success needs both!
- XP leads to better quality.
- The SDLC documentation should be treated as another XP User Story.
- Agile process handles the day-to-day process of development and lets managers concentrate on the overall progress.
- Bob Schatz & Ibrahim Abdelshafi
- Primavera Gets Agile: A successful transition to agile Development
- IEEE Software Magazine V22n3(May/Jun 2005)pp36-42
- =EXPERIENCE Scrum AGILE PROCESS =ADVERT TOOL
- Consequence: higher morale, customer reported defect/KLOC drops 30%, able to deliver one release 4 months early.
- Need for executive sponsor and external coach.
- Focus on developing teamwork.
- 40.hour week.
- Learn to negotiate and set expectations.
- Needed a process that takes accusal suggestion by a product owner into a new requirement.
- Then added test-driven development and re-emphasized code quality. Defect rate per item dropped 75%!
- Todd Little
- Context-adaptive agility: managing complexity and uncertainty
- IEEE Software Magazine V22n3(May/Jun 2005)pp28-35
- =PRACTICE ONE SIZE PROJECT -> PROCESS AGILE landmark
- Classify projects as Skunks, Dogs, colts,Cows and Bulls.
- A Skunk is typically a prototype but a Dog is a mature project.
- Projects change state. 3 common trajectories. Skunk->Colt->Dog, Skunk->Colt-> Bull->Cow->Dog, Bull->Cow->Dog.
- Fit the process to the animal.
Core practices + adaptions.
- Core Practice: product plan,prioritize requirements, quality targets, continuous integration, involve experts users, Project Dashboard.
- Project_dashboard:=web-based project status updated weekly.
- Colts benefit from short iterations, daily stand up meetings, and automated testing.
- Cows need more rigorous management tools and procedures: CPM, subprojects, teams coordinated by Scrum, functional specs of interfaces,...
- Bulls need BOTH Colt and Cow practices. They need the best experienced managers.
- Has several process and project metrics.
- Martina Ceschi & Alberto Sillitti & Giancarlo Succi & Stefano De Panfilis
- Project Management in plan based and agile companies
- IEEE Software Magazine V22n3(May/Jun 2005)pp21-27
- =POLL 20 MANAGERS PROCESS SATISFACTION AGILE
- All use some form of incremental delivery and face similar problems with deadlines and changing requirements,
- Some nonsignificant evidence that Agile companies tend to be more satisfied with project planning and customer relationships.
- 50% of both want developers that can work in a group.
- Dave Thomas
- Agile Programming: Design to accommodate change
- IEEE Software Magazine V22n3(May/Jun 2005)pp14-16
- =ADVERT TABULAR decision tables states FSM/STD Spreadsheets
- Convert changing code into data + table and let the users supply the data.
- Warren Harrison
- Skinner wasn't a Software Engineer
- IEEE Software Magazine V22n3(May/Jun 2005)pp5-7
- =EDITORIAL RESEARCH
- Notes problems with experiments (on students) and field studies.
- Describes single subject research designs.
- design::=baseline #(treatment withdraw).
- One subject implies no means. Looking for an observable change instead. therapeutic criterion
- Alex Potanin & James Noble & Marcus Frean & Robert Biddle
- Scale-Free Geometry in OO Programs
- Commun ACM V48n5(May 2005)pp99-103
- =STATISTICS Object-Oriented run-time heap data digraph
- Analyzed the heap of 9 large OO programs.
- Number of objects containing n pointers is roughly proportional to n ^ -3.
- Number of objects with n pointers pointing at them is roughly proportional to n ^ -2.5.
- Tendency for objects with many incoming pointers to have few outgoing pointers, and vice versa.
- Ian Sommerville & Jane Ransom
- An empirical study of industrial requirements engineering process assessment and improvement
- ACM TOSEM Trans Software Eng & Methodology V14n1(Jan 2005)pp85-117
- =EXPERIENCE 9 Greek IMPROVEMENT REQUIREMENTS ENGINEERING MATURITY TOOL IMPRESSION CMM CMMI REAIMS
- 3 levels. Initial; repeatable; defined.
- 66 good practice guidelines. 36 basic, 21 intermediate, 9 advanced. In 8 areas of requirements engineering. ....
- Scoring. never, discretionary, normal, standardized.
- Others studied business performance measurement.
- Greek companies, with English methodologists, so companies did not use techniques invented by the experimenters.
- At first, all companies didn't have a repeatable process, but some used intermediate and advanced practices anyway.
- Experimenters suggested guidelines to be targeted.
- All companies improved RE levels.
- Also looked at business results: critical success factors (CSF), key performance indicators (KPI). All companies showed improvements.
- Company reps said it was worth doing.
- Companies did not know what improvements to make.
- Classification of guidelines is domain dependent.
- The tool was worth developing: saved data entry time etc.