2.SoftwareDevelopment.pdf

CSIT314 Software Development Methodologies Introduction to Software Development and its Lifecyle 1 How software is different? Software is soft and intangible  There are no physical laws underlying software behaviour  Software are never wears out  cannot touch  traditional reliability measures do...

CSIT314 Software Development Methodologies Introduction to Software Development and its Lifecyle 1 How software is different? Software is soft and intangible  There are no physical laws underlying software behaviour  Software are never wears out  cannot touch  traditional reliability measures don’t apply Software is not mass produced  The specification for software continuously changes  updates 2 “Software eats the World”   “We are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy” (Marc Andreessen, “Why Software is Eating the World”, The Wall Street Journal, http://online.wsj.com/article/SB100014240531119034809 04576512250915629460.html) More and more major businesses and industries are being run on software and delivered online services. hard to find an industry that isn't using technology “Software eats the World” (cont.) Good news for us …. But “With great power there must also come great responsibility” … Low-quality software costs jobs... https://www.youtube.com/watch?v=7BKNnpJfWII Low-quality software costs money... On the 4th June 1996 at 1233 GMT (UTC) the European Space Agency launched a new rocket, Ariane 5, on its maiden unmanned flight, https://www.youtube.com/watch?v=kYUrqdUyEpI “It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business. All it took to explode that rocket less than a minute into its maiden voyage last June, scattering fiery rubble across the mangrove swamps of French Guiana, was a small computer program trying to stuff a 64-bit number into a 16-bit space” Source: http://www.around.com/ariane.html Low-quality software costs lives Software The Airbus A380 uses a substantial amount of software to create a "paperless" cockpit Q: How many lines of code constituting the plane's software? A: Millions of lines of code Android OS has 15 million lines of code. Moodle have 1 million lines of code. Windows XP has 45 million lines of code. Software Engineering plays a critical part in the development of such a large-scale software. 8 Software Development Activities Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  coding 9 Planning Identify business value  Analyse feasibility  Develop work plan  Staff the project  Estimate  Identify risk  You have learnt these in CSIT214 10 Software Engineering Development Activities Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  what functionalities and features it should have 11 Requirements analysis  The process of establishing what services are required and the constraints on the system’s operation and development.  There are two major activities:  Requirements elicitation    collect the requirement Who are the stakeholders of this project? talk to clients What do the system stakeholders require or expect from the system? Interviews, questionnaires, meeting, etc. business analysists talk to clients and get their requirements  e.g. the system should allow the user to track their favorites Requirements specification   Defining the requirements in detail Use cases are the major part of a requirements specification functional requirement is a functionality or UI non-functional is more like time or the size of the app 12 Software Engineering Development Activities Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  13 Design  What is Design?   How is Design different from Requirements Analysis?   Design is concerned with HOW we build a system Analysis is concerned with WHAT is to be built There are many different aspects to design 14 Design (cont.) Design comprises of different aspects: 1.Architectural design 2.Sub system design 3.Detailed design 4.Persistent data design 5.GUI design 15 Architecture Design Concerned with major structure of the software Similar to building architecture (e.g. roof, walls, foundations) Contains sub-systems (air-conditioning unit, water pump) Uses external services (sewerage, water, gas, electric) The most important part of design – if the architecture is wrong, the house will fall down (or software will fall down!) e.g. Moodle will have timetable, forum and other components 16 Design  Sub-system design     Describes interfaces/protocols of each subsystem Structure of each sub-system Structure can describe how each sub-system sub-divides into packages, components Detailed design Describes each class, methods, attributes/datatypes 17 Design (cont.)  Persistent data design Describes choice of database, tables, primary and foreign keys database design - tables, FK, PK   User interface design  Describes: how the GUI will look like what tools will be used to build it the structure of the GUI what design guidelines will be followed what style guidelines will be followed 18 Flashback Quiz  Software deteriorates rather than wears out because     A) Software suffers from exposure to hostile environments B) Defects are more likely to arise after software has been used often C) Multiple change requests introduce errors in component interactions D) Software spare parts become harder to order C 19 Software Engineering Development Activities Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  20 Implementation  Construction   Write the code for the project. Installation (or deployment) 21 Software Engineering Development Activities Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  22 Software verification and validation  Verification and validation (V & V) is intended to show that:  a system conforms to its specification and  meets the requirements of the system customer.  Testing is the most commonly used V & V activity.  System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. test meet the requirements 23 23 Verification   It works! Final check through all those use cases from the specification document  Does the system perform exactly as specified? difference between verification and validation verification - check if it works as specified in the requirements and behaves as required. validation - show that feature to the client and make sure that the client is satisfied. 24 and Validation Bring in the users and demonstrate You: It is working. Here let me demonstrate how you would …  not User: That’s what I wanted! I wanted … You: It is exactly what is in the agreed specification! You said you wanted … User: You should have implemented what I meant, not what I said. 25 Cost of defects …  Cost of correcting an error in requirement specifications increases as we move through lifecycle phases 26 Software Engineering Development Activities Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  27 Software maintenance and evolution  Changes are inevitable in software development – WHY?:  New requirements emerged at any time in the software development lifecycle.   Changes in business environments    E.g. new servers, new equipments, etc. New technology arriving   E.g. competition, laws, new markets, new customers, etc. Changes in infrastructure environments   E.g. new functionalities E.g. New version of OS, new standards, etc. Bugs need fixing Performance needs improvement. 28 Types of software maintenance  Adaptive maintenance   Corrective maintenance   Changing the system in response to changes in its environment so it continues to function Fixing errors & bugs Perfective maintenance  most common Changing the system’s functionality to meet changing needs 29 Change propagation changes change one class will result in changing the other classes cus related The ripple effect changes changes changes As a change is started on a software system, other coordinated changes are often needed at the same time in other parts of the software. 30 Change propagation (cont.) real life software classes example These other required changes, if not completed immediately, incur a kind of debt that must31be paid at some point in the future. Technical Debt “Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer”  If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes.  How to repay technical debt?  32 Source: https://en.wikipedia.org/wiki/Technical_debt The eight laws of software evolution Law 1: Continuing change  Law 2: Increasing complexity  Law 3: Self regulation  Law 4: Conservation of organisational stability  Law 5: Conservation of familiarity  Law 6: Continuing growth  Law 7: Declining quality  Law 8: Feedback system  Source: M. M. Lehman. Laws of Software Evolution Revisited. Lecture Notes in33 Computer Science 1149, pp. 108-124, Springer Verlag, 1997 The eight laws of software evolution  Law 1: Continuing change   A program that is used in a real-world environment must be continually adapted, or else become progressively less satisfactory Why?   New requirements emerged constantly Evolution of the environment => increasing mismatch between the system and its environment. 34 The eight laws of software evolution  Law 2: Increasing complexity   As a program is evolved, its complexity increases with time, unless specific work is done to maintain or reduce it. Why?    Unpaid technical debts increases software entropy Accumulated technical debt makes it more difficult to change. Refactoring and restructuring may be needed. 35 The eight laws of software evolution  Law 6: Continuing growth   Functional content of a program must be continually increased to maintain user satisfaction over its lifetime. Why?  If the users find they can get work done with the new system, then they will soon identify additional tasks for it to do and require changed forms for interaction with the system. 36 The eight laws of software evolution  Law 7: Declining quality   Evolving programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment. Why?  Similar to Law 1 but this law emphasizes on reliability and performance. 37 Review Planning  Requirements analysis  Design  Implementation  Verification & Validation  Maintenance and evolution  Development costs 38