R E A D : E S S E N T I A L S C R U M : A P R A C T I C A L G U I D E T O T H E M O S T P O P U L A R A G I L E P R O C E S S. C H.

Transcription

1 R E A D : E S S E N T I A L S C R U M : A P R A C T I C A L G U I D E T O T H E M O S T P O P U L A R A G I L E P R O C E S S. C H. 5 S O F T W A R E E N G I N E E R I N G B Y S O M M E R V I L L E S E C T I O N S , ,

2 PRODUCT BACKLOG A sorted and prioritized list of user stories as currently perceived. User stories values is determined according to value, cost, knowledge, and risk) the high-value items appear at the top of the product backlog Product backlog vs. Sprint backlog

3 PRODUCT BACKLOG On new-product development the product backlog items initially are features required to meet the product owner s vision. For ongoing product development, the product backlog might also contain new features, changes to existing features, defects needing repair, technical improvements, and so on.

4 PRODUCT BACKLOG ITEMS (PBI) Are a placeholder for business value. Avoid detailing a user story ahead of time. Later and through a series of conversations among the stakeholders, product owner, and development team, refining them into a collection of smaller, more detailed PBIs user stories.

5 GROOMING Includes three principal activities: creating and refining (adding details to) PBIs estimating PBIs prioritizing PBIs. PBIs near the top of the backlog: small in size, and very detailed so that they can be worked on in a near-term sprint. PBIs towards the bottom of the backlog, larger in size, and less detailed.

6 SPRINT PLANNING AND BACKLOG During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve. Using this goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace a pace at which the development team can comfortably work for an extended period of time. spring planning (4-8 hours) Break each user story into a set of tasks.

7 TECHNICAL DEBT A trade off between: Rapid delivery and delayed commitment Increased time to delivery and product failure. Ward Cunningham: inventor of wiki and one of the Agile Manifesto signers.

8 USER STORIES Indicate the estimated size. Includes an estimate for the effort to implement the user story. Assign user story points to each card, a relative indication of how long it will take a pair of programmers to implement the story. The team then knows that if it currently takes them on average 2.5 hours per point; Indicate the priority. can easily maintain a stack of prioritized requirements by moving the cards around in the stack as appropriate. Can use a scale of one to ten with one being the highest priority. Other prioritization approaches are possible priorities of High/Medium/Low Optionally include a unique identifier. You need to maintain some sort of traceability between the user story and other artifacts, in particular acceptance tests.

9 TYPES OF NON-FUNCTIONAL REQUIREMENTS As a user I want the system to have % uptime.

10 NON-FUNCTIONAL REQUIREMENTS Quantifiable format is essential The system should be easy to use by medical staff and should be organized in such a way that user errors are minimized. VS. Medical staff shall be able to use all the system functions after four hours of training. After this training, the average number of errors made by experienced users shall not exceed two per hour of system use.

11 STUDENT PORTFOLIO: NON-FUNCTINOAL REQS Security The system shall require users to register using university s The system shall verify the user is a final year student via the university student database The system shall require users to create a password of medium to high strength The system shall require users to update their passwords every 30 days Speed The system shall retrieve and display portfolio summary in less than 0.5 second Paging, run multiple queries Quantify response time The system shall respond to search queries in less than 0.3 seconds Search : Tokenize description

12 NON-FUNCTIONAL REQUIREMENTS

13 NON-FUNCTIONAL REQUIREMENTS Non-functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non-functional requirements often apply to the system as a whole, rather than individual system features or services. In reality, the distinction between different types of requirement is not as clear-cut as these simple definitions suggest. A user requirement concerned with security, such as a statement limiting access to authorized users, may appear to be a nonfunctional requirement. However, when developed in more detail, this requirement may generate other requirements that are clearly functional, such as the need to include user authentication facilities in the system.

14 TYPES OF NON-FUNCTIONAL REQUIREMENTS

15 SYSTEM DEPENDABILITY Dependability covers the related systems attributes of reliability, availability and security. These are all inter-dependent. For many computer-based systems, the most important system property is the dependability of the system. The dependability of a system reflects the user s degree of trust in that system. It reflects the extent of the user s confidence that it will operate as users expect and that it will not fail in normal use. C H A P T E R 11 S E C U R I T Y A N D D E P E N D A B I L I T Y 15

16 PRINCIPAL PROPERTIES Availability The probability that the system will be up and running and able to deliver useful services to users. Reliability The probability that the system will correctly deliver services as expected by users. Safety A judgment of how likely it is that the system will cause damage to people or its environment. Security A judgment of how likely it is that the system can resist accidental or deliberate intrusions. C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 16

17 DEPENDABILITY ECONOMICS Dependability costs tend to increase exponentially as increasing levels of dependability are required. There are two reasons for this The use of more expensive development techniques and hardware that are required to achieve the higher levels of dependability. The increased testing and system validation that is required to convince the system client and regulators that the required levels of dependability have been achieved. C H A P T E R 11 S E C U R I T Y A N D D E P E N D A B I L I T Y 17

18 AVAILABILITY Measure of the fraction of the time that the system is available for use. Takes repair and restart time into account Availability of means software is available for 998 out of 1000 time units. Relevant for non-stop, continuously running systems telephone switching systems, railway signalling systems. C H A P T E R 12 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 18

19 AVAILABILITY SPECIFICATION Availability Explanation 0.9 The system is available for 90% of the time. This means that, in a 24-hour period (1,440 minutes), the system will be unavailable for 144 minutes In a 24-hour period, the system is unavailable for 14.4 minutes The system is unavailable for 84 seconds in a 24-hour period The system is unavailable for 8.4 seconds in a 24-hour period. Roughly, one minute per week. C H A P T E R 12 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 19

20 AVAILABILITY AND RELIABILITY Reliability The probability of failure-free system operation over a specified time in a given environment for a given purpose Availability The probability that a system, at a point in time, will be operational and able to deliver the requested services Both of these attributes can be expressed quantitatively e.g. availability of means that the system is up and running for 99.9% of the time. C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 20

21 FAILURE TERMINOLOGY Term Human error or mistake System fault System error System failure Description Human behavior that results in the introduction of faults into a system. For example, in the wilderness weather system, a programmer might decide that the way to compute the time for the next transmission is to add 1 hour to the current time. This works except when the transmission time is between and midnight (midnight is in the 24-hour clock). A characteristic of a software system that can lead to a system error. The fault is the inclusion of the code to add 1 hour to the time of the last transmission, without a check if the time is greater than or equal to An erroneous system state that can lead to system behavior that is unexpected by system users. The value of transmission time is set incorrectly (to 24.XX rather than 00.XX) when the faulty code is executed. An event that occurs at some point in time when the system does not deliver a service as expected by its users. No weather data is transmitted because the time is invalid. C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 21

22 FAULTS AND FAILURES Failures are a usually a result of system errors that are derived from faults in the system However, faults do not necessarily result in system errors The erroneous system state resulting from the fault may be transient and corrected before an error arises. The faulty code may never be executed. Errors do not necessarily lead to system failures The error can be corrected by built-in error detection and recovery The failure can be protected against by built-in protection facilities. These may, for example, protect system resources from system errors C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 22

23 PERCEPTIONS OF RELIABILITY The formal definition of reliability does not always reflect the user s perception of a system s reliability The assumptions that are made about the environment where a system will be used may be incorrect Usage of a system in an office environment is likely to be quite different from usage of the same system in a university environment The consequences of system failures affects the perception of reliability Unreliable windscreen wipers in a car may be irrelevant in a dry climate Failures that have serious consequences (such as an engine breakdown in a car) are given greater weight by users than failures that are inconvenient C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 23

24 RELIABILITY METRICS Reliability metrics are units of measurement of system reliability. System reliability is measured by counting the number of operational failures and, where appropriate, relating these to the demands made on the system and the time that the system has been operational. A long-term measurement programme is required to assess the reliability of critical systems. Metrics Probability of failure on demand Rate of occurrence of failures/mean time to failure Availability C H A P T E R 1 2 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 24

25 PROBABILITY OF FAILURE ON DEMAND (POFOD) This is the probability that the system will fail when a service request is made. Useful when demands for service are intermittent and relatively infrequent. Appropriate for protection systems where services are demanded occasionally and where there are serious consequence if the service is not delivered. Relevant for many safety-critical systems with exception management components Emergency shutdown system in a chemical plant. C H A P T E R 1 2 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 25

26 RATE OF FAULT OCCURRENCE (ROCOF) Reflects the rate of occurrence of failure in the system. ROCOF of means 2 failures are likely in each 1000 operational time units e.g. 2 failures per 1000 hours of operation. Relevant for systems where the system has to process a large number of similar requests in a short time Credit card processing system, airline booking system. Reciprocal of ROCOF is Mean time to Failure (MTTF) Relevant for systems with long transactions i.e. where system processing takes a long time (e.g. CAD systems). MTTF should be longer than expected transaction length. C H A P T E R 1 2 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 26

27 SECURITY The security of a system is a system property that reflects the system s ability to protect itself from accidental or deliberate external attack. Security is essential as most systems are networked so that external access to the system through the Internet is possible. Security is an essential pre-requisite for availability, reliability and safety. C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 27

28 SECURITY TERMINOLOGY Term Asset Exposure Vulnerability Attack Threats Control Definition Something of value which has to be protected. The asset may be the software system itself or data used by that system. Possible loss or harm to a computing system. This can be loss or damage to data, or can be a loss of time and effort if recovery is necessary after a security breach. A weakness in a computer-based system that may be exploited to cause loss or harm. An exploitation of a system s vulnerability. Generally, this is from outside the system and is a deliberate attempt to cause some damage. Circumstances that have potential to cause loss or harm. You can think of these as a system vulnerability that is subjected to an attack. A protective measure that reduces a system s vulnerability. Encryption is an example of a control that reduces a vulnerability of a weak access control system C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 28

29 SECURITY RISK ASSESSMENT Asset identification Identify the key system assets (or services) that have to be protected. Asset value assessment Estimate the value of the identified assets. Exposure assessment Assess the potential losses associated with each asset. Threat identification Identify the most probable threats to the system assets C H A P T E R 1 2 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 29

30 SECURITY REQUIREMENTS Patient information must be downloaded at the start of a clinic session to a secure area on the system client that is used by clinical staff. Patient information must not be maintained on system clients after a clinic session has finished. A log on a separate computer from the database server must be maintained of all changes made to the system database. C H A P T E R 1 4 S E C U R I T Y E N G I N E E R I N G 30

31 THREAT CLASSES Threats to the confidentiality of the system and its data Can disclose information to people or programs that do not have authorization to access that information. leaks Threats to the integrity of the system and its data Can damage or corrupt the software or its data. Defacement - record manipulation Threats to the availability of the system and its data Can restrict access to the system and data for authorized users. Denial of service attacks C H A P T E R 1 1 S E C U R I T Y A N D D E P E N D A B I L I T Y 31

32 SECURITY REQUIREMENTS A password checker shall be made available and shall be run daily. Weak passwords shall be reported to system administrators. Access to the system shall only be allowed by approved client computers. All client computers shall have a single, approved web browser installed by system administrators. C H A P T E R 1 4 S E C U R I T Y E N G I N E E R I N G 32

33 TYPES OF SECURITY REQUIREMENT Identification requirements. Authentication requirements. Authorisation requirements. Immunity requirements. Integrity requirements. Intrusion detection requirements. Privacy requirements. Security auditing requirements. System maintenance security requirements. C H A P T E R 1 2 D E P E N D A B I L I T Y A N D S E C U R I T Y S P E C I F I C A T I O N 33