Lecture 2

Low quality software can cause jobs, lives and money. Example, Knight Capitol lost 440 million dollars because of a glitch in their software. Another example is the Therac-25. It is a radiation therapy machine that was produced by Atomic Energy of Canada Limited, and it was involved in at least 6 accidents in which patients were given massive overdose of radiation.

Planning Requirement Analysis Designing Implementing Verification and validation Maintenance and Evolution

There are two types of requirement analysis, requirement elicitation: finding out who the stakeholders are and interviewing them to figure out what their requirements with the software. requirement specification: specifying the requirements in details. For example, use cases and user stories.

Architectural design: the main structure of the software. Similar to building architecture. Ex, roof and foundation. Sub system design: breaking down a complex system into smaller sub parts and designing each of them to perform tasks. Each sub system typically interacts with the other sub systems to achieve the overall objectives in the system. Detailed design: describe the classes, methods attributes/data types. Persistent data design: design of the database like tables, pk and fk. User Interface design: how the GUI will look like, what tools will be used to build it, the structure of the GUI, what design and style guidelines to be followed.

Verification is checking if the system works as specified. It involves system testing which is executing the system with test cases that are derived from specification of real data that are to be processed by the system and final checking all the use cases from the specification document. Validating is checking with the system customer if the system is working as they required.

Bugs need fixing, performances need to be improved, changes in the business environment, new technologies incoming, new requirements, changes in the infrastructure environment.

Adaptive maintenance: changing the system in responds to changes in the environment so that it continues to function. Corrective maintenance: fix bugs and errors. Perfective maintenance: changing the system's functionality to meet changing needs.

Technical debt is a concept in software development that reflects the cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

Law 1: Continuing change A program that is used in a real-world environment must be continually adapted, or else become progressively less satisfactory because new requirements are emerging constantly, and evolution of the environment equals to increasing mismatch between the system and its environment.

Law 2: Increasing complexity As a program evolved, its complexity increases with time, unless specific work is done to maintain or reduce it because unpaid technical debt increases software disorder and increased technical debt makes it harder to change. refactoring and restructuring may be needed.

Law 6: Continuing growth Functional content of a program must be continually increased to maintain user satisfaction over its lifetime. Because if the user enjoys the software, they will use it repeatedly, but after using it many times, they will think of other functionalities that could make their work efficient, and an app needs to keep growing in that way to satisfy users.

Law 7: declining quality Evolving programs will be perceived as of declining quality unless maintained and adapted to a changing operational environment because of the same reason as law 1.