Software Engineering PDF

Software Engineering Engineering – The process of utilizing knowledge and principles to design, build, and analyze objects. Practically oriented! IT Experience while studying: - No industrial experience (or very limited) - Small size of the developed software - Individual work, som...

Software Engineering Engineering – The process of utilizing knowledge and principles to design, build, and analyze objects. Practically oriented! IT Experience while studying: - No industrial experience (or very limited) - Small size of the developed software - Individual work, sometimes in pairs - No real customer - Focus on technologies or academic questions - Software product is shelved once it’s completed Industrial IT Practice: - Professional, profitable software development - Complex products (micro 1000PM) - Larger teams (consisting of even few tens or hundreds) - A customer with specific needs - Focus on business application - Software is maintained and modified over years or decades Software specifics: - Immaterial product – software is an immaterial product; in order to “see” it, one must have at least partially implemented product; before it only some representations are available (e.g. specification, GUI design, algorithms) but each of them is limited - Focused on design not production – production (making of yet another copy) is not difficult nor requires effort; each software product is quite different - Does not wear out – does not wear out like physical resources (e.g. corrosions) but is still faulty; faults are result of design effects or environment incompatibility - Large complexity – larger that in case of a building; it is hard to check every path and release a defect-free product - No structural limitation – no limitations typical for the material world (e.g. laws of physics); designers have freedom about shaping system’s structure; bad structure can however make further modifications difficult - Interdependencies between components – many not obvious interdependencies (e.g. shared data, memory or namespace) which leads to development difficulties, defects and maintenance problems - Digital not analog mode – analog systems usually work in such way that a small change of input results in a small change of output; for a software, a tiny change in the input can result in entirely different output - Ease of modification – it's good feature; however, it can lead to some unwanted changes in the system, errors or poor quality of a final product Question: What should be done if the project is delayed, and we cannot expect to meet the deadline? Common sense answer: Put more people to work on that project! Harsh reality: in software project it will probably make the situation even worse Question: How to determine work progress? Common sense answer: Ask developers Harsh reality: A typical software project estimated in such way would be 90% finished for 90% of its schedule  Where are software errors made? Error corrections cost in time (1:10 rule)  Value for the customer, needs, requirements Software development vs software maintenance Reasons for software projects failures: - Unrealistic project goals - Inaccurate estimates for needed resources - Badly defined system requirements - Poor reporting of a project’s status - Unmanaged risks - Poor communication among developers, customers and users - Use of immature technology - Inability to handle the project’s complexity - Sloppy development practices - Poor project management - Commercial pressure Project success factors: - User involvement - Executive management support - Clear statement of requirements - Proper planning - Realistic expectations - Smaller project milestones - Competent staff - Clear vision and objectives - Hard working, focused staff The origins of a problem: - Rapid progress in computer equipment and programming languages - Emergence of interactive software supporting business processes - A significant rise in size and complexity of developed software Observation: The progress in software development methods does not keep up with the technological progress Conclusions 1. For most of engineering projects of greater size and complexity, it is necessary to apply a methodical approach in order to successfully complete them  2. There are however some additional software specifics, which often result in additional problems and thus require dedicated, advanced methods to cope with such problems (the methods are not necessarily shared with other engineering domains) Business analysis and system analysis The analyses are supposed to: - Provide an understanding of a business problem - the customer organization (the recipient of the IT system) including its business processes, goals and strategies - Identify requirements for the planned IT system - Describe the business problem and the IT system requirements (various representations can be used for this purpose, including abstract models) Vision document - An initial, rather generic attempt to define the business problem and the scope of the IT system. It’s a technical documentation!! Vision document structure: 1. Description of the customer organization 2. Stakeholders 3. System's context (users and cooperating systems) 4. Functional requirements 5. Quality requirements 6. Constraints The description of the customer organization: - The description must include precise data (also quantitative e.g. number of employees), the business profile, main business processes (related to production, services, sales etc.), the relationships with other organizations - Organizational structure, division of responsibilities - Identification of problems, which are currently encountered by the organization and can potentially be eliminated or reduced by introducing an IT system - A generic concept of the planned IT supporting system Stakeholders - each party (not necessarily a person) which is interested in the developed system and has a justifiable right to influence it, thus: a potential source of requirements for the system Stakeholders are: - Future users - Other employees of customer organization - External partners of the organization - Customers of the organization - External IT systems collaborating with the software - Laws and regulations - Organizations monitoring compliance to regulations Stakeholders' viewpoints: Example: Bank customers expect that the introduction of the new IT system will shorten the time spent at bank tellers and enable standard operations like fund transfers to be done directly, using Internet banking. Has a strong interest in security to avoid unauthorized operations and disclosure of his/her financial data. Viewpoints are related to: - Various ways and purposes of using the system - Organizational issues - Other cooperating IT systems - Domain knowledge - Regulations System’s context Users and their specifics: - Who will use the system? - In what environment it will be used (e.g. office, outdoors, etc.) - What is essential in user’s work (e.g. time of task accomplishment) - What are the user’s skills in using IT systems of a given kind - Will training courses be needed, and if so, what will be their scope - What additional help should be provided (e.g. manual, tutorials) External cooperating systems: - Scope of cooperation - Provided/expected functions - Technical means of cooperation - Format of exchanged data - Data shared between systems System requirements 1. Functional: - What is the system supposed to do? - What services will be available to users? 2. Quality (non-functional): - What is the expected quality of the services provided? 3. Constraints: - What restrictions are imposed on the supplier of the IT system? - e.g.: time, budget, particular technologies, documentation Quality requirements: - Performance - the requirements about the expected number of (concurrent) users, data volumes, system response time; also: how such parameters can change over time - Reliability – requirements expressing that software operation is failure-free for a specified period of time or for a number of uses - Availability – what is the required system’s uptime? What is an acceptable downtime? are there any hours of the day or days of the week/month this issue is more/less important? - Security – to what extent does the system need protection from external malicious attacks? - Safety – to what extent is the system expected to guarantee that it will not endanger its environment (e.g. hurt people, destroy property) - Portability – how important it is that the system can be used on different devices, platforms, operating systems, browsers etc. - Flexibility – to what extent should the system be easy for further development e.g. expanding its functionality, adding new modules? What are the most probable directions of its further extension?  - Configurability – are there any important parameters that usually are stable but in the longer time period can change and cannot be „hardcoded” but possible to modify e.g. by system administrator (for example - tax rates)? Expressing requirements: Functional - it is sufficient to list the services available to particular users Quality - requirements expressed in a verifiable and measurable way, but without imposing particular design solutions Constraints: - With respect to the project: The fully operable system shall be delivered and deployed before 31.05.2023. - With respect to the product: To be consistent with customer’s technology policy, the data layer of the system shall be based on MS SQL (imposed restriction, not independent design decision!)  Main areas of software engineering Business analysis: - Identification and comprehension of a business problem - Identification of business goals and related business strategies - High-level decisions about starting the project (or not) and its scope - Identification of business processes (and possibly re-engineering of existing processes) System analysis: - Capturing requirements for the system (requirements engineering) - Representing requirements e.g. as abstract models - Requirements management The borders between BA and SA can be blurred! Requirements engineering - The core, essential part of system analysis Main activities: - requirements elicitation - requirements analysis  - requirements specification - requirements validation - requirements management Design System design (architectural design) - Describes the system in terms of its building modules (layers, subsystems) and their terms of cooperation Class design (detailed design) - Describes the internal operations and dependencies within particular modules Definition of system’s architecture: - Logical architecture – decomposition into layers and subsystems - Physical architecture – assignment of logical modules to computers/devices - Communication interfaces - Frameworks Design patterns - repeatable „good solutions” to frequently encountered problems in design/code Good practices: - e.g. SOLID principles, object-oriented paradigm - metrics e.g. high cohesion, low coupling Decisions about priorities: - derived from requirements - e.g. performance vs. portability, code simplicity vs. optimized algorithms Coding: - using the available technologies - writing source code - unit testing (tests for particular classes, methods, functions) are often considered a part of coding Testing - an analysis of product’s behavior for the purpose of evaluating its quality The main goal is to detect bugs! bug (defect) – a wrong instruction or data definition in the program failure – program’s inability to deliver some functions (visible to users) error – the state or behavior of the program which deviates from expectations (but may not be visible) Testing cannot prove software program’s correctness – it can only show errors and failures, and therefore presence of defects! Challenges of testing: - Is it possible to test everything in a program/system? - Does the quality of a program/system increase with each defect found and removed? - Defect masking - Regression tests - The Pesticide Paradox Deployment – delivery of the IT system to the customer and enabling its use as part of achieving business goals Maintenance – introducing changes to the IT system after its deployment Deployment Development - the work in an IT project aimed to create an IT system Delivery – acceptance of the system by the customer Deployment – activities aimed at enabling usage of the IT system Go live – the moment usage can be started Usage – using IT system as part of customer’s business processes Deployment – activities: - Deployment planning / preparation - Installation of the IT system – possibly also of the equipment, operating systems, additional software - Configuring - Customization (tailoring a generic software product to the particular needs of the customer organization) - Training courses - for users - for administrators - possibly, at first for the deployment staff - Data migration / introduction - Changes in customer organization (!) - Audit / certification / formal acceptance - Readiness to go-live – possibly also decommissioning of the old system Maintenance What kind of changes are made? - Fixing defects [corrective maintenance]  - New functions, additional options, optimizations [perfective maintenance] - Adaptations to environment changes (e.g. application server, DBMS, web browser) [adaptive maintenance] - Changes addressing anticipated problems before they materialize [preventive maintenance] Long term maintenance - Changes introduced as part of maintenance usually negatively affect code structure, the source code becomes more difficult to understand and to be further maintained - To some extent the code can be automatically modified in order to e.g. remove unused parts of code, simplify conditional statements (so they become clearer), etc. But in the long run it is the task of humans Refactoring: - modification of the internal code structure, which does not change its observable behavior, but makes it more understandable and easier to modify in future - removal of so-called code bad smells Restructuring: - modification on a higher level of abstraction – changes in system’s architecture, subsystem interfaces, communications between subsystems/layers Quality assurance: - Good practices in design and code development - Software patterns - Defect detection and defect prevention - Metrics (e.g. of code, defect detection, test coverage) - Standards - Process management How to evaluate software quickly? Project success/failure Multiple dimensions: - Aims (