Presentation is loading. Please wait.

Presentation is loading. Please wait.

Leiden Institute of Advanced Computer Science

Similar presentations

Presentation on theme: "Leiden Institute of Advanced Computer Science"— Presentation transcript:

1 Leiden Institute of Advanced Computer Science
Software Engineering Leiden Institute of Advanced Computer Science Who made software before? Lecture Series for BSc. “Computer Science” year 2 (Fall semester 2013) 1

2 Outline Introduction / Course logistics
Introductory lecture Software Engineering What is Software Engineering? What does a Software Engineer do? What does a Software Engineering Process look like? These slides are based on slides by Drs. Werner Heijstek, Dr. Natallia Kokash, Dr. Michel Chaudron and Professor Dr. Hans van Vliet 2

3 Software Engineering “Course Logistics”
Leiden Institute of Advanced Computer Science Who made software before? Lecture Series for BSc. “Computer Science” year 2 (Fall semester 2013) 3

4 Who am I? Tim Cocx
Room 124 (Thursdays), , Teach this course for the second time Also: statistics Main job: Haagse Hogeschool I hold M.Sc. (2004) & Ph.D. (2009) degrees from Leiden University My current main focus points are programming and software design Married with two cats

5 What you will learn in this course?
Engineering = skill + knowledge This course 30% knowledge and 70% skills Basic concepts, vocabulary of Software Engineering Main activities in Software Engineering projects Main methods and techniques excluding: programming (Maybe) Guest Lectures by professionals Software Engineering as an academic research area 5

6 The Only Really Important Info

7 Lectures Schedule There is a iCal file on the website for phone / tablet usage Week 1 Morning: Course & Subject Introduction Afternoon: Nothing / Free / Self-Study Week 2 All day: Reverse Engineering Week 3 All day: Modelling Week 4-14: Morning: Class Afternoon: Lab Week 15 Monday & Tursday: All Day Assessments Exam NB: 3rd October: Only party NB: 24th October: No class, exam in afternoon 7

8 Grading Week 2: Reverse Engineering Assignment (20%) Deadline Week 4
Week 8: Modelling Exam (20%) Week 15: Assessments (40%) Week 16: Theoretical Exam (20%) All grades must be sufficient (>=5.5)

9 Lab You will do a Software Engineering Project In teams of 6-10 people
Focus on a proper development process Results: Documentation, process “Log’s”, Software Programming skills are required. Assignment: You’ll see when the lab starts (surprise!)

10 Software Engineering “An Introduction”
Leiden Institute of Advanced Computer Science Who made software before? Lecture Series for BSc. “Computer Science” year 2 (Fall semester 2013) 10

11 The Software Crisis “The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.” Edsger Dijkstra The Humble Programmer, Communications of the ACM (1972) 11

12 Division Computer costs
100 Hardware Development 60 Percent of total cost Software 20 Maintenance 1955 1970 1985 Year © SE, Introduction, Hans van Vliet 12

13 The Crisis Manifest Projects running over-budget
Projects running over-time Software was very inefficient Software was of low quality Software often did not meet requirements Projects were unmanageable and code difficult to maintain Software was never delivered

14 The Birth of Software Engineering
The term Software Engineering was introduced at 1968/69 NATO conferences Idea: software development is not an art, or a bag of tricks We should build software like we build bridges

15 What is Software Engineering?
The process of solving customers’ needs by the systematic development and evolution of large, high- quality software systems within cost, time and other constraints Solving customers’ problems This is the goal of software engineering Sometimes the solution is to buy, not build Adding unnecessary features does not help solve the problem Software engineers must communicate effectively to identify and understand the problem 15

16 Definition (IEEE) “Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software” © SE, Introduction, Hans van Vliet 16

17 Is Software Engineering, Engineering?
Software is logical, rather than physical Progress is hard to see Software is not continuous Further reading: Henry Petroski, Design Paradigms: Case Histories of Error and Judgement in Engineering A. Spector & D. Gifford, A Computer Science Perspective of Bridge Design, Communication of the ACM 29, 4 (1986) p

18 Types of Software Custom For a specific customer Generic
Sold on open market Often called COTS (Commercial Off The Shelf) Shrink-wrapped Embedded Built into hardware Hard to change 18

19 Types of Software Real time software
E.g. control and monitoring systems Must react immediately Safety often a concern Business Information Systems (Data processing) Used to run businesses Accuracy and security of data are key Some software has both aspects! 19

20 The Nature of Software Software is intangible
Hard to understand development effort Software is easy to reproduce Cost is in its development in other engineering products, manufacturing is the costly stage The industry is labor-intensive Hard to automate 20

21 The Nature of Software (Untrained) people can hack something together
Quality problems are hard to notice Software is easy to modify People make changes without fully understanding it Software does not ‘wear out’ It deteriorates by having its design changed: erroneously, or in ways that were not anticipated, thus making it complex 21

22 The CHAOS Report 1994 1996 1998 2000 2002 2004 2006 2009 Successful
16% 27% 26% 28% 34% 29% 35% 32% Challenged 53% 33% 46% 49% 51% 44% Failed 31% 40% 23% 15% 18% 19% 24% 1994 1996 1998 2000 2002 2004 2006 2009 Successful 16% 27% 26% 28% 34% 29% 35% 32% Challenged 53% 33% 46% 49% 51% 44% Failed 31% 40% 23% 15% 18% 19% 24% 1994 1996 1998 2000 2002 2004 2006 2009 Successful 16% 27% 26% 28% 34% 29% 35% 32% Challenged 53% 33% 46% 49% 51% 44% Failed 31% 40% 23% 15% 18% 19% 24%

23 Central Themes in Software Engineering
Software Engineering is concerned with large programs These programs are complex Software evolves Development must be efficient You’re doing it together Software must effectively support users Involves different disciplines Software Engineering is a balancing act - Space Shuttle software: 40 million lines of code - complexity often is not “mathematical” complexity, but caused by the myriad of details to be handled - reality changes, so the software has to change as well (e.g. salary administration and changing tax regulations) - software costs a tremendous amount of money (it is very labor intensive) - OS 360 cost 5000 person years (so you need rules and regulations - hence process models) - so user involvement - software engineers tend to have little knowledge of the application domain © SE, Introduction, Hans van Vliet 23

24 What does a Software Engineer do?
in a team interacting with clients individually Microsoft 1978 programming listening Specializing in different roles - designing, programming, testing … documenting explaining planning feedback presenting selling brainstorming discussing planning reviewing reporting 24

25 Simple “Life Cycle” Model
Typical distribution of effort (excluding maintenance) problem requirements engineering 15% reqs specification design 20% design implementation 20% system testing 45% working system maintenance © SE, Introduction, Hans van Vliet 25

26 Requirements Engineering
Includes Domain analysis Defining the problem Requirements gathering Obtaining input from as many (relevant) sources as possible Requirements analysis Organizing the information Requirements specification Writing detailed instructions about how the software should behave Results in a description of the DESIRED system: which functions possible extensions required documentation performance requirements Includes a feasibility study Resulting artifact: requirements specification - the requirements document often has a legal status too. - different stakeholders want different documents (the designer/impementer wants a precise, formal document, while the user is best served by a document in her natural language) - it is important the the requirements document is very precise; no TBD’s (To Be Determined). If you do not know what is being asked, chances are you will not come up with the right answer. 26

27 Design Includes Deciding how the requirements should be transferred to software, using the available technology Includes: Systems engineering: Deciding what should be in hardware and what in software Software architecture: Dividing the system into subsystems and deciding how the subsystems will interact Detailed design of the internals of a subsystem User interface design Design of databases Earliest design decisions captured in software architecture Decomposition into parts/components; what are the functions of, and interfaces between, those components? Emphasis on what rather than how Resulting artifact: specification 27

28 Implementation Focus on individual components
Goal: a working, flexible, robust, … piece of software Not a bag of tricks Present-day languages have a module and/or class concept 28

29 Testing Does the software do what it is supposed to do?
Are we building the right system? (validation) Are we building the system right? (verification) Start testing activities in phase 1, on day 1 Testing should not start after the implementation phase. Cleanroom development: developers are allowed to read the programs they’ve written, they are not allowed to execute them. Testing in Cleanroom is done by others. Question to students: do you dare to give a warranty on the software you wrote?

30 Maintenance Correcting errors found after the software has been delivered Adapting the software to changing requirements, changing environments, ...

31 Effort Distribution Rule of thumb: 40-20-40 distribution of effort
Trend: enlarge requirements specification/design slots; reduce test slot Beware: maintenance alone consumes 50-75% of total effort

32 Actual Effort Distribution

33 Software Engineering in a Nutshell

34 Codex Hamurabi “If a builder build a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death.” Article 229 of the Code of Hammurabi (1780 BC) - first king of the Babylonian Empire - Conquered most of Mesopotamia - Codex Hammurabi is a well-preserved Babylonian law code. - It is one of the oldest deciphered writings of significant length in the world. - 6th Babylonian king, Hammurabi, enacted the code - The Code consists of 282 laws, with scaled punishments, adjusting "an eye for an eye, a tooth for a tooth" (lex talionis) Also: if a house falls down and it kills the son on the owner, then the son of the builder shall be put to death als een huisvrouw niet bevalt, gooi haar dan in de rivier 34

35 Software Engineering Ethics
Act consistently with the public interest Act in a manner that is in the best interest of the client and employer Ensure that products meet the highest professional standards possible Maintain integrity in professional judgment Managers shall promote an ethical approach Advance the integrity and reputation of the profession Be fair to and supportive of colleagues Participate in lifelong learning and promote an ethical approach

36 Difficulties and Risks in Software Engineering
Complexity and large numbers of details Uncertainty about technology Uncertainty about requirements Uncertainty about software engineering skills Constant change Deterioration of software design Political risks 36

37 Software Development Methods
Software Projects are large and complex A phased approach to control it is necessary Traditional models are document-driven: There is a new pile of paper after each phase is completed Evolutionary models recognize that much of what is called maintenance is inevitable

38 Software Development Process Models
Waterfall Iterative 38

39 Software Development Process Models
Waterfall Model (Mid 70ies) Time Requ. Eng. & Architecting milestone 1 milestone 2 Specification milestone 3 Design milestone 4 Implementation milestone 5 Increments may also be internal Different technologies may have different lifecycle models Test No iterations Big bang scenario  First-time right 39

40 The waterfall model Feasibility study Analysis System Design
User Requirements Analysis System Design Program Design Coding Testing Operation Decomission 40 40

41 Pro's and Cons of the Waterfall Model
Imposes structure on complex projects Every stage needs to be checked and signed off: Elimination of midstream changes Good when quality requirements dominate cost and schedule requirements Cons: Limited scope for flexibility / iterations Full requirements specification at the beginning: User specifications No tangible product until the end 41 41

42 Problems of the Waterfall Process (2)
Different phases are handled by different people Business Modeling Consultants Architect(s) IT-Specialists IT-Engineers Requirements & Architecting Specification & Design Implementation Testing Communication becomes highly critical 42

43 Software Development Process Models
Waterfall Model (Mid 70ies) Test Specification Design Implementation Requ. Eng. & Architecting Evolutionary Models (80ies) Scope Time The size of the different phases is not an indication about their length Increments (Spiral cycles) Iteration 43

44 Rational Unified Process (RUP)
Phases Disciplines Iterations 44

45 Problems of Evolutionary Models
Inflexible point solutions The initial release is optimized for demonstration, consequently the architecture is difficult to extend High-risk downstream capabilities The initial release often defers quality attributes (dependability, scalability, etc.) in favor of early functionality Evolutionary development Incremental development E.g. Barry Boem’s spiral model Prototyping Construction of a durable prototype that can be extended in increments [check] 45

46 Incremental delivery Each component delivered must give some
system increment 1 2 3 design build install evaluate first incremental delivery design build install evaluate second incremental delivery design build install evaluate This approach involves breaking the application down into small components which are then implemented and delivered in sequence; each component delivered must give some benefit to the user Time-boxing is often associated with an incremental approach; here the scope of the deliverable for an increment is rigidly constrained by an agreed deadline, even at the cost of dropping some functionality third incremental delivery Each component delivered must give some benefit to the stakeholders 46

47 The Plan 47

48 Reality 48

49 The Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.”

50 12 Agile Principles Satisfy the customer through early and continuous delivery Welcome changing requirements, even late in development Deliver working software frequently Business people and developers work together daily Build projects around motivated individuals Convey information via face- to-face conversation Working software is the primary measure of progress Maintain a constant pace indefinitely Give continuous attention to technical excellence Simplify: maximize the amount of work not done Teams self-organize Teams retrospect and tune their behaviors

51 Prototyping Requirements elicitation is difficult
software is developed because the present situation is unsatisfactory however, the desirable new situation is as yet unknown Prototyping is used to obtain the requirements of some aspects of the system Prototyping should be a relatively cheap process use rapid prototyping languages and tools not all functionality needs to be implemented production quality is not required

52 Prototyping Approaches
Throwaway prototyping the n-th prototype is followed by a waterfall-like process Evolutionary prototyping the n-th prototype is delivered

53 Pro's and Cons of Prototyping
The resulting system is easier to use User needs are better accommodated The resulting system has fewer features Problems are detected earlier The design is of higher quality The resulting system is easier to maintain The development incurs less effort Cons The resulting system has more features The performance of the resulting system is worse The design is of less quality The resulting system is harder to maintain The prototyping approach requires more experienced team members

54 Popular Agile Methods Rapid Application Development (RAD) & Dynamic System Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) Unified Processes: Rational Unified Process Agile Unified Process (AUP) Open Unified Process (OpenUP)/Basic Essential Unified Process (EssUP) Scrum

55 (R)UP (Rational) Unified Process. Philosophy: Four phases in Waterfall Inception: Determine the plan and starting REQ Elaboration: Elaborate on REQ and Design Construction: Building & Testing Transition: Delivery, Installation, Instruction Within the phases iteration takes place until a predetermined ‘Milestone’ has been reached Disciplines are part of the team for the project duration There are, however, peaks in usage Artifacts (documents): Change during the project. There are however peaks in work on them.

56 Rapid Application Development (RAD)
Evolutionary development, with time boxes fixed time frames within which activities are done; Time frame is decided upon first, then one tries to realize as much as possible within that time frame; Other elements: Joint Requirements Planning (JRD) and Joint Application Design (JAD), workshops in which users participate; Requirements prioritization through a triage; Development in a SWAT team: Skilled Workers with Advanced Tools

57 Dynamic System Development Method
Is a RAD framework Popular in the UK Fundamental idea: fix time and resources (timebox), adjust functionality accordingly One needs to be a member of the DSDM consortium

58 Extreme Programming (XP)
Everything is done in small steps The system always compiles, always runs Client as the center of development team Developers have same responsibility w.r.t. software and methodology Pair Programming Manifesto: If … is good then [fill in extreme form]

59 Agile versus Traditional Development
Lightweight (Agile) Heavyweight Developers Knowledgeable, collocated, collaborative. Plan-driven, adequate skills, access to external knowledge. Customers Dedicated, knowledgeable, collocated, collaborative, representative, empowered Access to knowledgeable, collaborative, representative, empowered customers Requirements Largely emergent, rapid change Knowable early, largely stable Architecture Designed for current requirements Designed for current and foreseeable requirements Size Smaller teams and products Larger teams and products Primary objective Rapid value High assurance

60 Producing Software Means Using Software
Builders build pieces, integrators integrate them Component-Based Development (CBSD) Software Product Lines (SPL) Commercial Off-The-Shelves (COTS) Service Orientation (SOA)

61 Software Quality... Usability
Users can learn it and fast and get their job done easily Efficiency It doesn’t waste resources such as CPU time and memory Reliability It does what it is required to do without failing Maintainability It can be easily changed Reusability Its parts can be used in other projects, so reprogramming is not needed 61

62 Software Quality... Customer: User: solves problems at easy to learn;
an acceptable cost in efficient to use; terms of money paid and helps get work done resources used QUALITY SOFTWARE Development manager: Developer: sells more and easy to design; pleases customers easy to maintain; while costing less easy to reuse its parts to develop and maintain 62

63 Software Quality The different qualities can conflict
Increasing efficiency can reduce maintainability or reusability Increasing usability can reduce efficiency Setting objectives for quality is a key engineering activity You then design to meet the objectives Avoids ‘over-engineering’ which wastes money Optimizing is also sometimes necessary E.g. obtain the highest possible reliability using a fixed budget 63

64 Homework ‘Teach yourselves’ UML diagrams
This way you can start the assignment with a head- start.

Download ppt "Leiden Institute of Advanced Computer Science"

Similar presentations

Ads by Google