Software Engineering Lectures 1-8 PDF

Lectures 1-2 What is software?  Computer programs and associated documentation such as requirements, design models and user manuals.  Software products may be developed for a particular customer or may be developed for a general market.  Software products may be...

Lectures 1-2 What is software?  Computer programs and associated documentation such as requirements, design models and user manuals.  Software products may be developed for a particular customer or may be developed for a general market.  Software products may be  Generic - developed to be sold to a range of different customers e.g. PC software such as Excel or Word.  Bespoke (custom) - developed for a single customer according to their specification.  New software can be created by developing new programs, configuring generic software systems or reusing existing software. What is software engineering?  Software engineering is an engineering discipline that is concerned with all aspects of software production.  Software engineers should adopt a systematic and organized approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available. What is a Software Process?  A set of activities whose goal is the development or evolution of software.  Generic activities in all software processes are:  Specification - what the system should do and its development constraints  Development - production of the software system  Validation - checking that the software is what the customer wants  Evolution - changing the software in response to changing demands. What are software engineering methods?  Structured approaches to software development which include system models, notations, rules, design advice and process guidance.  Model descriptions  Descriptions of graphical models which should be produced;  Rules  Constraints applied to system models;  Recommendations  Advice on good design practice;  Process guidance  What activities to follow. What is CASE (Computer-Aided Software Engineering)?  Software systems that are intended to provide automated support for software process activities.  CASE systems are often used for method support.  Upper-CASE  Tools to support the early process activities of requirements and design;  Lower-CASE  Tools to support later activities such as programming, debugging and testing What are the Attributes of Good Software?  The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable.  Maintainability  Software must evolve to meet changing needs;  Dependability  Software must be trustworthy;  Efficiency  Software should not make wasteful use of system resources;  Acceptability  Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems. What are the key challenges facing software engineering?  Heterogeneity, delivery and trust:  Heterogeneity  Developing techniques for building software that can cope with heterogeneous platforms and execution environments;  Delivery  Developing techniques that lead to faster delivery of software;  Trust  Developing techniques that demonstrate that software can be trusted by its users. Issues of professional responsibility  Confidentiality  Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed.  Competence  Engineers should not misrepresent their level of competence. They should not knowingly accept work which is out with their competence. Code of Ethics - Principles  PUBLIC  Software engineers shall act consistently with the public interest.  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.  PRODUCT  Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. Code of Ethics - Principles  JUDGMENT  Software engineers shall maintain integrity and independence in their professional judgment.  MANAGEMENT  Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.  PROFESSION  Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. Code of Ethics - Principles  COLLEAGUES  Software engineers shall be fair to and supportive of their colleagues.  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. Ethical Dilemmas  Disagreement in principle with the policies of senior management.  Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system.  Participation in the development of military weapons systems or nuclear systems. Lectures 3-4 What is a system?  A purposeful collection of inter-related components working together to achieve some common objective.  A system may include software, mechanical, electrical and electronic hardware and be operated by people.  System components are dependent on other system components.  The properties and behavior of system components are inextricably inter-mingled System categories  Technical computer-based systems  Systems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self- aware.  Socio-technical systems  Systems that include technical systems but also operational processes and people who use and interact with the technical system. Socio-technical systems are governed by organizational policies and rules. Socio-technical system characteristics  Emergent properties  Properties of the system of a whole that depend on the system components and their relationships.  Non-deterministic  They do not always produce the same output when presented with the same input because the systems’s behavior is partially dependent on human operators.  Complex relationships with organizational objectives  The extent to which the system supports organizational objectives does not just depend on the system itself. Emergent Properties  Properties of the system as a whole rather than properties that can be derived from the properties of components of a system  Emergent properties are a consequence of the relationships between system components  They can therefore only be assessed and measured once the components have been integrated into a system Types of emergent property  Functional properties  These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.  Non-functional emergent properties  Examples are reliability, performance, safety, and security. These relate to the behavior of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.  System Reliability Engineering  Because of component inter-dependencies, faults can be propagated through the system.  System failures often occur because of unforeseen inter-relationships between components.  It is probably impossible to anticipate all possible component relationships.  Software reliability measures may give a false picture of the system reliability.  Influences on reliability  Hardware reliability  What is the probability of a hardware component failing and how long does it take to repair that component?  Software reliability  How likely is it that a software component will produce an incorrect output. Software failure is usually distinct from hardware failure in that software does not wear out.  Operator reliability  How likely is it that the operator of a system will make an error? Reliability Relationships  Hardware failure can generate spurious signals that are outside the range of inputs expected by the software.  Software errors can cause alarms to be activated which cause operator stress and lead to operator errors.  The environment in which a system is installed can affect its reliability. The ‘shall-not’ properties  Properties such as performance and reliability can be measured.  However, some properties are properties that the system should not exhibit:  Safety - the system should not behave in an unsafe way;  Security - the system should not permit unauthorized use.  Measuring or assessing these properties is very hard. Systems Engineering  Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems.  Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used. The System Engineering Process  Usually follows a ‘waterfall’ model because of the need for parallel development of different parts of the system  Little scope for iteration between phases because hardware changes are very expensive. Software may have to compensate for hardware problems.  Inevitably involves engineers from different disciplines who must work together  Much scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfil. The systems engineering process Inter-Disciplinary Involvement Software Electro nic M ech an ical engin eering engin eering engin eering Structural ATC systems User in terface engin eering engin eering design Civ il Electrical Architecture engin eering engin eering System Requirements Definition  Three types of requirement defined at this stage  Abstract functional requirements: System functions are defined in an abstract way;  System properties: Non-functional requirements for the system in general are defined;  Undesirable characteristics. Unacceptable system behavior is specified.  Should also define overall organizational objectives for the system. System Objectives  Should define why a system is being procured for a particular environment.  Functional objectives  To provide a fire and intruder alarm system for the building which will provide internal and external warning of fire or unauthorized intrusion.  Organizational objectives  To ensure that the normal functioning of work carried out in the building is not seriously disrupted by events such as fire and unauthorized intrusion. System Requirements Problems  Complex systems are usually developed to address wicked problems  Problems that are not fully understood;  Changing as the system is being specified.  Must anticipate hardware/communications developments over the lifetime of the system.  Hard to define non-functional requirements (particularly) without knowing the component structure of the system. The System Design Process 1. Partition requirements  Organize requirements into related groups. 2. Identify sub-systems  Identify a set of sub-systems which collectively can meet the system requirements. 3. Assign requirements to sub-systems  Causes particular problems when COTS are integrated. 4. Specify sub-system functionality. 5. Define sub-system interfaces  Critical activity for parallel sub-system development. The System Design Process System Design Problems  Requirements partitioning to hardware, software and human components may involve a lot of negotiation.  Difficult design problems are often assumed to be readily solved using software.  Hardware platforms may be inappropriate for software requirements so software must compensate for this. Requirements and Design  Requirements engineering and system design are inextricably linked.  Constraints posed by the system’s environment and other systems limit design choices so the actual design to be used may be a requirement.  Initial design may be necessary to structure the requirements.  As you do design, you learn more about the requirements. Spiral Model of Requirements/Design System Modelling  An architectural model presents an abstract view of the sub- systems making up a system  May include major information flows between sub-systems  Usually presented as a block diagram  May identify different types of functional component in the model Burglar alarm system Sub-System Description Su b -ss ty em D es crip tion M ov emen te s nsors D ete c ts mo ve me ntin thero omsm o nit oed rb yth esys te m D oo rse nso r s D ete c ts o d oro pen in ginth eex ter n ald oorsfth o ebu ildi n g A la rmc ontr oller C on tr olsh eto perat io nof he t s ys tem S ire n E mits ana udi b lew ar nin gwh en a n in tr ude risu sp setc ed V oice sy nh t esi ze r S ynth esiz esav oice messa ge giv ingth elo catio nfo th eusp setc edin tr ude r Te lep h onea lc l er M ake sex ter n al ca llsot notifys ecu rity ,th epo lice ,et c. ATC system architecture Sub-System Development  Typically parallel projects developing the hardware, software and communications.  May involve some COTS (Commercial Off-the-Shelf) systems procurement.  Lack of communication across implementation teams.  Bureaucratic and slow mechanism for proposing system changes means that the development schedule may be extended because of the need for rework. System Integration  The process of putting hardware, software and people together to make a system.  Should be tackled incrementally so that sub-systems are integrated one at a time.  Interface problems between sub-systems are usually found at this stage.  May be problems with uncoordinated deliveries of system components. System Installation  After completion, the system has to be installed in the customer’s environment  Environmental assumptions may be incorrect;  May be human resistance to the introduction of a new system;  System may have to coexist with alternative systems for some time;  May be physical installation problems (e.g. cabling problems);  Operator training has to be identified. System evolution  Large systems have a long lifetime. They must evolve to meet changing requirements.  Evolution is inherently costly  Changes must be analyzed from a technical and business perspective;  Sub-systems interact so unanticipated problems can arise;  There is rarely a rationale for original design decisions;  System structure is corrupted as changes are made to it.  Existing systems which must be maintained are sometimes called legacy systems. System Decommissioning  Taking the system out of service after its useful lifetime.  May require removal of materials (e.g. dangerous chemicals) which pollute the environment  Should be planned for in the system design by encapsulation.  May require data to be restructured and converted to be used in some other system. Process Activities  Software specification  Software design and implementation  Software validation  Software evolution Software specification  The process of establishing what services are required and the constraints on the system's operation and development.  Requirements engineering process  Feasibility study;  Requirements elicitation and analysis;  Requirements specification;  Requirements validation. The Requirements Engineering Process Software Design and Implementation  Def:The process of converting the system specification into an executable system.  Software design  Design a software structure that realizes the specification;  Implementation  Translate this structure into an executable program;  The activities of design and implementation are closely related and may be inter-leaved. Lectures 6 Design Process Activities  Architectural design  Abstract specification  Interface design  Component design  Data structure design  Algorithm design The Software Design Process Structured methods  Def: Systematic approaches to developing a software design.  The design is usually documented as a set of graphical models.  Possible models  Object model;  Sequence model;  State transition model;  Structural model;  Data-flow model. Programming and Debugging  Translating a design into a program and removing errors from that program.  Programming is a personal activity - there is no generic programming process.  Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process. The Debugging Process  Software 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.  Involves checking and review processes and system testing.  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. The Testing Process Testing Stages  Component or unit testing  Individual components are tested independently;  Components may be functions or objects or coherent groupings of these entities.  System testing  Testing of the system as a whole. Testing of emergent properties is particularly important.  Acceptance testing  Testing with customer data to check that the system meets the customer's needs. Testing phases Software evolution  Software is inherently flexible and can change.  As requirements change through changing business circumstances, the software that supports the business must also evolve and change.  Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. System evolution Lectures 7 Management Activities  Proposal writing.  Project planning and scheduling.  Project costing.  Project monitoring and reviews.  Personnel selection and evaluation.  Report writing and presentations. The project plan  The project plan sets out:  The resources available to the project;  The work breakdown;  A schedule for the work. Project Plan Structure  Introduction.  Project organisation.  Risk analysis.  Hardware and software resource requirements.  Work breakdown.  Project schedule.  Monitoring and reporting mechanisms. Activity Organization  Activities in a project should be organised to produce tangible outputs for management to judge progress.  Milestones are the end-point of a process activity.  Deliverables are project results delivered to customers.  The waterfall process allows for the straightforward definition of progress milestones. Milestones in the RE process Project Scheduling  Split project into tasks and estimate time and resources required to complete each task.  Organize tasks concurrently to make optimal use of workforce.  Minimize task dependencies to avoid delays caused by one task waiting for another to complete.  Dependent on project managers intuition and experience. The Project Scheduling Process Scheduling Problems  Estimating the difficulty of problems and hence the cost of developing a solution is hard.  Productivity is not proportional to the number of people working on a task.  Adding people to a late project makes it later because of communication overheads.  The unexpected always happens. Always allow contingency in planning. Lectures 8 Requirements Engineering  Def: The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.  The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. What is a requirement?  It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.  This is inevitable as requirements may serve a dual function:  May be the basis for a bid for a contract - therefore must be open to interpretation;  May be the basis for the contract itself - therefore must be defined in detail;  Both these statements may be called requirements.  Types of requirement  User requirements  Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.  System requirements  A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor. Functional and non-functional requirements  Functional requirements  Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.  Non-functional requirements  constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.  Domain requirements  Requirements that come from the application domain of the system and that reflect characteristics of that domain. Functional Rrequirements  Describe functionality or system services.  Depend on the type of software, expected users and the type of system where the software is used.  Functional user requirements may be high- level statements of what the system should do but functional system requirements should describe the system services in detail. Requirements imprecision  Problems arise when requirements are not precisely stated.  Ambiguous requirements may be interpreted in different ways by developers and users.  Consider the term ‘appropriate viewers’  User intention - special purpose viewer for each different document type;  Developer interpretation - Provide a text viewer that shows the contents of the document. Requirements completeness and consistency  In principle, requirements should be both complete and consistent.  Complete  They should include descriptions of all facilities required.  Consistent  There should be no conflicts or contradictions in the descriptions of the system facilities.  In practice, it is impossible to produce a complete and consistent requirements document.  Non-functional requirements  Def: These define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.  Process requirements may also be specified mandating a particular CASE system, programming language or development method.  Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.  Non-functional classifications  Product requirements  Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.  Organisational requirements  Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc.  External requirements  Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc. Goals and Requirements  Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.  Goal  A general intention of the user such as ease of use.  Verifiable non-functional requirement  A statement using some measure that can be objectively tested.  Goals are helpful to developers as they convey the intentions of the system users. Requirements Measures Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size M Bytes Numb er of ROM chips Ease of use Training time Numb er of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Numb er of target systems Requirements interaction  Conflicts between different non-functional requirements are common in complex systems.  Example: Spacecraft system  To minimise weight, the number of separate chips in the system should be minimised.  To minimise power consumption, lower power chips should be used.  However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?  Domain requirements  Derived from the application domain and describe system characteristics and features that reflect the domain.  Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.  If domain requirements are not satisfied, the system may be unworkable. Domain requirements problems  Understandability  Requirements are expressed in the language of the application domain;  This is often not understood by software engineers developing the system.  Implicitness  Domain specialists understand the area so well that they do not think of making the domain requirements explicit. User Requirements  Should describe functional and non- functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge.  User requirements are defined using natural language, tables and diagrams as these can be understood by all users. Problems with natural language  Lack of clarity  Precision is difficult without making the document difficult to read.  Requirements confusion  Functional and non-functional requirements tend to be mixed-up.  Requirements amalgamation  Several different requirements may be expressed together. System requirements  More detailed specifications of system functions, services and constraints than user requirements.  They are intended to be a basis for designing the system.  They may be incorporated into the system contract.  System requirements may be defined or illustrated using system models Requirements and design  In principle, requirements should state what the system should do and the design should describe how it does this.  In practice, requirements and design are inseparable  A system architecture may be designed to structure the requirements;  The system may inter-operate with other systems that generate design requirements;  The use of a specific design may be a domain requirement.  Problems with NL specification  Ambiguity  The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.  Over-flexibility  The same thing may be said in a number of different ways in the specification.  Lack of modularisation  NL structures are inadequate to structure system requirements. Structured language specifications  The freedom of the requirements writer is limited by a predefined template for requirements.  All requirements are written in a standard way.  The terminology used in the description may be limited.  The advantage is that the most of the expressiveness of natural language is maintained but a degree of uniformity is imposed on the specification. Form-based specifications  Definition of the function or entity.  Description of inputs and where they come from.  Description of outputs and where they go to.  Indication of other entities required.  Pre and post conditions (if appropriate).  The side effects (if any) of the function.