Advanced Information Systems Development (SD3043) Lecture 1: Introduction Dr. Chrisina Draganova [email protected]

Advanced Information Systems Development (SD3043)

Lecture 1: Introduction

Dr. Chrisina [email protected]

Advanced Information Systems Development

2

Lecture Outline

• Module Information– Description of the Module– Teaching & Assessment methods– Module Content

• Overview of Software Engineering

• UML Overview• Conclusion


3

Lecture Rules and Facts

• Start on time!• Ten minutes break• Attendance policy is followed• Previous years:

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


4

Description of the Module

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

and research topics related to information systems development

– Expose students to current issues in information systems development

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


5

The Module Team• Dr. Chrisina Draganova

– Module Leader, Lectures, Tutorials/Practicals

• Dr. Andrea Capiluppi– Lectures, tutorials / Practicals

• Kamaljit Kaur Bimrah– Tutorials / Practicals


6

Teaching and Assessment Methods

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

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


7

Recommended reading

• H. Mouratidis, G. Williams, Issues in Information Systems Development, Thomson education, 2005 (ISBN 184479458x)

• R. Pressman, 2000, Software Engineering, A Practioner’s Approach, McGraw-Hill• ‘Software Engineering’, 6th edition, by I. Sommerville, Addison-Wesley (2000)• B. Bruegge, A. H. Dutoit, Object Oriented Software Engineering: Using UML,

Patterns and JAVA (International Edition), Prentice Hall, 2004 (ISBN 0-13-191179-1)

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

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

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


8

Recommended reading• ‘Software Metrics’ by N.E. Fenton and S.L. Pfleeger, Thomson Learning (2000)• 'Object-Oriented Systems Analysis and Design', 2nd edn., by S. Bennett, S. McRobb

and R.Farmer, McGraw-Hill (2002) • H. Mouratidis, P. Giorgini, Integrating Security and Software Engineering:

Advances and Future Vision, Idea Group Publishing, (ISBN 1-59904-148-0)• B. Bruegge, A. H. Dutoit, Object Oriented Software Engineering: Using UML,

Patterns and JAVA (International Edition), Prentice Hall, 2004 (ISBN 0-13-191179-1)• Williams Godfried, Synchronizing E-Security (International series in Advances in

information security). Kluwer Academic Publishers (ISBN 1-4020-7646-0)

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

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

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

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

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


9

Coursework

• There is only one coursework for the module.

• Group coursework and each group consists of min. two max. four members

• The coursework consists of two parts: analysis and design (50%) and security and management (50%) – The analysis and design part is a group work. – On the other hand, the security and

management part is an individual piece of work.


10

Groups

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

the second tutorial• An email to [email protected] with the subject

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

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

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

mailto:[email protected]


11

Assignment’s Handout/in dates

• Handout Date• 4th week• Group Allocation• 2nd week• Hand in Date

– 11th of December 2009

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


12

Module Content1 Module Introduction / Software Engineering Overview :

1.Introduction to module and module outline.Overview of Software Engineering and UML:

•2 •Project Management, Risk Analysis and Management:

•3 •Risk Management - Security :

4 Advanced Information Systems Engineering

•5 •Patterns / Architectural Styles / Model Driven Architecture (MDA):

•6 •Design Patterns

•7 •Trends in Systems Development:

8 Testing:

•9 •Project Management – Techniques, Optimization and Estimation:

•10 •Project Management – Software Metrics and Software Cost Estimation:

•11 •Standards, Quality Assurance and Process Improvement

12 Review of the Module


13

Why another information systems development module?

• What is difficult about developing software systems?– Large and complex systems– Requirements change constantly

• Why not use an informal approach to software development?– Late projects– Costly projects


14

Software Engineering Failures

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

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

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


15

First Definition of Software Engineering

• NATO conference (1968)

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

is reliable and works efficiently on real machines”


16

What is Software Engineering?

• I. Sommerville defines it as:

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


17

What is Software Engineering?

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

• Software Engineers deal with complexity through modelling

– A problem-solving activity• Constraints and deadlines

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

knowledge– A rationale-driven activity

• Capture the context and the rationale behind the decisions


18

Modelling

• A model is an abstract representation of a system

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

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

But why models are useful in Software Engineering?


19

Software Engineering Models

• Need to understand the environment in which the system will operate– Stakeholders, users, connected systems

• Understand the systems itself– Components, Communication paths

• Evaluate different solutions and trade-offs– Fast versus Secure

Systems are expensive to build so we model them first


20

Problem Solving

• Software Engineers have limited resources, incomplete knowledge

• Search for an appropriate solution, evaluate alternatives

• Engineering method steps:– Formulate the problem– Analyse the problem– Search for solutions– Decide on appropriate solution– Specify the solution


21

Knowledge Acquisition

• Do not assume that acquisition of knowledge is linear.

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

• Be mentally prepare to start from scratch• There are processes to deal with the

problem– Risk-based development

• Anticipate surprises– Issue-based development

• Any activity can influence any other


22

Rationale

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

• This extra knowledge is called the Rationale of the system

• It is not trivial– Many decisions, many alternatives

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


23

Software Engineering Concepts (I)

• Participants and Roles– Collaboration of many people (participants)

• Client: orders/ pays the system• Developers team: Construct the system• Project Manager: plans/coordinates the project• Users: use the system

– A role is a set of responsibilities in the project

• Work Products– An artefact that is produced during development (e.g. a

document)– A work product that must be delivered to a client is

known as deliverable


24

Software Engineering Concepts (II)

• Tasks, Activities, Resources– A task is an atomic unit of work

• A manager assigns a task to a developer

– An activity (phase) is a set of tasks that is performed towards a specific purpose

• Requirements analysis is an activity aiming to analyse the requirements of the system

– Resources are assets used to accomplish work

• Might include time, equipment, labour


25

Functional/Non Functional Requirements

• Requirements specify a set of features the system must have

• Functional: describe what the system should do– The user must be able to access the database

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

security


26

Notations, Methods, Methodologies

• Notation– Graphical or textual set of rules for representing a model.– E.g. Alphabets, numbers, UML

• Method– Repeatable technique that specifies the steps involved in

a specific problem• A recipe is a method for cooking a dish

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

• A cookbook


27

Software Engineering Lifecycle

• Different activities necessary to develop a software system

• Lifecycle model represents all these activities and the relationships to each other

• The main activities are:– (Software Specification) Requirement Engineering– Software Design – Software Implementation– Software Testing (validation)– Software Evolution


28

O-O Activities

Application

Domain Objects

SubSystems

class...class...class...

Solution Domain Objects

SourceCode

Test Cases

?

Expressed in Terms Of

Structured By

Implemented

ByRealized By Verified By

SystemDesign

ObjectDesign

Implemen-tation

Testing

class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

Requirements Engineering


29

Requirements Engineering

RequirementsAnalysis

systemspecification

analysis

model

Problem StatementGeneration

RequirementsElicitation

ProblemStatement


30

Requirements Elicitation

• Process of deriving the system requirements• Results in a specification of a system that the

client understand• Very challenging activity• Requires collaboration of people with different

backgrounds– Users with application domain knowledge– Developers with solution domain knowledge

(design knowledge, implementation knowledge)


31

O-O Requirements Elicitation Activities

• Identify actors

• Identify scenarios

• Identify use cases

• Refine use cases

• Identify relationships among use cases

• Identify non functional requirements


32

Identify Actors

• It is not easy, especially in initial stages– Database

• Define the system boundary• Useful questions

– Which user groups are supported by the system to perform their work?

– Which user groups execute main, secondary functions of the system?

– What other systems interact with this system?


33

Identify Scenarios

• “Narrative description of what people do and experience as they try to make use of computer systems and applications” [Carroll, 1995]

• Informal description of a single feature of the system used by a single actor

• Do not replace use cases (complementary)– Focus on specific instance

• Describe the outcome of a decision– Two scenarios


34

Identify Use Cases

• A use case specifies all possible scenarios for a given piece of functionality

• Describe each of these use cases in more detail – Participating actors– Describe the Entry Condition – Describe the Flow of Events – Describe the Exit Condition – Describe Exceptions– Describe Special Requirements (Constraints,

Nonfunctional Requirements


35

Identify Non-Functional Requirements

• Usability: how easy the system is to operate– Conventions adopted by the user interface

• Reliability– Acceptable mean time to failure

• Performance– Response time, availability, accuracy

• Supportability: how easy is to change the system– Adaptability, maintainability

• Security– Security constraints

• Non-functional requirements often conflict!!– Prioritise them


36

Requirements Analysis

• Transition between real world and machine world• Requirements elicitation is the input• Analysis focuses on producing a model of the

system• Analysis model consistent with requirements• Main question to answer: what?

– What functions must the system perform?

• Different approaches– Structured– Object Oriented– Goal Oriented


37

O-O Analysis Activities

• Identify classes– Data Driven – Responsibility Driven

• Identify associations– aggregates, attributes, inheritance

• Review the model


38

System DesignSystem Design

2. System

Layers/PartitionsCohesion/Coupling

5. Data

1. Design Goals

DefinitionTrade-offs

4. Hardware/

Special purpose

Software

Buy or Build Trade-offAllocationConnectivity

3. Concurrency

Data structure

Persistent ObjectsFilesDatabases

ManagementAccess controlSecurity

6. Global Resource Handling

8. BoundaryConditions

InitializationTerminationFailure

Decomposition

Mapping

7. Software Control

Identification of Threads

MonolithicEvent-DrivenThreadsConc. Processes


39

O-O Design

• Design Classes are refined versions of the analysis classes

• Include implementation details– Full spec of attributes (visibility, type, etc)– Full spec of operations (return type, exceptions,

visibility, etc) – Full definition of relationships (navigability, etc)

• Not an 1-to-1 mapping– 1 analysis class could result in many design

classes


40

Reading list

• Any of the chapters of the useful textbooks that refer to software engineering


41

Conclusions

• Module Information– Description of the Module– Teaching & Assessment methods– Module Content

• Overview of Software Engineering

• Next Week: UML Overview

Documents

Advanced Information Systems Development (SD3043) Lecture 1: Introduction Dr. Chrisina Draganova [email protected]