An Introduction to Software Engineering FAQs about sw

An Introduction to Software Engineering

FAQs about sw engineering � What is software? � What is software engineering? � What is the difference between software engineering and computer science? � What is the difference between software engineering and system engineering? � What is a software process model?

FAQs about sw engineering � What are the costs of software engineering? � What are software engineering methods? � What is CASE (Computer-Aided Software Engineering) � What are the attributes of good software? � What are the key challenges facing software engineering?

What is software? Computer programs & associated documentation such as requirements, design models & user manuals. � SW products may be developed for a particular customer / 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 organised 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 the difference between sw engineering and computer science? � Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. � Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e. g. physics and electrical engineering).

What is the difference between sw engineering and system engineering? � System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process concerned with developing the software infrastructure, control, applications and databases in the system. � System engineers are involved in system specification, architectural design, integration and deployment.

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 sw system › Validation - checking that the software is what the customer wants › Evolution - changing the software in response to changing demands.

What is a sw process model ? A simplified representation of a software process, presented from a specific perspective. � Examples of process perspectives are › Workflow perspective - sequence of activities; › Data-flow perspective - information flow; › Role/action perspective - who does what. � Generic process models › Waterfall; › Iterative development; › Component-based software engineering. �

What are the costs of sw engineering ? � Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. � Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability. � Distribution of costs depends on the development model that is used.

Activity cost distribution

Product development costs

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 sw ? � � � The sw should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. Maintainability › Sw must evolve to meet changing needs; Dependability › Software must be trustworthy; Efficiency › Sw should not make wasteful use of syst resources; Acceptability › Sw 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.

Professional and ethical responsibility � Software engineering involves wider responsibilities than simply the application of technical skills. � Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. � Ethical behaviour is more than simply upholding the law.

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 outwith their competence.

Issues of professional responsibility � Intellectual property rights › Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. They should be careful to ensure that the intellectual property of employers and clients is protected. � Computer misuse › Software engineers should not use their technical skills to misuse other people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

ACM/IEEE Code of Ethics � The professional societies in the US have cooperated to produce a code of ethical practice. � Members of these organisations sign up to the code of practice when they join. � The Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.

Code of ethics - preamble � Preamble › The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as sw engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code. › In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

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.

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

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 behaviour is specified. � Should also define overall organisational 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. � Organisational 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.

The system design process � � � Partition requirements › Organise requirements into related groups. Identify sub-systems › Identify a set of sub-systems which collectively can meet the system requirements. Assign requirements to sub-systems › Causes particular problems when COTS are integrated. Specify sub-system functionality. Define sub-system interfaces › Critical activity for parallel sub-system development.

The system design process

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.

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

ATC system architecture

System integration The process of putting hardware, software and people together to make a system. � Should be tackled incrementally so that subsystems 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 analysed 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. �

Organisations/people/systems � Socio-technical systems are organisational systems intended to help deliver some organisational or business goal. � If you do not understand the organisational environment where a system is used, the system is less likely to meet the real needs of the business and its users.

Human and organisational factors � Process changes › Does the system require changes to the work processes in the environment? � Job changes › Does the system de-skill the users in an environment or cause them to change the way they work? � Organisational changes › Does the system change the political power structure in an organisation?

Legacy systems � Socio-technical systems that have been developed using old or obsolete technology. � Crucial to the operation of a business and it is often too risky to discard these systems › Bank customer accounting system; › Aircraft maintenance system. � Legacy systems constrain new business processes and consume a high proportion of company budgets.

Legacy system components � � � Hw - may be obsolete mainframe hardware. Support software - may rely on support sw from suppliers who are no longer in business. Application software - may be written in obsolete programming languages. Application data - often incomplete and inconsistent. Business processes - may be constrained by software structure and functionality. Business policies and rules - may be implicit and embedded in the system software.

The software process A structured set of activities required to develop a software system › Specification; › Design; › Validation; › Evolution. � A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. �

Generic software process models The waterfall model › Separate and distinct phases of specification and development. � Evolutionary development › Specification, development and validation are interleaved. � Component-based software engineering › The system is assembled from existing components. � There are many variants of these models e. g. formal development where a waterfall-like process is used but the specification is a formal specification that is refined through several stages to an implementable design. �

Waterfall model

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.

Software design and implementation � The process of converting the system specification into an executable system. � Software design › Design a software structure that realises the specification; � Implementation › Translate this structure into an executable program; � The activities of design and implementation are closely related and may be inter-leaved.

Design process activities � Architectural design � Abstract specification � Interface design � Component design � Data structure design � Algorithm design

Structured methods � 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. �

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.

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

Verification vs validation � Verification: "Are we building the product right”. � The software should conform to its specification. � Validation: "Are we building the right product”. � The software should do what the user really requires.

The V & V process � Is a whole life-cycle process - V & V must be applied at each stage in the software process. � Has two principal objectives › The discovery of defects in a system; › The assessment of whether or not the system is useful and useable in an operational situation.

V & V goals � Verification and validation should establish confidence that the software is fit for purpose. � This does NOT mean completely free of defects. � Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed.

V & V confidence � Depends on system’s purpose, user expectations and marketing environment › Software function �The level of confidence depends on how critical the software is to an organisation. › User expectations �Users may have low expectations of certain kinds of software. › Marketing environment �Getting a product to market early may be more important than finding defects in the program.

Types of testing � Defect testing › Tests designed to discover system defects. › A successful defect test is one which reveals the presence of defects in a system. � Validation testing › Intended to show that the software meets its requirements. › A successful test is one that shows that a requirements has been properly implemented.

Testing and debugging Defect testing and debugging are distinct processes. � Verification and validation is concerned with establishing the existence of defects in a program. � Debugging is concerned with locating and repairing these errors. � Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the system error. �