Skip to main contentCal State San Bernardino
>> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [New Bibliographic Items] >> newb0128 [Blog/News] || [Purpose] || [Notation] || [Copyright] || [Site Search] || [Bibliography Search]
Fri Jan 28 12:13:28 PST 2005

Contents


    Markus83

    1. M Lynne Markus
    2. Power, Politics, and MIS Implementation
    3. Commun ACM V26n6(Jun 1983)pp430-444 & [MyersAvisson02] Chapter 3, pp19-48
    4. =EXPERIENCE PEOPLE SYSTEMS RESISTANCE POLITICS ORGANIZATION MANAGEMENT FIS
    5. In this case People resisted a new system not just because it wasn't good enough, or because they were not trained etc, but because the new Financial Information System was a ploy to change the organization.
    6. New FIS system tended to move data and power toward a centralized system and away from divisional centers. Divisions fought the system.
    7. Sometimes it is better to change the organization first and then change the technological systems in use.

    MyersAvisson02

    1. Michael D Myers & David Avison
    2. Qualitive Research in Information Systems: A Reader
    3. SAGE Publications Thousand Oaks CA 2002 T58.64 Q35 ISBN 0-7619-6632-3
    4. =READER PEOPLE SYSTEMS
    5. Includes: [Markus83]

    Chandrasekaran97

    1. Periannan Chandrasekaran
    2. How use case modeling policies have affected the success of various projects (or how to improve use case modeling)
    3. OOPSLA'97 & ACM SIGPLAN notices V??n?(??? 1997)pp6-9 [ 274567.274569 ]
    4. =ANECDOTE USE CASE REQUIREMENTS OOSE Jacobson
    5. Tells conclusion from several large projects that used OOSE.
    6. Problems
      1. need details of all changes in system as use case proceeds
      2. Need comprehensive list of use cases involving users, a comprehensive and clean model of the human actors, and robust domain model.
      3. Include algorithms(business rules?) as regular requirements
      4. Use cases must capture all interfaces with external systems even if not human.
      5. The GUI is not the use case. One screen can trigger different use cases that are independent of each other.
      6. Keep the use case and domain model synchronized. Common well defined terminology.
      7. Use abstract use cases for algorithms.

    7. An abstract use case is one that is not initiated by an actor and contains common steps abstracted from other use cases. Example: calculate discounts on sale.
    8. Notes that people expressed common algorithms and procedures as "business rules" (possibly in an attempt to fit them to SQL and AI style Rule Engines). Claims they should be expressed as (abstract) use cases.
    9. (dick) |- may be better to restrict business rules to invariants only??

    Lindvall04

    1. Mikael Lindvall & Dirk Muthig &Aldo Dagnino& Christina Wallin & Michael Stupperich & David Kiefer & John May & Tuomo Kahkonen
    2. Agile Software Development in large organizations
    3. IEEE Computer Magazine V37n12(Dec 2004)pp26-3
    4. =POLL AGILE TECHNICAL PROCESS ONE SIZE XP ABB DaimlerChrysler Motorola Nokia
    5. Reports on meetings where several pilot XP projects were discussed
    6. XP adopted in large organizations for the same business reasons as small ones: need to increase productivity without losing quality . Problems with specifications becoming obsolete before project finished.
    7. XP always needed customization.
    8. It produced good or better software more quickly. Changes were handled faster. Morale was better.
    9. But XP doesn't fit well with existing practices in large organizations and so has to be tailored.
    10. Make it look like a CMM process.
    11. Change control boards do not work well with refactoring, continuous integration,
    12. Problems when XP team is not in one place.
    13. Problems with interfaces between XP team and Traditional team.
    14. Architecture is important.
    15. Clash between up-front top-down planning and XP planning game.
    16. Requirements were already inaccurate when XP started and were not user stories.
    17. Continuous testing vs an added round of acceptance tests done by a different team.
    18. XP pairing vs formal reviews for SQA.
    19. Management and QC want the old documentation and XP doesn't do documentation.
    20. (dick) |- write a user story for each required piece of documentation and do the planning game on it. "That will take us 2 days work, ..."

    MyersBANicholsWobbrockMiller04

    1. Brad A Myers & Jeffrey Nichols & Jacob O Wobbrock & Robert C Miller
    2. What
    3. IEEE Computer Magazine V37n12(Dec 2004)pp36-43
    4. =DEMO TOOLS HANDHELD PC INTEGRATION WIRELESS PDA CELL PHONE PalmOS
    5. SlideShowCommander::tool.
    6. PUC::protocol="Personal Universal Controller", allowing any device to be controlled from a handheld.
    7. ShortCutter::tool="device independent design of controller interfaces"
    8. People use both PC mouse and handheld together to do things.

    Colwell04b

    1. Bob Colwell
    2. Interface Quotas and Internet-Derived Value
    3. IEEE Computer Magazine V37n12(Dec 2004)pp10-11
    4. =ESSAY USER SAFETY SIMPLICITY WEB/NET
    5. Keep user interfaces similar to old & thouqht-free.
    6. Use internet to simplify & unify user interfaces.

    Rost04

    1. Johann Rost
    2. Political Reasons for failed software Projects
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp104+102-103
    4. =CASE SABOTAGE SUBVERSION PEOPLE STAKEHOLDERS

    SerranoCiordia04

    1. Nicolas Serrano & Ismael Ciordia
    2. Ant: Automating the process of Building Applications
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp89-91
    4. =ADVERT OPEN SOURCE TOOL Ant Apache Java XML
    5. Ant::acronym="Another neat tool", use XML to carry out routine tasks based on build.xml files and executes tasks as Java classes. [ http://ant.apache.org ]

    Jackson04

    1. Michael A Jackson
    2. Seeing More of the World
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp83-85
    4. =ESSAY REALITY REQUIREMENTS
    5. Requirements are about the problem world which interacts with the machine at the machine-world interface. Outer requirements describe the effects the stakeholders would like to experience in the problem world. Inner Requirements specify how the machine should behave at the machine-world interface to ensure the whole satisfies the outer requirements.
    6. Stakeholders needs are nearly always met by a causal chain problem-wold properties separating inner from outer.
    7. Sequence: outer; problem-world properties; inner.
    8. How to find some faults before they emerge as failures in use. Some questions to ask:
      • What if a use-case is abandoned in mid-execution?
      • How do use-cases fit together in sequences?
      • Consider any object's attribute, what happens if the real world attribute changes?
      • Take any actor, what other things might it do/might happen to it (eg die) and what should the machine do about it?
      • Start from an output, trace the chain of problem world events, what might happen? What might go wrong? What if things get delayed(crossed letters!)?

    DrobkaNoftzRaghu04

    1. Jerry Drobka & David Noftz & Rekha Raghu
    2. Piloting XP on four mission-critical projects
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp70-75
    4. =EXPERIENCE XP AGILE 4 Motorola Projects
    5. Gained a minimum of 260% productivity vs waterfall (incremental was 162%) with 70-90% test coverage, and with a 51..75% improvement in quality (defects at system test/KAELOC)
    6. High morale and confidence, training easier.
    7. Challenges: fitting with non-XP projects and managers. Need thorough training and coaching.
    8. Did an initial "blitz" software architecture rather like Unified Process.

    MadanmohanDe'04

    1. T R Madanmohan & Rahul De'
    2. Open Source Reuse in Commercial Firms
    3. IEEE Software Magazine V21n6(Nov /Dec 2004)pp62-69
    4. =POLL 13 projects OPEN SOURCE REUSE COMPONENTS BSD Apache MySQL SSH
    5. Selecting components is not easy.
    6. The License rules play an important part in the selection process, as does the activity of the community that supports the source code.
    7. Some components require other unusual components that make the package less appealing. Similarly, the documentation of interfaces lag behind implementations making some products less reusable.

End