Issay - longtest- finals

stage in the software engineering process at which an executable software system is developed.

concerned with understanding how a software system should be organized and designing overall structure of that system

Non-functional requirements of the system

Non-functional requirements of the system: architecture should be designed to localize critical operations within small number of components

Non-functional requirements of the system: a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers

Non-functional requirements of the system: architecture should be designed using fine-grain, self-contained components readily be changed.

Non-functional requirements of the system: architecture should be designed so that safety-related operations are co-located in a single component

Non-functional requirements of the system: architecture should be designed to include redundant components

Non-functional requirements of the system

ARCHITECTURAL VIEWS

ARCHITECTURAL VIEWS: shows the key abstractions in the system as objects or object classes.

Architectural view: shows the system hardware and how software components are distributed across the processors

ARCHITECTURAL VIEWS: shows how, at runtime, the system is composed of interacting processes.

ARCHITECTURAL VIEWS: - shows how the software is decomposed for development

ARCHITECTURAL VIEWS

Separates presentation and interaction from the system data.

layered approach supports incremental development of systems.

The majority of systems that use large amounts of data are organized around a shared database or repository.

illustrates a commonly used runtime organization for distributed systems.

Application systems are intended to meet a business or an organizational need.

designed to process user requests for information from a database, or requests to update a database.

All systems that involve interaction with a shared database

translate one language into an alternative representation of that language and, for programming languages, may also execute the resulting code.

made up of interacting objects that maintain their own local state and provide operations on that state.

By this stage in the design process, you should have some ideas about the essential objects in the system that you are designing.

involve developing programs in high- or low-level programming languages.

Aspects of implementation

Aspects of implementation: Production software does not usually execute on the same computer as the software development environment.

-Aspects of implementation: Most modern software is constructed by reusing existing components or systems.

Aspects of implementation: During the development process, many different versions of each software component are created

Aspects of implementation

Fundamental principle of open-source development is that source code should be freely available, this does not mean that anyone can do as they wish with that code.

intended to show that a program does what it is intended to do and to discover program defects before it is put into use.

all testing activities that are carried out.

3 stages of development testing

3 stages of development testing: process of testing program components, such as methods or object classes.

3 stages of development testing: where components integrated and the system is tested as a whole.

3 stages of development testing: where several individual units integrated to create composite components.

3 stages of development testing

process of testing a particular release of a system that is intended for use outside of the development team.

-3 types of user testing

3 types of user testing: larger group allow to experiment and raise problems they discover

3 types of user testing: selected group test early releases of the software.

3 types of user testing: customers test to decide whether or not it is ready

3 types of user testing

As computer systems have become deeply embedded in our business and personal lives, the problems that result from system and software failure are increasing.

Reason of Dependability of systems more important:

Reason of Dependability of systems more important:may cause information loss Data is very expensive to collect and maintain

Reason of Dependability of systems more important: that are unreliable, unsafe, or insecure

Reason of Dependability of systems more important: affect large number of people Many systems include functionality that is rarely used.

Reason of Dependability of systems more important:may be enormous For some applications, such as a reactor control system or an aircraft navigation system, the cost of system failure is orders of magnitude greater than the cost of the control system.

Reason of Dependability of systems more important:

Designing a dependable system to consider:

Designing a dependable system to consider :because of mistakes in its design, because of environmental factors; dampness or high temperatures

Designing a dependable system to consider: Human users may fail to use or operate the system as intended by its designers.

Designing a dependable system to consider: because of mistakes in its specification, design, or implementation.

Designing a dependable system to consider:

The dependability of a computer system is a property of the system that reflects its trustworthiness.

Fault–error–failure model (Brian Randell) defined;

Fault–error–failure model (Brian Randell) defined; characteristic of a software system that can lead to a system error.

Fault–error–failure model (Brian Randell) defined; event occurs at some point when system does not deliver service as expected by users.

Fault–error–failure model (Brian Randell) defined;Human behavior that results faults into system.

Fault–error–failure model (Brian Randell) defined;erroneous system state during execution that lead to system behavior that is unexpected by system users

Fault–error–failure model (Brian Randell) defined;

2 types of Dependability Requirements

---2 types of Dependability Requirements: Define checking and recovery facilities thatshould be included in the system and features that provide protection against system failures and external attacks.

---2 types of Dependability Requirements---- Define the required reliability and availability of the system.

4 types of functional reliability requirement

---4 types of functional reliability requirements--- geared to helping the system recover after a failure has occurred.

---4 types of functional reliability requirements---fault-avoidance requirements, which ensure that good practice is used in the development process.

---4 types of functional reliability requirements--- identify checks on inputs to system to ensure that incorrect or out-of-range inputs are detected before processed by system.

---4 types of functional reliability requirements--- specify redundant features of the system ensure that single component failure not lead to a complete loss of service.

---4 types of functional reliability requirements---

Systems in which it is essential that system operation is always safe.

4 activities in a hazard-driven safety specification process:

4 activities in a hazard-driven safety specification process: focuses on understanding factors lead to occurrence of hazard and consequences if incident associated with that hazard should occur.

4 activities in a hazard-driven safety specification process: identifies hazards that may threaten the system.

4 activities in a hazard-driven safety specification process: This process is based on the outcome of hazard analysis and leads to identification of safety requirements.

4 activities in a hazard-driven safety specification process: -root-cause analysis that identifies the events lead to occurrence of hazard.

3 risk categories that are used in hazard assessment

----3 risk categories that are used in hazard assessment---
those that have less serious consequences or that are serious but have a very low probability of occurrence.

----3 risk categories that are used in hazard assessment---\ those that threaten human life.

----3 risk categories that are used in hazard assessment---
those associated accidents normally result in minor damage.

----3 risk categories that are used in hazard assessment---\

---Software failures lead to an incorrect dose of insulin, “solutions” might be developed---

---Software failures lead to an incorrect dose of insulin, “solutions” might be developed--- there is no clear program exception that must be handled.

---Software failures lead to an incorrect dose of insulin, “solutions” might be developed--- occur when an arithmetic computation causes a representation failure.

set of activities that check that a system will operate safely.

Formally verifying programs using a deductive approach is difficult and expensive, but alternative approaches to formal analysis have been developed that are based on a more restricted notion of correctness.

set of documents that includes a description of the system to be certified

The widespread adoption of the Internet in the 1990s introduced a new challenge for software engineers—designing and implementing systems that were secure.

---3 security dimensions---

---3 security dimensions---Access to a system or its data that is normally available may not be possible.

---3 security dimensions--Information in a system may be disclosed or made accessible to people or programs that are not authorized to have access to that information.

---3 security dimensions---may be damaged or corrupted, making it unusual or unreliable.

3 security dimensions

3 level of security

3 level of security: concerned with the secure operation and use of the organization’s systems

3 level of security: concerned with maintaining the security of all systems and networks that provide an infrastructure and a set of shared services to the organization.

3 level of security: concerned with the security of individual application systems or related groups of systems.

3 level of security

system attribute that reflects the ability of the system to protect itself from malicious internal or external attacks.

---The controls that you might put in place to enhance system security are based on the fundamental notions of avoidance, detection, and recovery----

Controls that support recovery from problems.

Controls that are intended to detect and repel attacks.

Controls that are intended to ensure that attacks are unsuccessful.

Building secure systems is expensive and uncertain. It is impossible to predict costs of security failure, so companies find it difficult to judge how much should spend on system security

Organizational activities focus on identifying and understanding risks to information assets (systems and data) in organization.

---3 stages of risk assessment---

---3 stages of risk assessment---during development life cycle and is informed by the technical system design and implementation decisions.

---3 stages of risk assessment--- to identify generic risks that are applicable to system

---3 stages of risk assessment---focuses on use of system and possible risks that can arise.

---3 stages of risk assessment---

The specification of security requirements for systems has much in common with the specification of safety requirements. You cannot specify safety or security requirements as probabilities.

System designers have to find a balance between security, performance, and usability

Secure system design means designing security into an application system.

impossible to avoid system failures and so is concerned with limiting the costs of these failures and recovering from them.

---3 Concepts fundamental to resilience planning---

---3 Concepts fundamental to resilience planning---circumstances can cause harm by damaging or stealing organizational IT infrastructure or system assets.

---3 Concepts fundamental to resilience planning--- systems and data that have to be protected.

---3 Concepts fundamental to resilience planning---manifestations of threat where attacker aims to damage or steal websites or personal data.

---3 Concepts fundamental to resilience planning---

can resist and recover from adverse incidents such as software failures and cyberattacks.

---Examples of controls that may be used ---

---Examples of controls that may be used ---where incoming network packets are examined, then accepted or rejected according to a set of organizational rules.

---Examples of controls that may be used --- where data is algorithmically scrambled

---Examples of controls that may be used --- users of system have to show that they are authorized to access the system.

---Examples of controls that may be used ---