Please enable JavaScript.

Coggle requires JavaScript to display documents.

BLOCK 4 - Coggle Diagram

- - - - User requirements
      - Software requirements
      - Architectural Design
      - Detailed Design
      - Implementation and Unit Testing
      - Integration and Unit Testing
      - Operation and Maintenance
      - Work Breakdown Structure (WBS)
        
        Each item is given a value, 1 digit = level 1; 2 digits = level 2 and so on.
        
        Map of all work to be completed.
    - - Individuals and interactions over processes and tools.
      - Working software over comprehensive documentation.
      - Customer collaboration over contract negotiation
      - Responding to change over following a plan.
      - Working software is produced at the end of each cycle
      - Critiques
        
        Struggles to scale
        
        Increased maintenance
        
        Tendency to short-term thinking
        
        Lack of documentation leads to members being single points of failure
        
        Lack of predictability
        
        Need for heavy customer interaction
    - - Wish list of software is produced.
      - Sprint planning: choose top ten priorities and do them.
      - Sprint: Complete the items in a set amount of time.
      - ScrumMaster keeps the team focused on the tasks.
      - At the end of a sprint, software should be working.
      - Sprint retrospective: reflection time.
      - Start process again.
  - - - interview stakeholders
      - Observational studies
      - Examine existing software
      - Focus groups
    - - Results in outputs like prototype website
      - Stakeholders should sign-off on things at this stage.
      - E.g. Show initial wireframe, get feedback and alter until accepted.
    - - This is used to get stakeholders to identify which features are most important.
    - - Scope creep
      - Missing functionality
      - Unnecessary functionality
      - Meshing with existing systems
  - - - It should:
        
        (What) Identify quality standards
        
        (How) Determine procedures to ensure standards are met
        
        (Do) Monitor outpus to determine compliance
  - - - External Risks
      - Scope Risks
      - Technical Risks
      - Project Management Risks
      - Organisational Risks
    - - Likelihood impact assessment
        
        combines likelihood of risk with potential impact of the risk
        
        Qualitative assessment
        
        Scores likelihood and impact into low, medium and high probability.
      - Risk rating matrix
        
        Presents overall measure of risk
    - - Eliminate
      - Reduce likelihood
      - Reduce impact
      - Stop
      - Share risk
      - Accept risk
    - - Highlights most significant risks and outlines mitigation strategies and assigns responsibility for monitoring risks.
      - Is a summary of the risk situation a project faces
- - - - prepared statements
    - - weak passwords, regenerate session IDs
    - - HTTPS
    - - ISITSAFETORUN (PHP)
    - - sanitize form input?
    - - store data (like cookie data) where it cannot be tampered with
  - - - Configuring public servers to resist attacks.
      - Ensure all used services are disabled.
      - Bastion servers should not have any 'trust' relationships with the internet.
      - Restrict network protocols to those that the app needs.
      - No general-purpose user accounts should exist, and for the accounts that do exist, they should have strong passwords.
      - Secure comm channel should be employed.
      - OS updates should only be applied if it address a vulnerability.
    - - Always record all activities that occur on a server.
      - The following data should be recorded:
        
        URL
        
        HTTP method
        IP of requesting computer
        
        page requested
        
        name and version of page sent by server
        
        size of file sent
        
        time taken to process request
      - Status response that include 4xx (e.g. 403 and 401) should be looked at.
      - Logs can be sent to other servers for safe storage.
  - - - doc root
        
        doc root is defined with single line in apache's config file
        
        doc root directory is accessible via HTTP request
        
        on request, apache will append URL-path to doc root path
        
        to change the doc root allows for easy way to alter where web files are stored. The requesting client can still use the same URL, its just that apache's config will need to have the doc root that is wanted.
      - directory directive
        
        access rules for internet users are specified by the 'Directory' directive in the apache config file
        
        Each 'directory' entry specifies how a specific directory should be protected.
  - - - symmetric encryption: uses a single key to decrypt and decrypt
      - Asymmetric encryption (public key): use a pair of keys.
        Anything encrypted with private key can be decrypted with public key (vice versa).
        
        example - encrypt message with Alice's public key, then send her the message. She can decrypt with her private key.
        
        This method is computationally expensive. So a combo of methods is usually employed.
        
        E.g.
        
        new symmetric key is made and exchanged by encrypting it with asymmetric keys.
        
        sym key is short so its not computationally expensive.
        
        message to be exchanged can then be encrypted with sym key.
        
        once message exchange is complete, sym key can be destroyed.
    - - Domain name + Public key combo are made by server admin.
        
        This is sent to the CA to check if Authentic.
        
        If found to be an authentic combo, CA signs request with privK.
        
        This is the certificate, and it is given back to the original serrver admin.
        
        The certificate is then added to the web server config.
      - Certs are used to validate that client is connecting to intended domain. HTTPS security model includes certs for this reason.
      - There are a bunch of CA authorities that are considered safe by browsers, they are part of the public key infrastructure (PKI).
  - - - something you know
        
        pwd+username
      - something you are
        
        biometric, etc
      - something you have
        
        physical object, passport/cell phone auth app
      - Basic auth
        
        based on something you know model
        
        user must respond to presented dialogue with valid login info.
        
        once entered, credentials are sent to server for validation.
        
        encoding used is called Base64, and allows 8 bit data to be presented in 7-bit ASCII characters.
        
        encoding is not encryption, so this data must be sent over HTTPS to be considered secure.
      - Digest Authentication
        
        added to HTTP
        
        Uses MD5 hash function
        
        User attempts to access page - gets unauthorised message.
        
        Server responds with unique nonce.
        
        Browser responds with username + hash of password combined with nonce.
        
        Server extracts username from response, looks up password in its database, then runs MD5 hash function on that password + the nonce.
        
        If hash values are equal, then client is granted access.
  - - - Server provides digital cert to browser.
        
        Browser authenticates connection by checking certs signature by cross-checking domain name with signature.
        
        After this, data can be sent to the server securely by encrypting it with the servers key.
        
        All data exchanges are encrypted.
- - - - Functional
      - Usability
      - Accessibility
      - Interface
      - Compatibility
      - Performance
      - Security testing
      - Regression testing
  - - - verify execution of small pieces of code before integration into large elements of the project
      - a unit may be defined in various ways
      - for web development, this should be covered in unit test phase:
        
        html validation
        
        css validation
        
        forms
        
        internal hyperlinks
        
        client-side objects and functions
        
        server-side objects and functions
        
        database queries
    - - verifies that units work well together. This means testing functionality, usability, browser compatibility and accessibility
      - wide range of test values are important
        
        normal
        
        erroneous
        
        exceptional
    - - Navigation errors
      - Presentation errors
      - Control usage problems
      - Give user instruction to follow and see if they can do it.
    - - Test on hardware, check interoperability
      - Usability tests could take place here
      - Once test environment is set up, performance tests can commence
      - Performance tests
        
        load test: apply load to system, check results
        
        stress test: test when load exceeds expected usage
        
        capacity test: test to determine max number of users the app can support
    - - Does the app fulfil the user requirements decided initially.
      - Client performs acceptance tests
      - British computing society acceptance testing guide
        
        Identify requirements to test.
        
        Identify test conditions for each requirement.
        
        Establish test case.
        
        Write test procedure.
  - - - Katalon
      - Watir
      - JMeter
  - - - mixture of clients and servers used by developer
      - support development effort
    - - comprises isolated clients and servers in control of a 'test team'.
      - architecture should mimic production environment
    - - environment should reflect the equipment that will host the application
- - - - Repository timeline
        
        Repository with files created.
        
        Files 'checked out'. I.e. Files are extracted from the repository. These files are called the working copy.
        
        The working copy is modified.
        
        Once the modifications are finished, they are 'committed', meaning they are sent back to the working copy. The changes made to the original repository are logged.
      - Each time the repository is updated with a new working copy, a new revision, or version number is created.
      - Tagging
        
        Labelling a special copy of the repository that has significance, like a copy that is sent to the client.
        
        Is different to a simple increment of the normal copy.
        
        Is nice to use for when the entire application is tested. A tagged repository could represent a 'complete' version of the software.
      - Branching
        
        There is a main repo with all assets. A branch is a parallel stream to that.
        
        Dev will 'branch off' and work on a different snapshot (version) of the repo (although, there is still only one main repo).
        
        Later, when work on the branch is done, it will be merged with the main 'trunk.'
      - Merging
        
        Dealing with same asset alerations
        
        lock-modify-unlock
        
        Restrict write access to single person by placing a lock on the asset
        
        After it is modified, it is unlocked for others to modify.
        
        Can be slow, especially if someone forgets to unlock the asset.
        
        copy-modify-merge
        
        Allows multiple working copies of the asset.
        
        Each owner can modify.
        
        After modifying, the copy can be committed to repo and then merged.
      - Practicalities
        
        When to commit
        
        A commit should reflect a single purpose.
        
        Commit complete changes when they occur.
        
        Don't postpone commits.
        
        Don't commit anything that hasn't passed its tests or is incomplete.
        
        Don't commit on the basis of elapsed time.