Chapter 1, Introduction to Software Engineering

1. Chapter 1,Introduction to Software Engineering

2. Course format • A Single Semester Course • Lectures: Theoretical foundations and background • Project: Learn how to apply them in practice • Lectures and Project work are interleaved • Labs and Assignments complement lectures and the team project • A Single Project Course • Everybody is working on the same project • Cheating Rule for CS3013 • You cheat if you do not acknowledge the contribution made by others.

3. Lecture Overview • Introduction • Objectives of Course • Project • e-Textbook System Problem Statement • Top Level Design • Syllabus • Introduction of People • Administrative Matters • Software Engineering Overview • A UML class model of software engineering • Activities • Ticket distributor example

4. Objectives of this course • Acquire technical knowledge • Understand difference between program and software product • Be able to reconstruct the analysis and design of an existing software system • Be able to design and implement a subsystem that will be part of a larger system • Acquire managerial knowledge • produce a high quality software system within budget & time • while dealing with complexity and change

5. Emphasis is on team-work • Participate in collaborative design • Work as a member of a project team, assuming various roles • Create and follow a project and test plan • Create the full range of documents associated with a software product • Complete a project on time

6. How can we accomplish this? • Course Project • e-Textbook: online used textbook auction web site • The 4 R’s: • Real Problem: University students want an easy way to find used textbooks to buy as well as a way to auction off their own used textbooks (that they no longer need) • Real Client: You • Real Data: All textbooks purchased for courses at UNB and Saint Thomas • Real Deadline: April 12, 2001

7. Assumptions and Requirements for this Class • Assumption: • You are proficient in a programming language (Java preferred), but have no experience in analysis or design of a system • You have access to a Web Browser • Course Homepage: http://www.cs.unb.ca/profs/nickerson/courses/CS3013ci.htm • Requirements: • You have taken the prerequisite course CS2013 Software Engineering I • or • You have practical experience with maintaining or developing a large software system

8. Project Goals • Attempt to produce a web site with the e-Textbook auction site functionality • Implementation of three major processes: • Handling registration of used textbooks for auction. • Carrying out (in a secure fashion) the bidding process for textbooks. • Keeping track of all registered users of the e-Textbook site. • Demonstration of a conceptual prototype

9. Basic Software Architecture for e-Textbook Project Auction a Textbook Bidder Add Textbook Seller Notification of Sale Internet Administrator Add User

10. Teams • e-Textbook will be developed in a team-based approach • Each team will do the same e-Textbook project • You will be member of one team of four to six people • Teams will normally meet at least once per week during the lab session • Team selection is done by project management and will be announced in class, Tuesday, January 16. • Teams will be formed so that all team members have common lab times • If you wish to be part of the same team, please assign one person to send me a suggested team list by e-mail

11. Acceptance Milestone • The acceptance criteria are established in a dialog with the client during the requirements analysis phase • The e-Textbook system will be delivered with the following artifacts on a CD-ROM • Requirements Analysis Document • System Design Document • Object Design Document • Test Manual • Source Code Depot

12. If you need help • Questions about Passwords, Logging into the network, Accessing the Home page: • UNB Computing Services help desk (helpdesk@unb.ca), 453-5199, room HD-11 • Questions about getting into the ITD414 lab • Troy Cabel (tcabel@unb.ca), 452-6162, room GE-118 • Jeff Geddes (jgeddes@unb.ca), 452-6102, room GE-119 • Questions about the Course • Brad Nickerson (bgn@unb.ca), 458-7278, room ITC304 • office hours Wednesdays, 11:30 a.m. t o 12:30, Fridays 3:30 to 5:00 p.m.

13. Software Engineering • Software systems are complex • Impossible to understand by a single person • Many projects are never finished: "vaporware" • The problem is arbitrary complexity • Definitions • The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines (Bauer, F. L. Software Engineering. Information Processing 71., 1972). • Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1) (IEEE Std 610-1990). • Software engineering is the computer science discipline concerned with developing large applications. Software engineering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting (WebReference Webopaedia ). • Our definition: • Software Engineering means the construction of quality software with a limited budget and a given deadline in the context of constant change • Emphasis is on both, on software and on engineering

14. Modeling Problem-solving Knowledge Acquisition Rationale Driven Helps software engineers understand implications of change Activities

15. Modeling • Focusing relevant details at each development stage • A model is an abstract representation of a system for answering questions about the system • Real world system: a set of phenomena • Problem model: a set of interdependent concepts describing those aspects of the real world relevant to the problem under consideration. • Model of problem domain vs. model of solution domain • OO methods: Problem D. model + Solution D. model • Objects and relationships in problem domain • Object and relationships in solution domain (extension from 1) • Software Development: identify and describe a system as a set of models to address the end user’s problem.

17. Problem Solving • Software engineering is an engineering activity • Rely on empirical methods to evaluate the benefits of different alternatives represented as models • The engineering method: 1. Formulate the problem (requirements elicitation and 2. Analyze the problem analysis) 3. Search for solutions (system design and 4. Decide on the appropriate solution object design) 5. Specify the solution (implementation) • Activities: experimentation, pattern reuse, incremental evolution, reviews of problem and solution models

18. Knowledge Acquisition • In modeling application and solution domains • Data collection • Information organization • Knowledge formalization • Non-linear knowledge acquisition • Single piece of data can invalidate complete models • Linear software development process • Waterfall model • Non-linear software process • Risk-based development • develop higher risks first • Issue-based development • develop all issues in parallel

19. Rationale Driven • Rationale of the system • The context and rationale in which each design decision was made • To be captured and understood by software engineer • Represents a set of issue models with larger amount of information than the solution models • Not explicit (without explicitly evaluating different alternatives) • Enables software engineers to understand the implication of a proposed change when revising a decision. • Rationale management

20. Software Engineering Concepts • Participants and Roles • Role • a set of responsibilities • associated with a set of tasks • assigned to a participant • typical roles: end user, client, developer, project manager • Participant • any persons involved in the project • plays certain role(s) • Systems and Models • System: the underlying reality • example: ticket distributor for a train • Model: any abstraction of the reality • example: requirement, analysis, design, implementation models

21. Project Activity WorkProduct Task Resources System Participant Model Time Document Equipment Figure 1-1. Software engineering concepts, depicted as a UML class diagram (OMG, 1998). * is produced by consumes * * *

22. Work Products • Artifact produced during development • Internal work product • for the project’s internal consumption • any artifact not in the contract or requested by the client • example: test plan • Deliverable • for the client • defined prior to the start of the project and specified in the contract. • Activities, Tasks, and Resources • Activity or phases: a set of tasks for a special purpose such as requirement elicitation • Task: an atomic unit of work in terms of management, to be assigned to a developer. • Resources: assets to be used to accomplish work.

23. Goals, Requirements and Constraints • Goals • a high level principle to guide the project • define the attributes of the system that are important • primary goal and other goals of a project • conflicting goals • Functional requirements • area of functionality that the system must support (e.g. provide the user with a paper copy of the ticketing information) • Nonfunctional requirements • operation of the system (e.g. response back to user in less than one second 99% of the time) • examples: performance, reliability, security • Constraints • interface with an existing computer system

24. Notations, Methods, and Methodologies • Notation • a graphical or textual set of rules for representing a model • Example: UML for OO modeling, Z for system specification using sets • Method • A repeatable technique for solving a specific problem • Example: sorting algorithm, version control • Methodology • a collection of methods for solving a class of problems • decompose software process into activities • examples: Unified software development process, Object Modeling Technique (OMT), Catalysis.

25. Software Engineering Development Activities • Requirement elicitation (Client and Developer) • The client and developers define the purpose of the system • Result: description of actors and use cases for functional requirement • Example Use case name: PurchaseOneWayTicket Participating actor: Initialized by Traveler Entry condition: 1. Traveler stands in front of the ticket distributor at a station Flow of events: 2. Traveler selects the source and destination stations 3. TicketDistributor display the price of the ticket 4. Traveler inserts sufficient money 5. TicketDistributor issues the ticket and returns change Exit condition: 6. Traveler holds a valid ticket and the change Special requirements: If the transaction is not completed after 1 minute of inactivity, TicketDistributor returns all inserted money

26. Nonfunctional requirements • Reliability: The ticket distributor should be available to traveler at least 95% of the time • Performance: The ticket distributor should provide feedback to the traveler within a second after the transaction has been selected. • Analysis (Developer) • produce a model of the system that is correct, complete, consistent, unambiguous, realistic, and verifiable. • transform the use cases into an object model that completely describes the system • discover ambiguities and inconsistencies

27. Transaction Ticket Zone Coin Balance Bill Figure 1-3. An object model for the ticket distributor (UML class diagram). In the PurchaseOneWayTicket use case, a Traveler initiates a transaction that will result in a Ticket. A Ticket is valid only for a specified Zone. During the Transaction, the system tracks the Balance due by counting the Coins and Bills inserted. valid for results in amount paid

28. System Design (Developer) • define the design goals • decompose the system into smaller subsystems that can be realized by individual teams. • Select strategies for building the system • results: • strategy descriptions • subsystem decomposition • deployment diagram • Object Design (developer) • define custom objects to bridge the gap between the analysis model and the system design platform • Implementation • translate the object model into source code

29. Updater Traveler Interface Local Tariff Central Tariff Figure 1-4. A subsystem decomposition for the TicketDistributor (UML class diagram, folders represent subsystems, dashed lines represent dependencies). The TravelerInterface subsystem is responsible for collecting input from the Traveler and providing feedback (e.g., display ticket price, returning change). The LocalTariff subsystem computes the price of different tickets based on a local database. The CentralTariff subsystem, located on a central computer, maintains a reference copy of the tariff database. An Updater subsystem is responsible for updating the local databases at each TicketDistributor through a network when ticket prices change.

30. Managing Software Development • Communication • exchange models and documents • report the status of work products • provide feedback on the quality of work products • raise and negotiate issues • communicate decisions • common convention and tool based • Rationale management • the problem addressed • alternatives considered • evaluation criteria used • debate, consensus, and decision • difficulty: update and maintenance

31. Testing • find differences between the system and its models by execution with sample data • Unit testing • compare the object design model with each object and subsystem • Integration testing • compare the integrated subsystems with the system design • System testing • compare the system with the requirement model by running typical and exception cases

32. Software Configuration Management • the process that monitors and controls changes in work products • Example changes • requirement changes • client new feature • development new/improved understanding • platform changes • new technology available • system changes • fault and repair • enable developer to track changes • configuration items to be individually revised • versions for evolution of configuration items and roll back • enable developers to control change • define baselines • assess and approve increments from the baselines

33. Project management • oversight activities to ensure • the delivery of a high-quality system on time and within budget • plan and budget the project during negotiation with the client • hire developers and organize them into teams • monitor the status of the project • intervene when deviations occur • Software life Cycle • A general model of the software development process