1 / 25

Software Engineering COMP 201

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

gay
Download Presentation

Software Engineering COMP 201

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. The Requirements Engineering Process COMP201 - Software Engineering

  5. 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

  6. 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

  7. 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

  8. 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

  9. The Software Design Process COMP201 - Software Engineering

  10. 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

  11. 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

  12. 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

  13. The Debugging Process COMP201 - Software Engineering

  14. 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

  15. 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

  16. The Testing Process COMP201 - Software Engineering

  17. 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

  18. Testing Phases COMP201 - Software Engineering

  19. 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

  20. System Evolution COMP201 - Software Engineering

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

More Related