260 likes | 432 Views
Software Engineering COMP 201. Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 3 – Software Processes. Recap from Last Lecture: Generic Software Process Models. The Waterfall Model
E N D
Software EngineeringCOMP 201 Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 3 – Software Processes COMP201 - Software Engineering
Recap from Last Lecture: Generic Software Process Models • The Waterfall Model • Separate and distinct phases of specification and development • Evolutionary Development • Specification and development are interleaved • Formal Systems Development (example - ASML) • A mathematical system model is formally transformed to an implementation • Reuse-Based Development • The system is assembled from existing components COMP201 - Software Engineering
Software Specification • 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 COMP201 - Software Engineering
The Requirements Engineering Process COMP201 - Software Engineering
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 COMP201 - Software Engineering
Design Process Activities • Architectural design • The sub-systems making up the system and their relationships are identified and documented. • Abstract specification • For each sub-system, an abstract specification of its operational constraints and services is produced. • Interface design • For each sub-system, an unambiguous interface with other sub-systems is designed and documented • Formal specification may be used in this stage (we study this later) COMP201 - Software Engineering
Design Process Activities • Component design • Services are allocated to components and the interfaces of these components are designed • Data structure design • The data structures used in the system implementation are designed in detail and specified • Algorithm design • The algorithms used in components to provide services are designed and specified COMP201 - Software Engineering
An Example System • Consider the scenario of developing a Coffee/drinks machinesoftware • What are the major sub-systems? • Graphical display, cash handling, accounting, safety system, recipe handling, stock control • How may we define an abstract specification for each? How do the different sub-systems interact? • Can you define specifications for components/data structures and algorithms for one of the sub-systems? COMP201 - Software Engineering
The Software Design Process COMP201 - Software Engineering
Models • Graphical views of the operation/structure of the system • Can be dynamic or static • Why have models • Formalizes the type and format of required information • Easier to get the big picture than text documents • Some, can be translated automatically to software implementation • Can be tested for validity automatically COMP201 - Software Engineering
Design Methods • Design (structured) methods aresystematic approaches to developing a software design • The design is usually documented as a set of graphical models • Possible models (we study these in detail in later lectures) • Data-flow model • Entity-relation-attribute model (data base or class design) • Structural model • Object models • A state transition model showing system states and triggers COMP201 - Software Engineering
Programming and Debugging • Programming and Debugging consist of translating a design into a program and removing errors from that program • Programming is usually personal activity- there is no generic programming process, but there are good programming practices and organisational standards to be followed. • Programmers carry out some program testingto discover faults in the program and remove these faults in the debugging process COMP201 - Software Engineering
The Debugging Process COMP201 - Software Engineering
Debugging in real world • Ideally the software fault can be re-produced at will • Some software faults indicate problems with overall software design and require application re-design • e.g. lack of thread safety • If bugs hard or impossible to re-produce in test conditions • Insert debug/test code embedded into product which logs and alerts in fault conditions • Add patch code, which will help recover in fault conditions • Example catching exceptions and logging COMP201 - Software Engineering
Software Validation • Verification and validation is intended to show that a system conforms to its specification (verification) and meets the requirements of the system customer (validation) • Involves checking and review processes and system testing • System testing involves executing the system with test casesthat are derived from the specification of the real data to be processed by the system COMP201 - Software Engineering
The Testing Process COMP201 - Software Engineering
Testing Stages • Unit testing • Individual components are tested • Module testing • Related collections of dependent components are tested • Sub-system testing (merges with system testing) • Modules are integrated into sub-systems and tested. The focus here should be on interface testing • System testing • Testing of the system as a whole. Testing of emergent properties • Acceptance testing • Testing with customer data to check that it is acceptable COMP201 - Software Engineering
Testing Phases COMP201 - Software Engineering
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 • It is important to realise that maintenance costs are sometimes several times the initial development costs of the system. COMP201 - Software Engineering
System Evolution COMP201 - Software Engineering
Automated Process Support (CASE) • Computer-aided software engineering (CASE)is software to support software development and evolution processes • Activity automation: • Graphical editorsfor system model development • Data dictionaryto manage design entities • Graphical UI builderfor user interface construction • Bug/Issue management tools • Version control management tools • Debuggers to support program fault finding • Automated translatorsto generate new versions of a program COMP201 - Software Engineering
Case Technology Case technology has led to significant improvements in the software process though not the order of magnitude improvements that were once predicted. Why is this? • Software engineering requires creative thought- this is not readily automatable and the use of artificial intelligence to provide support for design has not been successful. • Software engineering is a team activityand, for large projects, much time is spent in team interactions. CASE technology does not really support such activities COMP201 - Software Engineering
CASE Classification Classification helps usunderstand the different types of CASE tools and their support for process activities • Functional perspective • Tools are classified according to their specific function • Process perspective • Tools are classified according to process activities that are supported • Integration perspective • Tools are classified according to their organisation into integrated units COMP201 - Software Engineering
CASE Integration • Tools (Bugzilla, GIT) • Support individual process tasks such as design consistency checking, text editing, etc. • Workbenches (Rational Rose UML) • Support a process phase such as specification or design, Normally include a number of integrated tools • Environments (example IDE like Eclipse) • Support all or a substantial part of an entire software process. Normally include several integrated workbenches COMP201 - Software Engineering
Lecture Key Points • Requirements engineering is the process of developing a software specification • Design and implementation processes transform the specification to an executable program • Validation involves checking that the system meets its specification and user needs • Evolution is concerned with modifying the system after it is in use • CASE technology supports software process activities COMP201 - Software Engineering