Course 254 451 Software Engineering Final Test Preparation Michael Brueckner.

งานนำเสนอเรื่อง: "Course 254 451 Software Engineering Final Test Preparation Michael Brueckner."— ใบสำเนางานนำเสนอ:

1 Course 254 451 Software Engineering Final Test Preparation Michael Brueckner

2 (c) Michael Brueckner 2005-2006 2 Introduction to Software Engineering  Terminology คำศัพท์เฉพาะทาง :  software,  software engineering,  software engineers,  software products  Difference ความแตกต่าง between software engineering and systems engineering  Difference between software engineering and computer science

3 (c) Michael Brueckner 2005-2006 3 Software  Software comprises รวมถึง computer programs and data plus technical descriptions used to run the programs.  Def. 1957 (John W. Turkey): Software is everything in a computer which is not hardware.  In legal เกี่ยวกับกฎหมาย / ได้รับอนุญาตตาม กฎหมาย view software is intellectual work ทรัพย์สินทางปัญญา

4 (c) Michael Brueckner 2005-2006 4 Software Engineering  All activities which lead to a software product  Get all requirements  Design the system  Programming  Testing the system  Track the versions  Manage the people

5 (c) Michael Brueckner 2005-2006 5 Software Products-1  Generic โดยทั่วไป products  Customized ซึ่งสร้าง ตามคำสั่งเฉพาะของ ลูกค้าคนเดียว products  We have to manage versions Where do you think do we have to manage more versions?

6 (c) Michael Brueckner 2005-2006 6 Software Development Process Basic Ideas  Requirements – Specification ข้อจำกัด  Development – Implementation ทำให้มีผล  Validation การให้เหตุผล – Distribution  Evolution วิวัฒนาการ – more versions!  Process models ต้นแบบ = simplified ทำให้ ง่ายขึ้น description of SW development

7 (c) Michael Brueckner 2005-2006 7 Software Engineering  „systematic ซึ่งเป็นระบบ,  disciplined,  quantifiable ซึ่งบอกจำนวน approach วิธีการ ทำให้ถึงจุดหมาย  to the development,  Operation การดำเนินการ, and  Maintenance การรักษาสภาพ of software".

8 (c) Michael Brueckner 2005-2006 8 Inter-Disciplinary Software Engineering Example: Air Traffic Control System

9 (c) Michael Brueckner 2005-2006 9 Engineering & Management  Science: experiments; empirical studies; theories characterizing system behavior (e.g. system reliability)  Management: organizing teams and activities; controlling and monitoring  Human factors: ergonomics in user interface design; user task understanding and modeling  Engineering: application of science to typical problems; solutions to typical problems; working out principles and good practices

10 (c) Michael Brueckner 2005-2006 10 Principles of SE  Modularity ประกอบด้วยหน่วยแยกต่างๆ and Decomposition การเน่าเปื่อย  Abstraction นามธรรม  Anticipation การรอคอยอย่างคาดหวัง of Change (“think in advance” ล่วงหน้า )  Generality กฎเกณฑ์ทั่วไป  Incrementality การเพิ่มขึ้น  Reliability ความน่าเชื่อถือ

11 (c) Michael Brueckner 2005-2006 11 Why is SE important?-1  Since the 1950s computers are part of modern society. This leads to the  need to be reliable เชื่อถือได้  need to be safe ปลอดภัย  need to be secure ไม่มีกังวล (stable)

12 (c) Michael Brueckner 2005-2006 12 Why is SE important?-2  Software is an important factor in business  Functional (the features)  Used for daily work  Used for communication  Used for information retrieval (information ist the most important factor in todays business)  Cost ค่าใช้จ่าย  Cost: only once (1 x),  money is the most important decision maker in business  Revenue รายได้

13 (c) Michael Brueckner 2005-2006 13 SE has to do with...  Programming  Problem solving  Management of people (psychology)  Processes

14 (c) Michael Brueckner 2005-2006 14 Types of Software Systems  Transaction Processing  Batch Processing  Real Time Processing  Transaction: การติดต่อทางธุรกิจ / การ ดำเนินการ / ความสัมพันธ์ระหว่างบุคคล

15 (c) Michael Brueckner 2005-2006 15 Batch Processing  Software is executed all at once  No need for user interaction  Used for time consuming ที่สิ้นเปลืองเวลา มาก processing  Movie rendering การแปล (put into other format)  Simulation software

16 (c) Michael Brueckner 2005-2006 16 Real Time Processing  Quick response software (like embedded software)  Data from environment สภาพแวดล้อม is processed  process control plants (manufacturing, refining),  telephone switching systems,  hospital patient monitoring systems,  air traffic control  weather data collection, water quality

17 (c) Michael Brueckner 2005-2006 17 Real Time vs. Transaction Processing  Real time can work automatically โดยอัตโนมัติ  Response การตอบสนอง depends on the state of the system (HW- SW)  Example: telephone switch –  all lines are busy  More complex design work needed  Safety issues  First version must be without bugs!  Example: Patient Monitoring System for hospital

18 (c) Michael Brueckner 2005-2006 18 Software Engineering Technology  Three layers  (1) Process แนวทางปฏิบัติ  (2) Methods วิธี of management and technology  (3) Tools เครื่องมือ

19 (c) Michael Brueckner 2005-2006 19 SE Process  Engineering Process  is a series อนุกรม of steps ก้าว to create a quality product* at the right time  is like a road map  has to be adapted ทำให้เหมาะ to the needs  leads to stability เสถียรภาพ, control and organization of the project activities *quality product: code, data and documents

20 (c) Michael Brueckner 2005-2006 20 SE Process Model-2  Basic SE process models  Linear Model (Waterfall)  Evolution วิวัฒนาการ Model (Prototyping)  Reusable นำกลับมาใช้ใหม่ Components Model

21 (c) Michael Brueckner 2005-2006 21 Linear Process Model-1  Problem definition  Requirements  Development  Testing  are distinct and separate phases

22 (c) Michael Brueckner 2005-2006 22 Linear Process Model-2

23 (c) Michael Brueckner 2005-2006 23 SE Process Model-2  Basic SE process models  Linear Model (Waterfall)  Evolution Model (Prototyping)  Reusable Components Model

24 (c) Michael Brueckner 2005-2006 24 Evolution Model-1  (1) Evolution Model 1: Development like an exploration  Find out with the customers how the system will work  Add new features according to customer understanding  (2) Evolution Model 2: Throw away prototype  Starts with poor understanding of requirements  Team develops a „quick and dirty“ system  Refinement

25 (c) Michael Brueckner 2005-2006 25 Example: Evolution Model

26 (c) Michael Brueckner 2005-2006 26 Evolutionary Model-2 Validation Final version Development Intermediate versions Specification Initial version Outline description Concurrent activities

27 (c) Michael Brueckner 2005-2006 27 SE Process Model-2  Basic SE process models  Linear Model (Waterfall)  Evolution Model (Prototyping)  Reusable Components Model

28 (c) Michael Brueckner 2005-2006 28 Reusable Components Model-1  Process stages  Component analysis  Requirements modification  System design with reuse  Development and integration

29 (c) Michael Brueckner 2005-2006 29 Reusable Components Model-2 Requirements specification Component analysis Development and integration System design with reuse Requirements modification System validation Component analysis Outside System Inside System

30 (c) Michael Brueckner 2005-2006 30 Project Management / Project  Examples: I build my own PC from spare parts: 1 person with limited budget, 1 month time schedule Bring a man on the moon: 25.000 people with Mio. USD-budget, 7 years time schedule Implementation of an information system: 50 people, 1 Mio. budget, 6 months time schedule A project is a temporary ที่เป็นการชั่วคราว endeavor ความ พยายาม with a budget งบประมาณ and a timeline to achieve สำเร็จ particular aims and to which project management can be applied.

31 (c) Michael Brueckner 2005-2006 31 Project Management / Definition  PM standardizes ทำให้เป็นมาตรฐาน and structures สร้างโครงสร้าง the basic จำเป็นที่สุด tasks in a project  PM aims at completing a project in the most cost- effective and efficient ซึ่งมีประสิทธิภาพ way Project Management is the application of knowledge, skills, tools, and techniques to the activities in a project. Project management comprises five basic tasks – Initiating ริเริ่ม, Planning วางแผน, Executing ดำเนินการ, Controlling ตรวจสอบ, Closing จบ

32 (c) Michael Brueckner 2005-2006 32 Project Management / Phase  Example: Project Start (Phase)  Activities: get the manpower กำลังคน, get the money, get the room and equipment, define the project‘s deadline กำหนดเวลา สุดท้ายที่ต้องทำให้เสร็จ  Milestone: Project application การขอ is signed  Documents: „Project Structure“, „Project Plan“ (time and budget), „Project Mission“ จุดมุ่งหมาย A Project Phase is a set of activities in a project which form a major ส่วนใหญ่ part of the work. The project phase is completed with a project milestone and defined documents that have to be delivered.

33 (c) Michael Brueckner 2005-2006 33 Project Management / Milestone Example: End of Project (Milestone):  Completes the phase "Installation and Maintenance“  Delivered documents: "Project Completion Approval" signed by Project Board A Milestone completes a project phase. It is defined as a date at which required ต้องการ documents have to be delivered. MS1 Phase 1Phase 2 MS2...

34 (c) Michael Brueckner 2005-2006 34 Project Management / Deliveries, Project Document For some results in the project there must be substitute คนหรือสิ่งที่เข้าแทนที่ documents, such as for executable code. A Project Document is a document which has a defined scope ขอบเขต and content สาร relevant เข้า ประเด็น to the project. Every Project Document must have an author (responsible for delivering ส่ง at time เกิดขึ้นเหมาะสมกับเวลา and in sufficient พอเพียง quality) and a review การทบทวน team (one or many persons).

35 (c) Michael Brueckner 2005-2006 35 PM / Work Breakdown Structure-1 The Work Breakdown Structure (WBS) is a plan which defines all the work that has to be done until the project is completed. Information investigation 10 days Keywords from "Principles of IS" "Journal of IM" / Web Scheduling (16 lectures, 15 labs) 2 days How many slides per class, types of exercises Excel Outline of slides..... 40 days Analyzing keywords Brainstorming..... Example / Part of the WBS of a course

36 (c) Michael Brueckner 2005-2006 36 PM / Work Breakdown Structure-2  Sometimes you add รวม the dependencies การพึ่งพาอาศัย / เมืองขึ้น to the WBS  This called a task network (Pressman, p. 180/181) Here you see the dependencies of the tasks and a timeline

37 (c) Michael Brueckner 2005-2006 37 Project Management / Time Scheduling  Another example: Document review  People need to read the document carefully อย่างระมัดระวัง  Depends ขึ้นอยู่กับ on the difficulty ความ ยากลำบาก  Depends on the number of pages  => it will take a minimal น้อยที่สุด time to review a document, you cannot share ใช้ ร่วมกัน the work Example:

38 (c) Michael Brueckner 2005-2006 38 Terminology  Requirements Engineering is the process in the software development life cycle where we find out, analyze, organize and check ตรวจสอบ the constraints ความยับยั้งชั่งใจ / ข้อจำกัด of the system  The Requirements Engineering Process consists of 5 distinct steps:  Requirements Elicitation ( เคลื่อนย้ายออกไปจาก )  Requirements Analysis and Negotiation ( การเจรจาต่อรอง )  Requirements Specification  Requirements Validation ( การให้เหตุผล )  Requirements Management

39 (c) Michael Brueckner 2005-2006 39 Interviews-1  Most important way to specify requirements  Important to understand the current way of work or „system“  Almost the only way to investigate problems with situation ... but who are the right persons to interview?

40 (c) Michael Brueckner 2005-2006 40 Paper Work  Very important:  Collect ไปนำมา all different types of working papers  forms  memos  notes  reports  Where do they come from  Where do they go to Information flow Forms Memos Reports

41 (c) Michael Brueckner 2005-2006 41 Observation  Watch what happens  Follow people as they do their work within the current system  Maybe you can set up a small „dummy“* system to watch the staff carefully as they work their tasks *) dummy = the very first prototype

42 (c) Michael Brueckner 2005-2006 42 Requirements Management-1  Why?  Requirements usually change during the lifecycle of the system/product  The requirements (and their changes!) must be  identified ระบุชื่อ  controlled ตรวจสอบ  tracked ติดตาม Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

43 (c) Michael Brueckner 2005-2006 43 Requirement Management-2  Identification / Example <requirement-type><requirement-number><requirement-type>:  F = functional  D = data requirement  I = interface requirement Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation Requirements Management

44 (c) Michael Brueckner 2005-2006 44 Requirements Management-3  Make a table for keeping track of req. A01A02A03Ann R01V R02Vv R03vvV R04Vv R05V Rnnvv Requirements Specific aspects of system/product

45 (c) Michael Brueckner 2005-2006 45 Problems of RE  The boundary ( ขอบเขต ) of the system is poorly described  Customers/users specify unnecessary ที่เกิน จำเป็น technical details that confuse ( ผสมปนเป กัน ) rather than clarify ทำให้ใสสะอาด / ทำให้ เข้าใจง่าย  Customers/users are not completely อย่างเสร็จ สมบูรณ์ sure what is needed  Customers/users omit ( ละเลยไป ) information that they think is „obvious“ ชัดเจน  Requirements change เปลี่ยน over time

46 (c) Michael Brueckner 2005-2006 46 What is system modelling?  System modelling helps the analyst นักวิเคราะห์ to understand the functionality การทำงาน of the system  Models are used to talk with customers  Different models present the system from different perspectives ทัศนคติ  External ภายนอก perspective shows the context or environment of the system  Behavioural perspective shows its behaviour together with users and other systems  Structural เกี่ยวกับโครงสร้าง perspective shows the system or data architecture

47 (c) Michael Brueckner 2005-2006 47 Data dictionaries  Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included ประกอบด้วย.  Advantages  Support name management and avoid หลีกเลี่ยง duplication การทำซ้ำ  Store สิ่งที่กักตุนไว้ of organisational knowledge linking analysis, design and implementation

48 (c) Michael Brueckner 2005-2006 48 Configuration Management? Software is? Code Data Technical Description (Documents)

49 (c) Michael Brueckner 2005-2006 49  New versions of software systems / Why?  For different machines/OS;  Different functionality;  Tailored for particular user requirements.  Configuration management manages changing software systems:  System change is a team activity;  CM aims to control the costs and effort of making changes to a system. Configuration management

50 (c) Michael Brueckner 2005-2006 50 Configuration management  Sets procedures and standards to manage changing software products  CM is part of the general quality คุณภาพ management process.

51 (c) Michael Brueckner 2005-2006 51 Baseline  When given to CM, software systems are sometimes called as they are a starting เริ่ม point for further ซึ่งเพิ่มเข้ามา development.  When given to CM, software systems are sometimes called baselines as they are a starting เริ่ม point for further ซึ่งเพิ่มเข้ามา development.

52 (c) Michael Brueckner 2005-2006 52 Versions and System Families Initial System HP version PC version SUN version Windows XP v. Linux version CE version v.1 v.1.01 v.1.1 v.1 v.1.1 v.2 v.1 v.1.01 v.1.05 v.0.9 v.1 v.1.1 v.1 v.1.01 v.1.1

53 (c) Michael Brueckner 2005-2006 53  All deliverables (documents) have to be managed:  Specifications  Designs  Programs  Test data  User manuals  Thousands of separate documents may be generated for a large, complex software system – most of them will have more than 1 version! Configuration Management Planning

54 (c) Michael Brueckner 2005-2006 54  Software systems are subject to ทำให้มี continual change requests ความต้องการ :  From users  From developers  From market forces.  Change management keeps track เขียน บันทึก of these changes and ensures ทำ ให้แน่ใจ that they are implemented in the most cost-effective way. Change management

55 (c) Michael Brueckner 2005-2006 55  Version: An instance กรณี / การ ดำเนินคดี ( กฎหมาย ) of a system which is functionally distinct แตกต่างชัดเจน in some way from other system instances.  Variant: An instance of a system which is functionally identical เหมือนกัน but non-functionally distinct from other instances of a system.  Release: An instance of a system which is distributed to users outside of the development team. Versions/Variants/Releases Windows 95 Windows 98 Windows XP Windows XP SP0.1 Windows XP SP2 Windows XP Windows XP SP2

56 (c) Michael Brueckner 2005-2006 56 System releases are …  more than a set of executable programs.  May also include:  Configuration files defining how the release is configured (=built) for a particular installation  Data files needed for system operation  Installation program (Windows) or shell script (Unix, Linux) to install the system on target HW  Electronic and paper documentation  Packaging ภาชนะบรรจุ and associated publicity การเผยแพร่

57 (c) Michael Brueckner 2005-2006 57 Release creation  Collect all files and documentation which we need to create a system release.  We need  Configuration descriptions (documentation)  Installation scripts (code and data)  Every release has to be well documented  So we know what the release is  We can create again if necessary