advanced information systems development (sd3043) lecture 1: introduction

Advanced Information Systems Advanced Information Systems Development (SD3043)Development (SD3043)

Lecture 1: IntroductionLecture 1: IntroductionDr. Haris MouratidisDr. Haris Mouratidis

[email protected]@uel.ac.uk

2626thth September 2006 September 2006

Advanced Information Systems DevelopmentAdvanced Information Systems Development 22

Lecture LayoutLecture Layout

Module InformationModule Information Description of the ModuleDescription of the Module Teaching & Assessment methodsTeaching & Assessment methods Module ContentModule Content

Overview of Software Overview of Software EngineeringEngineering

ConclusionConclusion


Lecture Rules and FactsLecture Rules and Facts

Start on time!Start on time! Ten minutes breakTen minutes break No mobile phones!!!No mobile phones!!! Previous years:Previous years:

Attend lectures, tutorials, submit assignment, sat Attend lectures, tutorials, submit assignment, sat exam- pass rate ~90%exam- pass rate ~90%


Description of the ModuleDescription of the Module

A third year software engineering module that A third year software engineering module that aims to:aims to: Develop a broad understanding on industrial Develop a broad understanding on industrial

and research topics related to information and research topics related to information systems developmentsystems development

Expose students to current issues in information Expose students to current issues in information systems developmentsystems development

Draw the students’ attention to the current trends and Draw the students’ attention to the current trends and future directions in the development of information future directions in the development of information systemssystems


The Module TeamThe Module Team Dr. Haris MouratidisDr. Haris Mouratidis

Module Leader, Lectures, Tutorials/PracticalsModule Leader, Lectures, Tutorials/Practicals PhD (Sheffield) - Information Systems DevelopmentPhD (Sheffield) - Information Systems Development Practical Development of IS for small and large organisations Practical Development of IS for small and large organisations

(e.g. NHS)(e.g. NHS) National and International Projects, Organisation of Research National and International Projects, Organisation of Research

Events, Research Grants Events, Research Grants Over 45 research publications and 4 booksOver 45 research publications and 4 books

Dr. Godfried WilliamsDr. Godfried Williams Lectures, tutorials / Practicals Lectures, tutorials / Practicals Risk Management, Risk Management, Years of ExperienceYears of Experience Author of various research papers and books Author of various research papers and books

Miss Divina MelomeyMiss Divina Melomey Tutorials / Practicals Tutorials / Practicals PhD Candidate, Novel information systems development PhD Candidate, Novel information systems development

techniquestechniques


Teaching and Assessment Teaching and Assessment MethodsMethods

What to expect from the module team – What to expect from the module team – TeachingTeaching Lectures (2 hours per week)Lectures (2 hours per week) Tutorial / Practical sessions (2 hours per week)Tutorial / Practical sessions (2 hours per week) Provide necessary information (WebCT)Provide necessary information (WebCT) Do our best to helpDo our best to help

What we expect from you – AssessmentWhat we expect from you – Assessment Assignment (50%)Assignment (50%) Exam (50%)Exam (50%) Pass both components!Pass both components!


Recommended readingRecommended reading

H. Mouratidis and G. Williams,H. Mouratidis and G. Williams, Issues in Information Systems Issues in Information Systems DevelopmentDevelopment, , Thomson Education Inc., (ISBN 184479458x)Thomson Education Inc., (ISBN 184479458x)

H. Mouratidis, P. Giorgini, H. Mouratidis, P. Giorgini, Integrating Security and Software Engineering: Integrating Security and Software Engineering: Advances and Future VisionAdvances and Future Vision, Idea Group Publishing, (ISBN 1-59904-148-0), Idea Group Publishing, (ISBN 1-59904-148-0)

B. Bruegge, A. H. Dutoit, B. Bruegge, A. H. Dutoit, Object Oriented Software Engineering: Using UML, Object Oriented Software Engineering: Using UML, Patterns and JAVAPatterns and JAVA (International Edition), Prentice Hall, 2004 (ISBN 0-13- (International Edition), Prentice Hall, 2004 (ISBN 0-13-191179-1)191179-1)

Williams GodfriedWilliams Godfried, Synchronizing E-Security , Synchronizing E-Security (International series in Advances (International series in Advances in information security). Kluwer Academic Publishers (ISBN 1-4020-7646-0) in information security). Kluwer Academic Publishers (ISBN 1-4020-7646-0)

'Object-Oriented Software Engineering'Object-Oriented Software Engineering ' by T.C. Lethbridge and R. Laganiere, ' by T.C. Lethbridge and R. Laganiere, McGraw-Hill (2001) McGraw-Hill (2001)

‘‘Using UML - Software Engineering with Objects and ComponentsUsing UML - Software Engineering with Objects and Components ’ by P. ’ by P. Stevens with R. Pooley, Pearson Education (2000)Stevens with R. Pooley, Pearson Education (2000)

‘‘Visual Modelling with Rational Rose and UMLVisual Modelling with Rational Rose and UML ’ by T. Quattrani, Addison-’ by T. Quattrani, Addison-Wesley Object Technology Series (2002)Wesley Object Technology Series (2002)

‘‘Software EngineeringSoftware Engineering’, 6th edition, by I. Sommerville, Addison-Wesley (2000)’, 6th edition, by I. Sommerville, Addison-Wesley (2000) ‘‘Software MetricsSoftware Metrics’ by N.E. Fenton and S.L. Pfleeger, Thomson Learning (2000)’ by N.E. Fenton and S.L. Pfleeger, Thomson Learning (2000) 'Object-Oriented Systems Analysis and Design'Object-Oriented Systems Analysis and Design ', 2nd edn., by S. Bennett, S. ', 2nd edn., by S. Bennett, S.

McRobb and R.Farmer, McGraw-Hill (2002) McRobb and R.Farmer, McGraw-Hill (2002)


Typical problems students have Typical problems students have with this modulewith this module

Underestimate the work neededUnderestimate the work needed Time managementTime management

ExamExam AssignmentAssignment

Usually not only one correct solution!Usually not only one correct solution! Not everything is correct!Not everything is correct!

Not reading the materialNot reading the material Expect everything to be givenExpect everything to be given Do not listen their peersDo not listen their peers


AssignmentAssignment

There is only one coursework for the module.There is only one coursework for the module. Group assignment and each group consists of Group assignment and each group consists of

two members two members The assignment consists of two parts: theoretical The assignment consists of two parts: theoretical

and practical (50%). and practical (50%). The practical part consists of the analysis and design The practical part consists of the analysis and design

of an information system and you must work as a of an information system and you must work as a group. group.

On the other hand, the theoretical part is an individual On the other hand, the theoretical part is an individual piece of work and each member is required to write a piece of work and each member is required to write a research paper on a specific topic. research paper on a specific topic.


GroupsGroups

Group members come from the same tutorial classGroup members come from the same tutorial class Group members will be assigned by the tutor during Group members will be assigned by the tutor during

the first tutorial (w/c 2the first tutorial (w/c 2ndnd of October). of October). An email to An email to [email protected]@uel.ac.uk with the subject with the subject

““SD3043: I cannot attend the group allocation SD3043: I cannot attend the group allocation tutorialtutorial.” .”

Once a group is formed, members cannot leave that Once a group is formed, members cannot leave that group without the consent of the module leader. group without the consent of the module leader.

If any problems arise between the group members, If any problems arise between the group members, it is their responsibility to contact the module leader it is their responsibility to contact the module leader as soon as possible. Any teams/members not as soon as possible. Any teams/members not following the above rules will receive a mark of zero.following the above rules will receive a mark of zero.


Part 1Part 1

The goal of the practical part is to analyse The goal of the practical part is to analyse and design a system according to the case and design a system according to the case study that will be assigned to your teamstudy that will be assigned to your team

Requested diagrams must be generated Requested diagrams must be generated usingusing Rational Rose Rational Rose, and full use should , and full use should be made of the facilities provided by the be made of the facilities provided by the Case Tool. Case Tool.


Part 2Part 2

The theoretical part of the assignment is The theoretical part of the assignment is an individual piece of work, where each an individual piece of work, where each member of the team is required to write a member of the team is required to write a research paper.research paper.

Abstract; (b) keywords; (c) introduction; (d) Abstract; (b) keywords; (c) introduction; (d) findings; (e) evaluation; (f) analysis; (g) findings; (e) evaluation; (f) analysis; (g) conclusion; (h) references. conclusion; (h) references.

Each member has a different topic.Each member has a different topic.


Assignment’s Handout/in datesAssignment’s Handout/in dates

Handout DateHandout Date 2626thth of September 2005 of September 2005

Group Allocation and TopicsGroup Allocation and Topics w/c 2w/c 2ndnd of October of October Hand in DateHand in Date

1313thth of December 2005 of December 2005

Strict Deadline!!! No extensions (UEL Strict Deadline!!! No extensions (UEL Policy) Policy)


Module ContentModule ContentTopic/DateTopic/Date ContentContent

1/ 1/ 27 27 SepSep

Module Introduction / Software Engineering Module Introduction / Software Engineering OverviewOverview

2 / 2 / 4 Oct4 Oct UML overviewUML overview

3 / 3 / 11 11 OctOct

Requirements Elicitation / Analysis / DesignRequirements Elicitation / Analysis / Design

4 / 4 / 18 18 OctOct

Advance UML and TestingAdvance UML and Testing

5 / 5 / 25 25 OctOct

Patterns/ Architectural Styles / Model Driven Patterns/ Architectural Styles / Model Driven Architecture (MDA)Architecture (MDA)

6 / 6 / 1 Nov1 Nov Project Management – Software Metrics and Project Management – Software Metrics and Software Cost EstimationSoftware Cost Estimation

7 / 7 / 8 Nov8 Nov Project Management – Techniques, Optimization Project Management – Techniques, Optimization and Estimationand Estimation

8 / 8 / 15 15 NovNov

Quality Assurance and Process Improvement Quality Assurance and Process Improvement

9 / 9 / 22 22 NovNov

Risk Assessment / Security (I)Risk Assessment / Security (I)

10/ 10/ 29 29 NovNov

Risk Assessment / Security (II)Risk Assessment / Security (II)

11 / 11 / 6 6 DecDec

Trends in Systems developmentTrends in Systems development

12 / 12 / 13 13 DecDec

Review of the ModuleReview of the Module


Any questions???Any questions???


Why another information systems Why another information systems development module? development module?

What is difficult about developing software What is difficult about developing software systems?systems? Large and complex systemsLarge and complex systems Requirements change constantlyRequirements change constantly

Why not use an informal approach to Why not use an informal approach to software development?software development? Late projectsLate projects Costly projectsCostly projects


Software Engineering FailuresSoftware Engineering Failures

April 10, 1990, London. A tube train left the April 10, 1990, London. A tube train left the station without its driver! station without its driver! The driver had taped the button that started the train, The driver had taped the button that started the train,

relying on the system that prevented the train from relying on the system that prevented the train from moving when doors were opened.moving when doors were opened.

He had left his train to close a door which was stuck. He had left his train to close a door which was stuck. When the door was finally shut, the train left. When the door was finally shut, the train left.


And another failure!And another failure!


First Definition of Software First Definition of Software EngineeringEngineering

NATO conference (1968)NATO conference (1968)

““Software Engineering is the establishment Software Engineering is the establishment and use of sound engineering principles in and use of sound engineering principles in order to obtain economically software that order to obtain economically software that

is reliable and works efficiently on real is reliable and works efficiently on real machinesmachines””


What is Software Engineering?What is Software Engineering?

I. Sommerville defines it as:I. Sommerville defines it as:

““Software Engineering is an Software Engineering is an engineering engineering disciplinediscipline which is concerned with which is concerned with all all aspects of software productionaspects of software production from the from the early stages of system specification early stages of system specification through to maintaining the system after it through to maintaining the system after it has gone into usehas gone into use””


What is Software Engineering?What is Software Engineering?

Bruegge and Dutoit add that Software Engineering Bruegge and Dutoit add that Software Engineering is:is: A modelling activityA modelling activity

Software Engineers deal with complexity through Software Engineers deal with complexity through modellingmodelling

A problem-solving activityA problem-solving activity Constraints and deadlinesConstraints and deadlines

A knowledge acquisition activityA knowledge acquisition activity Collect data, organise it into information, formalise it into Collect data, organise it into information, formalise it into

knowledgeknowledge A rationale-driven activityA rationale-driven activity

Capture the context and the rationale behind the decisionsCapture the context and the rationale behind the decisions


ModellingModelling

A model is an abstract representation of a A model is an abstract representation of a systemsystem

In general particularly useful when dealing In general particularly useful when dealing with large, complex, complicated systemswith large, complex, complicated systems

Useful also to understand systems that no Useful also to understand systems that no longer exist (e.g. models of dinosaurs) or longer exist (e.g. models of dinosaurs) or claim to exist (e.g. atomic models).claim to exist (e.g. atomic models).

But why models are useful in Software But why models are useful in Software Engineering?Engineering?


Software Engineering ModelsSoftware Engineering Models

Need to understand the environment in which Need to understand the environment in which the system will operatethe system will operate Stakeholders, users, connected systemsStakeholders, users, connected systems

Understand the systems itselfUnderstand the systems itself Components, Communication paths Components, Communication paths

Evaluate different solutions and trade-offsEvaluate different solutions and trade-offs Fast versus SecureFast versus Secure

Systems are expensive to build so we model Systems are expensive to build so we model them firstthem first


Problem SolvingProblem Solving

Software Engineers have limited resources, Software Engineers have limited resources, incomplete knowledgeincomplete knowledge

Search for an appropriate solution, evaluate Search for an appropriate solution, evaluate alternativesalternatives

Engineering method steps:Engineering method steps: Formulate the problemFormulate the problem Analyse the problemAnalyse the problem Search for solutionsSearch for solutions Decide on appropriate solutionDecide on appropriate solution Specify the solution Specify the solution


Knowledge AcquisitionKnowledge Acquisition

Do not assume that acquisition of knowledge Do not assume that acquisition of knowledge is linear.is linear.

A new piece of information may invalidate all A new piece of information may invalidate all the knowledge you have about a systemthe knowledge you have about a system

Be mentally prepare to start from scratchBe mentally prepare to start from scratch There are processes to deal with the problemThere are processes to deal with the problem

Risk-based developmentRisk-based development Anticipate surprisesAnticipate surprises

Issue-based developmentIssue-based development Any activity can influence any otherAny activity can influence any other


RationaleRationale

When developing a system, it is necessary to When developing a system, it is necessary to capture and understand the context in which capture and understand the context in which the design decisions are madethe design decisions are made

This extra knowledge is called the Rationale This extra knowledge is called the Rationale of the systemof the system

It is not trivialIt is not trivial Many decisions, many alternativesMany decisions, many alternatives

Rationale usually represents a larger amount Rationale usually represents a larger amount of information that the solution modelsof information that the solution models


Software Engineering Concepts Software Engineering Concepts (I)(I)

Participants and RolesParticipants and Roles Collaboration of many people (participants)Collaboration of many people (participants)

Client: orders/ pays the systemClient: orders/ pays the system Developers team: Construct the systemDevelopers team: Construct the system Project Manager: plans/coordinates the projectProject Manager: plans/coordinates the project Users: use the systemUsers: use the system

A role is a set of responsibilities in the projectA role is a set of responsibilities in the project Work ProductsWork Products

An artefact that is produced during development (e.g. a An artefact that is produced during development (e.g. a document)document)

A work product that must be delivered to a client is A work product that must be delivered to a client is known as deliverableknown as deliverable


Software Engineering Concepts (II)Software Engineering Concepts (II)

Tasks, Activities, ResourcesTasks, Activities, Resources A task is an atomic unit of workA task is an atomic unit of work

A manager assigns a task to a developerA manager assigns a task to a developer

An activity (phase) is a set of tasks that is An activity (phase) is a set of tasks that is performed towards a specific purposeperformed towards a specific purpose Requirements analysis is an activity aiming to Requirements analysis is an activity aiming to

analyse the requirements of the systemanalyse the requirements of the system

Resources are assets used to accomplish Resources are assets used to accomplish workwork Might include time, equipment, labourMight include time, equipment, labour


Functional/Non Functional Functional/Non Functional RequirementsRequirements

RequirementsRequirements specify a set of features the specify a set of features the system must havesystem must have

FunctionalFunctional: describe what the system should : describe what the system should dodo The user must be able to access the databaseThe user must be able to access the database

Non FunctionalNon Functional: Place constraints on how : Place constraints on how functional requirements are implemented.functional requirements are implemented. performance, user-friendliness, availability, performance, user-friendliness, availability,

securitysecurity


Notations, Methods, MethodologiesNotations, Methods, Methodologies

NotationNotation Graphical or textual set of rules for representing a model.Graphical or textual set of rules for representing a model. E.g. Alphabets, numbers, UMLE.g. Alphabets, numbers, UML

MethodMethod Repeatable technique that specifies the steps involved in Repeatable technique that specifies the steps involved in

a specific problema specific problem A recipe is a method for cooking a dishA recipe is a method for cooking a dish

MethodologyMethodology A collection of methods for solving a class of problems.A collection of methods for solving a class of problems. It specifies how and when each method should be used.It specifies how and when each method should be used.

A cookbookA cookbook


Software Engineering ActivitiesSoftware Engineering Activities

Requirements ElicitationRequirements Elicitation AnalysisAnalysis System DesignSystem Design Object DesignObject Design ImplementationImplementation TestingTesting


Requirements ElicitationRequirements Elicitation

Main participantsMain participants Client, developersClient, developers

AimAim Define the purpose of the systemDefine the purpose of the system

ResultResult Description of the system in terms of actors and use Description of the system in terms of actors and use

casescases ConceptsConcepts

ActorActor: external entity that interacts with the system: external entity that interacts with the system E.g. users, other systems, environmentE.g. users, other systems, environment

Use caseUse case: general sequences of events that describe : general sequences of events that describe all possible actions between an actor and the system all possible actions between an actor and the system for a given piece of functionalityfor a given piece of functionality


AnalysisAnalysis

Main participantsMain participants Developer – (client)Developer – (client)

AimAim Produce a model of the system that is correct, Produce a model of the system that is correct,

complete, consistent, unambiguouscomplete, consistent, unambiguous

ResultResult A model that completely describes the systemA model that completely describes the system


System DesignSystem Design

ParticipantsParticipants Developer (s)Developer (s)

AimAim Specify an easy-to-understand description Specify an easy-to-understand description

(architecture, components) of the system to (architecture, components) of the system to be.be.

ResultResult A complete design model of the systemA complete design model of the system


Object DesignObject Design

ParticipantsParticipants Developer (s)Developer (s)

AimAim Define objects according to the system designDefine objects according to the system design

ResultResult A detailed object model with precise A detailed object model with precise

descriptions for each elementdescriptions for each element


ImplementationImplementation

ParticipantsParticipants DevelopersDevelopers

AimAim Translate design into codeTranslate design into code

ResultResult A complete set of source code A complete set of source code


TestingTesting

ParticipantsParticipants DevelopersDevelopers

AimAim Find as many faults as possibleFind as many faults as possible

ResultResult a complete set of test casesa complete set of test cases

ConceptsConcepts Test case is a set of inputs and expected Test case is a set of inputs and expected

results that exercises a component in order to results that exercises a component in order to detect faultsdetect faults


Reading listReading list

Any of the chapters of the useful Any of the chapters of the useful textbooks that refer to software textbooks that refer to software engineeringengineering


ConclusionsConclusions

Module InformationModule Information Description of the ModuleDescription of the Module Teaching & Assessment methodsTeaching & Assessment methods Module ContentModule Content

Overview of Software EngineeringOverview of Software Engineering Next Week: UML OverviewNext Week: UML Overview

advanced information systems development (sd3043) lecture 1: introduction

Documents

information security

uml software engineering

software metrics

research topics

research grants

research publications

various research papers

students attention