IS2000 - Global analysis

Organisational factors

Organisational factor Flexibility and changeability Impact
O1: Management
O1.1: Build versus buy
There is a mild preference to build The organisation will consider buying if it is justified There is moderate impact on meeting the schedule
O1.2: Schedule versus functionality
Meeting schedule is preferable over delivering some features There is negotiability for several features There is a moderate impact on meeting the schedule and the first product release
O2: Staff skills
O2.1: Experience in building structured design
All in-house developers have these skills. n/a There is a small impact.
O2.2: Experience in object-oriented analysis and design
Half of the in-house developers have these skills It is feasible to hold training There is a moderate impact on achieving good design
O2.3: Experience in multi-threading
One in-house developer has this skill The subject area is too complex to rely on training There is a moderate impact on meeting performance
O2.4: Experience in building multi-purpose systems
Two in-house developers have this skill Training supplemented with software abstraction may alleviate lack of skills There is a large impact on meeting performance
O4: Development schedule
O4.1: Time to market
Time-to-market is 2 years There is no flexibility There is a large impact on design choices in all areas.
O4.2: Delivery of features
The features are prioritised These features are negotiable There is a moderate impact on meeting the schedule
O5: Development budget
O5.1: Head count
There are 12 developers We can hire 1 or 2 permanent or have a large number of contract developers There is a moderate impact on meeting schedule.

A study of these factor tables indicates:

  • There is no flexibility in time-to-market (Aggressive schedule)
  • Deficiency in skills in some areas (Skill deficiencies)

Technological factors

factors_tech.png
factors_tech2.png

Product factors

factors_prod.png

Issues / Strategies

  • Aggressive schedule (slides 29-30, lecture 3)
    • Solution: Reuse software, buy COTS components and release low-priority features at a later stage.
  • Skill deficiencies (slides 31-32, lecture 3)
    • Solution: Avoid the use of multi-threading and encapsulate multi-process facilities.
  • Changes in software technology (slide 40, lecture 3)
    • Solution: Use standards where possible, and develop internal standards for COTS components.
  • Easy addition and removal of features (slide 47, lecture 3)
    • Solution: Use the principle of separation of concerns to develop specific strategies to address particular problems with features and the UI.
  • Easy addition and removal of acquisition procedures and processing algorithms (slides 17-20, lecture 4)
    • Solution: Define domain-specific abstractions to facilitate the task of implementing acquisition and processing applications.
  • Real-time acquisition performance (slide 21, lecture 4)
    • Solution: Partition the system into separate components for algorithms, communication and control to provide the flexibility to implement different strategies.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License