CM10193 Software EngineeringLecture 1

What is software engineering?Software engineering is the adaptation and practical application of knowledge of computerscience concepts to deliver good software solutions for systems as well as subsystems.

Why does software engineering matter?The software crisis of 1968 [machines were getting more powerful and software creation forsmall systems did not scale up] meant that a managed approach to software production wasneeded, and a practical application of computer science developed into software engineeringconcepts.

What are the values and costs of software engineering?Value ­ All developed nation’s economies depend on software, and software engineering

expenditure is a large part of amount the Gross National Product of all of these developednations.

Cost ­ However the software component of a system tends to dominate the total costsfor the system, and it’s maintenance costs more than the initial development.

What is software?Software consists of the program itself, it’s configuration data and it’s documentation. Softwarecan be bespoke ­ made for a specific user and purpose ­ or generic ­ of the shelf softwarecreated for a large range of users in many situations.

What is good software?Good software will deliver it’s required functionality, and has several desirable properties;

Usable ­ Simple for the user to understand, and meets their demandsMaintainable ­ Easily evolvable to meet changing requirementsDependable ­ reliable in all situationsEfficient ­ not wasteful of system resources

How is good software created?Software process models are used to define a set of activities and their associated results toproduce a good software product. Although there are several different models for this, there arecommon activities in all of them: specification, design, implementation, validation and evolution.

What are the key challenges facing software engineering?Heterogeneity ­ developing flexible software that can be handled by a diverse range of

existing systems, support structures and legacy softwareDelivery ­ Meeting deadlines for the completion of complex software systems without

compromising on it’s quality.

1

Trust ­ developing techniques displaying to the user that the software will be reliable in alarge range of possible situations

What is a system?A system is a combinations of components in a purposeful way, with inter­related elementsworking together to achieve a common goal. This includes software and hardware that meetspeople's intentions and psychological capacity. System components(sub­systems) areinterdependent, and their properties and behaviour are entwined.

What is a subsystem?A subsystem is a smaller component of an overall system, that may or may not operateseparately from the whole system.

What is an emergent system property?Emergent system properties are the prominent properties of a whole system, such asrobustness, maintainability, usability, result of component relationship and the dynamicperformance of the system.

What are the different type of system categories?Technical computer­based ­ These systems include software and hardware, and are not

self aware.Socio­Technical ­ These systems include technical systems, but also include operations

and users of the system. These systems are governed by organisationalpolicy, and are non­deterministic (i.e the outcome will be different eachtime, and will depend of the operator judgement)

What is a systems purpose?A systems purpose can be defined by its objectives, which should define why it is being createdfor a particular environment, including functional and organisational objectives.

What is software systems engineering?Software systems engineering is a branch of software engineering for specifying, designing,implementing, validating and maintaining socio­technical systems. It is concerned with theservices provided and the way the system is used, as well as the constraints on it’sdevelopment.

Lecture 2What are the generic activities in a software process regardless of the model?There are three main parts in a software process; designing the specification ­ functionality andconstraints of the software, design and implementation ­ planning of architecture and choice oftechnology and realisation, validation ­ checking the implementation meets the specification, andfinally evolution ­ maintenance and upgrades to the software as time goes on.

2

What are the four stages of the software lifecycle?Specification, Design & Implementation, Validation & Evolution

What is a model?A model is an abstraction of a real world problem, with a selective description and is from aparticular perspective and for a particular purpose.

What is a software process?A software process is an organisational tool for software development, which has a lifecycledepending on it’s environment, and ensures a software products meets the needs for which theywere created. A software process should serve to protects engineers from change inducedchaos.

What is a software process model?Software process models are a simplified description of activities that need to be carried out tocreate a successful software system, for managing and organizing software engineeringactivities in a project.

What are the three different software process models?The waterfall model, the evolutionary development model & the component­based (re­use)model.

What is the waterfall model?The waterfall model requires each stage of the software engineering process to be completedand signed off before moving on to the next stage, meaning that section cannot then be revisited.This model is suitable for change­proof requirement projects ­ i.e stable business environmentswith low chance of change (expansion, contraction or diversification). The advantage of thewaterfall model is that it is a very clear project management model, with milestones at the end ofeach activity, and allows a simple workflow and allocation of responsibility. The disadvantage tothis model is the difficulty in allowing for changing requirements, as few businesses will havestable requirements where operations and context of these operations are not subject to change.

What is the evolutionary model?The evolutionary model allows progressive expansion of the software system, starting with aninitial version of the system, and with customer feedback, create more and more prototypes untilit evolves into a final version of the system. Here, specification, development and validation arenot clearly separated. Although this obviously allows feedback from the customer to make surethe system fulfils their needs, there are several problems with evolutionary development. Thesystem often ends up being brittle, as it is hard to understand, there is a lack of process visibility,and unplanned enhancements leads to poor architecture and difficult maintenance. This modelis generally used for small sized and short­lifetime systems.

What is the component­based model?

3

The component­based model includes the reuse of existing components or off the shelfsystems. This involves creating a requirements specification, analysing the components,modifying the requirements, design of the system with reuse, and development and integration.The advantage of this model is shorter development time due to already existing componentsthat do not have to be created. The disadvantage is the difficulties that could arise in theintegration of the component with the developed components.

What is iteration and why do we need it?Iteration involves cycling through things again, and can be applied to any of the generic softwaremodels, but is hard to do effectively ­ so there are special SPM’s created that include iteration.There is always pressure to change system requirements in the course of a project ­ forexample from customer feedback ­ so results of earlier activities must be reworked andimplications for later work must be considered as it can produce unpredictable results unlessproperly managed.

Lecture 3

What is programming?Programming is a type of problem solving, splitting large tasks into successively smaller tasksuntil they are simple enough to be performed by instructions of a programming language. Thisgoes from problem analysis, to establishing requirements ­ part of the problem, and designing,implementing and evaluating ­ part of the solution.

What is an architecture?Describes how a large problem splits into manageable parts. Architecture is the process ofdesigning/constructing, whilst reducing complexity but still adhering to functional, performanceand cost goals. Abstraction/separation of concerns by modular organization ­ a simpledescription of components and connections.

What is software architecture?Creating of software structures by identifying subsystems (by creating closely mappedrequirements and dividing them into logical groups), establishing sub­system control anddecomposing sub­systems into modules. The benefits of architectural design are stakeholdercommunication and large­scale reuse. Sub­system model is based around a structural style(repository, client­server, layered etc.).

How is software architecture evaluated?How well it supports functional and non­functional requirements after deployment. Earlyevaluation comes from known properties of reference architectures.

What is an architectural design document?Graphical models of the design with descriptive text, with the models presenting different

4

perspectives on the architecture.

What are the different types of architectural models?Static structural models ­ show the components (classes) of a system and their relationship,static control modes ­ describe flow of control between subsystems, and dynamic/behaviouralmodels ­ model the interactions between components.

What are the different types of static structural models?Repository ­ uses a central storage of data, Client­Server ­ services on server used by client,Layered ­ data travels through different layers of the architecture.

What is the Repository Model?Uses a central project repository which all sub­system communicate separately with, which theycan also use to communicate with each other. Generally for systems using large amounts ofdata. Advantages ­ centralised backup/security, efficient way to share large data, easy tointegrate new subsystems. Disadvantages ­ common point of failure, hard to replicate therepository, subsystems must compromise on their needs to conform to the model, data schemahard to change later on due to large dependency from subsystems on initial data scheme (limitsevolution or both repository and subsystems), common backup/security policy enforced on allsub­systems.

What is the Client­Server Model?Connects client via server over a network. 3 types of subsystems ­ client subsystems (usesservices ­ data and functions ­ provided by servers), network subsystems (permit use ofservices) and server subsystems (offer services to other subsystems). Uses request (clientside) and reply (server side) protocol. Advantages ­ extensible architecture, no shared datamodel so subsystems can organise data in any way. Disadvantage ­ may need to update clientsto reap benefits of new server functionality.

What is the Layered Model?Several layers of software/hardware built on top of each other which data has to travel through,each layer does something different with the data. Advantages ­ as long as interfaces arerespected layers can be changed, only adjacent layers are affected if interface does change, canenforce security policies to create protected core, supports incremental development.Disadvantages ­ outer layers may need to access facilities encapsulated by inner layers, largecommunication overhead (data travels further so bigger delays) with more layers so there is aperformance loss.

How are the Software Architecture and Non­functional requirements related?The s.a effects the NF requirements as it’s structure can affect system­level attributes such asperformance ­ reduced with small no. of subsystems with minimal communication, security ­consider layered model with security validation protecting inner layers, safety ­ keep safetycritical operations in a singles sub­system reducing complexity of safety validation, availability ­

5

build in redundant components, maintainability ­ use fine grain components easily substituted,avoiding shared data structures (repository) etc.

What is granularity?How far the problem can be split down; a fine­grained system is a larger number of smallersubsystems, a coarse­grained system is a smaller number of larger subsystems.

Lecture 4

What is the role of iteration in a process?Due to the continuing change in requirements we have to accommodate this evolution usingiteration. This can be applied to any of the structural models (repository, client­server, layered)but also has two special models that support it; spiral development and incrementaldevelopment.

What is the Spiral Model?The process is presented as a spiral, with each loop representing a phase of the softwareprocess, risks evaluated and resolved during the process, and no fixed processes (specification,design etc.) ­ loops of the spiral chosen as required.

There are four sectors of the spiral model; objective setting ­ objectives for the phase areidentified, risk assessment and reduction ­ activities put in place to reduce the key risks,development and validation ­ development model for the system is chosen (any generic model),planning ­ project reviewed and next phase of spiral planned.

What is incremental development?

6

Development of the system is broken down into increments, each delivering part of thefunctionality, with higher priority requirements being fulfilled first. Once delivered, requirementsfor that increment are frozen but later requirements for later increments can still be evolved.Process goes; specify requirements, plan increments, design architecture, develop increment,verify increment, integrate, verify system, develop increment, verify, integrate, verify system etc.Advantages ­ customers gain immediate value, high priority requirements delivered first, lowerrisk of overall failure, early increments used as prototypes which can inform requirements forlater increments.

What are Agile Methods of software development?Software development methods based in iterative/incremental design, where requirements andsolutions evolve through collaboration. Focuses on the software rather than it’s design ordocumentation. Key principles ­ customer involvement, incremental delivery, people not process,embrace change, maintain simplicity.

What is Extreme Programming (XP)?An example of an agile method (rapid software development), taking good practices (iterativedevelopment, customer involvement) to the extreme, with the customer as part of thedevelopment team and new versions being built up to several times a day. Requirements arebuilt as ‘story cards’ developed from user scenarios. XP uses test­first development ­ creatingtests to validate parts of the software, before it has even been written. This makes sure thesoftware meets all of the necessary requirements, and reduces chance of new incrementsintroducing errors into the software. Code is refactored and integrated continuously to preventbrittleness of the software, so static verification is used ­ constant informal reviewing. There arelimitations ­ XP is constraining (small co­located team) and invasive (pair programming), and isnot suitable to all projects ­ client must agree to be part of the development team (timeinvestment needed).

What is rapid application development (RAD)?Type of agile software development focusing on rapid prototyping rather than planning ofsoftware, making it easier for requirements to change and means creating the software quicker ­planning is done alongside development of the software. Used for data intensive businessapplications mostly.

Lecture 5

What are requirements?Functional and non­functional foundations of successful systems. Requirements are decided bynot only the f/nf needs of the system, but by users, domains and UCD, gathering evidence, theSRS (software requirements specifications) and scope of the system, as well as use cases andscenarios. Requirements are used to get from the human problem space to the technicalproblem space. They define all aspects of a system, including it’s capabilities and operationalcharacteristics, as well as the development process for creating the software. They are written

7

as a set of structured and interdependent statements including high­level and low­level featuresand details.

How is a system defined?A system is described by it’s needs, which will evolve into it’s features, which then can evolveinto the system’s specific requirements.

What are functional requirements?Function requirements are statements of services/features/functions the system should provide,relating to inputs & outputs.

What are non­functional requirements?General (non­functional) properties of the system and it’s behaviour, also including dealing withthe constraints on development and when/how it will be delivered. E.g system usability,performance, responsiveness, safety, security, technologies used, delivery schedule, QAstandards used, etc. Generally structured in the following order; product requirements ­ how thesystem will behave, organisational requirements ­ compliance with policies, then externalrequirements ­ wiser constraints & development process.

Why do we need precise requirements?Imprecise requirements may be mis­interpreted by different developers, so wrong end­productmay be done, and dependencies may be missed between requirements causing conflicts inoperations. Imprecise requirements can also not be (or be hard to) verify ­ e.g. ‘must be fast’how can this be measured?. Precise requirements are ordered, labelled (index/name), listedwith source, prioritised, and measurable along with the actual statement.

What are the 6 properties of a good set of requirements?A good set of requirements are prioritized, correct, modifiable, traceable, unambiguous andverifiable.

Lecture 6

Where do requirements come from?It can be hard to get a good set of requirements data from customers, as people struggle toexplain what they need from a system ­ how to express express, or even what they need ­ anddifferent people want different things, causing disagreements, and stakeholders will only tell youabout their part of the problem. The business environment may also change, and newstakeholders becoming involved can change the requirements of the system. There is thereforeno single solution to the problem of defining the requirements of the system, but differentviewpoints helps to organise requirements information and identify integration challenges withconflicts and tensions.

8

What are the different types of viewpoints in requirements gathering?Interactor viewpoints ­ primary and secondary users, who interact directly with the system,Indirect viewpoints ­ tertiary users, who don’t use the system but influence the requirements, andDomain viewpoints ­ like standards and rules creating domain characteristics that influence therequirements.

What type of written sources are used in requirements gathering?This can include documents (like example forms or existing data for the system) given to you bythe stakeholders, domain information (codes of conduct, legal documents, case studies ofsimilar domains), or product information about similar systems (features/scenarios of similarvendors systems).

What are the other types of sources for requirements information?Direct evidence from stakeholders, like interviews with primary/secondary/tertiary users orobservations made in the workplace.

What is an interview?An interview is a guided (with goals and questions) conversation between engineers and domainexperts. The SE team will prepare questions to stakeholders about the current socio­technicalsystem, as well as the software system to be developed. Interviews are good for getting anunderstanding of stakeholders viewpoints (what they do, how they interact), but are not good forunderstanding domain requirements as engineers may not fully understand domain terminologyor it may not be described to them correctly/well, which can be disastrous if they are not familiarwith it. We have to predetermine which stakeholders to interview (time, budget), devise ascheme for bringing the data together from interview ­ requirements, and we have to select thecorrect equipment to take to interview (notebook ­ static info, or records ­ dynamic info).

What are the structures of interviews?Fully structured interviews ­ interviewers stick to a predetermined set of questions. Unstructuredinterviews ­ no questions prepared, conversation with domain expert. Semi­structured interviews­ prompts and guides but no rigid agenda.

What is involved in interview practice?Behave ethically throughout ­ introduce self and purpose of interview, warm up questions, mainbody of questions, and closure. Beforehand we prepare a written summary of the purpose of theinterview and explain them to the interviewee, obtaining their consent to time/quotes/right ofcorrection etc. Be open minded (speak and listen), prompting the interviewee withquestions/proposals. These are all ethical interview practices.

What do we do after gathering requirement information?We can collate the requirement statements into a secure managed data store, making sure wemanage change in the environment/requirements. We track dependencies/relationships, so weknow in advance the knock­on effects of changing these requirements, and for architectural

9

implications.

Lecture 7

Note: architectural design reminder ­ the overall structure of a system, and is the critical linkbetween design and requirements engineering, resulting in a model that describes a set ofcommunicating components.

What is modularity?Modularity is the degree to which a systems components can be split into ­ called subsystems.We decide what the main elements of the system are and how to split them up, and how theywill connect. Finer­grain specifications (further split up) are better, we need to show how eachcomponent delivers it’s functionality to service the other components, and need to design thecontrol logic for processing to be done by the software system.

What is modular decomposition?Progressively splitting up work that the system performs on a whole. Top­down decompositioninto self contained subsystems, or bottom­up composition of modules thinking about puttingtogether small pieces of well defined work.

What is the representational formality debate?Simple block diagrams of the modules without formal semantics are food for informal designconversions and reduces effort documenting work, but limits their utility as a specification.

What are the two decomposition techniques?Function oriented pipelining (pipe and filter model) ­ modules accept input data, process it, andsend it to the next module as output. Modules arranged in sequence, with a fluid series ofoperations of the data moving through the pipeline. Piping is between modules, filtering is doneby modules. Advantages ­ role of each module simple, reuse of modules, evolve system byadding new modules into pipeline easily. Disadvantages ­ defined data communication rules,hard to deal with event driven activities.Object oriented decomposition ­ modules are set of communicating objects with responsibilitiesfor work (processing of data) to be done for that specific sub­system. To identify these objectsby analysing scenarios ­ nouns are object, verbs processes ­ entities in the applicationbecoming objects, or participating agents as objects. Objects have defined public interface forcommunication between objects in a subsystem or the whole system, with a hidden internalstate, and are built from classes to construct parts of the program. Advantages ­ strong link withentities in the problem domain, encapsulation, permits fine­grain reuse (through inheritance) andextensibility. Disadvantages ­ creating objects costs processing time and memory, and must bemanaged and disposed of later on.

What are control styles?Control styles supplement static structural models by describing the flow of control between

10

subsystems. There are two generic control styles ­ centralised control and event­driven control.

What is centralised control?Centralized control involves using a dedicated subsystem as a system controller,stopping/starting all other subsystems. Involves two control models; Call­return model ­ passescontrol from system controller to sub­system and back once that sub­system has finishedprocessing, delegating to one subsystem at a time. Top­down subroutine model, hard toaccommodate exceptions to normal operation but easy to analyse control flows. Centralisedmanager/event­loop model ­ co­ordinates subsystems as well as stopping/starting them, usedfor big concurrent systems, but induces large overheads, and has low independence at processlevel. Controller loops continuously, polling state of sensor devices, managing the execution ofthe processes. Can be used in soft real­time systems (no critical time constraints).

What is event­driven control?Each subsystem responds to external stimuli ­ or events. An event is a signal or message sentfrom a process to a system as a whole, intercepted by other processes in the system calledevent handlers. There are two types of event­based control; broadcast models andinterrupt­driven models.

What is a broadcast model?The event is broadcast to all subsystems and any event programmed to respond to that eventwill handle it ­ simple evolution but conflicts possible.

What are interrupt­driven models?They are hard real­time systems, and events are detected by a special interrupt handler whichthen control other processes in the system. There is a limited number of interrupt channels.

Lecture 8

What are stakeholders?Stakeholders are those affected by the system or who may have an influence on it’srequirements, and can be individuals or representatives of a larger group. These are catagorizedinto three types of system users; primary users ­ frequent hands­on users, secondary users ­occasional users or people who use it through an intermediary, tertiary users ­ people who arenot users but are affected by the software system (a wider socio­technical system).

What is a system domain?A domain is made up of practices, knowledge and values, and describes the characteristics ofthe work to be done. It also describes the socio­technical context of the technical system. Theyare used to focus effort on the most important parts of the system, helping to prioritizedevelopment/testing, and define requirements for specific knowledge and computation. Domainsalso ensure engineering assumptions are realistic. However the requirements of a domain canbe hard to understand by the engineer as they are expressed in the language of the application

11

domain. Domain specialists understand the domain well so they give implicit requirements, anddo not make them explicit (saying directly what is needed rather than implying it)

What is User­Centered Development?UCD makes users and their goals the driver behind development of the software, involving usersto develop good usable products, manage expectations (make sure users views of product arerealistic) and foster ownership (make the user feel they have been listened to and have more ofa stake in the outcome). UCD has three principles; focus on users and their normal tasks,empirical measurement (evidence not speculation), and iterative design (design, user test,measure, redesign). Users can be factored into the development by co­opting them on to thedesign team (expensive but valuable), with design workshops and interviews, evaluationsessions or via mailing.

How do we manage expectation?Through user involvement in development so they can see capabilities from an early stage.Should be focused on their own activities/services, avoiding vague statements aboutperformance/functionality. Should communication user requirements so they are understandableby users who don’t have technical knowledge, using natural language, table and diagrams sothey can be understood.

Lecture 9

What are the two kinds of requirements document?First is before a contractor bids, with requirements written in different ways of meeting the clientorganizations needs, and the second is after the contract has been awarded, writing a systemdefinition for the client in more detail, so the client understand and can validate what the softwarewill do.

Who are the users of a requirements document?The client organisation ­ business managers, end users, maintenance (clients systemengineers) and the developer organisation ­ architects, developers, contractor managers, testengineers.What is the context of a system?Systems exist within a context ­ the environment a system fits into. Software systems areusually subsystems of businesses or other organisations.

What is the scope of the system?The elements of the clients problem that are to be central to the s.e effort, and deciding howmuch of the system context is relevant to the development of the software. This sets boundarieson the proposed system, deciding the functions handled by the system, the goals the systemmust meet, and defining the major elements of the system and how subsystems interact withtheir environment.

12

What is in a Software Requirements Specification (SRS)?Introductory section ­ purpose, scope, goals, User requirements Definition ­ services systemprovides to users and nf req’s system should fulfil, System architecture ­ high­level sub­systemdescription, System requirements specification, System models, System evolution, Appendices& index.

What is is IEEE standard document?Basic structure for effective requirements document. The IEEE SRS includes; introduction,overall description, specific requirements (external interface reqs, f, nf ­ performance,constraints & attributes ­ and other), appendix & index.

What are structured language specifications?They specifications in which the descriptions that make up each requirements is constrained ­all statements written in a standard way and terminology is limited. They can be difficult to relatespecific to general, and cause modularity and amalgamation.

How should requirements be written?With a standard uniform format, with consistent language and text highlighting for key parts ofthe requirement.

What are graphical models used for?Diagrammatic representations of components of requirements and their relationships, and canbe used to consider dependencies, reason about changes of state and to describe sequences ofactions. An architectural system context model is just a simple block diagram of the wholecontext of a system, showing all of it’s subsystems. A process based system context modelshows all of the processes in the whole system (with system boundary marks showing functionsin different subsystems) and their relationships.

Lecture 10

What are application architectures?Application architectures are architectures in the form of subsystems and control mechanismsof applications within modules that are common, which help to identify reusable components, sothey are used for the internal architecture of an application looking at modularisation. Threeexample application architectures are event processing (instantaneous response essential),data processing (focus on large volumes of data) & transaction processing (data­centred butmore frequent changes).

What are event processing applications?Use a form of concurrent architecture where behaviour matters, where the system detectsevents and processes to change it’s state, and data structures are updated and re­displayed.

What are data processing applications?

13

Data records processed in batches from a file/database rather than interactively ­ simplearchitecture of input­process­output, but the data structures are often complex.

What are Transaction Processing applications?A transaction is a request by a process to read/write part of a database. This is a single atomicunit ­ all operations in the transaction need to be completed before a change is made to thedatabase that is permanent. Systems that include a shared database usually treated astransaction processing applications due to access of same data by separate subsystems. Morethan one process can read at a time but only one process can write at a time (and only when noreaders are active). Use layered and repository structural styles.

What is service­orientation in large systems?Service­oriented architectures define large­scale modularity around the provision of servicesfrom different developers, requiring an integration layer to publish service availability and mediatetransactions. Basically instead of taking subsystems from other systems and reconfiguring theminto subsystems, s­o architectures allow easy integration from other systems via an integrationlayer, using data and integration standards.

Lecture 11

What is a scenario?Scenarios are informal narrative descriptions of how a system can be used in ordinary language,detailing relevant user activity with a system and highlighting objects/relations in an episode ofinteraction. They can describe ordinary or exceptional interactions. Can be idiosyncratic (oneperspective), as it’s hard to decide on and manage the amount of detail.

What is scenario­based design?Uses scenarios to build the design of a system; clarity of communication, requirement elicitationand analysis via use­cases, software design and build, documentation and training, andevaluation.

What are use cases?Use cases are scenario­based descriptions developed during requirements analysis, thatembody a set of requirements on the system. They basically represent the system from theviewpoint of the user (called the actor) from an external point of view. They are models whichhelps visualise to the users the planned build and features of the software, and who can accesswhat. Actors are external entities, usually roles (customer, salesman etc.) and are the boundaryto the technical system and beneficiaries of system services. And actor plus system objectmakes and interaction. They only present behaviour seen externally, not internal implementation,and can be used to model how a subsystem behaves with respect to an actor. Represents inthe UML by a static diagram with descriptive scenarios relating to user goals.

What are sequence diagrams?

14

Sequence diagrams are models of how objects implement use­cases, and representrelationship between internal and external interactions, showing the order of event processing &dependencies.

Lecture 12

What is object­oriented development?OO development comprises of; OO analysis ­ identify OO model of application domain to reflectentities and operations, OO design ­ identify OO model of software system to implementrequirements, OO programming ­ realise the OO design. Typical activities in OO designprocess; define context & use cases, system architecture, main objects of the system,construct design models, specify object interfaces. There are two basic types of OO designmodel; static models (describing object classes), or dynamic models (describing interaction ofobjects). Good OO design = high cohesion /low coupling (functions in a class are similar andclosely related, and modules don’t depend on each other).

What is the Unified Modelling Language (UML)?UML is a set of graphical notation used to create OO software, representing both data andprocesses. Provides 13 (static+dynamic) modelling systems. We consider 4; class (static), usecases (dynamic) sequence (dynamic) and state machine (dynamic).

What are the differences between objects and classes?An object is a self­contained entity with attributes and operations. A class is a generic definitionof an entity for a set of similar objects. A class model provides a diagram of the static relationsbetween classes (components of the system) and their associations within the application.

What is inheritance in Object orientation?Child classes in the object hierarchy inherit attributes and operations from it’s parent(s) withextra specialisation. Good class model designs don’t inherit unnecessary attributes and nameclashes are resolved meaningfully.

What is an Entity­Relationship­Attribute (ERA) diagram?Type of semantic data model (a conceptual data model with semantics (meaning) included forinterpretation which describe logical structure of input/output by the system), which shows thestructure of data to be processed using entities, relationships and attributes. Must beaccompanied by data dictionary for name management and storing organisational information.

Lecture 13

More about UMLUML is a visual modelling language for representing and reasoning about software with a verybroad scope, with type families of tools; one to represent structure (static models) and one to

15

represent behaviour (dynamic models).

What are behavioural models?Specify how system components interact with each other ­ data flow diagrams, state machinemodels, sequence diagrams. The second 2 are UML models, but data flow diagrams are atraditional approach to describe systems with a single thread of data, with data beingtransformed to an alternative representation without much interaction between components.

What are sequence diagrams?Used to model interactions between objects, specifying how particular computations areperformed by the system showing which objects talk to others and in what order.

What are state­machine models (SMMs)?Used to design and analyse event processing systems (e.g. real­time systems). At any time, allsoftware systems are in one of a number of possible states ­ ‘ready for input’, ‘processing data’& ‘displaying output’, and the state expose the time­relevant logic of software systems.State­machine models in the UML show how a system responds to stimuli (from external sourceor internal code). These include a graphical diagram and a descriptive table. Superstates areexpanded additional SMMs.

Lecture 14

Validation and verification (V&V)V&V is used throughout the lifecycle process at each stage to ensure the integrity of the systemand the delivery of an effective system. There are two main categories of failure; constructing asystem with performance/execution/logical defects, and delivering a system with no value.Verification tests to see if the software conforms to its specification, and Validation tests to see ifthe system can deliver valuable services to the user.What is a defect?A defect is a fault in a component of a system, but safety cases can be written to design systemresponses to the presence of defects. In a socio­technical system, a user could be the faultycomponent. Defect tolerance ­ level of confidence depends on how critical the system is to anorganisation, and the degree of criticality comes from the nature of risk of system failure.

What is a failure?A failure is usually a systemic problem that occurs when the system can no longer safely delivera useful level of service. They usually occur when defects add together due to a series ofunfortunate coincidences. We need to validate at system level to catch accumulation of defects.

ValidationAims at ensuring the system works as its users intended, with evaluation throughout the design,with the design proceeding through iterative cycles of design­test­redesign. Evaluationestablishes confidence that the software is fit for purpose, and the environment and type of use

16

will determine the degree of confidence that is needed.

Lecture 15

Refining use casesWe can simplify a use case by simplifying its scenario by factoring out common sub­tasks. Usecase services can be composed of other services, and use cases can refer to one another ifand their common sub­tasks. Services should be defined in terms of user tasks, and in a usecase model can be mapped directly onto a particular subsystem or may be modelled byincluding intermediary services. Use cases may not relate directly to the architecture of thesystem, but the class model should be developed alongside use case models.

What are sequence diagrams?Sequence diagrams model the behaviour of objects in certain situations, and adds system­leveldetail to use cases, showing sequence of event processing in the system. Also showsinter­object dependencies, and reads system activities across time.

What are the challenges in modelling?Adequacy of conceptualization of current work, shelf life of task description.

What are the challenges for representing/supporting user activity?Escape sequences ­ cancelling an operation halfway through, representation of parallel tasks ­multi­tasking requires interruption and resumption, can impose unnecessary sequentialconstraints ­ order of required information vs. order users provide it in.

What is the task­artifact cycle?Artifacts created from study of clients & their tasks, but people use these artifacts to do newtasks, causing a cycle. Cycle can’t be broken unless the new ways of working can beforecasted.Lecture 16

Ethics & Professional conductSoftware engineers must work within the legal and social frameworks of society, and soprofessional s.e’s must act in compliance with relevant legislation and with an ethical and moralresponsibility. Codes of conduct are set by professional bodies, and are necessary to maintainprofessionalism. Codes of conduct are a set of principles that are meant to guide rather thanprescribe ­ ambiguous in application, used to aid professional judgement in ethical dilemmas.Difficulties ­ COC may be ambiguous, different parts may conflict, situation may not be covered,may put job at risk. They are always subject to continual development.

ACM/IEEE code of ethicsHas eight main principles; public, client/employer, product, judgement, management, profession,

17

colleagues, self.

What is the Computer misuse act (1990/2006) ?Supports prosecution of computer­related crime. Guilty of a crime is ­ causes a computer toperform an action with the intent to secure access to information on any computer with knownunauthorised access. Modification is a more serious offence again.

What is a Denial of Service attack?DDoS attack is a new type of cybercrime, bombing a server with many requests to overload andcrash it.

Lecture 17

Science & EngineeringScience ­ acquisition of objective knowledge through empirical methods to gather data.Engineering ­ application of scientific principles for practical purposes.

Project managementThe key roles of a project manager are ­ proposal writing, project planning (schedule, costs),personnel allocation, project monitoring (checking and reviewing), delivery to client(reports/presentations). Scheduling the project is done by estimating the time and resourcesrequired to complete activities and order them into a coherent sequence. Time given depends ongranularity (1­8 weeks), allowing contingencies (delays) and scheduling also considersconcurrency and dependency.

Scheduling methodsGantt chart ­ shows task timing, concurrency is clear, but dependencies/personnelresponsibilities hard to see.Critical path chart ­ identifies critical tasks and the paths taken, allowing project managers toinvest more resources to avoid project slip.Lecture 18

CohesionGroup cohesion means pulling together, caring about the team and willingness to share.Advantages ­ inhibitions to contribute are reduced, quality standard can be developed for thegroup, group member work closely so they can learn from each other and know their work.Influenced by organisational culture and personalities in the group. Can be encourage by socialevents, team­building, developing group identity and openness of information. Cohesive groupshave loyal membership ­ good but can lead to restrictive practices. Groupthink is preservation ofgroup irrespective of technical/organisational considerations ­ should be avoided.Communication strengthens cohesion.

18

Lecture 19

Risk managementRisk ­ unwanted event that may occur with negative consequencesRisk exposure (PRA ­probabilistic risk assessment) ­ Probability * negative effectRisk management ­ measuring/assessment of risk and development of strategies to manage it.

What are the three types of risk?cost increase, quality degradation, organisational (business) risk.

What is the risk management process?Risk identification ­ identify project, product and business risks via brainstorming/analogy, Riskanalysis/prioritisation ­ assess probability/loss of risk, Risk control ­ planning (plan to minimiserisk via avoidance/minimisation/contingency strategies) & resolution (implement plan), Riskmonitoring ­ iterative process with project planning

Critical Systems DevelopmentTypes of critical systems; Safety critical, Mission critical, Business criticalAll concerned with safe operation ­ i.e dependability (availability, reliability & security). Cost risesexponentially with dependability. Specification for these systems should be risk driven, identifyingrisks and their causes, with safety requirements to reduce risks.

Risk categorizationIntolerable: must never arise, As low as reasonably possible (ALARP): minimise possibility ofrisk given cost and schedule constraints, Acceptable: consequences are acceptable and noextra costs should be incurred to reduce possibility.

How can we identify the root causes of a risk?Fault tree analysis(FTA) ­ top­down technique, placing risk at the top of the tree and identify thesystem states that could lead to the hazard (linked by and/ors)

Critical Systems DesignInvolves redundancy & diversity; for example of replicated subsystems or replicated internalverification routines.

Fault toleranceRun­time fault checking for critical systems, with 4 aspects; fault detection, damageassessment, fault recovery & fault repair. Diversity can be achieved by: including requirementsthat differ approach to design, requiring implementations in different languages, requiring use ofdifferent development tools/environments, requiring different algorithms in some parts of theimplementation.

19

Lecture 20

Ethical practiceDoing the right thing, adhering to a code of honour, being decent and meeting moral obligations.Laws try to encode morality.

What is the Regulation of Investigatory Powers Act (RIPA 2000)Ensures convert investigations do not infringe on human rights law, needing an interceptionwarrant only awarded for policing/securing/safeguarding the economic well­being of the UK.Includes intrusive (in private) / directed (in public) surveillance and gathering of covert humanintelligence ­ about someone gathered through a covert relationship.

Data protection Act (1998)Respecting privacy by making aware of how information about them is obtained and used. Hasfour main concepts ­ Personal data; any data traced to a living identifiable person, Data subject:living person who is the subject of data, Data controller: person/organisation that processesdata, & the processing of the personal data; any operation performed on data.The personal data is usually sensitive data that allows them to be identified.In software engineering sensitive personal data can be processed if; explicit consent given, otherlaws require it, when it is necessary, processing by non­profit trade union business, becausesecretary of state says so.

Eight principles of data processingFair, Adequate, Rights, Specific, Transfer, Accurary, Retention, Security

Lecture 21

QualityThe match between a product and it’s specification ­ but a specification may not match a client'sexpectations or there may be conflicts between customer and developer ideas about quality. Soquality is always a compromise. There is a direct link between process and product quality ins.e, with individual skills & experience and external factors impacting the quality.

What are the activities in Quality Management?Quality Assurance (QA); establishes standards for all projects run by an organisation, Qualityplanning: select standards for a particular project, Quality control; monitor quality standards for aparticular project to make sure the S.E team are compliant. These are all independent fromproject management to avoid conflicts of interest.

Quality assurance (QA)Defines how the entire SE organisation can achieve high quality and can assess adherence toits own standards. Process standards ­ define processes to be followed to ensure delivery of

20

product standards. Product standards ­ coding standards and presentation standards (productand document structure). Use of software standards; Advantages ­ encode best practice,adherence to a formal standard enforces adherence to this best practice, continuity betweendevelopers. Disadvantages ­ bureaucratic, perceived as pedantic and tedious, may not reflectrecent innovations in best practice. To avoid these problems we can involve practioners instandards development, review standards & usage regularly, and standards should haveassociated tool support.

Quality planningWriting a quality plan ­ identify standards that apply & new standards to be used. Plan shoulddescribe the desired product qualities and the processes by which they are assessed. Structure;intro, product plans, process descriptions, quality goals (e.ge robustness, security, reliabilityetc.), risk and risk management. Should be short and clear.

Quality ControlChecking the software development process to ensure that procedures and standards are beingfollowed. Two approaches; quality reviews ­ discovery of system defects and inconsistenciesand deviation from standards, short process, or automated software assessment &measurement ­ software measurement (given a metric value) allowing for comparisons.

Lecture 22

Process measurement ­ Goal­Question­Metric paradigmGoals ­ what is it trying to achieve, Questions ­ areas of uncertainty, Metrics ­ relevent metrics tohelp answer questions. Process measures using quantifiable measurements ­ time, resources,occurrence.

process improvement ­ measure, analyse, change

Capability maturity model (CMM)Assesses sophistication of an ICT company's process improvement strategies. Levels; initial,repeatable, defined, managed and optimising.Lecture 23

variable ­ anything that can take different valuesfactor ­ variable that influences observationsvariables are not always factors

For comparisons to be fair, test conditions must be the same for each observation.

21