1. Event-B
: a formal language for writing a high-level specification of computer systems (derived from requirements)
- includes logic and set theory
- used in safety-critical applications
http://www.event-b.org/
2. Set Expression
- a set is a collection of elements
- may be finite or infinite
- For element x and set S, we express the membership relation: x ∈ S
- The cardinality of a finite set is the number of elements in that set: card(S)
- A set S is said to be subset of set T when every element of S is also an element of T: S ⊆ T
- Union of S and T: S ∪ T
- Intersection of S and T: S ∩ T
- Difference of S and T: S ⧵ T
3. Event-B structure
- B context
* Sets: abstract types used in specification
* Constants: logical variables whose value remain constant
* Axioms: constraints on the constants
- B machine
* Variables: state variables whose values can change
* Invariants: constraints on the variables that should always hold true
* Initialisation: initial values for the abstract variables
* Events: guarded actions specifying ways in which the variables can change
4. Types
: all variables and expressions in B must have a type
- Predefined Types: Ζ Integers / Β Booleans / Ν all-non-negative integers
- Basic Types
set Word Name
- Powersets: the powerset of a set S is the set whose elements are all subsets of S: Ρ(S)
5. Predicate Logic
- Negation: ￢ P
- Conjunction: P ∧ Q
- Disjunction: P ∨ Q
- Implication: P ⇒ Q
- Universal Quantification: ∀x ·P
- Existential Quantification: ∃x ·P
6. Relations and Functions
- Ordered pair (an element consisting of two parts): x |-> y
- Cartesian product (the set of pairs whose first parts is in S and second parts is in T): S × T
- Relations (a set of ordered pair): S ↔ T = Ρ(S × T)
- The domain of a relation R (the set of first parts of all the pairs in R): dom(R)
- The range of a relation R (the set of second parts of all the pairs in R): ran(R)
- The relational image of set A under relation R: R[A]
- Partial Functions (each domain element has at most one range element): f ∈ X +-> Y
* f is a many-to-one relation
- Domain Restriction (only contains pairs whose first part is in the set A): A <| R
- Domain Substraction (remove those pairs from R whose first part is in A): A <<| R
- Range Restriction: R |> B
- Range Substraction: R |>> B
- Functional Overriding (replace existing mappings with new ones): f <+ g
- Total Function (every domain element has range elements): f ∈ X -> Y
- Relational Inverse: R^-1
- Relational Composition: Q;R
- Injective Function (one-to-one function): f ∈ X >+> Y
- Total Injective Function: f ∈ X >-> Y
- Surjective Function (onto function): f ∈ X +->> Y
- Total Surjective Function: f ∈ X -->> Y
- Bijective Function: f ∈ X >->> Y
http://wiki.event-b.org/images/EventB-Summary.pdf
7. Extension Refinement
: a process of enriching or modifying a model in order to augment the functionality being modelled or explain how some purpose is achieved
- context c1 -(extends)-> context c2
- machine m1 -(refines)-> machine m2
=> add additional variables and invariants
=> extend existing events to act on additional variables
=> add new events to act additional variables
8. Proof-based verification
- Proof Obligations: mathematical theorems derived from a formal model (or programme)
=> a sequence of the form Hypotheses |- Goal
=> we should prove the goal while assuming that the hypotheses are true
- mathematical operators and rules validity of a PO could be derived from deductive rules of logic and set theory
* Well-definedness (WD)
e.g. avoid division by zero, partial function application
* Invariants preservation (INV): each event maintains invariants
* Guard strengthening (GRD): refined event only possible when abstract event possible
* Simulation (SIM): update of abstract variable correctly simulated by update of concrete variable
http://www.computing.dcu.ie/~hamilton/teaching/CA648/sld_po.pdf
2017년 1월 28일 토요일
Software Testing
1. Testing
: the process of evaluating a system or its components(s)
- An early start to testing reduces the cost, time
- Debugging: it involves identifying, isolating and fixing the problems/bugs
! the part of White box or Unit Testing
- Different types of testing
* Manual testing
* Automation testing (Test Automation): uses another software to test the software
http://istqbexamcertification.com/what-is-a-software-testing/
2. Different Methods of Software Testing
http://www.careerride.com/Testing-white-box-black-box-gray-box.aspx
3. Different Levels of Testing
- Functional Testing: to evaluate the system's compliance with its specified requirements
1) Unit testing: to isolate each part of the programme and show that individual parts are correct in terms of requirements and functionality
2) Integration testing: to test combined parts of an application to determine if they function correctly together
3) System testing: to test the system as a whole
* enables us to test, verify and validate both the business requirements as well as the Applications Architecture
4) Regression testing: to verify that a fixed bug hasn't resulted in another functionality or business rule violation
5) User Acceptance testing: conducted by the Quality Assurance Team
- Non-Functional Testing: Performance testing / Usability Testing / Security Testing ...
http://istqbexamcertification.com/what-is-functional-testing-testing-of-functions-in-software/
http://istqbexamcertification.com/what-are-software-testing-levels/
http://istqbexamcertification.com/what-is-non-functional-testing-testing-of-software-product-characteristics/
: the process of evaluating a system or its components(s)
- An early start to testing reduces the cost, time
- Debugging: it involves identifying, isolating and fixing the problems/bugs
! the part of White box or Unit Testing
- Different types of testing
* Manual testing
* Automation testing (Test Automation): uses another software to test the software
http://istqbexamcertification.com/what-is-a-software-testing/
2. Different Methods of Software Testing
Black Box Testing
|
Grey Box Testing
|
White Box Testing
|
|
| Definition | done without having any knowledge of the interior workings of the application | test with limited knowledge of the internal workings of an application | the detailed investigation of internal logic and structure of the code |
| Advantages | - large numbers of moderately skilled testers can test | - rely on interface definition and functional specifications - can design test scenarios especially around communication protocols and data type handling |
- helps in optimising the code - maximum coverage is attained |
| Disadvantages | - limited coverage - inefficient testing - blind coverage |
- testing every possible input stream is unrealistic - many program paths will go untested |
- the costs are increased - it is difficult to maintain white box testing as the use of specialised tools like code analysers debugging tools are required |
http://www.careerride.com/Testing-white-box-black-box-gray-box.aspx
3. Different Levels of Testing
- Functional Testing: to evaluate the system's compliance with its specified requirements
1) Unit testing: to isolate each part of the programme and show that individual parts are correct in terms of requirements and functionality
2) Integration testing: to test combined parts of an application to determine if they function correctly together
3) System testing: to test the system as a whole
* enables us to test, verify and validate both the business requirements as well as the Applications Architecture
4) Regression testing: to verify that a fixed bug hasn't resulted in another functionality or business rule violation
5) User Acceptance testing: conducted by the Quality Assurance Team
- Non-Functional Testing: Performance testing / Usability Testing / Security Testing ...
http://istqbexamcertification.com/what-is-functional-testing-testing-of-functions-in-software/
http://istqbexamcertification.com/what-are-software-testing-levels/
http://istqbexamcertification.com/what-is-non-functional-testing-testing-of-software-product-characteristics/
UI Design
1. UI Design
: provides an interface that allows users to accomplish their goals with the software, without unnecessary effort
- UI has a major effect on the success or failure of software systems
http://searchmicroservices.techtarget.com/definition/user-interface-UI
2. UI - Different Layers
1) The Surface Layer: finished visual design aspects
2) The Skeleton Layer: screen layout and functional compartments on the screen
3) The Structure Layer: navigation from one section to another section in the user interface
4) The Scope Layer: built to support user tasks
5) The Strategy Layer: incorporates not only what the people running the site want to get out of it but what the users want to get out of the site as well
3. General UI Design Principles
1) Visibility of system status
2) Match between system and the real world
3) User control and freedom
4) Consistency and standards
5) Error prevention
6) Recognition rather than recall
7) Flexibility and efficiency of use
8) Aesthetic and minimalist design
9) Help users recognise, diagnose, and recover from errors
10) Help and documentation
https://www.nngroup.com/articles/ten-usability-heuristics/
4. Usability vs. Utility
- usability: does the system allow the user to learn and to use the raw capabilities easily?
* Learnability
* Efficiency of use
* Error handling
* Acceptability
- utility: does the system provide the raw capabilities to allow the user to achieve their goal?
https://msdn.microsoft.com/en-us/library/ms997577.aspx
5. Usability Principles
1) Do not rely on usability guidelines - always test with users
2) Base UI designs on users' tasks
3) Ensure that the sequences of actions to achieve a task are as simple as possible
4) Ensure that the user always knows what he or she can and should do next
5) Provide good feedback including effective error messages
6) Ensure that the user can always get out, go back or undo an action
7) Ensure that response time is adequate
8) Use understandable encoding techniques
9) Ensure that the UI's appearance is uncluttered
10) Consider the needs of different groups of users
11) Provide all necessary help
12) Be consistent
6. Wireframes
- a schematic produced displaying
- blueprint for layout, text and image placement, navigation components, colour scheme, and other web page components
https://webdesign.tutsplus.com/articles/a-beginners-guide-to-wireframing--webdesign-7399
: provides an interface that allows users to accomplish their goals with the software, without unnecessary effort
- UI has a major effect on the success or failure of software systems
http://searchmicroservices.techtarget.com/definition/user-interface-UI
2. UI - Different Layers
1) The Surface Layer: finished visual design aspects
2) The Skeleton Layer: screen layout and functional compartments on the screen
3) The Structure Layer: navigation from one section to another section in the user interface
4) The Scope Layer: built to support user tasks
5) The Strategy Layer: incorporates not only what the people running the site want to get out of it but what the users want to get out of the site as well
3. General UI Design Principles
1) Visibility of system status
2) Match between system and the real world
3) User control and freedom
4) Consistency and standards
5) Error prevention
6) Recognition rather than recall
7) Flexibility and efficiency of use
8) Aesthetic and minimalist design
9) Help users recognise, diagnose, and recover from errors
10) Help and documentation
https://www.nngroup.com/articles/ten-usability-heuristics/
4. Usability vs. Utility
- usability: does the system allow the user to learn and to use the raw capabilities easily?
* Learnability
* Efficiency of use
* Error handling
* Acceptability
- utility: does the system provide the raw capabilities to allow the user to achieve their goal?
https://msdn.microsoft.com/en-us/library/ms997577.aspx
5. Usability Principles
1) Do not rely on usability guidelines - always test with users
2) Base UI designs on users' tasks
3) Ensure that the sequences of actions to achieve a task are as simple as possible
4) Ensure that the user always knows what he or she can and should do next
5) Provide good feedback including effective error messages
6) Ensure that the user can always get out, go back or undo an action
7) Ensure that response time is adequate
8) Use understandable encoding techniques
9) Ensure that the UI's appearance is uncluttered
10) Consider the needs of different groups of users
11) Provide all necessary help
12) Be consistent
6. Wireframes
- a schematic produced displaying
- blueprint for layout, text and image placement, navigation components, colour scheme, and other web page components
https://webdesign.tutsplus.com/articles/a-beginners-guide-to-wireframing--webdesign-7399
Data Modelling
1. Data Modelling
: a technique for organising and documenting a system's data
- data must be organised in a way that is flexible and adaptable to unanticipated business requirements
2. Database Design
- Approaches
* Conventional files
* Databases approach which includes Relational model, Object-oriented model, Hierarchical model, Network model and Non-relational model
- Methodology: For data design, the relational model and the OO model are the two which dominate contemporary software engineering.
3. Entity Relationship Diagram (ERD)
: Graphical representation for Date Modelling
- Entity: all systems contain data and data describes 'things'
- Attributes: the pieces of data that we want to store about each instance of a given entity
* one or more attributes must be defined as identifier - "key" to find an instance of the entity
* Candidate key: a candidate to become the primary identifier of instances of an entity
* Primary key: a candidate key which will most commonly be used to uniquely identify a single entity instance
* Alternative key: any candidate key that is not selected to become the primary key
- Relationships: associations between instances
* Cardinality: One-to-One / One-to-Many / Many-to-Many
* Modality: optional / mandatory
http://searchcrm.techtarget.com/definition/entity-relationship-diagram
: a technique for organising and documenting a system's data
- data must be organised in a way that is flexible and adaptable to unanticipated business requirements
2. Database Design
- Approaches
* Conventional files
* Databases approach which includes Relational model, Object-oriented model, Hierarchical model, Network model and Non-relational model
- Methodology: For data design, the relational model and the OO model are the two which dominate contemporary software engineering.
3. Entity Relationship Diagram (ERD)
: Graphical representation for Date Modelling
- Entity: all systems contain data and data describes 'things'
- Attributes: the pieces of data that we want to store about each instance of a given entity
* one or more attributes must be defined as identifier - "key" to find an instance of the entity
* Candidate key: a candidate to become the primary identifier of instances of an entity
* Primary key: a candidate key which will most commonly be used to uniquely identify a single entity instance
* Alternative key: any candidate key that is not selected to become the primary key
- Relationships: associations between instances
* Cardinality: One-to-One / One-to-Many / Many-to-Many
* Modality: optional / mandatory
http://searchcrm.techtarget.com/definition/entity-relationship-diagram
Design Patterns
1. Design Patterns
- describes a problem which frequently occurs in our environment, and then describes the core of the solution to the problem
- a way of reusing abstract knowledge about a problem and its solution
- Different types of Patterns
* Creational patterns: the process of object construction and the instantiation process
e.g. Singleton pattern / Abstract pattern / Factory Method pattern
* Structural patterns: Composition of classes/objects: how classes and objects are composed to form larger structures
e.g. Adapter pattern: when an existing class performs the services that a client needs but has different method names
Composite pattern: compose objects (Component interface) into tree structures to represent part-whole (Leaf-Composite class) hierarchies
Decorator pattern
* Behavioural patterns: the way classes and objects interact/patterns of communication between class
e.g. Iterator pattern / Observer pattern
https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm
http://www.oodesign.com/adapter-pattern.html
http://www.oodesign.com/composite-pattern.html
2. Observer Pattern
: defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
- Subject: the object which will frequently change its state and upon which other objects depend
* Keep track of its observers. Any number of Observer objects may observe a subject
* Provides an interface for attaching/detaching an observer
- Observer: the object which depends on a subject and updates according to its subject's state
* An updating interface for objects that gets notified of changes in a subject
(+) Minimal coupling between the Subject and the Observer
(+) Liability: possible cascading of notifications
- Implementing Issues
* Make sure the subject updates its state before sending out notifications
https://www.tutorialspoint.com/design_pattern/observer_pattern.htm
- describes a problem which frequently occurs in our environment, and then describes the core of the solution to the problem
- a way of reusing abstract knowledge about a problem and its solution
- Different types of Patterns
* Creational patterns: the process of object construction and the instantiation process
e.g. Singleton pattern / Abstract pattern / Factory Method pattern
* Structural patterns: Composition of classes/objects: how classes and objects are composed to form larger structures
e.g. Adapter pattern: when an existing class performs the services that a client needs but has different method names
Composite pattern: compose objects (Component interface) into tree structures to represent part-whole (Leaf-Composite class) hierarchies
Decorator pattern
* Behavioural patterns: the way classes and objects interact/patterns of communication between class
e.g. Iterator pattern / Observer pattern
https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm
http://www.oodesign.com/adapter-pattern.html
http://www.oodesign.com/composite-pattern.html
2. Observer Pattern
: defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
- Subject: the object which will frequently change its state and upon which other objects depend
* Keep track of its observers. Any number of Observer objects may observe a subject
* Provides an interface for attaching/detaching an observer
- Observer: the object which depends on a subject and updates according to its subject's state
* An updating interface for objects that gets notified of changes in a subject
(+) Minimal coupling between the Subject and the Observer
(+) Liability: possible cascading of notifications
- Implementing Issues
* Make sure the subject updates its state before sending out notifications
https://www.tutorialspoint.com/design_pattern/observer_pattern.htm
Detailed Design
1. Detailed design
: the process of refining and expanding the software architecture of a system or a component
- designers go deep into each component to define its internal structure and behavioural capabilities
- most of the problem-solving activities occur
- serves as the gatekeeper for ensuring that the system's specification and design are sufficiently complete before construction begins
http://softwareengineering.stackexchange.com/questions/19592/what-is-detailed-design-what-are-the-advantage-disadvantages-using-it
2. Main tasks in detailed design
1) Understanding the architecture and requirements
2) Creating detailed designs
- the focus is placed on the following
* Interface Design: internal interface design / external interface design
* Graphical User Interface design
* Internal Component Design
* Data Design
3) Evaluating detailed designs
- Technical Reviews: focus on the important aspects of your design; how your design helps meet requirements
4) Documenting detailed designs: the software design description (SDD)
5) Monitoring and controlling implementation
3. Object-oriented Design
- In heavyweight, the entire design is completed before coding/implementation begins
- In lightweight, an outline design is made before coding, but the details are completed as part of the coding process
4. UML
( http://melancholy8914.blogspot.co.uk/2017/01/architectural-design.html )
- Models used mainly for requirements: Use Case diagram
- Models used mainly for systems architecture: Component diagram / Deployment diagram
- Models used mainly for detailed design: Class diagram / Object diagram
- Models for interactive aspects of systems: Interactive diagram / Sequence diagrams / Statechart diagram / Activity diagram
5. Design Process
- effects: Development Time, Software Quality and Ease of Maintenance
1) Finding Classes & Developing Class Diagrams: Don't be too disorganised. Don't be too rigid either.
2) Deciding which Classes to Use
- Identify a set of candidate classes that represent the system design
- Modify the set of classes: Increase cohesion within classes, and lower coupling between classes
3) Identifying Classes
4) Identifying associations and attributes
5) Identifying generalisations and interfaces
6. Class Responsibility Collaboration (CRC) Card
: one card is for each candidate class
- Class Responsibility: based on Services it provides and Data it keeps
- Walkthroughs & Refining the design: All collaborations should match with CRC Cards
http://agilemodeling.com/artifacts/crcModel.htm
: the process of refining and expanding the software architecture of a system or a component
- designers go deep into each component to define its internal structure and behavioural capabilities
- most of the problem-solving activities occur
- serves as the gatekeeper for ensuring that the system's specification and design are sufficiently complete before construction begins
http://softwareengineering.stackexchange.com/questions/19592/what-is-detailed-design-what-are-the-advantage-disadvantages-using-it
2. Main tasks in detailed design
1) Understanding the architecture and requirements
2) Creating detailed designs
- the focus is placed on the following
* Interface Design: internal interface design / external interface design
* Graphical User Interface design
* Internal Component Design
* Data Design
3) Evaluating detailed designs
- Technical Reviews: focus on the important aspects of your design; how your design helps meet requirements
4) Documenting detailed designs: the software design description (SDD)
5) Monitoring and controlling implementation
3. Object-oriented Design
- In heavyweight, the entire design is completed before coding/implementation begins
- In lightweight, an outline design is made before coding, but the details are completed as part of the coding process
4. UML
( http://melancholy8914.blogspot.co.uk/2017/01/architectural-design.html )
- Models used mainly for requirements: Use Case diagram
- Models used mainly for systems architecture: Component diagram / Deployment diagram
- Models used mainly for detailed design: Class diagram / Object diagram
- Models for interactive aspects of systems: Interactive diagram / Sequence diagrams / Statechart diagram / Activity diagram
5. Design Process
- effects: Development Time, Software Quality and Ease of Maintenance
1) Finding Classes & Developing Class Diagrams: Don't be too disorganised. Don't be too rigid either.
2) Deciding which Classes to Use
- Identify a set of candidate classes that represent the system design
- Modify the set of classes: Increase cohesion within classes, and lower coupling between classes
3) Identifying Classes
4) Identifying associations and attributes
5) Identifying generalisations and interfaces
6. Class Responsibility Collaboration (CRC) Card
: one card is for each candidate class
- Class Responsibility: based on Services it provides and Data it keeps
- Walkthroughs & Refining the design: All collaborations should match with CRC Cards
http://agilemodeling.com/artifacts/crcModel.htm
Architectural Design
1. Architecture in The Life Cycle
- Iteration on both functional and quality requirements
- focuses on issues that will be difficult/impossible to change once the system is built
- defines structure
* Component interfaces
* Component communications and dependencies
* Component responsibilities
- permit / precludes achievement of a system's desired quality attributes
https://msdn.microsoft.com/en-us/library/ee658098.aspx
2. 4 + 1 View Model
- A logical view: the key abstractions in the systems as objects or object classes
- A process view: how, at run-time, the system is composed of interacting processes
- A development view: how the software is decomposed for development
- A physical view: the system hardware a how software component are distributed across the processors in the system
- (+1) A conceptual view: related using use cases or scenarios
http://www.slideshare.net/shobanachokkalingam/41-view-model
3. Architectural Patterns
- describes a family of architectures in terms of their structural organisation
- a description of component and connector types and a pattern of their runtime control and/or data transfer
- a means of representing, sharing and reusing knowledge
4. Model-View-Controller (MVC)
: separates presentation and interaction from the system data
- when? there are multiple ways to view and interact with data
- Model: manages the system data and associated operations
* encapsulates application state
* notifies view of state changes
- View: defines and manages how the data is presented to the user
* renders model
* requests model updates
* sends user events to controller
- Controller: manages user interaction and passes these interactions to the View and the Model
* maps user actions to model updates
* selects view
(+) allows the data to change independently of its representation and vice versa
(-) can involve additional code and code complexity
- MVC: Web Applications
* Component: a replaceable part of a system / as implementation of a subsystem
* Package: a general-purpose mechanism for organising elements into groups
* Node: a physical element that exists at run time and provides a computational resource
https://msdn.microsoft.com/en-us/library/ff649643.aspx
5. Layered Pattern
: organises the system into layers with related functionality associated with each layer
- Iteration on both functional and quality requirements
- focuses on issues that will be difficult/impossible to change once the system is built
- defines structure
* Component interfaces
* Component communications and dependencies
* Component responsibilities
- permit / precludes achievement of a system's desired quality attributes
https://msdn.microsoft.com/en-us/library/ee658098.aspx
2. 4 + 1 View Model
- A logical view: the key abstractions in the systems as objects or object classes
- A process view: how, at run-time, the system is composed of interacting processes
- A development view: how the software is decomposed for development
- A physical view: the system hardware a how software component are distributed across the processors in the system
- (+1) A conceptual view: related using use cases or scenarios
http://www.slideshare.net/shobanachokkalingam/41-view-model
3. Architectural Patterns
- describes a family of architectures in terms of their structural organisation
- a description of component and connector types and a pattern of their runtime control and/or data transfer
- a means of representing, sharing and reusing knowledge
4. Model-View-Controller (MVC)
: separates presentation and interaction from the system data
- when? there are multiple ways to view and interact with data
- Model: manages the system data and associated operations
* encapsulates application state
* notifies view of state changes
- View: defines and manages how the data is presented to the user
* renders model
* requests model updates
* sends user events to controller
- Controller: manages user interaction and passes these interactions to the View and the Model
* maps user actions to model updates
* selects view
(+) allows the data to change independently of its representation and vice versa
(-) can involve additional code and code complexity
- MVC: Web Applications
* Component: a replaceable part of a system / as implementation of a subsystem
* Package: a general-purpose mechanism for organising elements into groups
* Node: a physical element that exists at run time and provides a computational resource
https://msdn.microsoft.com/en-us/library/ff649643.aspx
5. Layered Pattern
: organises the system into layers with related functionality associated with each layer
when? building new facilities onn top of existing systems / there si a requirement for multi-level security
(+) allows replacement of entire layers so long as the interface is maintained
(+) redundant facilities (e.g. authentication) can be provided in each layer
(-) in practice, providing a clean separation between layers is often difficult
(-) performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer
https://msdn.microsoft.com/en-us/library/ee658109.aspx
6. The repository Pattern
: all data in a system is managed in a central repository that is accessible to all system components
when? you have a system in which large volumes of information are generated that has to be stored for a long time / in data-driven systems
(+) components can be independent - they do not need to know of the existence to other components
(-) the repository is a single point of failure so problems in the repository affect the while system
https://msdn.microsoft.com/en-us/library/ff649690.aspx
7. Client-Server Architecture
: the functionality of the system is organised into services, with each service delivered from a separate server
when? data in a shared database has to be accessed from a range of locations
(+) servers can be distributed across a network
(-) performance may be unpredictable because it depends on the network as well as the system
https://docs.oracle.com/cd/A57673_01/DOC/server/doc/SCN73/ch20.htm
8. Pipe and Filter Architecture
: each processing component (filter) is discrete and carries out one type of data transformation
when? in data processing applications (both batch- and transaction- based)
(+) easy to understand and supports transformation reuse
(+) can be implemented as either a sequential or concurrent system
(-) increases system overload
https://msdn.microsoft.com/en-us/library/dn568100.aspx
9. Architecture Validation
- to increase confidence of the design team
- has to be achieved within the project constraints of time and budget
- Main techniques
1) Questioning techniques
2) Construction of a prototype
3) Measuring techniques
(+) allows replacement of entire layers so long as the interface is maintained
(+) redundant facilities (e.g. authentication) can be provided in each layer
(-) in practice, providing a clean separation between layers is often difficult
(-) performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer
https://msdn.microsoft.com/en-us/library/ee658109.aspx
6. The repository Pattern
: all data in a system is managed in a central repository that is accessible to all system components
when? you have a system in which large volumes of information are generated that has to be stored for a long time / in data-driven systems
(+) components can be independent - they do not need to know of the existence to other components
(-) the repository is a single point of failure so problems in the repository affect the while system
https://msdn.microsoft.com/en-us/library/ff649690.aspx
7. Client-Server Architecture
: the functionality of the system is organised into services, with each service delivered from a separate server
when? data in a shared database has to be accessed from a range of locations
(+) servers can be distributed across a network
(-) performance may be unpredictable because it depends on the network as well as the system
https://docs.oracle.com/cd/A57673_01/DOC/server/doc/SCN73/ch20.htm
8. Pipe and Filter Architecture
: each processing component (filter) is discrete and carries out one type of data transformation
when? in data processing applications (both batch- and transaction- based)
(+) easy to understand and supports transformation reuse
(+) can be implemented as either a sequential or concurrent system
(-) increases system overload
https://msdn.microsoft.com/en-us/library/dn568100.aspx
9. Architecture Validation
- to increase confidence of the design team
- has to be achieved within the project constraints of time and budget
- Main techniques
1) Questioning techniques
2) Construction of a prototype
3) Measuring techniques
Software Modelling
1. Software Modelling
: The practice of creating and analysing software models
- Software Model: A description (textual or visual) of any aspect of a software system
- Modelling can help us check our understanding / communicate
2. Design / Modelling
- a set of activities that need to be performed by the designer
* in deriving and specifying a solution to a problem
* to produce a workable solution
- The fitness of the solution is measured by the correctness or appropriateness of the solution
- The process: iterative in nature
* Postulate a solution
* Build a model of the solution
* Evaluate the model against original requirements
* Elaborate the model to produce a detailed specification of the solution
!! The design process is not straightforward because of the nature of software
* The complexity of software
* The problem of conformity
* The (apparent) ease of changeability
* The invisibility of software
3. Modelling principles
1) Modularisation: drives the continuous decomposition of the software system until fine-grained components are created
2) Abstraction: focuses on essential characteristics of entities - in their context - while deferring unnecessary details
- Procedural abstraction: simplifies reasoning about behavioural operations containing a sequence of steps
- Data abstraction: simplifies reasoning about structural composition of data objects
3) Encapsulation: deals with providing access to the services of abstracted entities by exposing only the information that is essential to carry out such services while hiding details of how the services are carried out
4) Coupling: measurement of dependency between units
* Content / Code Coupling
* Data Coupling
=> reusability and maintainability decrease
=> a high degree of coupling gives rise to negative side effects
5) Cohesion: measures how well design units are put together for achieving particular tasks
=> High cohesion good, low cohesion bad ...
6) Separation of Interface and Implementation: deals with creating modules in such way that a stable interface is identified and separated from its implementation
=> different implementations of the same interface can be swapped to provide modified or new behaviour
7) Sufficiency: deals with capturing enough characteristics of the abstraction to permit meaningful interaction
8) Completeness: deals with interface capturing all the essential characteristics of the abstraction
http://ecomputernotes.com/software-engineering/principles-of-software-design-and-concepts
4. System Modelling Techniques
- Classic: Entity-Relationship Modelling / Finite State Machines / Data Flow Diagrams
- Object-oriented: variety of UML diagrams
- Formal Modelling Methods
5. Unified Modelling Language (UML)
: a visual modelling language for specifying, analysing, and designing/documenting essential aspects of software systems before construction
- uses graphical notation to communicate more clearly than natural language and code
- Structural diagram: shows the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other
* Class Diagram: static relationships between classes
* Component Diagram: the organisations and dependencies of the physical components
- Behaviour diagram: shows the dynamic behaviour of the objects in a system, which can be described as a series of changes to the system over time
* Use Case: capture requirements. Displays the relationships amongst actors and use cases
* Sequence Diagram: displays the time sequence
* State Machine Diagram: displays the sequence of states
* Activity Diagram: shows flow of control or object flow
http://www.uml.org/
6. Use Case Diagram
- Core components
* System boundary
* Actors: human users and other systems
* Use case: A set of scenarios
- Relationships between use cases
* Association: communication
* Generalisation: one general use case and one specific use case
* Include: is used to indicate that a particular Use case must include another use case to perform its function
* Extend: the extending use case may add behaviour to the base use case
https://msdn.microsoft.com/en-us/library/dd409432.aspx
7. Class Diagram
- A class describes a group of objects with
* similar properties (attributes)
* common behaviours (operations)
* common relationships to other objects
* common meaning ("semantics")
- Relationships between classes
* Generalisation: an inheritance link indicating one class is a superclass of the other
* Association: a relationship between instances of the two classes
* Aggregation: an association in which one class belongs to a collection
* Composition: a "strong" form of aggregation
https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/
8. State Machine Diagram
: a graph in which nodes correspond to states and directed arcs correspond to transitions labelled with event names
- Elements
* state: defines as the duration of time during which an object is doing an activity
* event: occurs at a point in time
* action: occurs in response to an event
* activity: an operation with certain duration that can be interrupted by another event
* guard: a logical condition
http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm
9. Sequence Diagram
- Elements
* Lifelines
* Messages
* Activation bar
* Deletion
http://www.ibm.com/developerworks/rational/library/3101.html
: The practice of creating and analysing software models
- Software Model: A description (textual or visual) of any aspect of a software system
- Modelling can help us check our understanding / communicate
2. Design / Modelling
- a set of activities that need to be performed by the designer
* in deriving and specifying a solution to a problem
* to produce a workable solution
- The fitness of the solution is measured by the correctness or appropriateness of the solution
- The process: iterative in nature
* Postulate a solution
* Build a model of the solution
* Evaluate the model against original requirements
* Elaborate the model to produce a detailed specification of the solution
!! The design process is not straightforward because of the nature of software
* The complexity of software
* The problem of conformity
* The (apparent) ease of changeability
* The invisibility of software
3. Modelling principles
1) Modularisation: drives the continuous decomposition of the software system until fine-grained components are created
2) Abstraction: focuses on essential characteristics of entities - in their context - while deferring unnecessary details
- Procedural abstraction: simplifies reasoning about behavioural operations containing a sequence of steps
- Data abstraction: simplifies reasoning about structural composition of data objects
3) Encapsulation: deals with providing access to the services of abstracted entities by exposing only the information that is essential to carry out such services while hiding details of how the services are carried out
4) Coupling: measurement of dependency between units
* Content / Code Coupling
* Data Coupling
=> reusability and maintainability decrease
=> a high degree of coupling gives rise to negative side effects
5) Cohesion: measures how well design units are put together for achieving particular tasks
=> High cohesion good, low cohesion bad ...
6) Separation of Interface and Implementation: deals with creating modules in such way that a stable interface is identified and separated from its implementation
=> different implementations of the same interface can be swapped to provide modified or new behaviour
7) Sufficiency: deals with capturing enough characteristics of the abstraction to permit meaningful interaction
8) Completeness: deals with interface capturing all the essential characteristics of the abstraction
http://ecomputernotes.com/software-engineering/principles-of-software-design-and-concepts
4. System Modelling Techniques
- Classic: Entity-Relationship Modelling / Finite State Machines / Data Flow Diagrams
- Object-oriented: variety of UML diagrams
- Formal Modelling Methods
5. Unified Modelling Language (UML)
: a visual modelling language for specifying, analysing, and designing/documenting essential aspects of software systems before construction
- uses graphical notation to communicate more clearly than natural language and code
- Structural diagram: shows the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other
* Class Diagram: static relationships between classes
* Component Diagram: the organisations and dependencies of the physical components
- Behaviour diagram: shows the dynamic behaviour of the objects in a system, which can be described as a series of changes to the system over time
* Use Case: capture requirements. Displays the relationships amongst actors and use cases
* Sequence Diagram: displays the time sequence
* State Machine Diagram: displays the sequence of states
* Activity Diagram: shows flow of control or object flow
http://www.uml.org/
6. Use Case Diagram
- Core components
* System boundary
* Actors: human users and other systems
* Use case: A set of scenarios
- Relationships between use cases
* Association: communication
* Generalisation: one general use case and one specific use case
* Include: is used to indicate that a particular Use case must include another use case to perform its function
* Extend: the extending use case may add behaviour to the base use case
https://msdn.microsoft.com/en-us/library/dd409432.aspx
7. Class Diagram
- A class describes a group of objects with
* similar properties (attributes)
* common behaviours (operations)
* common relationships to other objects
* common meaning ("semantics")
- Relationships between classes
* Generalisation: an inheritance link indicating one class is a superclass of the other
* Association: a relationship between instances of the two classes
* Aggregation: an association in which one class belongs to a collection
* Composition: a "strong" form of aggregation
https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/
8. State Machine Diagram
: a graph in which nodes correspond to states and directed arcs correspond to transitions labelled with event names
- Elements
* state: defines as the duration of time during which an object is doing an activity
* event: occurs at a point in time
* action: occurs in response to an event
* activity: an operation with certain duration that can be interrupted by another event
* guard: a logical condition
http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm
9. Sequence Diagram
- Elements
* Lifelines
* Messages
* Activation bar
* Deletion
http://www.ibm.com/developerworks/rational/library/3101.html
Capturing Requirements
1. Problem statement
: a clear and concise description of the issue(s) that need(s) to be addressed by a problem-solving team
- Issues: one or two sentences that describe the problem using specific issues
- Vision / Goals: what does the world look like if we solve the problem?
- Method: the process that will get followed to solve the problem
- Scope: boundaries of the proposed solution / new system
- The 5 'W's (Who / What / Where / When / Why) is a great tool that helps write a problem statement
* Who does the problem effect?
* What is the issue?
* Where is the issue occurring?
* When does the issue occur?
* Why is it important that we fix the problem?
http://www.ceptara.com/blog/how-to-write-problem-statement
2. From Problem Statements to the Requirements
- Requirement engineering: the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed
- Types of requirement
* User requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
* System requirements: A structured document setting out detailed descriptions of the system's functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor
* Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do.
* Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services
http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/
3. Requirement Engineering
- Components
* Requirements gathering: identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used
* Requirements analysis: about what is need and what is possible
* Requirements specification: documenting the system requirements in a semi-formal or formal manner
=> Desiderata for requirement specification: Valid / Unambiguous / Complete / Understandable / Consistent / Ranked / Verifiable / Modifiable / Traceable
http://www.sei.cmu.edu/productlines/frame_report/req_eng.htm
4. Tools for Requirement Engineering
1) User Stories: similar to system requirements, but focus on the user benefits, instead on system features
2) Scenario-Based Analysis: provides a more user-oriented view perspective on the design and development of an interactive system
3) Use Cases: Abstractions from scenarios for usage of the system typically describing series of interactions between users and the system to be developed
* Convenient way of generating requirements
http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
http://searchsoftwarequality.techtarget.com/definition/use-case
: a clear and concise description of the issue(s) that need(s) to be addressed by a problem-solving team
- Issues: one or two sentences that describe the problem using specific issues
- Vision / Goals: what does the world look like if we solve the problem?
- Method: the process that will get followed to solve the problem
- Scope: boundaries of the proposed solution / new system
- The 5 'W's (Who / What / Where / When / Why) is a great tool that helps write a problem statement
* Who does the problem effect?
* What is the issue?
* Where is the issue occurring?
* When does the issue occur?
* Why is it important that we fix the problem?
http://www.ceptara.com/blog/how-to-write-problem-statement
2. From Problem Statements to the Requirements
- Requirement engineering: the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed
- Types of requirement
* User requirements: Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers
* System requirements: A structured document setting out detailed descriptions of the system's functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor
* Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. May state what the system should not do.
* Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Often apply to the system as a whole rather than individual features or services
http://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/
3. Requirement Engineering
- Components
* Requirements gathering: identifying and communicating the purpose of a software-intensive system, and the contexts in which it will be used
* Requirements analysis: about what is need and what is possible
* Requirements specification: documenting the system requirements in a semi-formal or formal manner
=> Desiderata for requirement specification: Valid / Unambiguous / Complete / Understandable / Consistent / Ranked / Verifiable / Modifiable / Traceable
http://www.sei.cmu.edu/productlines/frame_report/req_eng.htm
4. Tools for Requirement Engineering
1) User Stories: similar to system requirements, but focus on the user benefits, instead on system features
2) Scenario-Based Analysis: provides a more user-oriented view perspective on the design and development of an interactive system
3) Use Cases: Abstractions from scenarios for usage of the system typically describing series of interactions between users and the system to be developed
* Convenient way of generating requirements
http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
http://searchsoftwarequality.techtarget.com/definition/use-case
Introduction
1. Frequently Asked Questions about software engineering
1) What is software?
- Computer programmes and associated documentation
2) What is the attribute of good software?
- Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
3) What is software engineering?
- Software engineering is an engineering discipline that is concerned with all aspects of software production
4) What are the fundamental software engineering activities?
- Software specification, software development, software validation and software evolution
5) What are the key challenges facing software engineering?
- Coping with increasing a complexity, demands for reduced delivery times and developing trustworthy software
2. Essential attributes of good software
- Maintainability: software should be written in such as way so that it can evolve to meet the changing needs of customers
- Dependability: dependable software should not cause physical or economic damage in the event of system failure.
* Software dependability includes a range of characteristics including reliability, security and safety,
- Efficiency: software should not make wasteful use of system resources such as memory and processor cycles
* Efficiency includes responsiveness, processing time, memory utilisation, etc
- Acceptability: software must be acceptable to the type of users for which it is designed
http://www.answers.com/Q/What_are_the_attributes_of_a_good_software?#slide=1
3. Software Engineering
: an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use
- Importance: more and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly
- Fundamentals
* Systems should be developed using a managed and understood development process
* Dependability and performance are important for all types of system
* Understanding and managing the software specification and requirements are important ( http://melancholy8914.blogspot.co.uk/2017/01/capturing-requirements.html )
* Where appropriate, you should reuse software that has already been developed rather than write new software
http://www.sei.cmu.edu/
4. Software Failure
- Software failures damage business
- Mostly software failures are caused by Confusion and misunderstanding in software development
- In software development life cycle, cost of fixing requirements or errors grows
* Errors in software can be time-consuming, expensive and possibly life-threatening
* Many problems result from faulty specification and design of systems
=> why is it difficult to identify errors?
=> Lack of precision / Too much complexity
=> Need for precision and abstraction at early stages
5. Validation and Verification
- Validation: ensure that specification of the software system satisfy the requirements of the stakeholders
- Verification: ensure that the finished product satisfies the specification
http://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/
1) What is software?
- Computer programmes and associated documentation
2) What is the attribute of good software?
- Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
3) What is software engineering?
- Software engineering is an engineering discipline that is concerned with all aspects of software production
4) What are the fundamental software engineering activities?
- Software specification, software development, software validation and software evolution
5) What are the key challenges facing software engineering?
- Coping with increasing a complexity, demands for reduced delivery times and developing trustworthy software
2. Essential attributes of good software
- Maintainability: software should be written in such as way so that it can evolve to meet the changing needs of customers
- Dependability: dependable software should not cause physical or economic damage in the event of system failure.
* Software dependability includes a range of characteristics including reliability, security and safety,
- Efficiency: software should not make wasteful use of system resources such as memory and processor cycles
* Efficiency includes responsiveness, processing time, memory utilisation, etc
- Acceptability: software must be acceptable to the type of users for which it is designed
http://www.answers.com/Q/What_are_the_attributes_of_a_good_software?#slide=1
3. Software Engineering
: an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use
- Importance: more and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly
- Fundamentals
* Systems should be developed using a managed and understood development process
* Dependability and performance are important for all types of system
* Understanding and managing the software specification and requirements are important ( http://melancholy8914.blogspot.co.uk/2017/01/capturing-requirements.html )
* Where appropriate, you should reuse software that has already been developed rather than write new software
http://www.sei.cmu.edu/
4. Software Failure
- Software failures damage business
- Mostly software failures are caused by Confusion and misunderstanding in software development
- In software development life cycle, cost of fixing requirements or errors grows
* Errors in software can be time-consuming, expensive and possibly life-threatening
* Many problems result from faulty specification and design of systems
=> why is it difficult to identify errors?
=> Lack of precision / Too much complexity
=> Need for precision and abstraction at early stages
5. Validation and Verification
- Validation: ensure that specification of the software system satisfy the requirements of the stakeholders
- Verification: ensure that the finished product satisfies the specification
http://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/
Metrics / MTBF / CAPM
1. Metrics
: measurement of software
: software * software development process
- Problems
* coming up with good metrics is nowhere near as easy as you might expect
* Access: there can be commercial confidence issues
* Human: people don't like to think they are being watched
* Lack of standardisation in software development process
=> Necessary to reach the higher levels of scales like CMM
( http://melancholy8914.blogspot.co.uk/2017/01/software-quality.html )
http://www.sqa.net/softwarequalitymetrics.html
2. MTBF (Mean Time Between Failure)
- ((fails on average - repair time) / fails on average) * 100
http://whatis.techtarget.com/definition/MTBF-mean-time-between-failures
3. CAPM (Capital Asset Pricing Model)
- The general idea is investors demand a return for two things: Time value of money / Risk
- It divides risk into two distinct classes: "Controlled" and "Uncontrolled"
- ra = rf + b(rm-rf)
where b = a risk measure, rf = risk-free rate, rm = expected market return
http://www.investopedia.com/articles/06/capm.asp
: measurement of software
: software * software development process
- Problems
* coming up with good metrics is nowhere near as easy as you might expect
* Access: there can be commercial confidence issues
* Human: people don't like to think they are being watched
* Lack of standardisation in software development process
=> Necessary to reach the higher levels of scales like CMM
( http://melancholy8914.blogspot.co.uk/2017/01/software-quality.html )
http://www.sqa.net/softwarequalitymetrics.html
2. MTBF (Mean Time Between Failure)
- ((fails on average - repair time) / fails on average) * 100
http://whatis.techtarget.com/definition/MTBF-mean-time-between-failures
3. CAPM (Capital Asset Pricing Model)
- The general idea is investors demand a return for two things: Time value of money / Risk
- It divides risk into two distinct classes: "Controlled" and "Uncontrolled"
- ra = rf + b(rm-rf)
where b = a risk measure, rf = risk-free rate, rm = expected market return
http://www.investopedia.com/articles/06/capm.asp
Monte Carlo Methods
1. Monte Carlo simulations/methods
: can be useful in all kinds of estimating situations
- see how many games worked out and make an estimate of the answer
=> hence, the probability of completing a game
=> The more you play, the more accurate your result
- Given a system which you can't or don't want to evaluate analytically, you can estimate properties by
* generating a set of input values (to serve as random numbers)
* running the system on each
* looking at the (distribution of) the results
http://blog.minitab.com/blog/understanding-statistics/monte-carlo-is-not-as-difficult-as-you-think
: can be useful in all kinds of estimating situations
- see how many games worked out and make an estimate of the answer
=> hence, the probability of completing a game
=> The more you play, the more accurate your result
- Given a system which you can't or don't want to evaluate analytically, you can estimate properties by
* generating a set of input values (to serve as random numbers)
* running the system on each
* looking at the (distribution of) the results
http://blog.minitab.com/blog/understanding-statistics/monte-carlo-is-not-as-difficult-as-you-think
Software Reuse
1. Software reuse
: when it works, save effort, cost and time
- "Ploys: to encourage reuse
* Make reusable code accessible
* Encourage a sense of collective ownership of the code available for reuse
* Have an easy to use, well-documented re-use database
* Financial rewards for creating reusable code and making it available and/or financial reward when it is used
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html
2. A model of reuse
- grounded in the assumption that a proportion of shortcomings (bugs) is found each time (new) tests are run on some segment of code
- suppose the code is used in again another project
- It will be subjected to a new round of tests in the new project
=> if the proportion of bugs typically found in a series of tests is p, the proportion left is (1 - p)
=> the second round of testing reduces the proportion of residual (unfound) bugs to (1 - p)^2
- Bugs in product (before testing) = Bug Content of new code * (1 - R) + Original Bug Content of reused code * R * (1 - p)^(n - 1)
Where, R = the proportion of code reused in this project,
p = the proportion of bugs removed in a cycle of testing,
1 - p = the proportion of bugs not removed in testing,
n = the number of times reused code has been reused
- How do we know the original bug count?: we have to estimate it
=> use "artificial bug insemination" ( http://melancholy8914.blogspot.co.uk/2017/01/finding-bugs.html )
=> suppose you insert n bugs deliberately, and testing uncovered a total of t bugs, m of which were inserted deliberately
=> An estimate of the total number of bugs in the original code (T) = The number of bugs actually found ( t ) / the proportion of bugs being found in the tests ( m/n )
( Assuming the tests are equally able to find real and artificial bugs )
=> T = t/(m/n) = tn/m - n
- What about p?
=> The only way is to look at other projects
: when it works, save effort, cost and time
- "Ploys: to encourage reuse
* Make reusable code accessible
* Encourage a sense of collective ownership of the code available for reuse
* Have an easy to use, well-documented re-use database
* Financial rewards for creating reusable code and making it available and/or financial reward when it is used
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html
2. A model of reuse
- grounded in the assumption that a proportion of shortcomings (bugs) is found each time (new) tests are run on some segment of code
- suppose the code is used in again another project
- It will be subjected to a new round of tests in the new project
=> if the proportion of bugs typically found in a series of tests is p, the proportion left is (1 - p)
=> the second round of testing reduces the proportion of residual (unfound) bugs to (1 - p)^2
- Bugs in product (before testing) = Bug Content of new code * (1 - R) + Original Bug Content of reused code * R * (1 - p)^(n - 1)
Where, R = the proportion of code reused in this project,
p = the proportion of bugs removed in a cycle of testing,
1 - p = the proportion of bugs not removed in testing,
n = the number of times reused code has been reused
- How do we know the original bug count?: we have to estimate it
=> use "artificial bug insemination" ( http://melancholy8914.blogspot.co.uk/2017/01/finding-bugs.html )
=> suppose you insert n bugs deliberately, and testing uncovered a total of t bugs, m of which were inserted deliberately
=> An estimate of the total number of bugs in the original code (T) = The number of bugs actually found ( t ) / the proportion of bugs being found in the tests ( m/n )
( Assuming the tests are equally able to find real and artificial bugs )
=> T = t/(m/n) = tn/m - n
- What about p?
=> The only way is to look at other projects
Planning a project
1. Planning
: about deciding what you are going to do how and when
- How long they will take?: usually, we have to make and use estimates
- Dependencies between tasks: which have to be finished before another can start
- Control: If you have a plan, you can see if you are following it
2. Gantt charts
: a visual way to present plans and timings for a project
http://www.gantt.com/
3. Critical Path Analysis (CPA)
: divide project into tasks -> estimate how long each will take -> decide what inter-dependencies there are between the tasks
- Dependencies normally mean some tasks can't be started until others are complete
(+) Knowing the critical path tells you which tasks have to be kept on time if the project is to finish on time
(+) Knowing all the numbers tells you when the various tasks of your project need to happen
- Critical path: the longest of all the paths from the start to the finish
=> the one which determines the project duration
- Earliest start / completion time
- Latest start / completion time
- Float / Slack time: only appears in tasks on non-critical paths
- Add a dummy process: sometimes there can be ambiguity or dependencies creep in (accidentally)
https://www.mindtools.com/critpath.html
4. PERT (Program Evaluation and Review Techniques)
: a refinement of classical CPA
: about deciding what you are going to do how and when
- How long they will take?: usually, we have to make and use estimates
- Dependencies between tasks: which have to be finished before another can start
- Control: If you have a plan, you can see if you are following it
2. Gantt charts
: a visual way to present plans and timings for a project
http://www.gantt.com/
3. Critical Path Analysis (CPA)
: divide project into tasks -> estimate how long each will take -> decide what inter-dependencies there are between the tasks
- Dependencies normally mean some tasks can't be started until others are complete
(+) Knowing the critical path tells you which tasks have to be kept on time if the project is to finish on time
(+) Knowing all the numbers tells you when the various tasks of your project need to happen
- Critical path: the longest of all the paths from the start to the finish
=> the one which determines the project duration
- Earliest start / completion time
- Latest start / completion time
- Float / Slack time: only appears in tasks on non-critical paths
- Add a dummy process: sometimes there can be ambiguity or dependencies creep in (accidentally)
https://www.mindtools.com/critpath.html
4. PERT (Program Evaluation and Review Techniques)
: a refinement of classical CPA
Costing and Budgeting
1. Tender & bidding
1) Tendering: the process of bidding for work
- "Private treaty" is probably the most widely used alternative
2) Bidding process for contracts: normally conventional, closed auction
- "Non-standard" bidding behaviour: factors outside the particular contract come into play
=> The theory doesn't always make sense
=> You want to submit a tender, how do you work out a price?
=> Decide what the work will cost / Estimate what others may bid, and what the client will pay
2. Costing
! Best guide is actual cost of similar activities in the past
- how? divide activity up into parts and estimate for each and sum to get a total
e.g. Empirical Costing models, Constructive Cost Model (CoCoMo)
http://www.mtisystems.com/cost-estimating-software-blog/cost-estimating-empirical-comparative-statistical-and-standards/
3. Budgeting
- In outline, to use budgetary control is to allocate resources to activities/tasks, then monitor consumption of the resource as the task progresses
- Classically everything is converted into money, but there are other possibilities (man-months, for example)
1) Tendering: the process of bidding for work
- "Private treaty" is probably the most widely used alternative
2) Bidding process for contracts: normally conventional, closed auction
- "Non-standard" bidding behaviour: factors outside the particular contract come into play
=> The theory doesn't always make sense
=> You want to submit a tender, how do you work out a price?
=> Decide what the work will cost / Estimate what others may bid, and what the client will pay
2. Costing
! Best guide is actual cost of similar activities in the past
- how? divide activity up into parts and estimate for each and sum to get a total
e.g. Empirical Costing models, Constructive Cost Model (CoCoMo)
http://www.mtisystems.com/cost-estimating-software-blog/cost-estimating-empirical-comparative-statistical-and-standards/
3. Budgeting
- In outline, to use budgetary control is to allocate resources to activities/tasks, then monitor consumption of the resource as the task progresses
- Classically everything is converted into money, but there are other possibilities (man-months, for example)
Finding bugs
1. Finding bugs
- One characteristic of high quality in Software Systems is absence of errors (bugs)
( http://melancholy8914.blogspot.co.uk/2017/01/software-quality.html )
=> Eliminate them!
=> How? try to avoid creating them in the first place / try to find them before they cause trouble
2. Testing
: a process of executing a programme with the intent of finding faults
e.g. Black box testing, White box testing, Grey box testing
1) Testing plan: Decisions and judgements about testing
=> Continue until you are finding no more bugs?
2) Automation: particularly popular in OO development e.g. JUnit
(+) Fast and easy: once setup, running and re-running requires an absolute minimum of effort from the developer
(+) Consistent: each test is run in exactly the same way every time
(-) Unsuitable for some types and classes of test
(-) Consistent: running a test by hand may lead to a failure which the automated system doesn't uncover
3) Coverage: a measure of what proportion of code is being exercised by testing
4) Artificial bug insemination: a technique for estimating number of residual bugs in a system
- Assumption:
* bugs found are fixed (!)
* bugs are evenly distributed (80/20 rules)
http://istqbexamcertification.com/what-is-a-software-testing/
- One characteristic of high quality in Software Systems is absence of errors (bugs)
( http://melancholy8914.blogspot.co.uk/2017/01/software-quality.html )
=> Eliminate them!
=> How? try to avoid creating them in the first place / try to find them before they cause trouble
2. Testing
: a process of executing a programme with the intent of finding faults
e.g. Black box testing, White box testing, Grey box testing
1) Testing plan: Decisions and judgements about testing
=> Continue until you are finding no more bugs?
2) Automation: particularly popular in OO development e.g. JUnit
(+) Fast and easy: once setup, running and re-running requires an absolute minimum of effort from the developer
(+) Consistent: each test is run in exactly the same way every time
(-) Unsuitable for some types and classes of test
(-) Consistent: running a test by hand may lead to a failure which the automated system doesn't uncover
3) Coverage: a measure of what proportion of code is being exercised by testing
4) Artificial bug insemination: a technique for estimating number of residual bugs in a system
- Assumption:
* bugs found are fixed (!)
* bugs are evenly distributed (80/20 rules)
http://istqbexamcertification.com/what-is-a-software-testing/
Industrial Relations
1. Job Regulation
- Unilateral Regulation
- Customary Regulation
- Joint Regulation
- Statutory
2. Frame of Reference
: One way to think about how and why people behave the way they do
- Unitary view: sees workplace unified by a common purpose
- Pluralist view: sees workplace as a collection of groups with divergent interests
- Radical view: sees relations in the workplace as part of a bigger structure of inequality, wealth, power, etc.
3. Main "players" (characters) in industry
- Employers, their organisation and representatives: Managers, Personnel departments, etc.
- Employees and their representatives: Individuals, Trade Unions, etc.
- The State: might be a major employer in its own right
- Unilateral Regulation
- Customary Regulation
- Joint Regulation
- Statutory
2. Frame of Reference
: One way to think about how and why people behave the way they do
- Unitary view: sees workplace unified by a common purpose
- Pluralist view: sees workplace as a collection of groups with divergent interests
- Radical view: sees relations in the workplace as part of a bigger structure of inequality, wealth, power, etc.
3. Main "players" (characters) in industry
- Employers, their organisation and representatives: Managers, Personnel departments, etc.
- Employees and their representatives: Individuals, Trade Unions, etc.
- The State: might be a major employer in its own right
Group formation
1. Group formation
- need to work with others in groups
- deal with issues in groups is a real challenge
1) Tuckman's Stages Model
: one of group development theories and models
- The team lifecycle: a level of acceptable behaviour
* Forming: finds out about each other
* Storming: difficult to recognise when you are involved in it
* Norming: emergence of commitment to the group
* Performing: a mature team
https://www.mindtools.com/pages/article/newLDR_86.htm
- need to work with others in groups
- deal with issues in groups is a real challenge
1) Tuckman's Stages Model
: one of group development theories and models
- The team lifecycle: a level of acceptable behaviour
* Forming: finds out about each other
* Storming: difficult to recognise when you are involved in it
* Norming: emergence of commitment to the group
* Performing: a mature team
https://www.mindtools.com/pages/article/newLDR_86.htm
Software Quality
1. What do we mean by "high quality"?
- Nobody would argue with an assertion that we should build high-quality software
=> But, what does that mean? What is "high-quality software"?
- Some suggestions: Software which
* Complies with the specification
* Does "clever things" quickly and easily
* Doesn't "fail"
2. Evaluation of S/W Development processes
"Good processes produce good results"
=> Trying to use or having a good software development process is a desirable if you want to produce good software
1) The Capability Maturity Model (CMM): Outlines a series of stages in the development of a software developer
- the Maturity Level: Initial-> Managed -> Defined -> Quantitative managed -> Optimising
https://www.tutorialspoint.com/software_testing_dictionary/capability_maturity_model.htm
2) The Capability ImMaturity Model (CIMM)
- the Immaturity Level: Negligent -> Obstructive -> Contemptuous -> undermining
3) The Capability Maturity Model Integration (CMMI)
- more recently, CMM has been enlarged, refined and redefined as CMMI
3. Project Quality Management
1) Quality Planning
- identifying which quality standards are relevant to the project and setting out to satisfy them
=> It is about deciding what you want to do
2) Quality Assurance
- evaluating (overall) project performance to ensure that the project will satisfy relevant quality standards
=> It is about evidence such as documenting and recording what you've done
- Tools used in Quality Assurance: Design
* Design of experiments: to identify which variables affect quality most
* Benchmarking: generate ideas by comparing specific project practices
* Quality audit: structured review of specific quality management activities
3) Quality Control
- monitoring specific project results to ensure that they comply with relevant (quality) standards and how to improve an overall quality
- in order to improve quality by correcting the causes of errors
- Outcomes: Acceptance decisions / Rework / Process adjustments
- Tools and techniques
* Causes and effect diagram (= fishbone diagram, Ishikawa diagram): help to decide the cause of a problem
* Pareto Analysis: help to identify and prioritise problem areas
* Control charts: help to find if process is out of control
* Testing
http://www.project-management-skills.com/project-quality-management.html
4. ISO 9000
- ISO: International Standard Organisation
- ISO 9000: effective and efficient Quality Management Systems
- By implementing:
* Avoid repetitions of past mistakes
* Provide continuity
* Useful when trading internationally
http://www.iso.org/iso/iso_9000
5. TickIT
: IT and Software Industry specific standards
: Now there's TickITplus
=> improve market confidence in third party quality management system certification
http://www.tickitplus.org/
- Nobody would argue with an assertion that we should build high-quality software
=> But, what does that mean? What is "high-quality software"?
- Some suggestions: Software which
* Complies with the specification
* Does "clever things" quickly and easily
* Doesn't "fail"
2. Evaluation of S/W Development processes
"Good processes produce good results"
=> Trying to use or having a good software development process is a desirable if you want to produce good software
1) The Capability Maturity Model (CMM): Outlines a series of stages in the development of a software developer
- the Maturity Level: Initial-> Managed -> Defined -> Quantitative managed -> Optimising
https://www.tutorialspoint.com/software_testing_dictionary/capability_maturity_model.htm
2) The Capability ImMaturity Model (CIMM)
- the Immaturity Level: Negligent -> Obstructive -> Contemptuous -> undermining
3) The Capability Maturity Model Integration (CMMI)
- more recently, CMM has been enlarged, refined and redefined as CMMI
3. Project Quality Management
1) Quality Planning
- identifying which quality standards are relevant to the project and setting out to satisfy them
=> It is about deciding what you want to do
2) Quality Assurance
- evaluating (overall) project performance to ensure that the project will satisfy relevant quality standards
=> It is about evidence such as documenting and recording what you've done
- Tools used in Quality Assurance: Design
* Design of experiments: to identify which variables affect quality most
* Benchmarking: generate ideas by comparing specific project practices
* Quality audit: structured review of specific quality management activities
3) Quality Control
- monitoring specific project results to ensure that they comply with relevant (quality) standards and how to improve an overall quality
- in order to improve quality by correcting the causes of errors
- Outcomes: Acceptance decisions / Rework / Process adjustments
- Tools and techniques
* Causes and effect diagram (= fishbone diagram, Ishikawa diagram): help to decide the cause of a problem
* Pareto Analysis: help to identify and prioritise problem areas
* Control charts: help to find if process is out of control
* Testing
http://www.project-management-skills.com/project-quality-management.html
4. ISO 9000
- ISO: International Standard Organisation
- ISO 9000: effective and efficient Quality Management Systems
- By implementing:
* Avoid repetitions of past mistakes
* Provide continuity
* Useful when trading internationally
http://www.iso.org/iso/iso_9000
5. TickIT
: IT and Software Industry specific standards
: Now there's TickITplus
=> improve market confidence in third party quality management system certification
http://www.tickitplus.org/
Software Development Process
1. Software Development Models
1) Waterfall
- It's classic
- It's linear: each state finished before moving on
=> It assumes stability and certainty about requirements and environment
=> Might be work in an ideal world
2) V Model
- Well known variation of waterfall attempting to fix some of the shortcomings
- But it's still essentially linear
3) Build and fix
- Another elementary model
- Gains the idea of cycles in development
4) Spiral Model
- Really get to grip with cyclic nature of development
5) WinWin
- A refinement of spiral Model
- In essence, it adds a decision point in each iteration which becomes the requirements exercise for the iteration
=> By negotiation, a "WinWin" condition is identified
=> all parties are satisfied by an iteration of the development
6) Another ..
- Incremental, Prototyping, Formal Methods, Agile, RUP
http://istqbexamcertification.com/what-are-the-software-development-models/
2. Agile methods
1) The Manifesto for Agile Software Development
2) Principles behind the manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
- Business people and developers must work together daily throughout the project
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
- Continuous attention to technical excellence and good design enhances agility
- Simplicity -- the art of maximising the amount of work not done-- is essential
- The best architectures, requirement and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
http://agilemethodology.org/
3) XP (eXtreme Programming)
: Iterative development with short iterations
- A "big name" in agile development
- Concepts
* Coding: In the final analysis, the code is all that matters
* Testing: It's good and finds flaws, so do lots of it
* Listening: Coders must listen to the client and understand their needs/wants
* Designing: Organising the logic of the system and avoiding unnecessary inter-dependencies
- Emphasis on Testing and Customer satisfactions / Teamwork and Pair programming
- Criticisms
* Onsite client making informal changes requests can lead to requirements "creep"
* Not clear it scales to larger projects
http://www.extremeprogramming.org/
4) Scrum
- Another of the well known Agile development "styles"
- Key features is the "sprint": A short iteration of product development
- At the start of each sprint, there's a planning meeting where it is decided what will be done in the next iteration
- Daily Scrum meeting to discuss progress
- At the end, there is a review/retrospective where work is presented to the client and team considers what went well and what didn't
https://www.scrum.org/Resources/What-is-Scrum
https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
5) Common features of Agile
- Small teams, small increments of development
- Rapid development
- Emphasis on testing and (interim) approval from client
- Close customer communication
- Flexible requirements - often generate "on the fly" - or very nearly so
1) Waterfall
- It's classic
- It's linear: each state finished before moving on
=> It assumes stability and certainty about requirements and environment
=> Might be work in an ideal world
2) V Model
- Well known variation of waterfall attempting to fix some of the shortcomings
- But it's still essentially linear
3) Build and fix
- Another elementary model
- Gains the idea of cycles in development
4) Spiral Model
- Really get to grip with cyclic nature of development
5) WinWin
- A refinement of spiral Model
- In essence, it adds a decision point in each iteration which becomes the requirements exercise for the iteration
=> By negotiation, a "WinWin" condition is identified
=> all parties are satisfied by an iteration of the development
6) Another ..
- Incremental, Prototyping, Formal Methods, Agile, RUP
http://istqbexamcertification.com/what-are-the-software-development-models/
2. Agile methods
1) The Manifesto for Agile Software Development
| We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. |
2) Principles behind the manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
- Business people and developers must work together daily throughout the project
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
- Working software is the primary measure of progress
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
- Continuous attention to technical excellence and good design enhances agility
- Simplicity -- the art of maximising the amount of work not done-- is essential
- The best architectures, requirement and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
http://agilemethodology.org/
3) XP (eXtreme Programming)
: Iterative development with short iterations
- A "big name" in agile development
- Concepts
* Coding: In the final analysis, the code is all that matters
* Testing: It's good and finds flaws, so do lots of it
* Listening: Coders must listen to the client and understand their needs/wants
* Designing: Organising the logic of the system and avoiding unnecessary inter-dependencies
- Emphasis on Testing and Customer satisfactions / Teamwork and Pair programming
- Criticisms
* Onsite client making informal changes requests can lead to requirements "creep"
* Not clear it scales to larger projects
http://www.extremeprogramming.org/
4) Scrum
- Another of the well known Agile development "styles"
- Key features is the "sprint": A short iteration of product development
- At the start of each sprint, there's a planning meeting where it is decided what will be done in the next iteration
- Daily Scrum meeting to discuss progress
- At the end, there is a review/retrospective where work is presented to the client and team considers what went well and what didn't
https://www.scrum.org/Resources/What-is-Scrum
https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
5) Common features of Agile
- Small teams, small increments of development
- Rapid development
- Emphasis on testing and (interim) approval from client
- Close customer communication
- Flexible requirements - often generate "on the fly" - or very nearly so
2017년 1월 27일 금요일
Low-Level Software Vulnerabilities
1. Vulnerability
- High-level Vulnerability: Security
e.g. Authentication, Privilege Escalation, Inappropriate Authorisation, Access Control, Integrity etc
- Low-level Vulnerability: Safety
e.g. Buffer Overflow, Heap-based exploitation, Stack-based exploitation, Integer overflow, File / Memory management etc
2. Buffer Overflow
: a bug that affects low-level code, typically in C and C++, with significant security implications
- an attacker can alter the situations that cause the program to do much worse than a simple crash
e.g. Steal private information / Corrupt valuable information / Run code of the attacker's choice
- Buffer: Contiguous memory associated with a variable or field
- Overflow: Put more into the buffer that it can hold
- Heap Overflow
- Integer Overflow
- Read Overflow / Format String Overflow
e.g. Heartbleed
http://www.thegeekstuff.com/2013/06/buffer-overflow/?utm_source=feedly
3. Code Injection
: the exploitation of a computer bug that is caused by processing invalid data
1) Create the injection vector
the vector = Shellcode address + Shellcode + NOP sled
2) Get injected code to run
https://www.techopedia.com/definition/20022/code-injection
4. Defence Strategies
- Avoid the buffer overflow entirely
* Secure coding: use C functions that support bounds checking
! Automatic Techniques
http://security.stackexchange.com/questions/20497/stack-overflows-defeating-canaries-aslr-dep-nx
* Code Review
http://www.testingexcellence.com/static-analysis-vs-dynamic-analysis-software-testing/
* Testing
- Make the buffer overflow harder to exploit
5. Types of Malware
- Target: Mass, Specific
- Forms: Trojan Horse, Virus, Worm etc.
- Characteristics
* Information stealing: Keyloggers, sniffers, Password stealers, Intercepting etc
* Remote access: Backdoor, Botnet etc
* Ransomware: Once everything is encrypted, inform the user and demand money
* Rootkit: Hooking into OS calls and changing their behaviours
* Scareware: Generally, disable general computer operation
* Downloader / Launcher: bundle other malware
- Common techniques
* Persistence: Malware generally needs to persist between system boots
* stealth: camouflage against legitimate system files
* Packing
* Obfuscation
* Rootkits
* Anti-analysis
- Basic Static Analysis: Examine the PE file itself
* Signature: What was it compiled with?
=> Detect it Easy
* Structure: Is it packed?
* Sections: How is the file made up?
=> PEStudio
* Metadata: what other information is there?
* Certification: Has the file been digitally signed?
* Imports: What does it use
=> Dependency Walker
* Exports: What does it make available?
* Strings: What text does it contain?
=> Strings
* Resources: What icons, menus, dialogs does it have
=> Resource Hacker
- Advanced Static Analysis: Taking the malware on the disk in binary form and disassembling it into assembly code
=> IDA
http://usa.kaspersky.com/internet-security-center/internet-safety/what-is-malware-and-how-to-protect-against-it#.WHuPIRvJxnI
- High-level Vulnerability: Security
e.g. Authentication, Privilege Escalation, Inappropriate Authorisation, Access Control, Integrity etc
- Low-level Vulnerability: Safety
e.g. Buffer Overflow, Heap-based exploitation, Stack-based exploitation, Integer overflow, File / Memory management etc
2. Buffer Overflow
: a bug that affects low-level code, typically in C and C++, with significant security implications
- an attacker can alter the situations that cause the program to do much worse than a simple crash
e.g. Steal private information / Corrupt valuable information / Run code of the attacker's choice
- Buffer: Contiguous memory associated with a variable or field
- Overflow: Put more into the buffer that it can hold
- Heap Overflow
- Integer Overflow
- Read Overflow / Format String Overflow
e.g. Heartbleed
http://www.thegeekstuff.com/2013/06/buffer-overflow/?utm_source=feedly
3. Code Injection
: the exploitation of a computer bug that is caused by processing invalid data
1) Create the injection vector
the vector = Shellcode address + Shellcode + NOP sled
2) Get injected code to run
https://www.techopedia.com/definition/20022/code-injection
4. Defence Strategies
- Avoid the buffer overflow entirely
* Secure coding: use C functions that support bounds checking
! Automatic Techniques
Stack Canaries
|
Non-Executable Stacks
|
ASLR
(Address Space Layout Randomisation)
|
|
| Goal | make sure we detect overflow of a return address | prevent an attacker to execute his code | prevent the attacker from guessing the memory address of his code |
| Idea | - The functions' prologues insert a canary on the stack - The canary is a value inserted between the return address and local variables |
- Mark data memory as non-executable | - Randomise the address in memory of all code, heap, stack, global variables, etc - Buffer overflow: the attacker does not know the address of shellcode |
| Advantages | - Useful to protect against buffer overflows that overwrite the return address | - Prevent only execution of malicious code on the stack | |
| Limitations | - Do not protect the program from exploits that modify variables, object pointers, or function pointers - Do not protect against heap buffer overflow |
- Do not prevent buffer overflow attacks that modify return address, variables, object pointers, or function pointers - Do not prevent buffer overflow in the heap or data segments of the memory of the program - May affect performance |
- Do not prevent the return address on the stack from being overwritten - Do not prevent attacks where the attacker overwrites data |
http://security.stackexchange.com/questions/20497/stack-overflows-defeating-canaries-aslr-dep-nx
* Code Review
Static Analysis
|
Dynamic Analysis
|
|
| Definition | all about what we can learn from the program without running it | all about what we can learn from the program while it is running |
| What can you find? | - Checking against pre-defined rules e.g. Flow issues, Security issues, Memory issues, Input issues, Resources leaks |
- Runtime error detection - Memory issues/leaks - Input / output validation issues - Pointer arithmetic errors - Performance |
| What cannot you find? | - non-trivial properties of programs are undecidable | - Anything off the runtime path e.g. input dependent |
| Tools | - Source code analysers - Byte code analysers - Binary code analysers => Intermediate Representations * Abstract Syntax Trees (AST) * Control Flow Graphs (CFG) |
- Valgrind: a tool suite that provides a number of debugging and profiling tools esp. Memcheck - Pin: a dynamic binary instrumentation framework => Pintools |
| Limitations | - False positives: the tool reports bugs that program does not contain - False negatives: the program contains vulnerabilities that the tool does not report |
- No false positives or negatives on a given run - Do not need source code - Clear which path was taken - Can be used on live code - Detect vulnerabilities only on execution path - Significant computational resources are required to perform the analysis - It is more difficult to track back a vulnerability to its exact location in the code |
http://www.testingexcellence.com/static-analysis-vs-dynamic-analysis-software-testing/
* Testing
- Make the buffer overflow harder to exploit
5. Types of Malware
- Target: Mass, Specific
- Forms: Trojan Horse, Virus, Worm etc.
- Characteristics
* Information stealing: Keyloggers, sniffers, Password stealers, Intercepting etc
* Remote access: Backdoor, Botnet etc
* Ransomware: Once everything is encrypted, inform the user and demand money
* Rootkit: Hooking into OS calls and changing their behaviours
* Scareware: Generally, disable general computer operation
* Downloader / Launcher: bundle other malware
- Common techniques
* Persistence: Malware generally needs to persist between system boots
* stealth: camouflage against legitimate system files
* Packing
* Obfuscation
* Rootkits
* Anti-analysis
- Basic Static Analysis: Examine the PE file itself
* Signature: What was it compiled with?
=> Detect it Easy
* Structure: Is it packed?
* Sections: How is the file made up?
=> PEStudio
* Metadata: what other information is there?
* Certification: Has the file been digitally signed?
* Imports: What does it use
=> Dependency Walker
* Exports: What does it make available?
* Strings: What text does it contain?
=> Strings
* Resources: What icons, menus, dialogs does it have
=> Resource Hacker
- Advanced Static Analysis: Taking the malware on the disk in binary form and disassembling it into assembly code
=> IDA
http://usa.kaspersky.com/internet-security-center/internet-safety/what-is-malware-and-how-to-protect-against-it#.WHuPIRvJxnI
Model Checking for Cyber Security
1. Why Model Checking?
- to ensure a software is secure
=> think hard about possible attack scenarios
=> what if you missed a possible attack?
=> Did you implement the attacks correctly?
- The general correctness problem: Does the system meet the specification?
2. Formal methods
- A different approach to correctness
=> Correctness problem is same
=> determine whether system meets the specification
=> However, system, specification must be mathematically precise
Establishing correctness = proof
"Mathematically complete argument that system meets specification"
=> Proofs are hard! They require deep expertise
...Maybe they can be automated? but, it is impossible to prove everything automatically
=> but maybe some can?
http://ecomputernotes.com/software-engineering/formal-methods-model
3. Model Checking
: Automated proofs of correctness
: An automatic verification technique for finite state concurrent systems
- Systems: Finite-state Kripke structures
e.g. Dining Philosophers
- Specifications: Temporal logic
* LTL: Linear Time Logic
4.Model Checking and Security
: Model checking detects (automatically) if given finite-state system satisfies TL formulas
- How can this be used to check system security?
1) Formulate desired security properties in TL
2) Model system and possible intruders
3) Check if system satisfies formulas
http://seclab.stanford.edu/pcl/mc/mc.html
5. Needham-Schroeder Protocol / Needham-Schroeder Protocol with Lowe's fix
: establish authenticated connection between A (initiator) and B (responder)
http://www.slashroot.in/needham-schroeder-protocol-explained
http://proverif.rocq.inria.fr/index.php
- to ensure a software is secure
=> think hard about possible attack scenarios
=> what if you missed a possible attack?
=> Did you implement the attacks correctly?
- The general correctness problem: Does the system meet the specification?
2. Formal methods
- A different approach to correctness
=> Correctness problem is same
=> determine whether system meets the specification
=> However, system, specification must be mathematically precise
Establishing correctness = proof
"Mathematically complete argument that system meets specification"
=> Proofs are hard! They require deep expertise
...Maybe they can be automated? but, it is impossible to prove everything automatically
=> but maybe some can?
http://ecomputernotes.com/software-engineering/formal-methods-model
3. Model Checking
: Automated proofs of correctness
: An automatic verification technique for finite state concurrent systems
- Systems: Finite-state Kripke structures
e.g. Dining Philosophers
- Specifications: Temporal logic
* LTL: Linear Time Logic
4.Model Checking and Security
: Model checking detects (automatically) if given finite-state system satisfies TL formulas
- How can this be used to check system security?
1) Formulate desired security properties in TL
2) Model system and possible intruders
3) Check if system satisfies formulas
http://seclab.stanford.edu/pcl/mc/mc.html
5. Needham-Schroeder Protocol / Needham-Schroeder Protocol with Lowe's fix
: establish authenticated connection between A (initiator) and B (responder)
http://www.slashroot.in/needham-schroeder-protocol-explained
http://proverif.rocq.inria.fr/index.php
Risk-Based Testing
1. Risk-based testing
: uses risk to prioritise and emphasise the appropriate tests
- Objective: to find the most important defects as early as possible at the lowest price
- Business based decision: involves key business and technical project stakeholders to align the focus and sequence of testing
http://istqbexamcertification.com/what-is-risk-based-testing/
: uses risk to prioritise and emphasise the appropriate tests
- Objective: to find the most important defects as early as possible at the lowest price
- Business based decision: involves key business and technical project stakeholders to align the focus and sequence of testing
Process
|
Basic concepts
|
|
| Test Planning | - the activity of establishing or updating a test plan - the objectives, scope, approach, resources, exit criteria, and schedule of intended test activities |
- Test objectives - Test prioritisation / selections - Risk metrics - Exit criteria |
| Test Design | - transforms the test plan into tangible test conditions and abstract test cases | - Coverage criteria - Test types |
| Test Execution | - comprises tasks to execute test cases - making the abstract test cases executable |
- Logging support - Test automation http://melancholy8914.blogspot.co.uk/2017/01/model-checking-for-cyber-security.html - Monitoring - Risk Metrics measurement |
| Test Evaluation | - evaluates the exit criteria and logged test results | - Risk reporting - Test re-assessment - Test exit decision - Risk mitigation |
http://istqbexamcertification.com/what-is-risk-based-testing/
Designing Secure Architectures Using Security Patterns
1. Building Secure Architectures
: Identify Threats -> Plan Mitigation Strategy -> Instantiate Strategy
|<--------- STRIDE / LINDDUN -------->|<- Security Patterns ->|
( http://melancholy8914.blogspot.co.uk/2017/01/uncover-security-design-flaws-with.html / http://melancholy8914.blogspot.co.uk/2017/01/uncover-privacy-design-flaws-with.html )
2. Security Pattern
: a well-understood solution to control, stop or mitigate a set of specific threats through some security mechanisms defined in a given context
- Template: Standard way to describe a pattern
- Instantiating a Security Pattern
* New components need to be introduced
* Wire the new components to the existing ones
* Modify existing components
http://www.securitypatterns.org
: Identify Threats -> Plan Mitigation Strategy -> Instantiate Strategy
|<--------- STRIDE / LINDDUN -------->|<- Security Patterns ->|
( http://melancholy8914.blogspot.co.uk/2017/01/uncover-security-design-flaws-with.html / http://melancholy8914.blogspot.co.uk/2017/01/uncover-privacy-design-flaws-with.html )
2. Security Pattern
: a well-understood solution to control, stop or mitigate a set of specific threats through some security mechanisms defined in a given context
- Template: Standard way to describe a pattern
Sections
|
Descriptions
|
| Name | - Should capture the essence of the pattern in a concise and catchy manner |
| Intent | - Should summarise the pattern briefly in 2/3 sentences - Includes what the purpose or intent of the pattern |
| Aliases | - Should enumerate other names for the patterns |
| Problem & Forces | - Outlines the context in which the patterns is applicable, as well as explaining the motivation for using patterns |
| Solution | - Should describe at a high level how the pattern solves the problem described in the problem statement |
| Static structure | - Presents the constituent elements involved in the usage of this pattern |
| Dynamic structure | - Describes interactions between the various components in the static structure |
| Implementation & Pitfalls | - Most common mistakes in the usage of this pattern and provide the reader with guidance for avoiding them |
| Consequences | - Describes the possible impact of using the pattern with respect to CIAA, performance, cost, manageability and usability |
| Example and Known Uses | - Explicit references to products or systems |
- Instantiating a Security Pattern
* New components need to be introduced
* Wire the new components to the existing ones
* Modify existing components
http://www.securitypatterns.org
피드 구독하기:
글 (Atom)