Skip to main contentCal State San Bernardino
>> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [New Bibliographic Items] >> newb1208 [Blog/News] || [Purpose] || [Notation] || [Copyright] || [Site Search] || [Bibliography Search]
Fri Dec 9 09:46:14 PST 2005

Contents

    Botting05b

    1. Richard Botting
    2. Small Errors in "Toward formalizing domain modeling semantics in language syntax"
    3. IEEE Trans Software Engineering V31n10(Oct 2005)pp911
    4. =Correction Statecharts fork vs decision

    Schuh05

    1. Peter Schuh
    2. Integrating agile development in the real world
    3. Charles river media 2005 ISBN1-58450-364-5 QA76.76
    4. =HOWTO agile

    Wile04

    1. David Wile
    2. Lessons learned from real DSL experiments
    3. Science of Computer Programming V51n3(Jun 2004)pp265-290 CR 0511-1252
    4. =UNREAD 3 EXPERIENCES DOMAIN LANGUAGES
    5. None went into use for the usual nontechnical reasons that software fails.

    HardgraveArmstrong05

    1. Bill C Hardgrave & Deborah J Armstrong
    2. Software Process Improvement: It's a Journey, not a Destination
    3. Commun ACM V48n11(Nov 2005)pp93-96
    4. =EXPERIENCE IMPROVEMENT vs CMM
    5. It took 4 years to move from CMM Level 1 to level 2.
    6. In the process installed a common methodology throughout the organization.
    7. Measurable improvements:customer satisfaction, schedule deviations, budget deviations.
    8. Lessons:=
      1. Need management guidance and support from start to finish.
      2. Engage the members.
      3. Use well-respected team members to lead the process.
      4. MEASURE from day 1
      5. SPI is a project and needs resources.
      6. Focus on continuous improvement rather than meeting the next level by a given deadline.
      7. Fit the improvement to the organization.

    Mookerjee05

    1. Radha Mookerjee
    2. Maintaining Enterprise Software Applications
    3. Commun ACM V48n11(Nov 2005)pp75-79
    4. =THEORY evolution maintenance multiple applications SYSTEMS COSTS
    5. Argues that it pays to schedule joint maintenance when fixed costs are high, applications are coupled, and the rate of change is low.
    6. Recommends separating implementation from interface and the use of wrappers, hubs, and web services.
    7. Organization: recommends separating development from maintenance,

    KupermanEtal05

    1. Benjamin A Kuperman & Carla E Brodley & Hilmi Ozdoganoglu & T N Viyakuma & AnkitJalote
    2. Detection and prevention of stack buffer overflow attacks
    3. Commun ACM V48n11(Nov 2005)pp51-56
    4. =REPORT TECHNICAL RISK ERROR STACK CODE V&V TOOLS
    5. Concludes that training and review is one of the more effective techniques for getting rid of code that can be exploited. Bit code review is not perfect.
    6. There are tools to spot potential security violations: ITS4, RATS, LCLint.
    7. Dynamic protection (eg modify compiler to do bounds checking) can be costly but hardware may evolve to spot attacks fast.

    Kugel05

    1. Peter Kugel
    2. It's time to think outside the computational box
    3. Commun ACM V48n11(Nov 2005)pp33-37
    4. =ESSAY PROGRAMMING BY EXAMPLE COMPUTE IN THE LIMIT
    5. Allowing programs to be wrong a finite number of times before being correct allows them to (in the limit) produce the program that fits all the given examples.
    6. (dick): most software development works like this anyway: testing, beta, alpha, ...

    Baggi05

    1. Denis L Baggi
    2. An IEEE Standard for Symbolic Music
    3. IEEE Computer Magazine V38n11(Nov 2005)pp100-102
    4. =REPORT MUSIC STANDARD P1599 XML MEI RM0
    5. P1599::= See http://www.computer.org/portal/pages/ieeecs/communities/standards/1599/par.html
    6. MusicXML::= See http://www.recordare.com/xml.html

    Cohn04

    1. Mike Cohn
    2. User Stories Applied: for agile software development
    3. Addison-Wesley 2004 ISBN 0-321-20568-5
    4. =UNREAD USER REQUIREMENTS AGILE XP

    DonnellanEtal05

    1. Brian Donnellan & Brian Fitzgerald & Brian Lake & John Sturdy
    2. Implementing an Open Source Knowledge Base
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp92-95
    4. =COMPARISON TOOLS KB OPEN SOURCE COSPA MetaData DSpace LAMP Data Centric KMS Lotus Notes
    5. KB::="Knowledge Base", part of an expert system, the body of knowledge available for the inference engine to use.
    6. Dublin_Core::standard= See http://dublincore.org.
      (Open archives initiative Protocol for Metadata Harvesting): framework [ http://www.openarchives.org ]

    7. Only works well when it evolves with the needs of the users.

    MathiassenNgwenyamaAaen05

    1. Lars Mathiassen & Ojelanki K Ngwenyama & Ivan Aaen
    2. Managing Change in process improvement
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp84- 91
    4. =CASE STUDY 4 DANISH COMPANIES VARIED SPI IMPROVEMENT
    5. All had limited success: software process was improved,none achieved as much as they wanted initially.
    6. SPI is organizational change.
    7. (above) |- need to use change management techniques.
      • Understand context: source, organization structure,existing processes and needs.
      • Create (and communicate) vision
      • Manage commitment
      • Plan
      • Stay agile
      • Monitor improvement
    8. One size does not fit all. For example,
      1. maintenance does not follow a development process.
      2. Small and simple projects do not need all the procedures and data recording of a complex or large project.
    9. In all 4 projects nobody expected that management would have to change!

    Erdogmus05

    1. Hakan Erdogmus
    2. The Economic Impact of learning and flexibility on Process decisions
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp76-83
    4. =ESSAY MATH ONE SIZE Economics PROCESS ITERATIVE vs SEQUENTIAL COST-BENEFIT
    5. Calculated values of projects.
    6. Iteration & learning can make a project profitable in an uncertain situation.

    DangleLarsenShawZelkowitz05

    1. Kathleen Coleman Dangle & Patricia Larsen & Michele Shaw & Marvin V Zelkowitz
    2. Software Process Improvement in Small Organizations: A Case Study
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp68-75
    4. =CASE STUDY DSCS CMM
    5. (dick) |- when does software process improvement merge into business process reengineering?
    6. (dick) |- Rediscovers some trad systems analysis and design ideas.
    7. Discoveries:
      • Processes and process improvement should address business goals not just CMM dogma,
      • Choose the sequence of improvements to support needs not CMM KPAs.
      • TANSTAAFL: Improvement needs resources.
      • Test proposed improvements on selected projects and change them before expanding enterprise-wide.
      • Ongoing activities should drive the plans for introducing new processes.
      • Start formal reviews immediately to provide feedback to stakeholders.
      • Divide improvements up and delegate.
      • Assess experience with software processes and SP improvement.

    DarcyKemerer05

    1. David P Darcy & Chris F Kemerer
    2. OO metrics in Practice
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp17-19
    4. =ADVERT =SURVEY CK METRICS Object-Oriented

    Dick05

    1. Jeremy Dick
    2. Design traceability
    3. IEEE Software Magazine V22n5(Nov/Dec 2005)pp14-16
    4. =ESSAY traceability REQUIREMENTS DESIGN
    5. Value in knowing why something is needed or how a need is met.
    6. Defines implicit traceability and rich traceability.
    7. Review. Sufficient design? Necessary design?

End