21 March 2016M253 Team working in distributed environments 1

21 March 2016M253 Team working in distributed environments 2 Introduction We will discuss  The System approach  Project planning and Scheduling  Specifying requirements

21 March 2016M253 Team working in distributed environments 3 The System approach To identify a problem and find potential solutions for it, you need to focus initially on  what the system will do.

21 March 2016M253 Team working in distributed environments 4 The System approach …continued What is a system? A system is a bounded entity which, in its environment, achieves a definite objective through the interaction of its component parts’. A system has a boundary A conceptual line drawn a round the system to clarify what is inside it and outside it. The functional boundary divide between what the system can and cannot do.

21 March 2016M253 Team working in distributed environments 5 The System approach …continued  A system has an environment The something which is outside the boundary is the environment. A system and its environment interact but a system may be affected by events occurring in its environment, the environment is not affected by events occurring in the system.

21 March 2016M253 Team working in distributed environments 6 The System approach …continued  A system has components -(subsystems) -To handle the situation, we can group elements that appear related together physically or logically to deal with it as a subsystem

21 March 2016M253 Team working in distributed environments 7 The System approach …continued

21 March 2016M253 Team working in distributed environments 8 The System approach …continued

21 March 2016M253 Team working in distributed environments 9 The System approach …continued

21 March 2016M253 Team working in distributed environments 10 The System approach …continued  A system has interface The existence of a boundary and a surrounding environment imply that there must be a set of rules for how a system interacts (communicates) with the environment in which it operates.

21 March 2016M253 Team working in distributed environments 11 The System approach …continued  A system has structure -There is a whole hierarchical structure of subsystems within a given system. -The characteristic of a system that can be divided into subsystems. It functions as a whole in order to achieve its objectives.

21 March 2016M253 Team working in distributed environments 12 The System approach …continued  A system has synergy holistic behavior: the way in which the combined subsystems behave as a whole.  A system has a purpose (objective) the system has a purpose, a reason for its existence, a set of defined objectives. An example of a system human body

21 March 2016M253 Team working in distributed environments 13 The System approach …continued  Checkland's defined soft systems by contrast with the ‘hard’ systems: traditionally handled by industrial design engineers as those in which ‘objectives are hard to define, decision taking is uncertain, measures of performance are at best qualitative and human behavior is irrational’

21 March 2016M253 Team working in distributed environments 14 The System approach …continued  Checkland's Soft Systems approach Checkland's view was ’problem solving is dependent on problem structuring’. The initial phases of Checkland's methodology investigate the problem situation by using rich pictures, are employed in order to capture important aspects of the structure, processes and concerns that have been identified in these initial investigations.

21 March 2016M253 Team working in distributed environments 15 The System approach …continued –mnemonic CATWOE is used, where the letters each represent an important aspect of the system that has to be considered: C Client A Actors T Transformation W World view O Owner E Environment

21 March 2016M253 Team working in distributed environments 16 The System approach …continued  Questions to ask Who is your system for? Who are the actors? What are their roles? How do they perceive the system? What does your system have to do? You need to clarify the purposes/goals/functionality of the system. What is the problem that the system is required to solve?. Using the KISS principle: ‘keep it simple, sunshine’.

21 March 2016M253 Team working in distributed environments 17 Project planning and scheduling Project planning for simple projects involves three main steps. 1) identify the tasks (for which the technique called work breakdown structure is best); 2) determine the duration of each task and then determine their order, which can most easily be done using a graphical networking technique; 3) identify the critical path and then use its total duration to plan either beginning at a starting time or at the completion date.

21 March 2016M253 Team working in distributed environments 18 Project planning and scheduling…continued

21 March 2016M253 Team working in distributed environments 19 Project planning and scheduling…continued

21 March 2016M253 Team working in distributed environments 20 Project planning and scheduling…continued (Note that the letter I has not been used as an identifier: this is because it, and the letter O, are easily confused with numerals.)

21 March 2016M253 Team working in distributed environments 21 Project planning and scheduling…continued Determining order: which tasks to do before others

21 March 2016M253 Team working in distributed environments 22 Project planning and scheduling…continued There are some simple rules-of-thumb that can aid the planner in setting out the network. Any task that has no predecessor tasks is a candidate for the first task in the network. If there is no clear candidate for this because there are several such tasks, create a ‘dummy’ task, such as ‘start project’ with a duration of zero time, to form a neat chart with a single beginning point. Any task that has no successor tasks is a candidate for the last task in the network. If there is more than one candidate task, create a ‘dummy’ task, such as ‘end project’ with a duration of zero time, to form a single ending point.

21 March 2016M253 Team working in distributed environments 23 Project planning and scheduling…continued

21 March 2016M253 Team working in distributed environments 24 Project planning and scheduling…continued

21 March 2016M253 Team working in distributed environments 25 Project planning and scheduling…continued  Exercise Calculate the total duration in days for the project of refurbishing and redecorating the hospital ward based on Figures 2 and 4 above. The sequence of tasks dictating the overall time required for this project is B to C to D to F to G to H to K to L. Adding up the durations for those arrows yields: = 18 days.

21 March 2016M253 Team working in distributed environments 26 Project planning and scheduling…continued  Backwards: When a pre-determined completion date forms a constraint on a project, then planning dates by which tasks must start is very similar to finding the completion date except that the planner works.  Critical path analysis technique that involves analyzing the identified tasks, each of whose earliest and latest times are estimated, determining all the relationships between tasks in terms of their precedence to produce a graphical representation of the project as a network.

21 March 2016M253 Team working in distributed environments 27 Project planning and scheduling…continued Three reasons for underestimating the time required for tasks: The people carrying out the work may not be familiar with the task and thus have little basis on which to judge accurately how long something might take. Even experienced people can forget to take into account unexpected events, the fact that things can go wrong and may need to be re- done, or that other work may take priority over the task in hand. People often fail to take account of the complexity of project work, particularly where several people are trying to work together.

21 March 2016M253 Team working in distributed environments 28 Specifying requirements  Requirements analysis: is the name given to the process of attempting to produce a complete, unambiguous, consistent, precise, verifiable, and implementation, independent description of the proposed system, which is readable, modifiable and well-organized for reference and review.

21 March 2016M253 Team working in distributed environments 29 Specifying requirements…continued  A software requirement is: a software capability that must be met or possessed by a system or system component to satisfy a contract, standard, or other formally imposed documentation

21 March 2016M253 Team working in distributed environments 30 Specifying requirements…continued Categories of requirements  Functional requirements They describe what the inputs are, what the outputs are, what transforms are necessary in order to convert specified inputs to specified outputs in specified circumstances. In a library information system ‘the user should be able to search for books based on title, author or ISBN’.

21 March 2016M253 Team working in distributed environments 31 Specifying requirements…continued  Design constraints cover restrictions on the design of a system that need to be fulfilled in order to meet external technical, business or contractual obligations. Example: the system is to be designed for access by blind users and that there is a requirement ‘that the information on the user interface screens must be readable by a particular screen- reading tool’

21 March 2016M253 Team working in distributed environments 32 Specifying requirements…continued  Non-functional requirements They are aspects of the overall quality of the system. A simple example as a system security requirement that ‘all data shall be protected from unauthorized access’.  User interface requirements systems that involve a significant amount of user interaction.

21 March 2016M253 Team working in distributed environments 33 Specifying requirements…continued  How do we document requirements? It should be equally meaningful to the customers, the project managers, the software designers and coders, and the system testers and maintainers. It acts as a source of reference and possibly even as the basis for any development contract. It can be named as requirements definition, a functional specification or a software requirements specification.

21 March 2016M253 Team working in distributed environments 34 Specifying requirements…continued classic IEEE/ANSI standard which suggests the following contents and structure:

21 March 2016M253 Team working in distributed environments 35 Specifying requirements…continued Prioritizing requirements  the MoSCoW rule:  Must have applies the fundamental requirements to the system without which it would effectively be inoperable.  Should have mandatory requirements would still be usable and useful in the system.

Specifying requirements…continued  Could have valuable requirements but are only to be included if time and money allows them to be.  Won't have applies to other requirements identified as potentially valuable enhancements to the system at some later date. 21 March 2016M253 Team working in distributed environments 36

21 March 2016M253 Team working in distributed environments 37 Summary  The System approach A system is a bounded entity which, in its environment, achieves a definite objective through the interaction of its component parts’.  Project planning and Scheduling Project planning for simple projects involves three main steps.  Specifying requirements Prioritizing requirements (the MoSCoW rule) Read The resource sheets carefully Good luck and Have fun