>> [Comp Sci Dept]
>> [R J Botting]
>> [New Bibliographic Items]
|| [Site Search]
|| [Bibliography Search]
Mon Apr 18 15:06:33 PDT 2005
- Shari Lawrence Pfleeger
- Soup or Art: The role of evidential force in empirical software engineering
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp
- =IDEA EVIDENCE ARGUMENT TECHNOLOGY META-ANALYSIS
- Evidence of technology works: meaning of "works"? Kind of evidence? Who provides? Who reviewed it? What domain? Other domains? Social, economics, politics -- Risk.
- Types of evidence: tangible, testimonial, equivocal testimonial, missing, accepted facts.
- Multi-legged arguments are better: several diverse pieces of evidence have the same consequence.
- Tom Dyba & Barbara A Kitchenham & Magne Jorgensen
- EVIDENCE-BASED Software Engineering for Practitioners
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp58-65
- =IDEA PRACTICES LITERATURE SURVEY EBSE
- How to select technologies, methods, processes to put into a project?
- EBSE::acronym="EVIDENCE-BASED Software Engineering", and following
- Convert problem/information into answerable question.
- Search the literature for best evidence.
- Critically appraise evidence: valid? Impact?, Applicable?
- Apply the evidence that fits current project: experience, values, circumstances.
- Evaluate performance and seek to improve.
- Resources page 61
- Checklist page 62.
- Example page 64: Chaos report does not fit with other surveys and does not include data to evaluate the accuracy of its evidence.
- David Bodolf & Patrick C K King & Mordechai Ben-Menachem
- Web Metadata Standards: Observations and Prescriptions
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp78-85
- =ESSAY WEB STANDARDS METADATA ONTOLOGIES AI
- Table 1 page 80: List of standards: ebXML, CPP, WSDL, UDDI, SOAP, WS-Security, P3P, DC, CIMI, OWL.
- Don't ignore testing, SQA and other long standing problems.
- Don't target a standard at too many purposes/uses.
- To find things may need meta-meta-data.
- Need tools to support search and navigation through classifications and thesaurus hierarchies.
- Don't add useless indexing.
- Don't work at too high a level and allow too much freedom at more concrete levels.
- Conventional ontologies should be limited to narrow domains until more reliable methods to develop ontologies are developed.
- Terry Halpern and others
- Object Relation Modeling
[ http://www.orm.net/ ]
- =SITE DATA CONCEPTUAL MODEL METHOD FACTS OBJECTS CONSTRAINTS Visio .NET ORM ERD RELATIONAL SCHEMA SQL
- Dan Romanchick
- Is the Rational Unified Process (RUP) Right for small teams
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp-
- =INTERVIEW PROCESS PEOPLE TEAMS RUM
- Common mistakes for small teams: putting process above people and preparing artifacts that aren't used in future stages of the project.
- Ref "Software Development for small Teams: a RUP-centric Approach by Gary Police & Liz Augustine & Chris Lowe & Jas Madhur, Addison Wesley
- June M Verner & William M Evanco
- IN-House software development: What project management practices lead to success
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp86-92
- =POLL PROJECT SUCCESS FINANCE COMPARISON
- 62% regarded as successful.
- Changing the project manager is correlated with failure.
- Manager's people skills and support correlated with success.
- Most (54%) projects didn't have significant interaction with analysts!
- Nearly half started with incomplete requirements. But completing them during the project was associated with success.
- Well defined requirements and scope is correlated with success, as is user involvement in setting requirements.
- Actively managing requirments change was correlated with success.
- Bigger projects tended to fail more often.
- Good estimation linked to success. Optimistic estimation with failure.
- Not having a schedule not associated with success or failure. Large projects tended to have a schedule.
- Estimates come top-down to the project manager before requirments are started.
- Better estimates tended to have project manager input.
- 8 used UML for requirements and 3 were successful.
- Not much risk management. Few post mortems. Both associated with success.
- Daniel M Berry & Erik Kamsties
- The syntactically dangerous ALL and Plural in Specifications
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp55-57
- =IDEA AMBIGUITY LOGIC LANGUAGE SPECIFICATION CS565
- Words to suspect: "only", "all", "also", "each".
- Use "each" when describing a property of the individual members of a set.
- Use "all" for shared properties across a set.
- Can use simple logic to clarify an ambiguity.
- All the lights in the room have a single on-off switch.
- Each light has its own switch.
- For all y:lights_in_room, one x: switch (x is on_off_switch_for y).
- All the lights share a common switch.
- For one x: switch, all y:lights_in_room (x is on_off_switch_for y).
(End of Net)
- Similarly for plurals: "Students enroll in six courses" vs "Students enroll in hundreds of courses".
- Barbara Peach & Jorg Dorr & Mathias Koehler
- Improving Requirments Engineering communication in multiproject environments
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp40-47
- =EXPERIENCE PEOPLE COMMUNICATIONS DOCUMENTATION DATA FLOW Nokia
- Use a workshop to understand problems in a software process and to design solutions.
- Johan Natt och Dag & Bjorn Regnell & Vincenzo Gervasi & Sjaak Brinkkemper
- A Linguistic-Engineering Approach to Large-scale Requirments Management
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp32-39
- =IDEA LANGUAGE SIMILARITY DOCUMENTATION RETRIEVAL REQUIREMENTS
- Map documents into vector space and use cos(angle) to measure matches when retrieving.
- Use log functions to scale the frequency of occurrence of words (formula is suspect)
- Applied to matching market requirements to business requirments.
- Lars Hagge & Katherine Lappe
- Sharing Requirements engineering experience using patterns
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp24-31
- =Advert Requirements engineering people patterns
- Organize the specification to parallel the structure of the project. Teams appoint one member as an author. Authors coordinated by the requirements engineer.
- Help stakeholders write specifications by giving them guidelines based on the prefered process by analysts,
- Record requirements on index cards and classify them.
- Link components to requirements by checklists.
- Fig6:UML model for pattern mining/database.
- Ian Sommerville
- Integrated Requirements engineering: A Tutorial
- IEEE Software Magazine V22n1(Jan /Feb 2005)pp16-23
- =Tutorial HISTORY Requirements engineering nonsequential agile Components COTS open-target
- C M F Rubira & R de Lemos & G R M Ferreira & F Castor Filho
- Exception handling in the development of dependable component-based systems
- Software - Practice & Experience V35n3(Mar 2005)pp195-236
- =CASESTUDY RELIABILITY COMPONENTS ARCHITECTURE USE CASES EXCEPTIONS CLASSES Catalysis
- Exceptional cases can not all be handled by a single component, one must map out the collaborations between several components for some of them.
- Showed exceptional events as actors in Use Cases: <<actor>> WaterLow, <<actor>>Alarm, ... !
- Per Kroll & Phillippe Kruchten
- The Rational Unified Process made easy: a practitioner's Guide to the RUP
- Addison-Wesley 2003 ISBN 0321166094 QA67.76 D47K75
- =HOWTO =ADVERT RUP PROCESS TOOLS TEMPLATES METHODS PEOPLE ONE-SIZE
- The Spirit of RUP::=following,
- Attack major risks early and continuously or they will attack you.
- Ensure you deliver value to your customer.
- Stay focused on executable software.
- Accommodate change early in the project.
- Baseline an executable architecture early on.
- Build your system with components.
- Work together as one team (not annalists versus developers vs testers)(make architecture central).
- Make quality a way of life, not an after thought.
- Gives examples of small,....large projects.
- Stephane Ducasse & Michele Lanza
- The Class Blueprint: visually supporting the understanding of classes
- IEEE Trans Software Engineering V31n1(Jan 2005)pp79-90
- =EXPERIMENTAL GRAPHIC Object-Oriented code metrics structure smalltalk
- Classifies attributes and methods into layers: initialization, interface, internal implementation, accessors, attributes.
- Attributes and methods shown as boxes. Metrics mapped to height and width. Type to color.
- Caller-callee link goes from bottom of caller box to top of called.
- Tested on real code. and by a dozen students (all found it helpful).
- Gennaro Costagliola & Filomena Ferruci & Genoveffa Tortara & Giuliana Vitiello
- Class Point: an approach for the size estimation of Object-Oriented systems
- IEEE Trans Software Engineering V31n1(Jan 2005)pp53-74
- =EXPERIMENT ESTIMATION CODE SIZE LoC EFFORT FP IFPUG TUCP METRICS NEM NSR
- CP1::level= "Class Point 1", based on NEM and NSR (Methods and services requested).
- level::= (low, average, high).
- CP2::level= "Class Point 2", based on NEM, NSR, and NOA(attributes).
- TUCP::= "Totally Unadjusted Class Point",based on CP1 and CP2.
- |-TUCP=Sum [class_type c, level l]( weight[c, l] * number classes[c, l]).
- class_type::= problem_domain | human_interaction | data_management | task_management.
- CP::= "Class Point", based on TUCP and 18 technical factors.
- p71. fig 6. Form
- Significant correlation between CP1 and CP2
- Vittorio Cortellessa & Katerina Goseva-Postojanova & Kalaivani Appukkutty & Ajith R Guedin & Ahmed Hassan & Rania Alnaggar & Walid Abdelmoez & Hany H Ammar
- Model-Based Performance Analysis
- IEEE Trans Software Engineering V31n1(Jan 2005)pp3-20
- =DEMO REQUIREMENTS DESIGN QUALITY PERFORMANCE TIMING RISK PROBABILITY LOAD UML1.5 MODEL
- How to estimate the probability that a performance requirement will fail.
For each scenario:
- assign demand vectors(CPU,Disk,network,...) to steps in sequence diagram; map to software execution model (=~= Activity diagram)
- Add hardware info to deployment diagram
- Devise workload parameters, map to execution model, contention analysis, est. Probability of violating timing
- Severity analysis
- Risk=severity * probability; identify high risk components.
- Estimate probability of failure at workload w, P(w) by linear interpolation from upper and lower bounds on throughput (l(w).. u(w)) and objective t.
Assume l & u are monotonic increasing.
- If u(w0)=t then P(<=w0)= 0 and if l(w1) = t then P(>=w1) =1.
- For w: [w0..w1], P(w)= (u(w)-t)/(u(w)- l(w)).
- Joerg Evermann & Yair Wand
- Toward formalizing domain modeling semantics in language syntax
- IEEE Trans Software Engineering V31n1(Jan 2005)pp21-37
- =IDEA REALITY DOMAIN Bunge ONTOLOGY LANGUAGES MODEL UML STATE CHART METAMODEL
- Map ontology of the real domain into constraints on modeling languages to minimize "impedance mismatch" between analysis and design.