Software Engineering I
Overview and Review
– Computer Science and Software Engineering Department
Copyright By PowCoder代写 加微信 powcoder
Software Engineering
• Definitions:
– Software engineering studies the nature of software, approaches and methodologies of large-scale software development, and the theories and laws behind software behaviours and software engineering practices.
• Challenges:
– Complex, abstract, people interaction, …
• Typical activities:
– Requirements, Design, Coding, Testing and Maintenance, …
• Processes, activities and lifecycles:
– Cascade, V-Model, Iterative and incremental, …
Software Engineering
• Requirements Specification:
– Elicit, analyze, document.
– Functional and Quality requirements.
– Software structure and behaviour through models.
– Architecture and Detailed Design.
• Testing:
– Verify and validate.
Project Management
• Project and Project Management definitions.
• Risks and risk management.
• Traditional:
– Collection of prescribed processes, plan-driven, standardized.
– Individuals and interactions, collaboration, quick response to changes to deliver valuable software.
• Relationships:
– Association, Aggregation, Composition, Inheritance, Dependency, …
• Use cases:
– Actors, Functional requirements, Relationships, Scope, …
• Classes:
– Structure, attributes, behaviour, dependencies and relationships, …
• Sequence:
– Lifeline, objects, messages, interactions, …
• Packages and Statecharts too.
• OO, compiled, static typing, conventions, data types, …
• Variables assignment.
• Reserved words:
– Static, final, public, private, protected, …
• Operators:
– =,–,++,!,*,%
• Control Flow:
– If, else, while, do, while, for, break continue, …
OO principles
• Encapsulation:
– Keeping fields within a class private, then providing access to them via public
methods. • Inheritance:
– Classes can be derived from other classes, thereby inheriting fields and methods from those classes.
• Polymorphism:
– One name, many forms.
• Abstraction:
– Essential characteristics of an object that distinguish it from all other kinds of objects.
• A reusable solution to a commonly occurring problem within a given
Think of Good Design Principles. Be able to identify violations.
• Design patterns:
– Observer, Builder, Façade.
• Architectural patterns:
– 3-tier, Client-Server, MVC, …
Software Configuration
• Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
• CVCSs and DVCSs.
• An object state is represented by current attribute values.
• State Transition Diagram:
– States, Transitions, Nested States, Actions, Guards, …
• Test Cases:
– Pre and post-conditions.
Verification and Validation
• Determine whether the development products conform to the pre- established requirements, and the software satisfies its intended use and user needs.
• Verification and Validation go together, but they have different meanings.
• Concepts:
– Fault, error, failure, defect, exceptions, …
• Test levels and types:
– Unit, Integration, System, Acceptance, Regression and Mutation.
– Black and white box testing.
Software Engineering I
Project demo
– Computer Science and Software Engineering Department
Project DEMO
• You will have up to 7 minutes to run your game during which time you will be expected to demonstrate the following:
– Construct a new game and choose a monster (with valid and invalid inputs)
– View your inventory
– View the properties of your team
– Choose a battle and fight
– Visit the shop and view, buy and sell items
– Show random events occur
– Show the game can be completed
– Show any extra features you completed
Project DEMO
• Before your demo, ensure that you are prepared by practicing with your partner.
• You should also come prepared to answer questions about your and be able to
point to specific code.
• Read very carefully the Demo Instructions posted in the Project section on LEARN.
Project data
– 1,387 records (216 students)
– 13,470 hours (124h per team)
• Individual contribution
– Median: 50% (my contribution and my partner’s contribution)
– Average: 52% (my contribution) vs. 48% (my partner’s contribution)
• Team satisfaction
– Median: 5
– Average: 4.5
Software Engineering I
Final Exam conditions
– Computer Science and Software Engineering Department
Exam examples
• Analyze a UML use case diagram for an online login system, involving users, a login system and a database that stores user details.
Exam examples
• [1 mark] Explain what black box testing is. Expected:
It is a method to examine the functionality of the software without the knowledge of its details.
Exam examples
• [2 marks] Explain what black box testing is. Expected:
It is a method to examine the functionality of the software without the knowledge of its details. Such test can be designed using equivalence partitioning, boundary value analysis or use case testing.
Non-coding questions
• Multiple choice
• Select missing words
• Short answer
• True/False
Coding questions
Exam conditions
• The final exam is two hours (120 minutes) long.
• It is worth 50% of the final grade.
• The test is worth a total of 100 marks.
• There are no optional questions. Unanswered questions will result in 0
• Despite penalties, the total number of marks for a question cannot be less than 0.
Exam conditions
• The test will include coding questions and non-coding questions.
• Check carefully the number of marks allocated to each question. This
suggests the amount of time you should spend on the question.
• Questions may not be in order of increasing difficulty.
• Non-coding questions are single attempt only. You will not be able to retry these questions.
Exam conditions
• For coding questions we include example tests. However, due to the number of tests, not all tests are shown to you.
• You will receive one 10% penalty, then one 20% penalty and finally 40% penalties for incorrect submissions for all coding questions.
• You will not see your final results immediately.
• There may be additional instructions on a question so pay attention to the question description.
Exam conditions
• The final exam is an open book assessment item.
– You are allowed any non-electronic reference material.
– You are permitted to use an IDE (Eclipse) and the Java API documentation.
• No form of collaboration is permitted.
• We reserve the right to require an additional assessment if we suspect
unethical behaviour during this exam.
• Academic integrity must be observed at all times.
Exam conditions
Academic integrity is a principle at UC whereby both staff and students agree to act honesty, fairly, ethically and with respect for each other in teaching and learning.
For some students, there may be increased temptation to cheat and engage in dishonest academic practices such as:
Plagiarism/Self-plagiarism – using someone’s ideas and information without acknowledging them as the source or self-plagiarism where someone attempts to submit their own writing to two different assessments to gain credit twice;
Collusion – copying the work of someone else or allowing someone else to copy your work without disclosing this with the intent to deceive;
Impersonating/Ghost writing – having another person or commercial organisation impersonate you and complete an assessment item on your behalf; and/or
Fabrication – ‘inventing’ data for example in a lab report or from a publication.
Cheating and academic dishonesty will not be tolerated at UC. If you are suspected of engaging in a dishonest academic practice this will result in disciplinary action being taken against you such as receiving a fine or being suspended/expelled from your studies.
• Answer the Student Evaluation of Teaching survey – It is available since this morning
• Project marks
– Will be released not later than June 17
• Final exam
– Monday, June 20 at 9:30am
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com