Chapter 1 - Introduction to Software Engineering

Class Schedule

Today's Agenda

• Course Overview
  • Textbooks
  • Course evaluation
  • Course objectives
  • Lecture schedule
• Introduction to Software Engineering

Course Objectives

• Understand software engineering principles
• Understand software development life cycle (SDLC)
• Understand software engineering process and software process models
• Understand key concepts of software quality and software quality assurance (SQA)

Evaluation Criteria

Group Project (40%)

Topic: Propose an application that can help students or general users to solve significant problems.

Two Presentations Required:

1. Business and User Requirements & UML Use Case (20%)

   • 10 minutes presentation
   • Evaluation: 15% from Instructor + 5% from Team members (peer review)

2. Design and Mock-ups (20%)

   • 10 minutes presentation
   • Evaluation: 15% from Instructor + 5% from Team members (peer review)

Textbooks

Main Text Book

• Software Engineering (10th Edition)
  • Author: Sommerville
  • Publisher: Addison Wesley

Additional Reading

• Software Engineering Additional Notes (will be given based on topics)
• UML 2.0 Tutorial

What is Software?

Definition: Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market.

Software encompasses:

1. Instructions (computer programs) that when executed provide desired functions and performance
2. Data structures that enable the programs to adequately store and manipulate information
3. Documentation that describes the operation and use of the programs
   • แค่ตั้งชื่อตัวแปรก็เป็นหนึ่งใน Good Documentation แล้ว - easy to read
   • not just let h = 180 but let height = 180 is obviously better!

Think of software like a recipe book: the instructions are the steps to cook (programs), the ingredients list is the data structure (what you need and where to store it), and the photos and tips are the documentation (how to use it effectively).

Software Products

Generic Products

• Stand-alone systems that are marketed and sold to any customer who wishes to buy them
• Examples:
  • PC software such as editing, graphics programs, project management tools
  • CAD software
  • Software for specific markets such as appointments systems for dentists

Like buying a Microsoft Office suite off the shelf - it's made for anyone to use.

Customized Products

• Software that is commissioned by a specific customer to meet their own needs
• Examples:
  • Inventory management systems
  • Traffic monitoring systems

Like commissioning a tailor-made suit - designed specifically for your measurements and needs.

Software Costs

• Software costs often dominate computer system costs.
  • The costs of software on a PC are often greater than the hardware cost.
• Software costs more to maintain than it does to develop.
  • For systems with a long life, maintenance costs may be several times development costs.
• Software engineering is concerned with cost-effective software development.

It's like buying a car: the initial purchase price might be high, but the real cost comes from years of maintenance, repairs, and upgrades.

Development cost is expensive, based on requirements. If the software have a good design, the maintenance cost will be cheaper in long run.

ถ้าโดนถามว่าอะไรแพงกว่าระหว่าง Development cost and maintenance cost ก็ต้องตอบว่า it depends haha

Types of Software

• System software (e.g., compilers, editors, file management utilities)
  • macOS, iOS, Xcode compiler, Terminal, Finder (file management)
• Application software (e.g., stand-alone program for specific needs)
  • Excel application, Adobe Photoshop Application, etc.
• Engineering/scientific software (e.g., molecular biology analysis, etc.)
  • Swift Playgrounds (for learning programming), Instruments (performance analysis tool)
• Embedded software (e.g., home appliance control software, etc.)
  • watchOS (Apple Watch), tvOS (Apple TV), HomePod firmware, AirPods firmware
• Product-line software (e.g., Microsoft offices, DB management software, etc.)
  • iWork Suite (Pages, Numbers, Keynote), iLife Suite (iMovie, GarageBand), Final Cut Pro
• Web Application (run on browsers and require internet connection)
  • iCloud.com (Mail, Photos, Notes, Pages, Numbers, Keynote web versions), Apple Music Web Player
• Mobile Application
  • iOS apps like Apple Maps, Apple Music, FaceTime, Messages, Health, Wallet
• AI Application
  • Siri, Photos app (face recognition, image classification), Translate app, Live Text feature
• IoT Application
  • HomeKit (smart home control), Find My network, AirTag tracking, Apple Watch health monitoring

Importance of Software Engineering

• More and more, individuals and society rely on advanced software systems.
  • We need to be able to produce reliable and trustworthy systems economically and quickly.
• It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project.
• For most types of system, the majority of costs are the costs of changing the software after it has gone into use.

Building software without engineering principles is like building a house without blueprints - it might work initially, but any changes or repairs will be expensive and risky.

FAQ - Frequently Asked Questions

Programmer vs Software Engineer

A programmer is like a chef who cooks individual dishes, while a software engineer is like a restaurant manager who plans the entire menu, ensures quality, manages the team, and keeps records of everything.

Essential Attributes of Good Software

Software Process

Definition: A process is a collection of activities, actions and tasks that are performed when some work product is to be created. It is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work to pick and choose the appropriate set of work actions and tasks.

Purpose: To deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it.

Think of a software process like a recipe with flexible steps - you follow the general flow, but adapt based on your ingredients, tools, and who you're cooking for.

Five Main Activities in Software Process

1. Communication
   • Clearly communicate with customer to understand objectives and gather requirements
   • คุยกับ team, คุยกับ user
2. Planning
   • Creates a "map" that defines the work by describing the tasks, risks and resources, work products and work schedule
3. Modeling
   • Create a "sketch" of what it looks like architecturally, how the constituent parts fit together and other characteristics
4. Construction
   • Code generation and testing
5. Deployment
   • Delivered to the customer who evaluates the products and provides feedback based on the evaluation

Like building a house: you communicate with the client about their needs, plan the layout and resources, model it with blueprints, construct it, and finally hand over the keys.

Good Software Process Helps...

Complement the five process framework activities and help team manage and control progress, quality, change, and risk.

• Software project planning, tracking and control: Plan and assess progress against the plan and take actions to maintain the schedule
• Risk management: Assesses risks that may affect the outcome and quality
• Software quality assurance: Defines and conducts activities to ensure quality
• Technical reviews: Assesses work products to uncover and remove errors before going to the next activity
• Measurement: Define and collect process, project, and product measures to ensure stakeholder's needs are met
• Software configuration management: Manage the effects of change throughout the software process and do version controls
• Reusability management: Defines criteria for work product reuse and establishes mechanism to achieve reusable components
• Work product preparation and production: Create work products such as models, documents, logs, forms and lists

Agile and Adaptable Process

The process should be agile and adaptable to problems. Process adopted for one project might be significantly different than a process adopted for another project (to the problem, the project, the team, organizational culture).

• Among the differences are:
  • The overall flow of activities, actions, and tasks and the interdependencies among them
  • The overall degree of detail and rigor with which the process is described
  • The degree to which the customer and other stakeholders are involved with the project
  • The degree to which actions and tasks are defined within each framework activity
  • The degree to which work products are identified and required
  • The degree to which quality assurance activities are applied
  • The manner in which project tracking and control activities are applied
  • The level of autonomy given to the software team
  • The degree to which team organization and roles are prescribed

Like choosing between agile scrum for a startup app vs waterfall for a NASA rocket system - same core activities, vastly different execution.

The Essence of Practice

How does the practice of software engineering fit in the process activities mentioned previously? (Communication, planning, modeling, construction and deployment)

• The essence of problem solving suggests:
  1. Understand the problem (communication and analysis)
  2. Plan a solution (modeling and software design)
  3. Carry out the plan (code generation)
  4. Examine the result for accuracy (testing and quality assurance)

Understand the Problem

ตอนจะทำ Project มาตอบคำถามพวกนี้ก่อน - PCS

Key Questions:

• Who has a stake in the solution to the problem?
  • Who are the stakeholders?
    • Example: Library
      • User Group: Student
      • Other Stakeholders: Librarians, Head of the Library
  • What are the roles of users and their accessibility?
• What are the unknowns?
  • What data, functions, and features are required to properly solve the problem?
  • How to obtain those data?
• Can the problem be compartmentalized?
  • Is it possible to represent smaller problems that may be easier to understand?
  • Can we break down a complex system into smaller modules?
• Can the problem be represented graphically?
  • We can model a workflow or a mockup UI to confirm the understanding of the problem and how to solve it

Before building a house, you need to know: Who will live there? What rooms do they need? Can we design it floor by floor? Can we sketch it first?

Plan the Solution

Key Questions:

• Have you seen similar problems before?
  • Are there patterns that are recognizable in a potential solution?
  • Is there existing software that implements the data, functions, and features that are required?
• Has a similar problem been solved?
  • If so, are elements of the solution reusable?
• Can subproblems be defined?
  • If so, are solutions readily apparent for the subproblems?
• Can you represent a solution in a manner that leads to effective implementation?
  • Can a design model be created?

Like planning a road trip: Have you been on similar routes? Can you reuse parts of old itineraries? Can you break the journey into manageable segments?

Carry Out the Plan

Key Questions:

• Does the solution conform to the plan?
  • Is source code traceable to the design model?
• Is each component part of the solution provably correct?
  • Has the design and code been reviewed or tested thoroughly?

During construction, constantly check: Are we building according to the blueprint? Is each wall sturdy and properly built?

Examine the Result

Key Questions:

• Is it possible to test each component part of the solution?

  • Has a reasonable testing strategy been implemented?

• Does the solution produce results that conform to the data, functions, and features that are required?

  • Has the software been validated against all stakeholder requirements?

After building the house, test everything: Do all doors open? Do lights work? Does it meet the owner's original requirements?

Hooker's General Principles for Software Engineering Practice

Help you establish mind-set for solid software engineering practice (David Hooker 1996).

1. The Reason It All Exists: Provide value to users

2. KISS (Keep It Simple, Stupid!): As simple as possible

3. Maintain the Vision: Otherwise, incompatible design

4. What You Produce, Others Will Consume: Code with concern for those that must maintain and extend the system

5. Be Open to the Future: Never design yourself into a corner as specification and hardware changes

6. Plan Ahead for Reuse

7. Think!: Place clear complete thought before action produces better results

Software Myths Examples

Myth 1

Myth: Once we write the program and get it to work, our job is done.

Reality: The sooner you begin writing code, the longer it will take you to get done. 60% to 80% of all efforts are spent after software is delivered to the customer for the first time.

Myth 2

Myth: Until I get the program running, I have no way of assessing its quality.

Reality: Technical reviews are a quality filter that can be used to find certain classes of software defects from the inception of a project.

Myth 3

Myth: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down.

Reality: It is not about creating documents. It is about creating a quality product. Better quality leads to reduced rework. Reduced work results in faster delivery times.

Key Challenges Facing Software Engineering

Three Main Challenges: Heterogeneity, Delivery and Trust

1. Heterogeneity

   • Developing techniques for building software that can cope with heterogeneous platforms and execution environments

2. Delivery

   • Developing techniques that lead to faster delivery of software

3. Trust

   • Developing techniques that demonstrate that software can be trusted by its users

Professional and Ethical Responsibility

• Software engineering involves wider responsibilities than simply the application of technical skills
• Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals
• Ethical behaviour is more than simply upholding the law

Issues of Professional Responsibility

Confidentiality

• Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed
• Non-Disclosure Agreement (NDA) is usually required

Competence

• Engineers should not misrepresent their level of competence
• They should not knowingly accept work which is outside their competence

Intellectual Property Rights

• Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc.
• They should be careful to ensure that the intellectual property of employers and clients is protected

Computer Misuse

• Software engineers should not use their technical skills to misuse other people's computers
• Computer misuse ranges from relatively trivial (game playing on an employer's machine) to extremely serious (dissemination of viruses)

IEEE Code of Ethics

The professional societies in the US have cooperated to produce a code of ethical practice. Members of these organizations sign up to the code of practice when they join.

The Code contains ten principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession.

The Ten Principles:

1. To hold paramount the safety, health, and welfare of the public, to strive to comply with ethical design and sustainable development practices, to protect the privacy of others, and to disclose promptly factors that might endanger the public or the environment
   • วิศวกรซอฟต์แวร์พบว่าแอป health-tracking เก็บข้อมูลผู้ใช้โดยไม่เข้ารหัส → รีบแจ้งทีมและหยุด deploy แม้จะกระทบ deadline
2. To improve the understanding by individuals and society of the capabilities and societal implications of conventional and emerging technologies, including intelligent systems
   • ไม่ขายฝันเกินจริง
3. To avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist
4. To avoid unlawful conduct in professional activities, and to reject bribery in all its forms
5. To seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, to be honest and realistic in stating claims or estimates based on available data, and to credit properly the contributions of others
   • Engineer ที่ดี = กล้ายอมรับ error
6. To maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations
   • Dev junior ถูกขอให้ implement cryptography → บอกตรง ๆ ว่ายังไม่เชี่ยวชาญ และขอ senior review
   • ไม่มั่ว ถ้าไม่ชัวร์
7. To treat all persons fairly and with respect, and to not engage in discrimination based on characteristics such as race, religion, gender, disability, age, national origin, sexual orientation, gender identity, or gender expression
8. To not engage in harassment of any kind, including sexual harassment or bullying behavior
9. To avoid injuring others, their property, reputation, or employment by false or malicious actions, rumors or any other verbal or physical abuses
10. To support colleagues and co-workers in following this code of ethics, to strive to ensure the code is upheld, and to not retaliate against individuals reporting a violation

Software Engineering Code of Ethics and Professional Practice (ACM)

Short Version - Eight Principles:

Principle 1: PUBLIC

Software engineers shall act consistently with the public interest.

Principle 2: CLIENT AND EMPLOYER

Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

Principle 3: PRODUCT

Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

Principle 4: JUDGMENT

Software engineers shall maintain integrity and independence in their professional judgment.

Principle 5: MANAGEMENT

Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

Principle 6: PROFESSION

Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

Principle 7: COLLEAGUES

Software engineers shall be fair to and supportive of their colleagues.

Principle 8: SELF

Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Detailed Ethical Principles

Principle 1: Products

• 1.01 Ensure adequate software specification
• 1.02 Understand specifications fully
• 1.03 Ensure you are suitably qualified
• 1.04 Ensure all goals are achievable
• 1.05 Ensure proper methodology use
• 1.06 Ensure good project management
• 1.07 Ensure all estimates are realistic
• 1.08 Ensure adequate documentation
• 1.09 Ensure adequate testing and debugging
• 1.10 Promote privacy of individuals
• 1.11 Use data legitimately
• 1.12 Delete outdated and flawed data
• 1.13 Identify and address contentious issues
• 1.14 Promote maximum quality and minimum cost
• 1.15 Follow appropriate industry standards

Principle 2: Public

• 2.01 Disclose any software-related dangers
• 2.02 Approve only safe, well tested software
• 2.03 Only sign documents in area of competence
• 2.04 Cooperate on matters of public concern
• 2.05 Produce software that respects diversity
• 2.06 Be fair and truthful in all matters
• 2.07 Always put the public's interests first
• 2.08 Donate professional skills to good causes
• 2.10 Accept responsibility for your own work

Principle 3: Judgement

• 3.01 Maintain professional objectivity
• 3.02 Only sign documents within your responsibility
• 3.03 Reject bribery
• 3.04 Do not accept secret payments from the client
• 3.05 Accept payment from only one source for a job
• 3.06 Disclose conflicts of interest
• 3.07 Avoid conflicting financial interests
• 3.08 Temper technology judgments with ethics

Principle 4: Client and Employer

• 4.01 Provide services only where competent
• 4.02 Ensure resources are authentically approved
• 4.03 Only use property as authorized by the owner
• 4.04 Do not use illegally obtained software
• 4.05 Honor confidentiality of information
• 4.06 Raise matters of social concern
• 4.07 Inform when a project becomes problematic
• 4.08 Accept no detrimental outside work
• 4.09 Represent no interests adverse to your employer

Principle 5: Management

• 5.01 Assure standards are known by employees
• 5.02 Assure knowledge of confidentiality protocols
• 5.03 Assign work according to competence
• 5.04 Provide due process for code violations
• 5.05 Develop fair ownership agreements
• 5.06 Accurately describe conditions of employment
• 5.07 Offer only fair and just remuneration
• 5.08 Do not prevent a subordinate's promotion
• 5.09 Do not ask a person to breach this code

Principle 6: Profession

• 6.01 Associate with reputable people
• 6.02 Promote commitment of this code
• 6.03 Support followers of this code
• 6.04 Help develop an ethical environment
• 6.05 Report suspected violations of this code
• 6.06 Take responsibility for errors
• 6.07 Only accept appropriate remuneration
• 6.08 Be accurate and honest regarding software
• 6.09 Place professional interests before personal
• 6.10 Obey all laws governing your work
• 6.11 Exercise professional responsibility
• 6.12 Promote public knowledge of the subject
• 6.13 Share software knowledge with the profession

Principle 7: Colleagues

• 7.01 Assist colleagues in professional development
• 7.02 Review other's work only with their consent
• 7.03 Credit fully the work of others
• 7.04 Review others work candidly
• 7.05 Give fair hearing to colleagues
• 7.06 Assist colleagues' awareness of work practices
• 7.08 Do not hinder a colleague's career
• 7.09 Do not pursue a job offered to a colleague
• 7.10 Seek help with work outside your competence

Principle 8: Self

• 8.01 Further your own professional knowledge
• 8.02 Improve your ability to produce quality work
• 8.03 Improve your ability to document work
• 8.04 Improve your understanding of work details
• 8.05 Improve your knowledge of relevant legislation
• 8.06 Improve your knowledge of this code
• 8.07 Do not force anyone to violate this code
• 8.08 Consider code violations inconsistent with software engineering

Summary

Software Engineering is a comprehensive discipline that goes beyond just coding. It encompasses:

• Professional practices for building quality software
• Systematic processes from requirements to deployment
• Ethical responsibilities to society, clients, and colleagues
• Continuous learning and adaptation to new challenges
• Quality focus over quick fixes
• Team collaboration and communication

Remember: Software engineering is like being a professional architect - you need technical skills, ethical principles, clear communication, proper documentation, and a commitment to quality and safety.

Key Takeaways

1. Software engineering ≠ Programming alone
2. 60-80% of costs come AFTER initial delivery (maintenance)
3. Process matters - adapt it to your project needs
4. Ethics and professionalism are fundamental
5. Documentation and testing are not optional
6. Communication is as important as coding
7. Think before you code - planning saves time
8. Quality over speed - doing it right is faster in the long run

End of Lecture 1 Notes