Skip to main contentCal State San Bernardino
>> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [New Bibliographic Items] >> newb0519 [Blog/News] || [Purpose] || [Notation] || [Copyright] || [Site Search] || [Bibliography Search]
Thu May 19 18:41:48 PDT 2005

Contents


    IEEE Software Magazine Mar/Apr 2005

      Rost05

      1. Johan Rost
      2. What
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp96+94-95
      4. =ESSAY ONESIZE EDUCATION HEAVY vs LITE PROCESS
      5. Argues that the best practices that he teaches may be too heavy for many projects found outside the lab and classroom.

      BaudryEtal05

      1. Benoit Baudry & Franck Fleurey & Jean-Marfc Jezequel & Yves Le Traon
      2. Automatic Test Case Optimization: A Bacteriologic Algorithm
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp76-81
      4. =IDEA C# PARSER BUILDER VISITOR TESTING MUTATION EVOLUTION FITNESS
      5. Nice use of patterns in the sample Component Under Test (CUT) a C# parser.
      6. Need 30 generations to produce a set of tests that could kill all 500 mutants.

      LangFitzgerald05

      1. Michael Lang & Brian Fitzgerald
      2. Hypermedia Systems Development Practices: A Survey
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp68-75
      4. =POLL 167 IRISH PROCESS WEB/NET MEDIA REQUIREMENTS MANAGEMENT PEOPLE
      5. Mixture of people from software development and from graphic design. 41% people with equal background.
      6. 30% hit time targets and 47% hit cost target. However 17% had 50% timed over run, and 14% had a cost overrun.
      7. Most of the problems where minor or moderate rather than major.
      8. Project scope, feature creep, volatile and changing requirements tended to be more of a problem than estimation, time pressure, communication, or coordination.
      9. Most had a clear process and written requirements specification(mostly 10..50 pages).
      10. Wide range of methods including hybrid, custom, SSADM JSP, SDLC, RAD, XP, RUP plus tool focussed: PHP, Java, Flash, ASP, J2EE,UML. Pus FuseBox, WSDM, OOHDM, ...
      11. No evidence that academic research has produced methods for hypermedia/web that developers are using.

      Hohpe05

      1. Gregor Hohpe
      2. Your coffee shop doesn't use two-phase commit
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp64-66 & letter V22n3(May/Jun 2005)pp8-9
      4. =ARTICLE PATTERNS CONCURRENCY TRANSACTIONS ACID NONSEQUENTIAL
      5. 4 strategies: write-off, retry, compensate/undo, coordinate.
      6. Compare 1970s SSADM/Jackson recognition problems.
      7. Shorter version at [ 18-starbucks.html ]

      Hirsh05

      1. Barbara Hirsh
      2. Positive Reinforcement as a Quality Tool
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp62-63
      4. =EXPERIENCE CHANGE IMPROVEMENT QPM SQM CMM SQA V&V AUDIT
      5. After enterprise-wide training and several audited projects hold a competition for the "best X" where X is a desired change with meaningful prizes..
      6. In this case 30 submissions, 20% peer review.

      Gonzales05

      1. Regina Gonzales
      2. Developing the Requirements Discipline: software vs systems
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp59-61
      4. =HISTORY SYSTEMS ENGINEERING vs SOFTWARE ENGINEERING REQUIREMENTS
      5. Tendency to jump to solutions before understanding the problems.
      6. Systems engineers get the big picture(including people and politics) but don't understand software.
      7. Software engineers miss the big picture and focus on formalizable models.

      Krutchen05

      1. Philippe Krutchen
      2. Casting software design in the Function-Behavior-Structure framework
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp52-58
      4. =IDEA ENGINEERING Gero PROCESS WATERFALL RUP FBS
      5. FBS::= following
        Net
        1. F:set(function).
        2. S:structure.
        3. Be: set(behavior), expected.
        4. Bs: set(behavior), actual.
        5. D:description.
        6. formulation:F->Be.
        7. synthesis:Be->S.
        8. analysis:S->Bs.
        9. evaluation:(Be,Bs)->acceptability.
        10. documentation:S->D.
        11. structural formulation:S->S.
        12. behavioral formulation:S->Be.
        13. functional formulation:S->F.

        (End of Net)

      6. Author maps above into RUP.
      7. Software_engineering = SWEBOK.software_design+ requirements + coding + testing.
      8. Formulating the problem is part of engineering design.
      9. Lack of techniques for analyzing the behavior of structures, other than testing.
      10. A piece of software is less expensive to change than a bridge. Hence, software developers can afford more reformulation on the way to an acceptable product.
      11. Legacy systems: D to S to Be to F...
      12. COTS: F to Be to S.
      13. Patterns?
      14. SwEng words mean different things to other engineers.

      CaplatSourrouille05

      1. Guy Caplat & Jean-Louis Sourrouille
      2. Model Mapping Using Formalism Extensions
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp44-51
      4. =EXAMPLE THEORY METAMODEL TRANSLATION + EXTENSIONS MOF UML PROFILES MDA ARTO C++ PIM PSM CODE Sherlock Constraint Checker
      5. The real problem in MDA is mapping between formalisms/languages.
      6. Translating between different modeling formalisms is complicated because they have extensions.
      7. Extensions are needed because translations can not be made between formalisms.
      8. Extensions become UML profiles.
      9. Constraint Checker is a tool that tests if a model conforms to a profile and uses the language Sherlock.

      GarzasPiatini05

      1. Javier Garzas & Mario Piatini
      2. An Ontology for Microarchitectural Design Knowledge
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp28-33
      4. =IDEA ORGANIZE DESIGN KNOWLEDGE ONTOLOGY
      5. Distinguishes and relates rules: Principle, heuristic, best practice,bad smell, refactoring, and pattern.

      TyreeAkerman05

      1. Jeff Tyree & Art Akerman
      2. Architecture Decisions: Demystifying Architecture
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp19-27
      4. =EXAMPLE DOCUMENT DECISIONS DETAILS CHOICES ARCHITECTURE
      5. Gives a template: list of the data to record about decisions: Issue, Decision, Status, Group:{integration,presentation, data, ...}, assumptions, constraints, Positions(=options=alternatives), Argument,implications, related decisions,related requirements, related artifacts, related principles, notes,
      6. Proposes tabulating alternatives and evaluating them vs selection criteria.
      7. Describes how decisions fit together.
      8. Compare with [Larman04]

      SerranoCiordia05

      1. Nicolas Serrano & Ismael Ciordia
      2. Bugzilla, ITracker, and Other Bug Trackers
      3. IEEE Software Magazine V22n2(Mar/Apr 2005)pp11-13
      4. =SURVEY TOOLS PROJECT ISSUES MANAGEMENT
      5. Has pointer to site with 70 tools [ bugtrack.html ]

    . . . . . . . . . ( end of section IEEE Software Magazine Mar/Apr 2005) <<Contents | End>>

End