diff --git a/2C-SE.assets/1024px-Characteristics_of_Capability_Maturity_Model.svg.png b/2C-SE.assets/1024px-Characteristics_of_Capability_Maturity_Model.svg.png new file mode 100644 index 0000000..12bfb39 Binary files /dev/null and b/2C-SE.assets/1024px-Characteristics_of_Capability_Maturity_Model.svg.png differ diff --git a/2C-SE.assets/1542636369213.png b/2C-SE.assets/1542636369213.png new file mode 100644 index 0000000..955faad Binary files /dev/null and b/2C-SE.assets/1542636369213.png differ diff --git a/2C-SE.assets/1542636375661.png b/2C-SE.assets/1542636375661.png new file mode 100644 index 0000000..95b841c Binary files /dev/null and b/2C-SE.assets/1542636375661.png differ diff --git a/2C-SE.assets/1543142448637.png b/2C-SE.assets/1543142448637.png new file mode 100644 index 0000000..8a1b3c3 Binary files /dev/null and b/2C-SE.assets/1543142448637.png differ diff --git a/2C-SE.assets/1543143069292.png b/2C-SE.assets/1543143069292.png new file mode 100644 index 0000000..569c6ef Binary files /dev/null and b/2C-SE.assets/1543143069292.png differ diff --git a/2C-SE.assets/1543143798585.png b/2C-SE.assets/1543143798585.png new file mode 100644 index 0000000..b28305d Binary files /dev/null and b/2C-SE.assets/1543143798585.png differ diff --git a/2C-SE.assets/1543144642816.png b/2C-SE.assets/1543144642816.png new file mode 100644 index 0000000..552d708 Binary files /dev/null and b/2C-SE.assets/1543144642816.png differ diff --git a/2C-SE.assets/1543146629660.png b/2C-SE.assets/1543146629660.png new file mode 100644 index 0000000..f07ce06 Binary files /dev/null and b/2C-SE.assets/1543146629660.png differ diff --git a/2C-SE.assets/1543147108484.png b/2C-SE.assets/1543147108484.png new file mode 100644 index 0000000..f1ebee8 Binary files /dev/null and b/2C-SE.assets/1543147108484.png differ diff --git a/2C-SE.assets/1543147264443.png b/2C-SE.assets/1543147264443.png new file mode 100644 index 0000000..58699b8 Binary files /dev/null and b/2C-SE.assets/1543147264443.png differ diff --git a/2C-SE.assets/1543147982905.png b/2C-SE.assets/1543147982905.png new file mode 100644 index 0000000..3cd1dbb Binary files /dev/null and b/2C-SE.assets/1543147982905.png differ diff --git a/2C-SE.assets/1543148029020.png b/2C-SE.assets/1543148029020.png new file mode 100644 index 0000000..15aaac2 Binary files /dev/null and b/2C-SE.assets/1543148029020.png differ diff --git a/2C-SE.assets/1543148331734.png b/2C-SE.assets/1543148331734.png new file mode 100644 index 0000000..c677b61 Binary files /dev/null and b/2C-SE.assets/1543148331734.png differ diff --git a/2C-SE.assets/1543148442267.png b/2C-SE.assets/1543148442267.png new file mode 100644 index 0000000..2cfe292 Binary files /dev/null and b/2C-SE.assets/1543148442267.png differ diff --git a/2C-SE.assets/1543585250853.png b/2C-SE.assets/1543585250853.png new file mode 100644 index 0000000..fee3a56 Binary files /dev/null and b/2C-SE.assets/1543585250853.png differ diff --git a/2C-SE.assets/1543585265509.png b/2C-SE.assets/1543585265509.png new file mode 100644 index 0000000..9a38735 Binary files /dev/null and b/2C-SE.assets/1543585265509.png differ diff --git a/2C-SE.assets/1543667647524.png b/2C-SE.assets/1543667647524.png new file mode 100644 index 0000000..67e2788 Binary files /dev/null and b/2C-SE.assets/1543667647524.png differ diff --git a/2C-SE.assets/1543668447275.png b/2C-SE.assets/1543668447275.png new file mode 100644 index 0000000..6ca5f77 Binary files /dev/null and b/2C-SE.assets/1543668447275.png differ diff --git a/2C-SE.assets/output1000.png b/2C-SE.assets/output1000.png new file mode 100644 index 0000000..b5540db Binary files /dev/null and b/2C-SE.assets/output1000.png differ diff --git a/2C-SE.md b/2C-SE.md new file mode 100644 index 0000000..7d01e16 --- /dev/null +++ b/2C-SE.md @@ -0,0 +1,1213 @@ +# 2C (SE) - Software Engineering - Notes + +## 18 September 2018 + +### Software Engineering Activities + +1. Requirements Capture +2. Design +3. Construction/Implementation +4. Testing & Debugging +5. Maintenance/Evolution + +## 4 October 2018 + +### Identifying Classes and Operations + +- Identifying Classes + + - Ignore all non-nouns and instead focus on the *nouns* in the *project description*. + +- Identifying Operations + +- Focus on *verbs* instead. + +**In both cases, use your judgement again to eliminate some concepts for further simplicity and clarity.** + +**Beware of subclassing/inheritance relationships between classes (or of its concepts).** + + + +## 18 October 2018 + +### Software Configuration Management + +- Version Control +- Compiling (and *Building* as a general idea) + +### Version Control + +- Lock-Modify-Unlock Model *[OLD]* + + - Advantages + + - Very simple. + - Central source of truth. + + - Disadvantages + + - Multiple developers cannot work on the same file. + - Deadlocks might occur (especially if scripts are doing some maintenance work on the repo for instance, say linting multiple files). + - Requires access to repo at all times (*e.g.* you cannot checkout a file to modify it during the holiday, lest it will be inaccessible for a week). + +- Copy-Modify-Merge *[NEW]* + + - Advantages + + - Multiple developers can work on the same file at the same time. + - Deadlocks cannot occur since there is no locking. + - Distributed repositories might be beneficial for certain development. models (*i.e.* open-source projects where every contributor might want to have a full-access). + - Does not require access to repo at all times. + + - Disadvantages + + - More complicated than Lock-Modify-Unlock model. + - Multiple sources of truth (though in reality there is often a master repo). + - Merge conflicts happen, and they are not uncommon. + - Automatic merging used to be faulty sometimes but software are getting better. + - Not every file-type is *mergable*, such as photographs, PDF documents, audio files, or spreadsheets. + - **Merging requires certain assumptions about the file semantics.** + + + +- Three-Way Merge + +- 1. Original File: + + ``` + Alpha + Bravo + Charlie + ``` + + 2. Tester 1 edits the Original File: + + ``` + Alpha + Foxtrott + Charlie + ``` + + 3. Tester 2 edits the Original File: + + ``` + Delta + Alpha + Echo + Charlie + ``` + + 4. Tester 2 commits changes. + + 5. Tester 1's commit fails. + + 6. Tester 1 updates and merge reports conflicts: + + ``` + Delta + Alpha + <<<<<< .mine + Foxtrott + ====== + Echo + >>>>>> .r4 + Charlie + ``` + + 7. Tester 1 now has to choose whether to retain her or Tester 2’s version. + +### Compiling and Building + +- C + + - Make *[OLD]* + - CMake *[NEW]* + +- Java + + - Ant *[OLD]* + - Maven *[NEW]* + +## 23 October 2018 + +### Refactoring + +- **As code evolves its quality naturally decays.** + + - Because **changes are often local, without full understanding of the context.** + +- **Refactoring**, is about restoring good design in a *disciplined way*. + + - There are **refactoring patterns**. + - There are patterns for everything in Software Engineering... + +- *Refactoring is changing __internal__ structure of software to make it:* + + - *easier to understand, and* + - *cheaper to modify* + + _**without changing its observable behaviour.**_ + +- Refactoring was once seen as a kind of maintenance, but it can also be an integral part of the development process! + + - Agile methodologies (*e.g.* XP) advocate continual refactoring. + +- **A refactoring is a _small_ transformation.** + + - Do NOT confuse it with **rewrite**. + +- To ensure that refactoring hasn’t **changed**/broken something? + + - *test, refactor, test* + +### Bad Code Smells + +- Duplicated code +- Long methods +- Large classes +- Long parameter lists +- Lazy classes + *i.e.* Classes that are ridiculously small. +- Long message chains + *i.e.* Having too many (unnecessary) indirections. + +## 25 October 2018 + +### Verification, Validation, and Testing (VV&T) + +- **VV&T** generally refers to all techniques for improving **product quality**. +- **Verification:** are we building the software *right*? + - Does software meet requirements? + - *Static analysis, reviews, inspections, walk-throughs* +- **Validation:** are we building the *right software*? + - Does software accommodate customers' needs? + - *Prototyping, early releases* + - Validation is more general than verification. +- **Testing is a useful technique for both.** + +### Testing + +- In essence, testing is + - *Generating stimulus* for a component + - *Collecting outputs* from the component + - *Checking* if *actual* outputs are as *expected* +- __Automation of tests is essential.__ + - Speeds up the whole testing process. + - **Makes tests deterministic.** + - Not necessarily always, but definitely more deterministic than a human being. +- `assert` statements are common to compare the actual results and expectations. + - **Checks can also be spread throughout the program code itself.** + +#### Kinds of Tests + +* Testing approaches: + * **Black-Box Testing** + purely specification-based (treating the component as a "black box") + * **White-Box Testing** + also considers the internal structure +* Kinds of tests: + * **Module (or Unit) Tests** + for each class in OO software + * **Integration Tests** + test components interact properly + * **System Tests** + check if functional and non-functional requirements met, *verification* + * **Acceptance Tests** + in customer environment, *validation* + * **Stress Tests** + look for graceful degradation, not catastrophe + * **Performance Tests** + performance is often a non-functional requirements (*e.g.* in real-time systems) + * **Regression Tests** + more like a testing methodology, repeated full-tests after each modification + +#### How to Test + +- Tests should be + - **repeatable** + - **documented** + both the tests and the results + - **precise** + - **done on configuration-controlled software** +- **Ideally test spec should be written at the same time as the requirements spec.** + - Tests and requirement features can be cross-referenced! + - Use cases can suggest tests. + - **Also helps to ensure *testability* of requirements.** + +### Preconditions, Postconditions, Invariants + +- **Method Precondition** + A condition that must be true when a method is invoked. +- **Method Postcondition** + A condition that the method guarantees to be true when it finishes. +- **Class Invariant** + A condition that should *always* be true for all the instances of a given class. + - *Always* as in all *client-visible* states, that is, whenever the object is not executing one of its methods! + +#### Java Modelling Language (JML) + +- JML provides + + - A richer language (predicate logic) for writing boolean conditions than Java boolean expressions (propositional logic), for example allowing *quantifiers* such as `\forall` and `\exists`. + - Special comment syntax for common assertion types: + - **Preconditions:** `//@ requires x > 0;` + - **Postconditions:** `//@ ensures \result % 2 == 0;` + - **Invariants:** `//@invariant name.length <= 8; ` + - **General assertions:** `//@ assert i + j = 12;` + +- Examples: + + - ```java + //@ requires x >= 0.0 + /*@ ensures JMLDouble + @ .approximatelyEqualTo + @ (x, \result * \result, eps); + @*/ + public static double sqrt(double x) { + /*...*/ + } + ``` + - ```java + /*@ requires a != null + @ && (\forall int i; + @ 0 < i && i < a.length; + @ a[i-1] <= a[i]); + @*/ + int binarySearch(int[] a, int x) { + // ... + } + ``` + - > Note that this universally quantified expression in JML must have parentheses around it, `(\forall ... )`. + + - > The range is optional, but if omitted, such a universally quantified expression may not be executable; it can still be used for documentation purposes, however. + +- > In return for the benefit of faster understanding, modular reasoning imposes a cost. This cost is that clients are not allowed to conclude anything that is not justified by the contracts of the methods that they call. Another way of looking at this is that, to allow modular reasoning with contract specifications, **the client code must work for every implementation that satisfies the contract.** + + - > Otherwise, the implementation would no longer be free to change the algorithm used. + +- > There are other good reasons not to use code as contracts. **Code makes a poor contract, because by only using code one cannot convey to readers what is intended (i.e., what the *essential properties* of the method are) and what parts are merely implementation decisions (*accidental features*).** + + - > For example, if the code for `sqrt` computes square roots to 7 decimal places, cannot this be changed in the next release? Without some separate description of what is intended, the reader can’t tell if that 7 decimal places were intended, or just happened to be computed; perhaps 4 decimal places are all that is necessary for the rest of the program. + +- Some tools such as *jmlc, jmlrac, etc.* compile and run JML-annotated Java code into bytecode with specific **runtime assertion checking**. +- __Assertions can also be used on *inputs* to *constrain* the *random generation of input data*.__ + + - QuickCheck! + +*Quotes from:* http://www.eecs.ucf.edu/~leavens/JML//jmldbc.pdf + +### Kinds of Bugs + +- In order of increasing severity: + + 1. **Mistake** + A human action that produces a fault. + 2. **Fault (Defect)** + An incorrect step, process, or data definition in a computer program. + 3. **Error** + A difference between some computed value and the correct value. + 4. **Failure** + The software (or whole system) failing to deliver some service it is expected to deliver. + + - **Faults do not necessarily lead to errors.** + - **Errors do not necessarily lead to failures.** + +### Test-First Development + +- **Motivation:** Tests implicitly define... + + - interface, and + - **specification of behaviour** + + for the functionality being developed. + + - **Writing tests first often clarifies requirements!** + - Testing code demands more precision than an English specification. + +- **Idea** is + + - write tests **before** writing the code they apply to, + - run tests as code is written. + - *In an ideal world, the system will be complete when all your tests pass. :)* + - **TFD avoids poor ambiguity resolution.** + - Instead of choosing what is easiest to implement in the face of ambiguity, you will implement the right thing (that your tests check for). + +- **Consequently** + + - bugs found at earliest possible point of development + - locating bugs are relatively easy (due to locality of tests) + - **TFD ensures adequate time for test writing.** + - Often testing time is squeezed or eliminated. + +### Test-Driven Development + +- A subtly different term, covers the way that in Extreme Programming detailed tests *replace* a written specification. + +### Limitations of Testing + +- **Writing tests is time-consuming** + +- **Coverage almost always limited** + may happen not to exercise a bug. + +- **Difficult/impossible to emulate live environment perfectly** + *e.g.* *race conditions* that appear under real load conditions can be hard to find by testing. + +- **Can only test executable things** + mainly code, or certain kinds of model – not high level design or requirements. + +### Reviews, Walkthroughs, Inspections + +- ![1542636369213](2C-SE.assets/1542636369213.png) +- ![1542636375661](2C-SE.assets/1542636375661.png) + +### Static Analysis + +- Static analysis is **the inspection of the code to determine properties of it *without running it*.** + - When contrasted with testing, testing is called *dynamic testing*. +- **Type-checking** during compilation is a basic kind of static analysis. +- **Trade-offs** + - As the properties checked get more complicated, + - only smaller programs can be analysed. + - the process is less automated (*e.g.* **annotations** required). + - As tools are more automated and designed to work on larger programs, they often *cannot* + - guarantee every problem flagged is a real error (*i.e.* false-positives) + - find every error (*i.e.* false-negatives). + - The latter kind of tools are more to aid bug-hunting than ensuring *correctness*. + +## 1 November 2018 + +### Deployment + +- Getting software out of the hands of the developers into the hands of the users. +- More than 50% of commissioned software is not used, mostly because it fails at deployment stage. + +#### Key Issues + +- **Business processes** + Most large software systems require the customer to change the way they work; has this been properly thought through? +- **Training** +- **Deployment itself** + How *physically* to get the software installed. +- **Equipment** + Is the customers' hardware up to the job? +- **Expertise** + Does the customer have the IT expertise to install & use the software? +- **Integration** + How will the software integrate with other systems of the customers'? + +- "Installing" is the easiest part of deployment... + + ### Maintenance + +The process of *changing a system after it has been delivered*. + +- **Fixing bugs and vulnerabilities** + not only in code, but also design and requirements +- **Adapting to new platforms and software environments** + *e.g.* new hardware, new OSes, new software/systems to integrate... +- **Supporting new features and requirements** + necessary as operating environments change in response to competitive pressures. + +#### Challanges + +- **(Un)popularity of maintenance work:** + - Unpopular -- seen as less skilled, can (and often does) involve obsolete languages. +- Often a new team has to understand the software. +- **Development and maintenance often separate business contracts.** +- Things often degrade over time. +- Working with obsolete compilers, OSes, hardware... + +### Re-engineering + +- **Source code translation** + *E.g.* from obsolete language, or assembly, to modern language, ... +- **Reverse engineering** + *I.e.* analysing the program, possibly in the absence of source code! +- **Structure improvement** + Especially modularisation, architectural refactoring, ... +- **Data re-engineering** + Reformatting and cleaning up data. +- **Adding adaptor interfaces <3** + to users and newer other software + +#### Issues + +- Specification might be lost as well... +- Which bugs do you deliberately preserve? + +### Bug Reporting + +- Many projects use a *bug tracking system* for both bug reports and new feature requests. +- These provide extensive support for *receiving*, *tracking*, notifying, monitoring, *etc.* +- Each *ticket* has a + - unique **ticket number** + - **summary** + - **component** where the bug is observed + (it might not always be clear; sometimes bugs arise out of integration issues) + - **version** of the program + - **milestone** in which this bug is aimed to be fixed + - **type** + *e.g.* *defect*, or maybe *enhancement* for feature requests! + - **owner** + *i.e.* the creator of the ticket + - **assignee** + *i.e.* the person responsible for the resolution of the ticket + - **status** + *new*, *assigned*, *notabug* if the developers think it's not a bug, *resolved*, ... + - **priority** + some bugs and/or feature requests are more important than others! + - and much more! + +- When **reporting bugs**: + - Include tediously detailed information about + - what *exactly* you did + - so that bug can be *reproduced* + - what did you expect to happen + - what happened instead + - Include full information about the system & environment such as + - operating system + - hardware (processor, graphics card, ...) + - Make an intelligent attempt at diagnosing the problem if you can. + - Keep your *diagnosis* completely separate from the report of *what happened*. + - Add a concise summary at the beginning. + - Do **not** omit information you think is irrelevant; you are probably wrong in what you think. + +## 8 November 2018 + +### Software Processes + +- A process is *"a set of activities and way of organising/coordinating those activities in order to produce a software system."* +- **Activities:** + - **Software Specification** + goals, functionality, and constraints + - **Software Development** + producing software: design, construction, verification + - **Software Validation** + ensuring that software accommodates the customers' needs + - **Software Evolution** + adapting software to changing needs and requirements +- Processes are about *management*: + - ordering activities + - outcomes of activities + - allocating people and resources + - planning in advance, predicting time/cost/resource usage + - **monitoring** + - **risk reduction** +- **Process models** are *ideals*, in practice mix and match! + +#### Waterfall Model + +![1543142448637](2C-SE.assets/1543142448637.png) + +**Pros:** + +- Better than no process at all, makes clear that requirements must be analysed, software must be tested, *etc.* +- Suitable for + - very slowly evolving systems where high-reliability, safety *etc.* are top priorities (*e.g.* engine control unit of a car), in other words, **safety-critical** + - for **embedded systems** where resources are extremely limited and deployment is often only once (during flashing!), + - very **large systems** where the interaction between multiple components must be clearly laid out (which also allows simultaneous development of different components). + +**Cons:** + +- Inflexible and unrealistic: *e.g.* verification will show up problems with requirements capture. + - Many real-world application (need to) evolve rapidly in response to the changing customer needs and competitive market conditions. +- Slow and expensive: in an attempt to avoid problems later, we end up "gold plating" early phases. + - *E.g.* Over-engineering at Requirements and Design stage so to avoid problems during implementation and verification. + +#### Spiral Model + +![1543143069292](2C-SE.assets/1543143069292.png) + +- **Cycles** are an essential concept: + 1. Determine **Objectives** + objectives are settled + 2. Identify and Resolve **Risks** + risks identified, alternatives considered (*e.g.* go for prototype to analyse uncertain requirements) + 3. **Development and Test** + 4. **Review** for the next iteration + project reviewed and decisions made about continuing +- **A key innovation is prominent role of risk.** + + + +**Pros:** + +- Risk plays a prominent role, which is crucial. +- Iterative approach is more suitable (than the Waterfall) to real-world. +- Steps are clearly identified. + +**Cons:** + +- Loops are still *sequential*, but in real-world it's more of a back-and-forth, and there is more concurrency (*e.g.* realising that a requirement has been misunderstood during development forces you to revise your requirements) +- Steps are not as elaborate as UP for instance; no guidelines on how to proceed with validation, with business modelling, and how the importance of each varies through the time... + +#### Unified Process + +![1543143798585](2C-SE.assets/1543143798585.png) + +- Again, **cycles**: + 1. **Inception** ends with commitment from the *project sponsor* to go ahead: + *business case* for the project and its basic feasibility & scope known + 2. **Elaboration** ends with + - **basic architecture** of the system in place + - a **plan for construction** agreed + - all **significant risks identified** + 3. **Construction** (definitely **iterative**) ends with a beta-release system + 4. **Transition** is introducing the system to its users +- The process for a single product will have several *cycles*. +- **Each instance of a phase might have several iterations.** + +##### Workflows + +![1543144642816](2C-SE.assets/1543144642816.png) + +**6 Engineering workflows:** + +1. **Business modelling** [Inception cycle] + A key *pro* of UP is the fact that it includes the *business* side of software engineering into the software process itself. The fact that *business modelling* precedes *requirements* evidences that software is developed to serve a (business) purpose. +2. Requirements [Elaboration cycle] +3. Analysis and design [Elaboration cycle] +4. Implementation [Construction cycle] +5. Test [Construction cycle] +6. Deployment [Transition cycle] + +**3 Supporting workflows:** +always ongoing workflows in the background + +1. Configuration and change management +2. Project management +3. Environment (*e.g.* process and tools) + + + +##### UP Best Practises + +1. **Develop software iteratively** +2. **Manage requirements** + document explicitly, analyse impact before adopting +3. **Use component-based architectures** + promote systematic reuse +4. **Visually model software** + UML... +5. **Verify software quality** + testing, linting, coding standards +6. **Control change to software** + configuration management + +#### Personal Software Process + +- UNIMPORTANT. + +- **PSP provides a ladder of gradually more sophisticated practises.** +- The idea: + 1. Identify those (UP) large-system **software methods & practises that can be used by individuals**, + 2. Define a subset of those methods and practises that can be applied while developing **small programs**, + 3. Structure them so that they can **gradually introduced**, + 4. Provide **exercises suitable for practising** these methods in an educational setting. +- Lots of forms to fill in: time recording log, defect recording log, ... +- A relatively **high ceremony** process, aimed at **individuals and small projects**. + - It's often used as a training for high(er) ceremony processes such as UP. + +## 13 November 2018 + +### Agile Processes + +- Software development has to be *agile*: **able to react quickly to change** +- **Maxims:** + - **Individuals and interactions** over processes and tools + - **Working software** over comprehensive documentation + - **Customer collaboration** over contract negotiation + - **Responding to change** over following a plan + +![1543146629660](2C-SE.assets/1543146629660.png) + +#### 12 Principles of Agile + +1. **Customer satisfaction** by **rapid delivery** of **useful software** +2. **Welcome changing requirements**, even late in development +3. **Working software is delivered frequently (weeks rather than months)** +4. **Working software is the principal measure of progress** +5. **Sustainable development**, able to **maintain a constant pace** +6. **Close, daily co-operation between business people and developers** +7. Face-to-face conversation is the best form of communication (**co-location**) +8. Projects are built around motivated **individuals, who should be given right support and trusted to get job done** +9. **Continuous attention** to technical excellence and good design +10. **Simplicity is essential** +11. Best requirements and designs form **self-organising teams** +12. **Regular reflection** on process and tuning of behaviour + +### Extreme Programming (XP) + +- **EXTREME PROGRAMMING IS AN AGILE VARIANT.** + + - Other Agile processes include Scrum and DSDM. + + ![1543147108484](2C-SE.assets/1543147108484.png) + +- **Activities** + + - **Listening** + understanding the customer, communicating efficiently + - **Designing** + creating structure, organising system logic + - **Coding** + - **Testing** + *embodying requirements*, assessing quality, guiding coding + + + +##### XP Practices - Planning Game + +![1543147264443](2C-SE.assets/1543147264443.png) + +##### XP Practices - On-Site Customer + +- Someone capable of making the business's decisions in the planning game, a representative of the customer who sits with the development team, being always ready to + - clarify + - (help) write functional tests + - make small-scale priority and scope decisions +- Customer can do their *normal work* when not needed to interact with the development team. + + + +##### XP Practices - Small Releases + +- **Release as frequently as is possible whilst still adding some *business value* in each release.** + - **You get feedback as soon as possible.** + - **Lets the customer have the most essential functionality ASAP.** +- Every week or every month. +- Outside XP releases commonly every 6 months or longer. + + + +##### XP Practices - Methaphors + +- About an easily-communicated overarching view of the system. +- **Encompasses concept of software architecture.** +- **Eases the developer-customer communication.** +- Provides a sense of cohesion. +- **Often suggests a consistent vocabulary.** + + + +##### XP Practices - Continuous Integration + +- **Code is integrated, debugged, and tested in full system build frequently** (at most a few hours or a day after being written). +- **Maintains a working system at all times.** +- **Makes bugs easier to trace.** + - "It was alright an hour ago! Let me check what has changed since then." +- **Simplifies integration, prevents late-stage surprises.** + + + +##### XP Practices - Testing + +- **Any program feature without an automated test simply doesn't exist.** +- **Tests are the contract between your developers, and between you and your customers.** + - Programmers write **unit tests**. + - Customers (with your help) write **functional tests**. + + + +##### XP Practices - Refactoring + +![1543147982905](2C-SE.assets/1543147982905.png) + +##### XP Practices - Pair Programming + +![1543148029020](2C-SE.assets/1543148029020.png) + +##### XP Practices - Collective Ownership + +- **Every developer is responsible for the codebase as a whole**, and is permitted to modify and improve as they seem fit. + + + +##### XP Practices - Coding Standards + +- **The whole team adheres to a single set of *conventions* about how code is written.** + - **In order to make *pair programming* and *collective ownership* work.** + + + +##### Mixing and Matching XP Practices + +![1543148331734](2C-SE.assets/1543148331734.png) + +- XP practices are *very* interrelated & interdependent so it's dangerous: + - *Collective Ownership* without *Coding Standards* will create an inconsistent mess. + - *Simple Design* without *Refactoring* will create code smell. + - *Planning Game* without *On-Site Customer* is simply unimaginable! + +### Comparison of Different Processes + +![1543148442267](2C-SE.assets/1543148442267.png) + +- **Formal Methods** go beyond Waterfall and what we've seen in this course. + - Developing on-board software for Curiosity Space Rover for instance! + +## 15 November 2018 + +### Improving Processes + +#### "Risks" + +- We improve a process to manage (*i.e.* reduce, predict, and plan for) **risks** (*i.e.* bad things that might happen to us). +- **Risks can be categorised in many different ways.** + - **Project risks** affect schedule or resources + *e.g.* staff loss, management change, missing resources + - **Product risks** affect quality or performance of the software + *e.g.* always-changing requirements, delays in requirements analysis (and consequently rushing it) + - **Business risks** affect the software developer or buyer + *e.g.* mis-estimation of costs, competitor gets to market first +- **Planing for risks** + - **Identify** risks early, categorise them + - **Analyse** each identified risk; is it minor, major, serious, fatal? What is the *chance* of it happening? + - **Plan** how to *cope* with each risk: + - Can it be **avoided** by reducing the probability of occurrence? + - Can you plan to **minimise** the effect if it does happen? + - What is your **contingency plan** if it does happen? + +#### "Quality" + +- **Quality is anything that the customer cares about.** + + - **Quality planning** + *how will you ensure that this project delivers a high quality product?* + - **Quality metrics** + *what measurements must you make in order to tell whether what you're doing is making the difference you intend?* + - **Quality improvement** + *what can you learn from this project to help you plan and run the next one better?* + - **Quality control** + *how can you ensure and prove that your quality plan was followed?* + - **Quality assurance (QA)** + *an umbrella term for the whole field dealing with quality.* + +- Quality improvement may focus on + + - *the software product itself* + verification, validation, testing, code/design reviews, inspections, walkthroughs... + - *the process by which the software is produced* + what we'll focus on! + +- **Process focus** + + - [+] has the potential to improve *all* products of the organisation + - [+] makes it possible to *certify* (ISO 9000) the whole organisation + - [+] might be unavoidable as some things --such as planning--are hard to approach in any other way + - [-] done badly, can easily increase costs with no actual benefits + +- **Centres of Process-Focused Quality Assurance** + + 1. **Organisation ---> Project ---> Individual** + Organisation's management *decides*, influencing projects. + Project managers *direct* individuals into desired behaviour. + 2. **Organisation <--- Project <--- Individual** + Individuals *introduce* improvements to the rest of the project. + Project improvements *spread* to the rest of the organisation. + + - Making these centres work together productively depends on the software engineering *culture* of the organisation and *attitude to work* of the individual. + +##### Standard Quality Assurance Models + +1. **Capability Maturity Model Integration (CMMI)** + + quality planning, control, and *improvement* framework (*i.e.* maturity of the organisation increases) + +2. **ISO 9000** + quality *control* framework (*i.e.* less emphasis on improvement) + +- These can be complementary! + + + +- **CMMI** + - It provides a generic --but specialisable to software project-- description of **process areas**, **goals** associated with each area, and **practices** that may achieve goals. + - Organisations are assessed at a **maturity level** according to *how* they achieve goals and follow practices: + - ![img](2C-SE.assets/1024px-Characteristics_of_Capability_Maturity_Model.svg.png) + + + +- **Total Quality Management (TQM)** + + - **Plan, Do, Check, Act** + - *Improving quality is everyone's job --not just that of the QA department!* + + 1. Quality can and must be managed. + 2. *Everyone* has a customer to delight. + 3. Processes, not the people, are the problem. + 4. *Every employee is responsible for quality.* + 5. Problems must be *prevented*, not just fixed. + 6. Quality must be *measured*, so it can be *controlled*. + 7. *Quality improvements must be continuous.* + 8. **Quality goals must be based on customer requirements.** + + + +* **ISO 9001** + * An international standard for quality assurance. + * It specifies *how* to specify documents, and procedures that a company should follow in its quality control. It *does not* however, specify or require any *level of product quality*. + + + +- **Bottom line:** things only get better when those involved... + - ...have enough information to tell what's wrong + - that's why you aim to take *quantitative measurements* + - ...think about the process + - nothing important, merely stating that you need to know that a thing called QA exists + - ...plan how to improve + - not only the specific product, but the whole process + - ...actually make sure the plan happens + - quality control + - ...check whether it worked + - quality control & quality imprvement + +#### "Estimating" + +- **Cost estimation** + + - Prior to any --significant-- project, you need to *estimate* how much it will *cost*. + - Time cost, human resources cost, financial cost, ... + - Many factors: + - software size + - software complexity + - engineer productivity (individually and as a team) + - **We'll consider only software size and complexity** + - and define *Productivity is the ratio of these to time required.* + +- **Lines of Code (LoC)** + + - [-] Not very meaningful by itself, what is a line of code? + - [-] Does not make sense across different programming languages: imagine Haskell, Java, C... + - [+] Still widely used! Alternatives like "function points" exist. + + + +##### **Estimation approaches** +- **algorithmic cost modelling** + develop (from past data) a model relating size/complexity to ultimate cost +- **expert consensus** + get a bunch of expert estimates; compare, discuss, and repeat until convergence +- **analogy** + relate the cost to that of similar completed projects +- ***what customer will pay*** + dangerous... + + + + +- **COCOMO I** + - [+] A long-standing algorithmic model, publicly available, well supported and widely used. + - $$ \text{Effort} = \text{A} \times \text{Size}^\text{B} \times \text{M} $$ + - **Effort** is measured in person-months + - **A** is a constant, dependent on kind of software *and* developing organisation + - **B** typically range in $$1\ldots 1.5$$. + - **M** is a *multiplier*. Product of 15 factors, each typically in range $0.9\ldots 1.4$, that are derived from ratings of attributes such as: *required reliability*, *required time to market*, *software engineer capability*, ... + - [- ] Getting good values for **A**, **B**, and **M** is highly non-trivial. + - [+] Considerable data available too. + - Different versions, sub-models, tweaks available. + +#### "Scheduling" + +- **Why do projects almost always slip?** + - *"People tend to be risk-averse when there is a potential of loss"* + - *"People are unduly optimistic in their plans and forecasts"* + - *"People prefer to use intuitive judgement rather than (quantitative) models"* + + + +- **Gantt Charts** + - Divide project into **tasks**, with **milestones** at the end. + - Analyse dependencies between tasks. + - Lay these tasks out as **bars running across time**, *respecting dependencies*. + - The graph reveals the **critical path** of tasks for the project. + - Optionally, show **permissible slippage** with shaded bars. + - For example: + - ![1543585250853](2C-SE.assets/1543585250853.png) + - ![1543585265509](2C-SE.assets/1543585265509.png) + + + +#### The Rest + +- **Tracking** + - A balance between too little and too much information to track. + - One is insufficient, one is too much to process and manage! +- **Revising the Project Plan** + - As the project goes on, estimates have to be revised in the light of progress, unforeseen problems, in other words, recent developments! + +## 20 November 2018 + +### Non-Functional Requirements (NFR) + +- **Concerns the whole system, not just the software** +- About + - Ways the system needs to be related to other system and versions of itself: + - flexibility + - maintainability + - reusability + - portability + - Properties of the system in use + - usability + - *dependability* + - safety, reliability, availability, resilience + - *efficiency* + - *performance* (throughput, response time), resource usage + - *security* + - integrity, confidentiality + - scalability +- NFRs must be identified along with functional requirements -- at the end is to late. +- **Often tied up with architectural decisions** which are almost impossible to modify later. +- It is essential to + - **quantify the requirement** + - **have ways to measure -- *metrics*** + +### Metrics + +- Ideally, metrics are + - **measurable** + not based on "intuition" or "opinions" of someone + - **specified with a precision** + *i.e.* uncertainities must be recorded + - **MEANINGFUL** + numbers must have something to do with something we care about! + +#### Reliability Metric + +![1543668447275](2C-SE.assets/1543668447275.png) + +- **Reliability is a key non-function requirement in many systems.** +- **There are several ways to specify reliability requirements, depending on the nature of the system.** + +##### POFOD - Probability of Failure on Demand + +- POFOD is the probability that the system will fail when service is requested. +- **Mainly useful for systems that provide emergency or safety services.** + - *e.g.* the emergency shutdown in a nuclear power plant will (hopefully) never be used -- but if it is, it should not fail! +- Can be evaluated through... + - ...repeated tests in simulation. + - which might be expensive. + - ...static analysis of the whole system + - which is definitely expensive, and to ensure that our analysis is correct, some real-world testing would be required. + +##### ROCOF - Rate of Occurrence of Failure + +- ROCOF is the number per unit time of failures (*i.e.* unexpected behaviour). +- **Time may mean *elapsed time*, *processing time*, *Number of Transactions*, *etc.*** +- **Mainly used for systems providing regular service, where failure is significant.** + - *e.g.* banking systems + - VisaNet processes over 10^9^ transactions/day. Failure rate is not published, but probably (much) less than 10^-5^ failures/transaction. + +##### MTTF & MTBF - Mean Time To/Between Failures + +- **MTTF is used when system is non-repairable.** + - *e.g.* often in the case of hardware +- **MTBF is used when system can recover from failures.** + - *e.g.* operating system crashes +- **Both are mainly used where a single client uses the system *for a long time*.** + - *e.g.* desktop PCs (and their components), *consumer products* + +- **Keep in mind that *mean* alone is often insufficient to be decisive:** + - Variation matters! + ![1543667647524](2C-SE.assets/1543667647524.png) + - Whilst the component whose MTTF is shown with the red curve is more predictable to fail after MTTF whilst the blue curve indicates that the failure might occur much before (or much after) the MTTF. + - *You would like your curve to be sharp & pointy.* + +##### Availability + +- Availability is the portion of the time that the system is "available for use". +- Often quoted as "five nines" (0.99999), "four nines", *etc.* +- **Appropriate for systems offering a *continuous service*, where clients expect it to be there all the time.** +- Often achieved by large data processing systems, such as mainframes. +- **The difference between availability and ROCOF** is that availability takes the time to recover from a failure into consideration too; *availability gives a better overall picture.* + - For instance your ROCOF might be once in a year, but if it takes you 3 months to recover, that's not high availability. + +### Usability + +- We'll concern ourselves with User Interfaces (UI) only. +- *Most user errors are actually interface design failures.* + + + +- **Human Limitations:** Humans... + - ...have very limited short-term memory: 5-7 items. + - ...make mistakes, especially under stress. + - ...vary widely, capability-wise, preference-wise, and so on. + - ...organise their perceived world differently! + + + +#### Principles of UI Design +- **User familiarity** + - The interface should "look familiar" to the users. + - It should use concepts and *entities* (*e.g.* textboxes, buttons, sliders) from existing experience of the users. + +- **Consistency** + - Similar operations should be represented in similar ways. + - *E.g.* Red always indicates a situation that requires caution, or to draw the user's attention; yellow indicates recoverable failure, ... + - Consistency should be enforced (at least) across the application, but many "systems" (Android, iOS, ...) also enforce it across *all applications*. + - Brands enforce their own consistency too! Microsoft and Google apps look alike across all the platforms. + - *Beware that similarity might not always be well defined!* +- **Minimal surprise** + - Avoid situations where the user will be surprised by the behaviour of the system. + - Often is the case with *modal* applications where different keys have different effects in different modes. +- **Recoverability** + - Allow the user to recover (easily) from errors. + - *Reversibility* (*i.e.* being able to undo) is relevant here. + - Checkpointing/autosaving is a valuable technique. +- **User guidance** + - Kindly guide the user for taking the appropriate action through your UI. + - As opposed to demanding them read 100 pages long manual. + - Provide *meaningful* (*i.e.* actionable) error messages. + - *E.g.* Bad: "File Save Error" Good: "File could not be saved because disk is full; open up some space and try again." + - This is not always easy of course, there are tons of assumptions we make within our abstractions which --when violated-- does not yield a meaningful error message. +- **User diversity** + - Remember that users vary on numerous levels on various axes. + - Healthy, colour-blind, blind + - Healthy, hearing-impaired, deaf + - Fluent in English, intermediate, doesn't know English, or even illiterate! + - Power users, casual users + - Wherever possible, provide choices for *customisability*. + - Often there are legal obligations about *accessibility*. + +#### Task Analysis + +1. What tasks users want to do with the system? +2. In what order and combination? + + + +- *E.g.* Information should be presented wherever it is required. + - AND to reduce the clutter, *information should not be represented wherever it is not required.* +- Running through user stories and use cases are often useful here. + + + +#### User Interaction + +- How do users interact with the system? + + + +- **Direct manipulation** + such as drag-and-drop +- **Menu selection** + perhaps on a directly selected object +- **Form fill-in** + typically used for data entry +- **Command language** + typically used by traditional systems (UNIX) +- **Natural language** + sometimes as a front end to a command language, but more advanced versions have emerged such as Siri, using NLP +- **Body language** + such as Nintendo Wii, or XBox Kinect + + + +#### Information Presentation + +- How should information be presented to the user? + - This has *nothing* to do with the way information is represented internally. + +- Continuously varying information is best represented in an analogue representation (*i.e.* continuous graphs), not as numbers. + - *Data visualisation* +- **Presentation should depend on the audience: *e.g.* graphs vs graphics.** + + + +#### Colour +- Use few colours *consistently*, no more than four or five per context and no more than seven in total. +- Colour changes should signal something significant. +- Be careful about colour pairings (*e.g.* do not put red on blue background). + - Contrast also affects accessibility; low contrast is harder to process visually (in general, but especially for the visually impaired). +- In general, vary colours along only one of the three dimensions (hue, saturation, brightness) to make a distinction. +- Know the output technology; primary green is often unreadable on screen but fine in print. +- Remember that around 10% of men are red-green colour-blind! + +#### Interface design and evaluation +- Design iteratively. +- Only real end users are good judges of the interface; testing is important. + - Evaluation is hard; get professionals, read HCI books. +- In expensive or critical software, involve professional from appropriate fields (*e.g.* ethnography). + +## 22 November 2018 + +### Intellectual Property (IP) + +> IP is not property, and it’s not intellectual. It resists definition, but one definition of IP might be: *a monopoly right to exploit an intangible product of human thought or labour.* + +Several broad categories: + +- **copyright** applies to literary or artistic works +- **patents** apply to inventions of things or processes +- **design rights** apply to design of products +- *none of these were invented with software in mind...* + +#### Patents + +- Arose to protect *inventors* of physical objects or processes. +- **Stronger than copyright** + - stops other people using/making object even if they invented it independently +- **Duration is sorter** -- 17 years +- **Software patents are controversial** + - In U.S., yes; in Europe, no (roughly speaking). + - In U.S., *business processes* are patentable (*e.g.* Amazon has patents on *one-click* shopping, and on the idea of customers reviewing products!). + +#### Copyright + +- Copyright protects *the expression of an idea*, not the idea itself. + - *The original IP.* +- Restricts the ability to copy, adapt, *etc.* artistic or literary works. +- **Unlike patents, no merit [invention] is required; this document is a literary work for copyright purposes.** +- **Duration is longer** -- life of author + ~70 years. +- **The protected rights may be *assigned* in whole or in part, or *licensed* in whole or in part, with or without restrictions.** +- Source code is subject to copyright. + - Object code and machine code are *adaptations or translations* of source code, hence protected. + +- Clean-room reverse engineering is permissible under many jurisdictions. + +#### Licenses + +- Can be licensed per computer, per user, or per CPU cores! +- Sometimes it's the license to access and use a website. + - *E.g.* Office 365 +- Shareware/Fremimum, Free Open Source, Proprietary, ... +- GPL -- General Public License + - **copyleft** -- modifications or adaptations of the work (including other works which depends on it) must be licensed under the same license. + - As a result, *copyleft licenses are incompatible with each other*. +- LGPL -- Lesser General Public License + - **weak copyleft** -- same as GPL, except other works which depends on our work does *not* have to be licensed under the same license. + - Again, incompatible with other copyleft licenses. + + + +Choosing a license may depend on: + +- **philosophy** + some consider restricting software to be unethical, some motivated by utilitarian views... +- **legal constraints** + you may have used other software that restricts your choices (proprietary or copyleft). +- **business relevance** + sharing the most valuable asset of your company might not be the best business strategy! +- **support** + do you want your users to contribute? + +## 27 November 2018 + +### Ethics + +> Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a *beneficial* and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles: +> +> 1. **PUBLIC** --- Software engineers shall act consistently with the public interest. +> 2. **CLIENT AND EMPLOYER** --- Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. +> 3. **PRODUCT** --- Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. +> 4. **JUDGEMENT** --- Software engineers shall maintain integrity and independence in their professional judgement. +> 5. **MANAGEMENT** --- Software engineering mangers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. +> 6. **PROFESSION** --- Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. +> 7. **COLLEAGUES** --- Software engineers shall be fair to and supportive of their colleagues. +> 8. **SELF** --- Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. + +https://ethics.acm.org/code-of-ethics/software-engineering-code/ + +- **You should be able to answer, given an example, which codes of ethics the incident violates.** \ No newline at end of file diff --git a/2C-SE.tex b/2C-SE.tex new file mode 100644 index 0000000..8058fdc --- /dev/null +++ b/2C-SE.tex @@ -0,0 +1,3035 @@ +\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere +\PassOptionsToPackage{hyphens}{url} +% +\documentclass[a4paper]{article} +\usepackage{tipa} % for IPA +\usepackage{lmodern} +\usepackage{amssymb,amsmath} +\usepackage{ifxetex,ifluatex} +\usepackage{fixltx2e} % provides \textsubscript +\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex + \usepackage[T1]{fontenc} + \usepackage[utf8]{inputenc} + \usepackage{textcomp} % provides euro and other symbols +\else % if luatex or xelatex + \usepackage{unicode-math} + \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase} +\fi +% use upquote if available, for straight quotes in verbatim environments +\IfFileExists{upquote.sty}{\usepackage{upquote}}{} +% use microtype if available +\IfFileExists{microtype.sty}{% +\usepackage[]{microtype} +\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts +}{} +\IfFileExists{parskip.sty}{% +\usepackage{parskip} +}{% else +\setlength{\parindent}{0pt} +\setlength{\parskip}{6pt plus 2pt minus 1pt} +} +\usepackage{hyperref} +\hypersetup{ + pdfborder={0 0 0}, + breaklinks=true} +\urlstyle{same} % don't use monospace font for urls +\usepackage{color} +\usepackage{fancyvrb} +\newcommand{\VerbBar}{|} +\newcommand{\VERB}{\Verb[commandchars=\\\{\}]} +\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}} +% Add ',fontsize=\small' for more characters per line +\newenvironment{Shaded}{}{} +\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}} +\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} +\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{#1}} +\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}} +\newcommand{\BuiltInTok}[1]{#1} +\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} +\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{#1}}} +\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} +\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{#1}} +\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}} +\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{#1}} +\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}} +\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{#1}}} +\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}} +\newcommand{\ExtensionTok}[1]{#1} +\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}} +\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{#1}} +\newcommand{\ImportTok}[1]{#1} +\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} +\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}} +\newcommand{\NormalTok}[1]{#1} +\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{#1}} +\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{#1}} +\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{#1}} +\newcommand{\RegionMarkerTok}[1]{#1} +\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} +\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{#1}} +\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} +\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{#1}} +\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}} +\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}} +\usepackage{graphicx,grffile} +\makeatletter +\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi} +\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi} +\makeatother +% Scale images if necessary, so that they will not overflow the page +% margins by default, and it is still possible to overwrite the defaults +% using explicit options in \includegraphics[width, height, ...]{} +\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio} +\setlength{\emergencystretch}{3em} % prevent overfull lines +\providecommand{\tightlist}{% + \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}} +\setcounter{secnumdepth}{0} +% Redefines (sub)paragraphs to behave more like sections +\ifx\paragraph\undefined\else +\let\oldparagraph\paragraph +\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}} +\fi +\ifx\subparagraph\undefined\else +\let\oldsubparagraph\subparagraph +\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}} +\fi + +% set default figure placement to htbp +\makeatletter +\def\fps@figure{htbp} +\makeatother + + +\date{} + +\usepackage{fancyhdr} +\pagestyle{fancy} +\rhead{Copyright \textcopyright\ 2018, Bora M. Alper} +\cfoot{\thepage} + +\begin{document} + +\hypertarget{2c-se---software-engineering---notes}{% +\section{2C (SE) - Software Engineering - +Notes}\label{2c-se---software-engineering---notes}} +Revision 2018-12-01T18:40Z + +Based on \href{http://homepages.inf.ed.ac.uk/pbj/}{Paul Jackson}'s lecture slides. + +\begin{description} + \item[\textit{caveat emptor} (/\textipa{[\textsecstress kæv\textepsilon\textscripta\textlengthmark t \textprimstress\textepsilon mpt\textopeno\textlengthmark r]}/)] ``Let the buyer beware.'' A principle in commerce: without a warranty the buyer takes the risk. +\end{description} + +\vfill +\begin{center} + \includegraphics [width=2in] {2C-SE.assets/output1000.png} +\end{center} + +\tableofcontents +\newpage + +\hypertarget{18-september-2018}{% +\subsection{18 September 2018}\label{18-september-2018}} + +\hypertarget{software-engineering-activities}{% +\subsubsection{Software Engineering +Activities}\label{software-engineering-activities}} + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + Requirements Capture +\item + Design +\item + Construction/Implementation +\item + Testing \& Debugging +\item + Maintenance/Evolution +\end{enumerate} + +\hypertarget{4-october-2018}{% +\subsection{4 October 2018}\label{4-october-2018}} + +\hypertarget{identifying-classes-and-operations}{% +\subsubsection{Identifying Classes and +Operations}\label{identifying-classes-and-operations}} + +\begin{itemize} +\item + Identifying Classes + + \begin{itemize} + \tightlist + \item + Ignore all non-nouns and instead focus on the \emph{nouns} in the + \emph{project description}. + \end{itemize} +\item + Identifying Operations +\item + Focus on \emph{verbs} instead. +\end{itemize} + +\textbf{In both cases, use your judgement again to eliminate some +concepts for further simplicity and clarity.} + +\textbf{Beware of subclassing/inheritance relationships between classes +(or of its concepts).} + + + +\hypertarget{18-october-2018}{% +\subsection{18 October 2018}\label{18-october-2018}} + +\hypertarget{software-configuration-management}{% +\subsubsection{Software Configuration +Management}\label{software-configuration-management}} + +\begin{itemize} +\tightlist +\item + Version Control +\item + Compiling (and \emph{Building} as a general idea) +\end{itemize} + +\hypertarget{version-control}{% +\subsubsection{Version Control}\label{version-control}} + +\begin{itemize} +\item + Lock-Modify-Unlock Model \emph{{[}OLD{]}} + + \begin{itemize} + \item + Advantages + + \begin{itemize} + \tightlist + \item + Very simple. + \item + Central source of truth. + \end{itemize} + \item + Disadvantages + + \begin{itemize} + \tightlist + \item + Multiple developers cannot work on the same file. + \item + Deadlocks might occur (especially if scripts are doing some + maintenance work on the repo for instance, say linting multiple + files). + \item + Requires access to repo at all times (\emph{e.g.} you cannot + checkout a file to modify it during the holiday, lest it will be + inaccessible for a week). + \end{itemize} + \end{itemize} +\item + Copy-Modify-Merge \emph{{[}NEW{]}} + + \begin{itemize} + \item + Advantages + + \begin{itemize} + \tightlist + \item + Multiple developers can work on the same file at the same time. + \item + Deadlocks cannot occur since there is no locking. + \item + Distributed repositories might be beneficial for certain + development. models (\emph{i.e.} open-source projects where every + contributor might want to have a full-access). + \item + Does not require access to repo at all times. + \end{itemize} + \item + Disadvantages + + \begin{itemize} + \tightlist + \item + More complicated than Lock-Modify-Unlock model. + \item + Multiple sources of truth (though in reality there is often a + master repo). + \item + Merge conflicts happen, and they are not uncommon. + \item + Automatic merging used to be faulty sometimes but software are + getting better. + \item + Not every file-type is \emph{mergable}, such as photographs, PDF + documents, audio files, or spreadsheets. + + \begin{itemize} + \tightlist + \item + \textbf{Merging requires certain assumptions about the file + semantics.} + \end{itemize} + \end{itemize} + \end{itemize} +\end{itemize} + + + +\begin{itemize} +\item + Three-Way Merge + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \item + Original File: + +\begin{verbatim} +Alpha +Bravo +Charlie +\end{verbatim} + \item + Tester 1 edits the Original File: + +\begin{verbatim} +Alpha +Foxtrott +Charlie +\end{verbatim} + \item + Tester 2 edits the Original File: + +\begin{verbatim} +Delta +Alpha +Echo +Charlie +\end{verbatim} + \item + Tester 2 commits changes. + \item + Tester 1's commit fails. + \item + Tester 1 updates and merge reports conflicts: + +\begin{verbatim} +Delta +Alpha +<<<<<< .mine +Foxtrott +====== +Echo +>>>>>> .r4 +Charlie +\end{verbatim} + \item + Tester 1 now has to choose whether to retain her or Tester 2's + version. + \end{enumerate} +\end{itemize} + +\hypertarget{compiling-and-building}{% +\subsubsection{Compiling and Building}\label{compiling-and-building}} + +\begin{itemize} +\item + C + + \begin{itemize} + \tightlist + \item + Make \emph{{[}OLD{]}} + \item + CMake \emph{{[}NEW{]}} + \end{itemize} +\item + Java + + \begin{itemize} + \tightlist + \item + Ant \emph{{[}OLD{]}} + \item + Maven \emph{{[}NEW{]}} + \end{itemize} +\end{itemize} + +\hypertarget{23-october-2018}{% +\subsection{23 October 2018}\label{23-october-2018}} + +\hypertarget{refactoring}{% +\subsubsection{Refactoring}\label{refactoring}} + +\begin{itemize} +\item + \textbf{As code evolves its quality naturally decays.} + + \begin{itemize} + \tightlist + \item + Because \textbf{changes are often local, without full understanding + of the context.} + \end{itemize} +\item + \textbf{Refactoring}, is about restoring good design in a + \emph{disciplined way}. + + \begin{itemize} + \tightlist + \item + There are \textbf{refactoring patterns}. + + \begin{itemize} + \tightlist + \item + There are patterns for everything in Software Engineering... + \end{itemize} + \end{itemize} +\item + \emph{Refactoring is changing \textbf{internal} structure of software + to make it:} + + \begin{itemize} + \tightlist + \item + \emph{easier to understand, and} + \item + \emph{cheaper to modify} + \end{itemize} + + \emph{\textbf{without changing its observable behaviour.}} +\item + Refactoring was once seen as a kind of maintenance, but it can also be + an integral part of the development process! + + \begin{itemize} + \tightlist + \item + Agile methodologies (\emph{e.g.} XP) advocate continual refactoring. + \end{itemize} +\item + \textbf{A refactoring is a \emph{small} transformation.} + + \begin{itemize} + \tightlist + \item + Do NOT confuse it with \textbf{rewrite}. + \end{itemize} +\item + To ensure that refactoring hasn't \textbf{changed}/broken something? + + \begin{itemize} + \tightlist + \item + \emph{test, refactor, test} + \end{itemize} +\end{itemize} + +\hypertarget{bad-code-smells}{% +\subsubsection{Bad Code Smells}\label{bad-code-smells}} + +\begin{itemize} +\tightlist +\item + Duplicated code +\item + Long methods +\item + Large classes +\item + Long parameter lists +\item + Lazy classes \emph{i.e.} Classes that are ridiculously small. +\item + Long message chains \emph{i.e.} Having too many (unnecessary) + indirections. +\end{itemize} + +\hypertarget{25-october-2018}{% +\subsection{25 October 2018}\label{25-october-2018}} + +\hypertarget{verification-validation-and-testing-vvt}{% +\subsubsection{Verification, Validation, and Testing +(VV\&T)}\label{verification-validation-and-testing-vvt}} + +\begin{itemize} +\tightlist +\item + \textbf{VV\&T} generally refers to all techniques for improving + \textbf{product quality}. +\item + \textbf{Verification:} are we building the software \emph{right}? + + \begin{itemize} + \tightlist + \item + Does software meet requirements? + \item + \emph{Static analysis, reviews, inspections, walk-throughs} + \end{itemize} +\item + \textbf{Validation:} are we building the \emph{right software}? + + \begin{itemize} + \tightlist + \item + Does software accommodate customers' needs? + \item + \emph{Prototyping, early releases} + \item + Validation is more general than verification. + \end{itemize} +\item + \textbf{Testing is a useful technique for both.} +\end{itemize} + +\hypertarget{testing}{% +\subsubsection{Testing}\label{testing}} + +\begin{itemize} +\tightlist +\item + In essence, testing is + + \begin{itemize} + \tightlist + \item + \emph{Generating stimulus} for a component + \item + \emph{Collecting outputs} from the component + \item + \emph{Checking} if \emph{actual} outputs are as \emph{expected} + \end{itemize} +\item + \textbf{Automation of tests is essential.} + + \begin{itemize} + \tightlist + \item + Speeds up the whole testing process. + \item + \textbf{Makes tests deterministic.} + + \begin{itemize} + \tightlist + \item + Not necessarily always, but definitely more deterministic than a + human being. + \end{itemize} + \end{itemize} +\item + \texttt{assert} statements are common to compare the actual results + and expectations. + + \begin{itemize} + \tightlist + \item + \textbf{Checks can also be spread throughout the program code + itself.} + \end{itemize} +\end{itemize} + +\hypertarget{kinds-of-tests}{% +\paragraph{Kinds of Tests}\label{kinds-of-tests}} + +\begin{itemize} +\tightlist +\item + Testing approaches: + + \begin{itemize} + \tightlist + \item + \textbf{Black-Box Testing} purely specification-based (treating the + component as a "black box") + \item + \textbf{White-Box Testing} also considers the internal structure + \end{itemize} +\item + Kinds of tests: + + \begin{itemize} + \tightlist + \item + \textbf{Module (or Unit) Tests} for each class in OO software + \item + \textbf{Integration Tests} test components interact properly + \item + \textbf{System Tests} check if functional and non-functional + requirements met, \emph{verification} + \item + \textbf{Acceptance Tests} in customer environment, \emph{validation} + \item + \textbf{Stress Tests} look for graceful degradation, not catastrophe + \item + \textbf{Performance Tests} performance is often a non-functional + requirements (\emph{e.g.} in real-time systems) + \item + \textbf{Regression Tests} more like a testing methodology, repeated + full-tests after each modification + \end{itemize} +\end{itemize} + +\hypertarget{how-to-test}{% +\paragraph{How to Test}\label{how-to-test}} + +\begin{itemize} +\tightlist +\item + Tests should be + + \begin{itemize} + \tightlist + \item + \textbf{repeatable} + \item + \textbf{documented} both the tests and the results + \item + \textbf{precise} + \item + \textbf{done on configuration-controlled software} + \end{itemize} +\item + \textbf{Ideally test spec should be written at the same time as the + requirements spec.} + + \begin{itemize} + \tightlist + \item + Tests and requirement features can be cross-referenced! + \item + Use cases can suggest tests. + \item + \textbf{Also helps to ensure \emph{testability} of requirements.} + \end{itemize} +\end{itemize} + +\hypertarget{preconditions-postconditions-invariants}{% +\subsubsection{Preconditions, Postconditions, +Invariants}\label{preconditions-postconditions-invariants}} + +\begin{itemize} +\tightlist +\item + \textbf{Method Precondition} A condition that must be true when a + method is invoked. +\item + \textbf{Method Postcondition} A condition that the method guarantees + to be true when it finishes. +\item + \textbf{Class Invariant} A condition that should \emph{always} be true + for all the instances of a given class. + + \begin{itemize} + \tightlist + \item + \emph{Always} as in all \emph{client-visible} states, that is, + whenever the object is not executing one of its methods! + \end{itemize} +\end{itemize} + +\hypertarget{java-modelling-language-jml}{% +\paragraph{Java Modelling Language +(JML)}\label{java-modelling-language-jml}} + +\begin{itemize} +\item + JML provides + + \begin{itemize} + \tightlist + \item + A richer language (predicate logic) for writing boolean conditions + than Java boolean expressions (propositional logic), for example + allowing \emph{quantifiers} such as \texttt{\textbackslash{}forall} + and \texttt{\textbackslash{}exists}. + \item + Special comment syntax for common assertion types: + + \begin{itemize} + \tightlist + \item + \textbf{Preconditions:} + \texttt{//@\ requires\ x\ \textgreater{}\ 0;} + \item + \textbf{Postconditions:} + \texttt{//@\ ensures\ \textbackslash{}result\ \%\ 2\ ==\ 0;} + \item + \textbf{Invariants:} + \texttt{//@invariant\ name.length\ \textless{}=\ 8;\ } + \item + \textbf{General assertions:} \texttt{//@\ assert\ i\ +\ j\ =\ 12;} + \end{itemize} + \end{itemize} +\item + Examples: + + \begin{itemize} + \item +\begin{Shaded} +\begin{Highlighting}[] +\CommentTok{//@ requires x >= 0.0} +\CommentTok{/*@ ensures JMLDouble} +\CommentTok{ @ .approximatelyEqualTo} +\CommentTok{ @ (x, \textbackslash{}result * \textbackslash{}result, eps);} +\CommentTok{ @*/} +\KeywordTok{public} \DataTypeTok{static} \DataTypeTok{double} \FunctionTok{sqrt}\NormalTok{(}\DataTypeTok{double}\NormalTok{ x) \{} + \CommentTok{/*...*/} +\NormalTok{\}} +\end{Highlighting} +\end{Shaded} + \item +\begin{Shaded} +\begin{Highlighting}[] +\CommentTok{/*@ requires a != null} +\CommentTok{ @ && (\textbackslash{}forall int i;} +\CommentTok{ @ 0 < i && i < a.length;} +\CommentTok{ @ a[i-1] <= a[i]);} +\CommentTok{ @*/} +\DataTypeTok{int} \FunctionTok{binarySearch}\NormalTok{(}\DataTypeTok{int}\NormalTok{[] a, }\DataTypeTok{int}\NormalTok{ x) \{} + \CommentTok{// ...} +\NormalTok{\}} +\end{Highlighting} +\end{Shaded} + + \begin{itemize} + \item + \begin{quote} + Note that this universally quantified expression in JML must have + parentheses around it, \texttt{(\textbackslash{}forall\ ...\ )}. + \end{quote} + \item + \begin{quote} + The range is optional, but if omitted, such a universally + quantified expression may not be executable; it can still be used + for documentation purposes, however. + \end{quote} + \end{itemize} + \end{itemize} +\item + \begin{quote} + In return for the benefit of faster understanding, modular reasoning + imposes a cost. This cost is that clients are not allowed to conclude + anything that is not justified by the contracts of the methods that + they call. Another way of looking at this is that, to allow modular + reasoning with contract specifications, \textbf{the client code must + work for every implementation that satisfies the contract.} + \end{quote} + + \begin{itemize} + \item + \begin{quote} + Otherwise, the implementation would no longer be free to change the + algorithm used. + \end{quote} + \end{itemize} +\item + \begin{quote} + There are other good reasons not to use code as contracts. + \textbf{Code makes a poor contract, because by only using code one + cannot convey to readers what is intended (i.e., what the + \emph{essential properties} of the method are) and what parts are + merely implementation decisions (\emph{accidental features}).} + \end{quote} + + \begin{itemize} + \item + \begin{quote} + For example, if the code for \texttt{sqrt} computes square roots to + 7 decimal places, cannot this be changed in the next release? + Without some separate description of what is intended, the reader + can't tell if that 7 decimal places were intended, or just happened + to be computed; perhaps 4 decimal places are all that is necessary + for the rest of the program. + \end{quote} + \end{itemize} +\item + Some tools such as \emph{jmlc, jmlrac, etc.} compile and run + JML-annotated Java code into bytecode with specific \textbf{runtime + assertion checking}. +\item + \textbf{Assertions can also be used on \emph{inputs} to + \emph{constrain} the \emph{random generation of input data}.} + + \begin{itemize} + \tightlist + \item + QuickCheck! + \end{itemize} +\end{itemize} + +\emph{Quotes from:} +\href{http://www.eecs.ucf.edu/~leavens/JML//jmldbc.pdf}{http://www.eecs.ucf.edu/\textasciitilde{}leavens/JML//jmldbc.pdf} + +\hypertarget{kinds-of-bugs}{% +\subsubsection{Kinds of Bugs}\label{kinds-of-bugs}} + +\begin{itemize} +\item + In order of increasing severity: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \tightlist + \item + \textbf{Mistake} A human action that produces a fault. + \item + \textbf{Fault (Defect)} An incorrect step, process, or data + definition in a computer program. + \item + \textbf{Error} A difference between some computed value and the + correct value. + \item + \textbf{Failure} The software (or whole system) failing to deliver + some service it is expected to deliver. + \end{enumerate} + + \begin{itemize} + \tightlist + \item + \textbf{Faults do not necessarily lead to errors.} + \item + \textbf{Errors do not necessarily lead to failures.} + \end{itemize} +\end{itemize} + +\hypertarget{test-first-development}{% +\subsubsection{Test-First Development}\label{test-first-development}} + +\begin{itemize} +\item + \textbf{Motivation:} Tests implicitly define... + + \begin{itemize} + \tightlist + \item + interface, and + \item + \textbf{specification of behaviour} + \end{itemize} + + for the functionality being developed. +\item + \textbf{Writing tests first often clarifies requirements!} + + \begin{itemize} + \tightlist + \item + Testing code demands more precision than an English specification. + \end{itemize} +\item + \textbf{Idea} is + + \begin{itemize} + \tightlist + \item + write tests \textbf{before} writing the code they apply to, + \item + run tests as code is written. + \item + \emph{In an ideal world, the system will be complete when all your + tests pass. :)} + \item + \textbf{TFD avoids poor ambiguity resolution.} + + \begin{itemize} + \tightlist + \item + Instead of choosing what is easiest to implement in the face of + ambiguity, you will implement the right thing (that your tests + check for). + \end{itemize} + \end{itemize} +\item + \textbf{Consequently} + + \begin{itemize} + \tightlist + \item + bugs found at earliest possible point of development + \item + locating bugs are relatively easy (due to locality of tests) + \item + \textbf{TFD ensures adequate time for test writing.} + + \begin{itemize} + \tightlist + \item + Often testing time is squeezed or eliminated. + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{test-driven-development}{% +\subsubsection{Test-Driven Development}\label{test-driven-development}} + +\begin{itemize} +\tightlist +\item + A subtly different term, covers the way that in Extreme Programming + detailed tests \emph{replace} a written specification. +\end{itemize} + +\hypertarget{limitations-of-testing}{% +\subsubsection{Limitations of Testing}\label{limitations-of-testing}} + +\begin{itemize} +\item + \textbf{Writing tests is time-consuming} +\item + \textbf{Coverage almost always limited} may happen not to exercise a + bug. +\item + \textbf{Difficult/impossible to emulate live environment perfectly} + \emph{e.g.} \emph{race conditions} that appear under real load + conditions can be hard to find by testing. +\item + \textbf{Can only test executable things} mainly code, or certain kinds + of model -- not high level design or requirements. +\end{itemize} + +\hypertarget{reviews-walkthroughs-inspections}{% +\subsubsection{Reviews, Walkthroughs, +Inspections}\label{reviews-walkthroughs-inspections}} + +\begin{itemize} +\tightlist +\item + \includegraphics{2C-SE.assets/1542636369213.png} +\item + \includegraphics{2C-SE.assets/1542636375661.png} +\end{itemize} + +\hypertarget{static-analysis}{% +\subsubsection{Static Analysis}\label{static-analysis}} + +\begin{itemize} +\tightlist +\item + Static analysis is \textbf{the inspection of the code to determine + properties of it \emph{without running it}.} + + \begin{itemize} + \tightlist + \item + When contrasted with testing, testing is called \emph{dynamic + testing}. + \end{itemize} +\item + \textbf{Type-checking} during compilation is a basic kind of static + analysis. +\item + \textbf{Trade-offs} + + \begin{itemize} + \tightlist + \item + As the properties checked get more complicated, + + \begin{itemize} + \tightlist + \item + only smaller programs can be analysed. + \item + the process is less automated (\emph{e.g.} \textbf{annotations} + required). + \end{itemize} + \item + As tools are more automated and designed to work on larger programs, + they often \emph{cannot} + + \begin{itemize} + \tightlist + \item + guarantee every problem flagged is a real error (\emph{i.e.} + false-positives) + \item + find every error (\emph{i.e.} false-negatives). + \end{itemize} + \item + The latter kind of tools are more to aid bug-hunting than ensuring + \emph{correctness}. + \end{itemize} +\end{itemize} + +\hypertarget{1-november-2018}{% +\subsection{1 November 2018}\label{1-november-2018}} + +\hypertarget{deployment}{% +\subsubsection{Deployment}\label{deployment}} + +\begin{itemize} +\tightlist +\item + Getting software out of the hands of the developers into the hands of + the users. +\item + More than 50\% of commissioned software is not used, mostly because it + fails at deployment stage. +\end{itemize} + +\hypertarget{key-issues}{% +\paragraph{Key Issues}\label{key-issues}} + +\begin{itemize} +\item + \textbf{Business processes} Most large software systems require the + customer to change the way they work; has this been properly thought + through? +\item + \textbf{Training} +\item + \textbf{Deployment itself} How \emph{physically} to get the software + installed. +\item + \textbf{Equipment} Is the customers' hardware up to the job? +\item + \textbf{Expertise} Does the customer have the IT expertise to install + \& use the software? +\item + \textbf{Integration} How will the software integrate with other + systems of the customers'? +\item + "Installing" is the easiest part of deployment... +\end{itemize} + +\hypertarget{maintenance}{% +\subsubsection{Maintenance}\label{maintenance}} + +The process of \emph{changing a system after it has been delivered}. + +\begin{itemize} +\tightlist +\item + \textbf{Fixing bugs and vulnerabilities} not only in code, but also + design and requirements +\item + \textbf{Adapting to new platforms and software environments} + \emph{e.g.} new hardware, new OSes, new software/systems to + integrate... +\item + \textbf{Supporting new features and requirements} necessary as + operating environments change in response to competitive pressures. +\end{itemize} + +\hypertarget{challanges}{% +\paragraph{Challanges}\label{challanges}} + +\begin{itemize} +\tightlist +\item + \textbf{(Un)popularity of maintenance work:} + + \begin{itemize} + \tightlist + \item + Unpopular -\/- seen as less skilled, can (and often does) involve + obsolete languages. + \end{itemize} +\item + Often a new team has to understand the software. +\item + \textbf{Development and maintenance often separate business + contracts.} +\item + Things often degrade over time. +\item + Working with obsolete compilers, OSes, hardware... +\end{itemize} + +\hypertarget{re-engineering}{% +\subsubsection{Re-engineering}\label{re-engineering}} + +\begin{itemize} +\tightlist +\item + \textbf{Source code translation} \emph{E.g.} from obsolete language, + or assembly, to modern language, ... +\item + \textbf{Reverse engineering} \emph{I.e.} analysing the program, + possibly in the absence of source code! +\item + \textbf{Structure improvement} Especially modularisation, + architectural refactoring, ... +\item + \textbf{Data re-engineering} Reformatting and cleaning up data. +\item + \textbf{Adding adaptor interfaces \textless{}3} to users and newer + other software +\end{itemize} + +\hypertarget{issues}{% +\paragraph{Issues}\label{issues}} + +\begin{itemize} +\tightlist +\item + Specification might be lost as well... +\item + Which bugs do you deliberately preserve? +\end{itemize} + +\hypertarget{bug-reporting}{% +\subsubsection{Bug Reporting}\label{bug-reporting}} + +\begin{itemize} +\item + Many projects use a \emph{bug tracking system} for both bug reports + and new feature requests. +\item + These provide extensive support for \emph{receiving}, \emph{tracking}, + notifying, monitoring, \emph{etc.} +\item + Each \emph{ticket} has a + + \begin{itemize} + \tightlist + \item + unique \textbf{ticket number} + \item + \textbf{summary} + \item + \textbf{component} where the bug is observed (it might not always be + clear; sometimes bugs arise out of integration issues) + \item + \textbf{version} of the program + \item + \textbf{milestone} in which this bug is aimed to be fixed + \item + \textbf{type} \emph{e.g.} \emph{defect}, or maybe \emph{enhancement} + for feature requests! + \item + \textbf{owner} \emph{i.e.} the creator of the ticket + \item + \textbf{assignee} \emph{i.e.} the person responsible for the + resolution of the ticket + \item + \textbf{status} \emph{new}, \emph{assigned}, \emph{notabug} if the + developers think it's not a bug, \emph{resolved}, ... + \item + \textbf{priority} some bugs and/or feature requests are more + important than others! + \item + and much more! + \end{itemize} +\item + When \textbf{reporting bugs}: + + \begin{itemize} + \tightlist + \item + Include tediously detailed information about + + \begin{itemize} + \tightlist + \item + what \emph{exactly} you did + + \begin{itemize} + \tightlist + \item + so that bug can be \emph{reproduced} + \end{itemize} + \item + what did you expect to happen + \item + what happened instead + \end{itemize} + \item + Include full information about the system \& environment such as + + \begin{itemize} + \tightlist + \item + operating system + \item + hardware (processor, graphics card, ...) + \end{itemize} + \item + Make an intelligent attempt at diagnosing the problem if you can. + + \begin{itemize} + \tightlist + \item + Keep your \emph{diagnosis} completely separate from the report of + \emph{what happened}. + \end{itemize} + \item + Add a concise summary at the beginning. + \item + Do \textbf{not} omit information you think is irrelevant; you are + probably wrong in what you think. + \end{itemize} +\end{itemize} + +\hypertarget{8-november-2018}{% +\subsection{8 November 2018}\label{8-november-2018}} + +\hypertarget{software-processes}{% +\subsubsection{Software Processes}\label{software-processes}} + +\begin{itemize} +\tightlist +\item + A process is \emph{"a set of activities and way of + organising/coordinating those activities in order to produce a + software system."} +\item + \textbf{Activities:} + + \begin{itemize} + \tightlist + \item + \textbf{Software Specification} goals, functionality, and + constraints + \item + \textbf{Software Development} producing software: design, + construction, verification + \item + \textbf{Software Validation} ensuring that software accommodates the + customers' needs + \item + \textbf{Software Evolution} adapting software to changing needs and + requirements + \end{itemize} +\item + Processes are about \emph{management}: + + \begin{itemize} + \tightlist + \item + ordering activities + \item + outcomes of activities + \item + allocating people and resources + \item + planning in advance, predicting time/cost/resource usage + \item + \textbf{monitoring} + \item + \textbf{risk reduction} + \end{itemize} +\item + \textbf{Process models} are \emph{ideals}, in practice mix and match! +\end{itemize} + +\hypertarget{waterfall-model}{% +\paragraph{Waterfall Model}\label{waterfall-model}} + +\includegraphics{2C-SE.assets/1543142448637.png} + +\textbf{Pros:} + +\begin{itemize} +\tightlist +\item + Better than no process at all, makes clear that requirements must be + analysed, software must be tested, \emph{etc.} +\item + Suitable for + + \begin{itemize} + \tightlist + \item + very slowly evolving systems where high-reliability, safety + \emph{etc.} are top priorities (\emph{e.g.} engine control unit of a + car), in other words, \textbf{safety-critical} + \item + for \textbf{embedded systems} where resources are extremely limited + and deployment is often only once (during flashing!), + \item + very \textbf{large systems} where the interaction between multiple + components must be clearly laid out (which also allows simultaneous + development of different components). + \end{itemize} +\end{itemize} + +\textbf{Cons:} + +\begin{itemize} +\tightlist +\item + Inflexible and unrealistic: \emph{e.g.} verification will show up + problems with requirements capture. + + \begin{itemize} + \tightlist + \item + Many real-world application (need to) evolve rapidly in response to + the changing customer needs and competitive market conditions. + \end{itemize} +\item + Slow and expensive: in an attempt to avoid problems later, we end up + "gold plating" early phases. + + \begin{itemize} + \tightlist + \item + \emph{E.g.} Over-engineering at Requirements and Design stage so to + avoid problems during implementation and verification. + \end{itemize} +\end{itemize} + +\hypertarget{spiral-model}{% +\paragraph{Spiral Model}\label{spiral-model}} + +\includegraphics{2C-SE.assets/1543143069292.png} + +\begin{itemize} +\tightlist +\item + \textbf{Cycles} are an essential concept: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \tightlist + \item + Determine \textbf{Objectives} objectives are settled + \item + Identify and Resolve \textbf{Risks} risks identified, alternatives + considered (\emph{e.g.} go for prototype to analyse uncertain + requirements) + \item + \textbf{Development and Test} + \item + \textbf{Review} for the next iteration project reviewed and + decisions made about continuing + \end{enumerate} +\item + \textbf{A key innovation is prominent role of risk.} +\end{itemize} + +\textbf{Pros:} + +\begin{itemize} +\tightlist +\item + Risk plays a prominent role, which is crucial. +\item + Iterative approach is more suitable (than the Waterfall) to + real-world. +\item + Steps are clearly identified. +\end{itemize} + +\textbf{Cons:} + +\begin{itemize} +\tightlist +\item + Loops are still \emph{sequential}, but in real-world it's more of a + back-and-forth, and there is more concurrency (\emph{e.g.} realising + that a requirement has been misunderstood during development forces + you to revise your requirements) +\item + Steps are not as elaborate as UP for instance; no guidelines on how to + proceed with validation, with business modelling, and how the + importance of each varies through the time... +\end{itemize} + +\hypertarget{unified-process}{% +\paragraph{Unified Process}\label{unified-process}} + +\includegraphics{2C-SE.assets/1543143798585.png} + +\begin{itemize} +\tightlist +\item + Again, \textbf{cycles}: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \tightlist + \item + \textbf{Inception} ends with commitment from the \emph{project + sponsor} to go ahead: \emph{business case} for the project and its + basic feasibility \& scope known + \item + \textbf{Elaboration} ends with + + \begin{itemize} + \tightlist + \item + \textbf{basic architecture} of the system in place + \item + a \textbf{plan for construction} agreed + \item + all \textbf{significant risks identified} + \end{itemize} + \item + \textbf{Construction} (definitely \textbf{iterative}) ends with a + beta-release system + \item + \textbf{Transition} is introducing the system to its users + \end{enumerate} +\item + The process for a single product will have several \emph{cycles}. +\item + \textbf{Each instance of a phase might have several iterations.} +\end{itemize} + +\hypertarget{workflows}{% +\subparagraph{Workflows}\label{workflows}} + +\includegraphics{2C-SE.assets/1543144642816.png} + +\textbf{6 Engineering workflows:} + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + \textbf{Business modelling} {[}Inception cycle{]} A key \emph{pro} of + UP is the fact that it includes the \emph{business} side of software + engineering into the software process itself. The fact that + \emph{business modelling} precedes \emph{requirements} evidences that + software is developed to serve a (business) purpose. +\item + Requirements {[}Elaboration cycle{]} +\item + Analysis and design {[}Elaboration cycle{]} +\item + Implementation {[}Construction cycle{]} +\item + Test {[}Construction cycle{]} +\item + Deployment {[}Transition cycle{]} +\end{enumerate} + +\textbf{3 Supporting workflows:} always ongoing workflows in the +background + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + Configuration and change management +\item + Project management +\item + Environment (\emph{e.g.} process and tools) +\end{enumerate} + +\hypertarget{up-best-practises}{% +\subparagraph{UP Best Practises}\label{up-best-practises}} + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + \textbf{Develop software iteratively} +\item + \textbf{Manage requirements} document explicitly, analyse impact + before adopting +\item + \textbf{Use component-based architectures} promote systematic reuse +\item + \textbf{Visually model software} UML... +\item + \textbf{Verify software quality} testing, linting, coding standards +\item + \textbf{Control change to software} configuration management +\end{enumerate} + +\hypertarget{personal-software-process}{% +\paragraph{Personal Software Process}\label{personal-software-process}} + +\begin{itemize} +\item + UNIMPORTANT. +\item + \textbf{PSP provides a ladder of gradually more sophisticated + practises.} +\item + The idea: + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \tightlist + \item + Identify those (UP) large-system \textbf{software methods \& + practises that can be used by individuals}, + \item + Define a subset of those methods and practises that can be applied + while developing \textbf{small programs}, + \item + Structure them so that they can \textbf{gradually introduced}, + \item + Provide \textbf{exercises suitable for practising} these methods in + an educational setting. + \end{enumerate} +\item + Lots of forms to fill in: time recording log, defect recording log, + ... +\item + A relatively \textbf{high ceremony} process, aimed at + \textbf{individuals and small projects}. + + \begin{itemize} + \tightlist + \item + It's often used as a training for high(er) ceremony processes such + as UP. + \end{itemize} +\end{itemize} + +\hypertarget{13-november-2018}{% +\subsection{13 November 2018}\label{13-november-2018}} + +\hypertarget{agile-processes}{% +\subsubsection{Agile Processes}\label{agile-processes}} + +\begin{itemize} +\tightlist +\item + Software development has to be \emph{agile}: \textbf{able to react + quickly to change} +\item + \textbf{Maxims:} + + \begin{itemize} + \tightlist + \item + \textbf{Individuals and interactions} over processes and tools + \item + \textbf{Working software} over comprehensive documentation + \item + \textbf{Customer collaboration} over contract negotiation + \item + \textbf{Responding to change} over following a plan + \end{itemize} +\end{itemize} + +\includegraphics{2C-SE.assets/1543146629660.png} + +\hypertarget{12-principles-of-agile}{% +\paragraph{12 Principles of Agile}\label{12-principles-of-agile}} + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + \textbf{Customer satisfaction} by \textbf{rapid delivery} of + \textbf{useful software} +\item + \textbf{Welcome changing requirements}, even late in development +\item + \textbf{Working software is delivered frequently (weeks rather than + months)} +\item + \textbf{Working software is the principal measure of progress} +\item + \textbf{Sustainable development}, able to \textbf{maintain a constant + pace} +\item + \textbf{Close, daily co-operation between business people and + developers} +\item + Face-to-face conversation is the best form of communication + (\textbf{co-location}) +\item + Projects are built around motivated \textbf{individuals, who should be + given right support and trusted to get job done} +\item + \textbf{Continuous attention} to technical excellence and good design +\item + \textbf{Simplicity is essential} +\item + Best requirements and designs form \textbf{self-organising teams} +\item + \textbf{Regular reflection} on process and tuning of behaviour +\end{enumerate} + +\hypertarget{extreme-programming-xp}{% +\subsubsection{Extreme Programming (XP)}\label{extreme-programming-xp}} + +\begin{itemize} +\item + \textbf{EXTREME PROGRAMMING IS AN AGILE VARIANT.} + + \begin{itemize} + \tightlist + \item + Other Agile processes include Scrum and DSDM. + \end{itemize} + + \includegraphics{2C-SE.assets/1543147108484.png} +\item + \textbf{Activities} + + \begin{itemize} + \tightlist + \item + \textbf{Listening} understanding the customer, communicating + efficiently + \item + \textbf{Designing} creating structure, organising system logic + \item + \textbf{Coding} + \item + \textbf{Testing} \emph{embodying requirements}, assessing quality, + guiding coding + \end{itemize} +\end{itemize} + +\hypertarget{xp-practices---planning-game}{% +\subparagraph{XP Practices - Planning +Game}\label{xp-practices---planning-game}} + +\includegraphics{2C-SE.assets/1543147264443.png} + +\hypertarget{xp-practices---on-site-customer}{% +\subparagraph{XP Practices - On-Site +Customer}\label{xp-practices---on-site-customer}} + +\begin{itemize} +\tightlist +\item + Someone capable of making the business's decisions in the planning + game, a representative of the customer who sits with the development + team, being always ready to + + \begin{itemize} + \tightlist + \item + clarify + \item + (help) write functional tests + \item + make small-scale priority and scope decisions + \end{itemize} +\item + Customer can do their \emph{normal work} when not needed to interact + with the development team. +\end{itemize} + +\hypertarget{xp-practices---small-releases}{% +\subparagraph{XP Practices - Small +Releases}\label{xp-practices---small-releases}} + +\begin{itemize} +\tightlist +\item + \textbf{Release as frequently as is possible whilst still adding some + \emph{business value} in each release.} + + \begin{itemize} + \tightlist + \item + \textbf{You get feedback as soon as possible.} + \item + \textbf{Lets the customer have the most essential functionality + ASAP.} + \end{itemize} +\item + Every week or every month. +\item + Outside XP releases commonly every 6 months or longer. +\end{itemize} + +\hypertarget{xp-practices---methaphors}{% +\subparagraph{XP Practices - +Methaphors}\label{xp-practices---methaphors}} + +\begin{itemize} +\tightlist +\item + About an easily-communicated overarching view of the system. +\item + \textbf{Encompasses concept of software architecture.} +\item + \textbf{Eases the developer-customer communication.} +\item + Provides a sense of cohesion. +\item + \textbf{Often suggests a consistent vocabulary.} +\end{itemize} + +\hypertarget{xp-practices---continuous-integration}{% +\subparagraph{XP Practices - Continuous +Integration}\label{xp-practices---continuous-integration}} + +\begin{itemize} +\tightlist +\item + \textbf{Code is integrated, debugged, and tested in full system build + frequently} (at most a few hours or a day after being written). +\item + \textbf{Maintains a working system at all times.} +\item + \textbf{Makes bugs easier to trace.} + + \begin{itemize} + \tightlist + \item + "It was alright an hour ago! Let me check what has changed since + then." + \end{itemize} +\item + \textbf{Simplifies integration, prevents late-stage surprises.} +\end{itemize} + +\hypertarget{xp-practices---testing}{% +\subparagraph{XP Practices - Testing}\label{xp-practices---testing}} + +\begin{itemize} +\tightlist +\item + \textbf{Any program feature without an automated test simply doesn't + exist.} +\item + \textbf{Tests are the contract between your developers, and between + you and your customers.} + + \begin{itemize} + \tightlist + \item + Programmers write \textbf{unit tests}. + \item + Customers (with your help) write \textbf{functional tests}. + \end{itemize} +\end{itemize} + +\hypertarget{xp-practices---refactoring}{% +\subparagraph{XP Practices - +Refactoring}\label{xp-practices---refactoring}} + +\includegraphics{2C-SE.assets/1543147982905.png} + +\hypertarget{xp-practices---pair-programming}{% +\subparagraph{XP Practices - Pair +Programming}\label{xp-practices---pair-programming}} + +\includegraphics{2C-SE.assets/1543148029020.png} + +\hypertarget{xp-practices---collective-ownership}{% +\subparagraph{XP Practices - Collective +Ownership}\label{xp-practices---collective-ownership}} + +\begin{itemize} +\tightlist +\item + \textbf{Every developer is responsible for the codebase as a whole}, + and is permitted to modify and improve as they seem fit. +\end{itemize} + +\hypertarget{xp-practices---coding-standards}{% +\subparagraph{XP Practices - Coding +Standards}\label{xp-practices---coding-standards}} + +\begin{itemize} +\tightlist +\item + \textbf{The whole team adheres to a single set of \emph{conventions} + about how code is written.} + + \begin{itemize} + \tightlist + \item + \textbf{In order to make \emph{pair programming} and + \emph{collective ownership} work.} + \end{itemize} +\end{itemize} + +\hypertarget{mixing-and-matching-xp-practices}{% +\subparagraph{Mixing and Matching XP +Practices}\label{mixing-and-matching-xp-practices}} + +\includegraphics{2C-SE.assets/1543148331734.png} + +\begin{itemize} +\tightlist +\item + XP practices are \emph{very} interrelated \& interdependent so it's + dangerous: + + \begin{itemize} + \tightlist + \item + \emph{Collective Ownership} without \emph{Coding Standards} will + create an inconsistent mess. + \item + \emph{Simple Design} without \emph{Refactoring} will create code + smell. + \item + \emph{Planning Game} without \emph{On-Site Customer} is simply + unimaginable! + \end{itemize} +\end{itemize} + +\hypertarget{comparison-of-different-processes}{% +\subsubsection{Comparison of Different +Processes}\label{comparison-of-different-processes}} + +\includegraphics{2C-SE.assets/1543148442267.png} + +\begin{itemize} +\tightlist +\item + \textbf{Formal Methods} go beyond Waterfall and what we've seen in + this course. + + \begin{itemize} + \tightlist + \item + Developing on-board software for Curiosity Space Rover for instance! + \end{itemize} +\end{itemize} + +\hypertarget{15-november-2018}{% +\subsection{15 November 2018}\label{15-november-2018}} + +\hypertarget{improving-processes}{% +\subsubsection{Improving Processes}\label{improving-processes}} + +\hypertarget{risks}{% +\paragraph{"Risks"}\label{risks}} + +\begin{itemize} +\tightlist +\item + We improve a process to manage (\emph{i.e.} reduce, predict, and plan + for) \textbf{risks} (\emph{i.e.} bad things that might happen to us). +\item + \textbf{Risks can be categorised in many different ways.} + + \begin{itemize} + \tightlist + \item + \textbf{Project risks} affect schedule or resources \emph{e.g.} + staff loss, management change, missing resources + \item + \textbf{Product risks} affect quality or performance of the software + \emph{e.g.} always-changing requirements, delays in requirements + analysis (and consequently rushing it) + \item + \textbf{Business risks} affect the software developer or buyer + \emph{e.g.} mis-estimation of costs, competitor gets to market first + \end{itemize} +\item + \textbf{Planing for risks} + + \begin{itemize} + \tightlist + \item + \textbf{Identify} risks early, categorise them + \item + \textbf{Analyse} each identified risk; is it minor, major, serious, + fatal? What is the \emph{chance} of it happening? + \item + \textbf{Plan} how to \emph{cope} with each risk: + + \begin{itemize} + \tightlist + \item + Can it be \textbf{avoided} by reducing the probability of + occurrence? + \item + Can you plan to \textbf{minimise} the effect if it does happen? + \item + What is your \textbf{contingency plan} if it does happen? + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{quality}{% +\paragraph{"Quality"}\label{quality}} + +\begin{itemize} +\item + \textbf{Quality is anything that the customer cares about.} + + \begin{itemize} + \tightlist + \item + \textbf{Quality planning} \emph{how will you ensure that this + project delivers a high quality product?} + \item + \textbf{Quality metrics} \emph{what measurements must you make in + order to tell whether what you're doing is making the difference you + intend?} + \item + \textbf{Quality improvement} \emph{what can you learn from this + project to help you plan and run the next one better?} + \item + \textbf{Quality control} \emph{how can you ensure and prove that + your quality plan was followed?} + \item + \textbf{Quality assurance (QA)} \emph{an umbrella term for the whole + field dealing with quality.} + \end{itemize} +\item + Quality improvement may focus on + + \begin{itemize} + \tightlist + \item + \emph{the software product itself} verification, validation, + testing, code/design reviews, inspections, walkthroughs... + \item + \emph{the process by which the software is produced} what we'll + focus on! + \end{itemize} +\item + \textbf{Process focus} + + \begin{itemize} + \tightlist + \item + {[}+{]} has the potential to improve \emph{all} products of the + organisation + \item + {[}+{]} makes it possible to \emph{certify} (ISO 9000) the whole + organisation + \item + {[}+{]} might be unavoidable as some things -\/-such as + planning-\/-are hard to approach in any other way + \item + {[}-{]} done badly, can easily increase costs with no actual + benefits + \end{itemize} +\item + \textbf{Centres of Process-Focused Quality Assurance} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \tightlist + \item + \textbf{Organisation -\/-\/-\textgreater{} Project + -\/-\/-\textgreater{} Individual} Organisation's management + \emph{decides}, influencing projects. Project managers \emph{direct} + individuals into desired behaviour. + \item + \textbf{Organisation \textless{}-\/-\/- Project \textless{}-\/-\/- + Individual} Individuals \emph{introduce} improvements to the rest of + the project. Project improvements \emph{spread} to the rest of the + organisation. + \end{enumerate} + + \begin{itemize} + \tightlist + \item + Making these centres work together productively depends on the + software engineering \emph{culture} of the organisation and + \emph{attitude to work} of the individual. + \end{itemize} +\end{itemize} + +\hypertarget{standard-quality-assurance-models}{% +\subparagraph{Standard Quality Assurance +Models}\label{standard-quality-assurance-models}} + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\item + \textbf{Capability Maturity Model Integration (CMMI)} + + quality planning, control, and \emph{improvement} framework + (\emph{i.e.} maturity of the organisation increases) +\item + \textbf{ISO 9000} quality \emph{control} framework (\emph{i.e.} less + emphasis on improvement) +\end{enumerate} + +\begin{itemize} +\item + These can be complementary! +\item + \textbf{CMMI} + + \begin{itemize} + \tightlist + \item + It provides a generic -\/-but specialisable to software project-\/- + description of \textbf{process areas}, \textbf{goals} associated + with each area, and \textbf{practices} that may achieve goals. + \item + Organisations are assessed at a \textbf{maturity level} according to + \emph{how} they achieve goals and follow practices: + + \begin{itemize} + \tightlist + \item + \includegraphics{2C-SE.assets/1024px-Characteristics_of_Capability_Maturity_Model.svg.png} + \end{itemize} + \end{itemize} +\item + \textbf{Total Quality Management (TQM)} + + \begin{itemize} + \tightlist + \item + \textbf{Plan, Do, Check, Act} + \item + \emph{Improving quality is everyone's job -\/-not just that of the + QA department!} + \end{itemize} + + \begin{enumerate} + \def\labelenumi{\arabic{enumi}.} + \tightlist + \item + Quality can and must be managed. + \item + \emph{Everyone} has a customer to delight. + \item + Processes, not the people, are the problem. + \item + \emph{Every employee is responsible for quality.} + \item + Problems must be \emph{prevented}, not just fixed. + \item + Quality must be \emph{measured}, so it can be \emph{controlled}. + \item + \emph{Quality improvements must be continuous.} + \item + \textbf{Quality goals must be based on customer requirements.} + \end{enumerate} +\end{itemize} + +\begin{itemize} +\tightlist +\item + \textbf{ISO 9001} + + \begin{itemize} + \tightlist + \item + An international standard for quality assurance. + \item + It specifies \emph{how} to specify documents, and procedures that a + company should follow in its quality control. It \emph{does not} + however, specify or require any \emph{level of product quality}. + \end{itemize} +\end{itemize} + +\begin{itemize} +\tightlist +\item + \textbf{Bottom line:} things only get better when those involved... + + \begin{itemize} + \tightlist + \item + ...have enough information to tell what's wrong + + \begin{itemize} + \tightlist + \item + that's why you aim to take \emph{quantitative measurements} + \end{itemize} + \item + ...think about the process + + \begin{itemize} + \tightlist + \item + nothing important, merely stating that you need to know that a + thing called QA exists + \end{itemize} + \item + ...plan how to improve + + \begin{itemize} + \tightlist + \item + not only the specific product, but the whole process + \end{itemize} + \item + ...actually make sure the plan happens + + \begin{itemize} + \tightlist + \item + quality control + \end{itemize} + \item + ...check whether it worked + + \begin{itemize} + \tightlist + \item + quality control \& quality imprvement + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{estimating}{% +\paragraph{"Estimating"}\label{estimating}} + +\begin{itemize} +\item + \textbf{Cost estimation} + + \begin{itemize} + \tightlist + \item + Prior to any -\/-significant-\/- project, you need to + \emph{estimate} how much it will \emph{cost}. + + \begin{itemize} + \tightlist + \item + Time cost, human resources cost, financial cost, ... + \end{itemize} + \item + Many factors: + + \begin{itemize} + \tightlist + \item + software size + \item + software complexity + \item + engineer productivity (individually and as a team) + \end{itemize} + \item + \textbf{We'll consider only software size and complexity} + + \begin{itemize} + \tightlist + \item + and define \emph{Productivity is the ratio of these to time + required.} + \end{itemize} + \end{itemize} +\item + \textbf{Lines of Code (LoC)} + + \begin{itemize} + \tightlist + \item + {[}-{]} Not very meaningful by itself, what is a line of code? + \item + {[}-{]} Does not make sense across different programming languages: + imagine Haskell, Java, C... + \item + {[}+{]} Still widely used! Alternatives like "function points" + exist. + \end{itemize} +\end{itemize} + +\hypertarget{estimation-approaches}{% +\subparagraph{\texorpdfstring{\textbf{Estimation +approaches}}{Estimation approaches}}\label{estimation-approaches}} + +\begin{itemize} +\item + \textbf{algorithmic cost modelling} develop (from past data) a model + relating size/complexity to ultimate cost +\item + \textbf{expert consensus} get a bunch of expert estimates; compare, + discuss, and repeat until convergence +\item + \textbf{analogy} relate the cost to that of similar completed projects +\item + \emph{\textbf{what customer will pay}} dangerous... +\item + \textbf{COCOMO I} + + \begin{itemize} + \tightlist + \item + {[}+{]} A long-standing algorithmic model, publicly available, well + supported and widely used. + \item + \$\$ \textbackslash{}text\{Effort\} = \textbackslash{}text\{A\} + \textbackslash{}times + \textbackslash{}text\{Size\}\^{}\textbackslash{}text\{B\} + \textbackslash{}times \textbackslash{}text\{M\} \$\$ + + \begin{itemize} + \tightlist + \item + \textbf{Effort} is measured in person-months + \item + \textbf{A} is a constant, dependent on kind of software \emph{and} + developing organisation + \item + \textbf{B} typically range in \$\$1\textbackslash{}ldots 1.5\$\$. + \item + \textbf{M} is a \emph{multiplier}. Product of 15 factors, each + typically in range \$0.9\textbackslash{}ldots 1.4\$, that are + derived from ratings of attributes such as: \emph{required + reliability}, \emph{required time to market}, \emph{software + engineer capability}, ... + \end{itemize} + \item + {[}- {]} Getting good values for \textbf{A}, \textbf{B}, and + \textbf{M} is highly non-trivial. + + \begin{itemize} + \tightlist + \item + {[}+{]} Considerable data available too. + \end{itemize} + \item + Different versions, sub-models, tweaks available. + \end{itemize} +\end{itemize} + +\hypertarget{scheduling}{% +\paragraph{"Scheduling"}\label{scheduling}} + +\begin{itemize} +\item + \textbf{Why do projects almost always slip?} + + \begin{itemize} + \tightlist + \item + \emph{"People tend to be risk-averse when there is a potential of + loss"} + \item + \emph{"People are unduly optimistic in their plans and forecasts"} + \item + \emph{"People prefer to use intuitive judgement rather than + (quantitative) models"} + \end{itemize} +\item + \textbf{Gantt Charts} + + \begin{itemize} + \tightlist + \item + Divide project into \textbf{tasks}, with \textbf{milestones} at the + end. + \item + Analyse dependencies between tasks. + \item + Lay these tasks out as \textbf{bars running across time}, + \emph{respecting dependencies}. + \item + The graph reveals the \textbf{critical path} of tasks for the + project. + \item + Optionally, show \textbf{permissible slippage} with shaded bars. + \item + For example: + + \begin{itemize} + \tightlist + \item + \includegraphics{2C-SE.assets/1543585250853.png} + \item + \includegraphics{2C-SE.assets/1543585265509.png} + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{the-rest}{% +\paragraph{The Rest}\label{the-rest}} + +\begin{itemize} +\tightlist +\item + \textbf{Tracking} + + \begin{itemize} + \tightlist + \item + A balance between too little and too much information to track. + + \begin{itemize} + \tightlist + \item + One is insufficient, one is too much to process and manage! + \end{itemize} + \end{itemize} +\item + \textbf{Revising the Project Plan} + + \begin{itemize} + \tightlist + \item + As the project goes on, estimates have to be revised in the light of + progress, unforeseen problems, in other words, recent developments! + \end{itemize} +\end{itemize} + +\hypertarget{20-november-2018}{% +\subsection{20 November 2018}\label{20-november-2018}} + +\hypertarget{non-functional-requirements-nfr}{% +\subsubsection{Non-Functional Requirements +(NFR)}\label{non-functional-requirements-nfr}} + +\begin{itemize} +\tightlist +\item + \textbf{Concerns the whole system, not just the software} +\item + About + + \begin{itemize} + \tightlist + \item + Ways the system needs to be related to other system and versions of + itself: + + \begin{itemize} + \tightlist + \item + flexibility + \item + maintainability + \item + reusability + \item + portability + \end{itemize} + \item + Properties of the system in use + + \begin{itemize} + \tightlist + \item + usability + \item + \emph{dependability} + + \begin{itemize} + \tightlist + \item + safety, reliability, availability, resilience + \end{itemize} + \item + \emph{efficiency} + + \begin{itemize} + \tightlist + \item + \emph{performance} (throughput, response time), resource usage + \end{itemize} + \item + \emph{security} + + \begin{itemize} + \tightlist + \item + integrity, confidentiality + \end{itemize} + \item + scalability + \end{itemize} + \end{itemize} +\item + NFRs must be identified along with functional requirements -\/- at the + end is to late. +\item + \textbf{Often tied up with architectural decisions} which are almost + impossible to modify later. +\item + It is essential to + + \begin{itemize} + \tightlist + \item + \textbf{quantify the requirement} + \item + \textbf{have ways to measure -\/- \emph{metrics}} + \end{itemize} +\end{itemize} + +\hypertarget{metrics}{% +\subsubsection{Metrics}\label{metrics}} + +\begin{itemize} +\tightlist +\item + Ideally, metrics are + + \begin{itemize} + \tightlist + \item + \textbf{measurable} not based on "intuition" or "opinions" of + someone + \item + \textbf{specified with a precision} \emph{i.e.} uncertainities must + be recorded + \item + \textbf{MEANINGFUL} numbers must have something to do with something + we care about! + \end{itemize} +\end{itemize} + +\hypertarget{reliability-metric}{% +\paragraph{Reliability Metric}\label{reliability-metric}} + +\includegraphics{2C-SE.assets/1543668447275.png} + +\begin{itemize} +\tightlist +\item + \textbf{Reliability is a key non-function requirement in many + systems.} +\item + \textbf{There are several ways to specify reliability requirements, + depending on the nature of the system.} +\end{itemize} + +\hypertarget{pofod---probability-of-failure-on-demand}{% +\subparagraph{POFOD - Probability of Failure on +Demand}\label{pofod---probability-of-failure-on-demand}} + +\begin{itemize} +\tightlist +\item + POFOD is the probability that the system will fail when service is + requested. +\item + \textbf{Mainly useful for systems that provide emergency or safety + services.} + + \begin{itemize} + \tightlist + \item + \emph{e.g.} the emergency shutdown in a nuclear power plant will + (hopefully) never be used -\/- but if it is, it should not fail! + \end{itemize} +\item + Can be evaluated through... + + \begin{itemize} + \tightlist + \item + ...repeated tests in simulation. + + \begin{itemize} + \tightlist + \item + which might be expensive. + \end{itemize} + \item + ...static analysis of the whole system + + \begin{itemize} + \tightlist + \item + which is definitely expensive, and to ensure that our analysis is + correct, some real-world testing would be required. + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{rocof---rate-of-occurrence-of-failure}{% +\subparagraph{ROCOF - Rate of Occurrence of +Failure}\label{rocof---rate-of-occurrence-of-failure}} + +\begin{itemize} +\tightlist +\item + ROCOF is the number per unit time of failures (\emph{i.e.} unexpected + behaviour). +\item + \textbf{Time may mean \emph{elapsed time}, \emph{processing time}, + \emph{Number of Transactions}, \emph{etc.}} +\item + \textbf{Mainly used for systems providing regular service, where + failure is significant.} + + \begin{itemize} + \tightlist + \item + \emph{e.g.} banking systems + + \begin{itemize} + \tightlist + \item + VisaNet processes over 10\^{}9\^{} transactions/day. Failure rate + is not published, but probably (much) less than 10\^{}-5\^{} + failures/transaction. + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{mttf--mtbf---mean-time-tobetween-failures}{% +\subparagraph{MTTF \& MTBF - Mean Time To/Between +Failures}\label{mttf--mtbf---mean-time-tobetween-failures}} + +\begin{itemize} +\item + \textbf{MTTF is used when system is non-repairable.} + + \begin{itemize} + \tightlist + \item + \emph{e.g.} often in the case of hardware + \end{itemize} +\item + \textbf{MTBF is used when system can recover from failures.} + + \begin{itemize} + \tightlist + \item + \emph{e.g.} operating system crashes + \end{itemize} +\item + \textbf{Both are mainly used where a single client uses the system + \emph{for a long time}.} + + \begin{itemize} + \tightlist + \item + \emph{e.g.} desktop PCs (and their components), \emph{consumer + products} + \end{itemize} +\item + \textbf{Keep in mind that \emph{mean} alone is often insufficient to + be decisive:} + + \begin{itemize} + \tightlist + \item + Variation matters! \includegraphics{2C-SE.assets/1543667647524.png} + + \begin{itemize} + \tightlist + \item + Whilst the component whose MTTF is shown with the red curve is + more predictable to fail after MTTF whilst the blue curve + indicates that the failure might occur much before (or much after) + the MTTF. + \item + \emph{You would like your curve to be sharp \& pointy.} + \end{itemize} + \end{itemize} +\end{itemize} + +\hypertarget{availability}{% +\subparagraph{Availability}\label{availability}} + +\begin{itemize} +\tightlist +\item + Availability is the portion of the time that the system is "available + for use". +\item + Often quoted as "five nines" (0.99999), "four nines", \emph{etc.} +\item + \textbf{Appropriate for systems offering a \emph{continuous service}, + where clients expect it to be there all the time.} +\item + Often achieved by large data processing systems, such as mainframes. +\item + \textbf{The difference between availability and ROCOF} is that + availability takes the time to recover from a failure into + consideration too; \emph{availability gives a better overall picture.} + + \begin{itemize} + \tightlist + \item + For instance your ROCOF might be once in a year, but if it takes you + 3 months to recover, that's not high availability. + \end{itemize} +\end{itemize} + +\hypertarget{usability}{% +\subsubsection{Usability}\label{usability}} + +\begin{itemize} +\item + We'll concern ourselves with User Interfaces (UI) only. +\item + \emph{Most user errors are actually interface design failures.} +\item + \textbf{Human Limitations:} Humans... + + \begin{itemize} + \tightlist + \item + ...have very limited short-term memory: 5-7 items. + \item + ...make mistakes, especially under stress. + \item + ...vary widely, capability-wise, preference-wise, and so on. + \item + ...organise their perceived world differently! + \end{itemize} +\end{itemize} + +\hypertarget{principles-of-ui-design}{% +\paragraph{Principles of UI Design}\label{principles-of-ui-design}} + +\begin{itemize} +\item + \textbf{User familiarity} + + \begin{itemize} + \tightlist + \item + The interface should "look familiar" to the users. + + \begin{itemize} + \tightlist + \item + It should use concepts and \emph{entities} (\emph{e.g.} textboxes, + buttons, sliders) from existing experience of the users. + \end{itemize} + \end{itemize} +\item + \textbf{Consistency} + + \begin{itemize} + \tightlist + \item + Similar operations should be represented in similar ways. + + \begin{itemize} + \tightlist + \item + \emph{E.g.} Red always indicates a situation that requires + caution, or to draw the user's attention; yellow indicates + recoverable failure, ... + \end{itemize} + \item + Consistency should be enforced (at least) across the application, + but many "systems" (Android, iOS, ...) also enforce it across + \emph{all applications}. + + \begin{itemize} + \tightlist + \item + Brands enforce their own consistency too! Microsoft and Google + apps look alike across all the platforms. + \end{itemize} + \item + \emph{Beware that similarity might not always be well defined!} + \end{itemize} +\item + \textbf{Minimal surprise} + + \begin{itemize} + \tightlist + \item + Avoid situations where the user will be surprised by the behaviour + of the system. + \item + Often is the case with \emph{modal} applications where different + keys have different effects in different modes. + \end{itemize} +\item + \textbf{Recoverability} + + \begin{itemize} + \tightlist + \item + Allow the user to recover (easily) from errors. + \item + \emph{Reversibility} (\emph{i.e.} being able to undo) is relevant + here. + \item + Checkpointing/autosaving is a valuable technique. + \end{itemize} +\item + \textbf{User guidance} + + \begin{itemize} + \tightlist + \item + Kindly guide the user for taking the appropriate action through your + UI. + + \begin{itemize} + \tightlist + \item + As opposed to demanding them read 100 pages long manual. + \end{itemize} + \item + Provide \emph{meaningful} (\emph{i.e.} actionable) error messages. + + \begin{itemize} + \tightlist + \item + \emph{E.g.} Bad: "File Save Error" Good: "File could not be saved + because disk is full; open up some space and try again." + \item + This is not always easy of course, there are tons of assumptions + we make within our abstractions which -\/-when violated-\/- does + not yield a meaningful error message. + \end{itemize} + \end{itemize} +\item + \textbf{User diversity} + + \begin{itemize} + \tightlist + \item + Remember that users vary on numerous levels on various axes. + + \begin{itemize} + \tightlist + \item + Healthy, colour-blind, blind + \item + Healthy, hearing-impaired, deaf + \item + Fluent in English, intermediate, doesn't know English, or even + illiterate! + \item + Power users, casual users + \end{itemize} + \item + Wherever possible, provide choices for \emph{customisability}. + \item + Often there are legal obligations about \emph{accessibility}. + \end{itemize} +\end{itemize} + +\hypertarget{task-analysis}{% +\paragraph{Task Analysis}\label{task-analysis}} + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + What tasks users want to do with the system? +\item + In what order and combination? +\end{enumerate} + +\begin{itemize} +\tightlist +\item + \emph{E.g.} Information should be presented wherever it is required. + + \begin{itemize} + \tightlist + \item + AND to reduce the clutter, \emph{information should not be + represented wherever it is not required.} + \end{itemize} +\item + Running through user stories and use cases are often useful here. +\end{itemize} + +\hypertarget{user-interaction}{% +\paragraph{User Interaction}\label{user-interaction}} + +\begin{itemize} +\item + How do users interact with the system? +\item + \textbf{Direct manipulation} such as drag-and-drop +\item + \textbf{Menu selection} perhaps on a directly selected object +\item + \textbf{Form fill-in} typically used for data entry +\item + \textbf{Command language} typically used by traditional systems (UNIX) +\item + \textbf{Natural language} sometimes as a front end to a command + language, but more advanced versions have emerged such as Siri, using + NLP +\item + \textbf{Body language} such as Nintendo Wii, or XBox Kinect +\end{itemize} + +\hypertarget{information-presentation}{% +\paragraph{Information Presentation}\label{information-presentation}} + +\begin{itemize} +\item + How should information be presented to the user? + + \begin{itemize} + \tightlist + \item + This has \emph{nothing} to do with the way information is + represented internally. + \end{itemize} +\item + Continuously varying information is best represented in an analogue + representation (\emph{i.e.} continuous graphs), not as numbers. + + \begin{itemize} + \tightlist + \item + \emph{Data visualisation} + \end{itemize} +\item + \textbf{Presentation should depend on the audience: \emph{e.g.} graphs + vs graphics.} +\end{itemize} + +\hypertarget{colour}{% +\paragraph{Colour}\label{colour}} + +\begin{itemize} +\tightlist +\item + Use few colours \emph{consistently}, no more than four or five per + context and no more than seven in total. +\item + Colour changes should signal something significant. +\item + Be careful about colour pairings (\emph{e.g.} do not put red on blue + background). + + \begin{itemize} + \tightlist + \item + Contrast also affects accessibility; low contrast is harder to + process visually (in general, but especially for the visually + impaired). + \end{itemize} +\item + In general, vary colours along only one of the three dimensions (hue, + saturation, brightness) to make a distinction. +\item + Know the output technology; primary green is often unreadable on + screen but fine in print. +\item + Remember that around 10\% of men are red-green colour-blind! +\end{itemize} + +\hypertarget{interface-design-and-evaluation}{% +\paragraph{Interface design and +evaluation}\label{interface-design-and-evaluation}} + +\begin{itemize} +\tightlist +\item + Design iteratively. +\item + Only real end users are good judges of the interface; testing is + important. + + \begin{itemize} + \tightlist + \item + Evaluation is hard; get professionals, read HCI books. + \end{itemize} +\item + In expensive or critical software, involve professional from + appropriate fields (\emph{e.g.} ethnography). +\end{itemize} + +\hypertarget{22-november-2018}{% +\subsection{22 November 2018}\label{22-november-2018}} + +\hypertarget{intellectual-property-ip}{% +\subsubsection{Intellectual Property +(IP)}\label{intellectual-property-ip}} + +\begin{quote} +IP is not property, and it's not intellectual. It resists definition, +but one definition of IP might be: \emph{a monopoly right to exploit an +intangible product of human thought or labour.} +\end{quote} + +Several broad categories: + +\begin{itemize} +\tightlist +\item + \textbf{copyright} applies to literary or artistic works +\item + \textbf{patents} apply to inventions of things or processes +\item + \textbf{design rights} apply to design of products +\item + \emph{none of these were invented with software in mind...} +\end{itemize} + +\hypertarget{patents}{% +\paragraph{Patents}\label{patents}} + +\begin{itemize} +\tightlist +\item + Arose to protect \emph{inventors} of physical objects or processes. +\item + \textbf{Stronger than copyright} + + \begin{itemize} + \tightlist + \item + stops other people using/making object even if they invented it + independently + \end{itemize} +\item + \textbf{Duration is sorter} -\/- 17 years +\item + \textbf{Software patents are controversial} + + \begin{itemize} + \tightlist + \item + In U.S., yes; in Europe, no (roughly speaking). + \item + In U.S., \emph{business processes} are patentable (\emph{e.g.} + Amazon has patents on \emph{one-click} shopping, and on the idea of + customers reviewing products!). + \end{itemize} +\end{itemize} + +\hypertarget{copyright}{% +\paragraph{Copyright}\label{copyright}} + +\begin{itemize} +\item + Copyright protects \emph{the expression of an idea}, not the idea + itself. + + \begin{itemize} + \tightlist + \item + \emph{The original IP.} + \end{itemize} +\item + Restricts the ability to copy, adapt, \emph{etc.} artistic or literary + works. +\item + \textbf{Unlike patents, no merit {[}invention{]} is required; this + document is a literary work for copyright purposes.} +\item + \textbf{Duration is longer} -\/- life of author + \textasciitilde{}70 + years. +\item + \textbf{The protected rights may be \emph{assigned} in whole or in + part, or \emph{licensed} in whole or in part, with or without + restrictions.} +\item + Source code is subject to copyright. + + \begin{itemize} + \tightlist + \item + Object code and machine code are \emph{adaptations or translations} + of source code, hence protected. + \end{itemize} +\item + Clean-room reverse engineering is permissible under many + jurisdictions. +\end{itemize} + +\hypertarget{licenses}{% +\paragraph{Licenses}\label{licenses}} + +\begin{itemize} +\tightlist +\item + Can be licensed per computer, per user, or per CPU cores! +\item + Sometimes it's the license to access and use a website. + + \begin{itemize} + \tightlist + \item + \emph{E.g.} Office 365 + \end{itemize} +\item + Shareware/Fremimum, Free Open Source, Proprietary, ... +\item + GPL -\/- General Public License + + \begin{itemize} + \tightlist + \item + \textbf{copyleft} -\/- modifications or adaptations of the work + (including other works which depends on it) must be licensed under + the same license. + \item + As a result, \emph{copyleft licenses are incompatible with each + other}. + \end{itemize} +\item + LGPL -\/- Lesser General Public License + + \begin{itemize} + \tightlist + \item + \textbf{weak copyleft} -\/- same as GPL, except other works which + depends on our work does \emph{not} have to be licensed under the + same license. + \item + Again, incompatible with other copyleft licenses. + \end{itemize} +\end{itemize} + +Choosing a license may depend on: + +\begin{itemize} +\tightlist +\item + \textbf{philosophy} some consider restricting software to be + unethical, some motivated by utilitarian views... +\item + \textbf{legal constraints} you may have used other software that + restricts your choices (proprietary or copyleft). +\item + \textbf{business relevance} sharing the most valuable asset of your + company might not be the best business strategy! +\item + \textbf{support} do you want your users to contribute? +\end{itemize} + +\hypertarget{27-november-2018}{% +\subsection{27 November 2018}\label{27-november-2018}} + +\hypertarget{ethics}{% +\subsubsection{Ethics}\label{ethics}} + +\begin{quote} +Software engineers shall commit themselves to making the analysis, +specification, design, development, testing and maintenance of software +a \emph{beneficial} and respected profession. In accordance with their +commitment to the health, safety and welfare of the public, software +engineers shall adhere to the following Eight Principles: + +\begin{enumerate} +\def\labelenumi{\arabic{enumi}.} +\tightlist +\item + \textbf{PUBLIC} -\/-\/- Software engineers shall act consistently with + the public interest. +\item + \textbf{CLIENT AND EMPLOYER} -\/-\/- Software engineers shall act in a + manner that is in the best interests of their client and employer + consistent with the public interest. +\item + \textbf{PRODUCT} -\/-\/- Software engineers shall ensure that their + products and related modifications meet the highest professional + standards possible. +\item + \textbf{JUDGEMENT} -\/-\/- Software engineers shall maintain integrity + and independence in their professional judgement. +\item + \textbf{MANAGEMENT} -\/-\/- Software engineering mangers and leaders + shall subscribe to and promote an ethical approach to the management + of software development and maintenance. +\item + \textbf{PROFESSION} -\/-\/- Software engineers shall advance the + integrity and reputation of the profession consistent with the public + interest. +\item + \textbf{COLLEAGUES} -\/-\/- Software engineers shall be fair to and + supportive of their colleagues. +\item + \textbf{SELF} -\/-\/- Software engineers shall participate in lifelong + learning regarding the practice of their profession and shall promote + an ethical approach to the practice of the profession. +\end{enumerate} +\end{quote} + +\href{https://ethics.acm.org/code-of-ethics/software-engineering-code/}{https://ethics.acm.org/code-of-ethics/software-engineering-code/} + +\begin{itemize} +\tightlist +\item + \textbf{You should be able to answer, given an example, which codes of + ethics the incident violates.} +\end{itemize} + +\end{document}