Software Engineering Overview
Software engineering plays a crucial role in today's technology-driven world. This field involves applying engineering principles to develop reliable and efficient software solutions for real-world problems. With examples showcasing the importance of software quality and impact on various sectors, the essence of software engineering is highlighted. The definition, context, and perspectives of software engineering are explored, emphasizing the significance of planning, documentation, agility, and iteration in the software development process.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Introduction to Software Engineering
Why Study Software Engineering An air traffic controller, relying on information from his computer console, directs two Boeing 747's onto intersecting paths. The jets collide and burst into flame, and all aboard perish. -- Washington Post "Software Gone Awry", Scientific American, October 1996 --Investigators appointed by the European Space Agency reported in July that a software bug brought down the new $8-billion Ariane 5 rocket. A hospital minicomputer, monitoring a patient recovering from surgery, fails to alert hospital staff that the patient is having a stroke. The patient dies. -- Washington Post "Computer bug bites Alberta exchange", Calgary Herald, October 24, 1996 -- The Alberta Stock Exchange crashed at 7:38 a.m. Wednesday, brought down by a glitch in its new, fully computerized trading system. A company dicovers that its computer has mangled valuable and sensitive information beyond recovery. The loss gravely weakens the company's market position. -- Washington Post Also see http://www5.in.tum.de/~huckle/bugse.html
Why Study Software Engineering ESaaS Mooc video Introduction to Software Egineering
1. The Context of Software Engineering Science Engineering Software Engineering Computer Science
What is Engineering The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is appliedwith judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind -- Accreditation Board for Engineering and Technology, 1996
What is Software Engineering? Plan and Document Perspective: Software engineering (SE) is "the establishment and use of sound engineering principles in order to obtain, economically, software that is reliable and works efficiently on real machines" [Fritz Bauer at the seminal conference on SE, 1969] SE is about applying computer science to real- world problems
What is Software Engineering? Agile / Iterative Perspective: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan [The Agile Manifesto - http://agilemanifesto.org] While there is value in the items on the right, we value the items on the left more. SE is as much craft as it is sceince/engineering
2. Activities of Software Engineering defining the software development process to be used (ch.1) managing the development project (ch.2 and throughput) describing the intended software product (ch. 3,4) designing the product (ch.5, 6) implementing (programming) the product (ch. 7) testing the parts of the product (ch. 8) integrating the parts and testing them as a whole (ch. 9) maintaining the product (ch. 10) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The One Week Project Sat: Martin asks Nick about developing a web-based Time Management Tool for project team members. Sun: Nick develops business case (value) and preliminary plan to sell to Martin architecture by Tues, then go/no-go Mon: Nick develops problem statement, vision of system, risk list, project plan, sense of value and cost. Tue: Nick develops prototype in AM, meets with Martin for lunch to review all artifacts and update requiremenst. Go/No-go decision. Develop use cases and test in PM. Wed: Nick designs, codes and tests iteration 1 and 2. User Dan provides feedback on iteration 1. New req. added Thur: Nick designs, codes and tests iteration 3. Version control tool and bug list used to manage growing code. New req. added. Capacity tests. Fri: Beta version installed on some of Martin s team computers in AM. Users find bugs. New release created in PM. First Alpha version created on CD in evening.
Highlights of the Project Fully understand users needs, and convey developer needs (greatest ask of user?) Develop business case Assess risks and mitigate: Technical Business What did Nick use to mitigate risk? Develop core architecture Develop test cases that matched requirements Stay on top of the job discipline, document Use version control to backup software changes Write important stuff down and share it
The Four P s of Software Engineering * People (by whom it is done) * Symbology from [Ja1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Four P s of Software Engineering Unified Process Matrix * Jacobson et al: USDP Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. .. .. Requirements Process (the manner in which it is done) People Analysis Design Implemen- tation Test (by whom it is done) * Symbology from [Ja1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Four P s of Software Engineering Unified Process Matrix * Jacobson et al: USDP Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. .. .. Requirements Process (the manner in which it is done) People Analysis Design Implemen- tation Test (by whom it is done) Project (the doing of it) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
The Four P s of Software Engineering Unified Process Matrix * Jacobson et al: USDP Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. .. .. Requirements Process (the manner in which it is done) People Analysis Design Implemen- tation Test (by whom it is done) Project Product (the doing of it) (the application artifacts) * Symbology from [Ja1]; explained in chapter 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Process Set of activities carried out to produce one or more artifacts
Set of activities carried out to produce an application Process Development sequence: Waterfall Iterative Process frameworks: Personal Software ProcessSM Team Software ProcessSM Capability Maturity ModelSM -- for organizations Standards: Institute of Electrical and Electronic Engineers (IEEE) International Standards Organization (ISO) Canadian Information Processing Society (CIPS) Unified Process Matrix Jacobson et al: USDP Inception Elaboration Construction Transition Prelim. iterations Iter. #1 Iter. #n Iter. #n+1 Iter. #m Iter. #m+1 Iter. #k .. .. .. Requirements Analysis Design Implemen- tation Test Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.
Project Implementation of processes to to produce the desired artifacts
Project people flow of work Set of activities required to to produce the desired artifacts Object Orientation: very useful paradigm Unified Modeling Language: design notation Legacy systems: common starting point replacement of, enhancement or addition to existing system Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
4. People The most challenging part of any project
People A small software project can be done by one person Medium/large software projects require a team Interactions between people necessary, but difficult Managers, analysts, programmers, testers, users, customers We will learn certain skills Project Management Effective Meetings Presentations Pair-programming Technical documentation Technical Reviews Your project work will provide practical hand-on experience
5. Product The software application and associated project artifacts
Product -- the application and associated artifacts, including: Artifacts Software Requirements Specification Requirements Specifies what the product must do Software architecture Single user, network centric, database? Detailed design Describes how the product will work Implementation Emphasizes standards Employs selected coding methods Test artifacts Design model Source & object code Test procedures; test cases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Quality A software application must satisfy a predetermined level of quality
Methods to attain desired level of quality Inspection team-oriented process for ensuring quality applied to all stages of the process Paired programming creates more readable, better commented code Formal methods mathematical checks to ensure programs do what they are meant to do Testing at the unit (component) level, integration level at the whole application level Project control techniques predict costs and schedule control artifacts (versions, scope etc. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Professional and Ethical responsibility SE involves wider responsibilities than simply the application of technical skills SEs must behave in an honest and ethically responsible way if they are to be respected as professionals Ethical behaviour should be > legal responsibility: Confidentiality - respect the confidentiality and intellectual property of their employers or clients Competence - do not misrepresent level of competence or accept work beyond ability to deliver
Ethical dilemmas you may encounter Disagreement in principle with the policies of senior management Your employer acts in an unethical way and releases a safety-critical system without finishing the testing of the system Participation in the development of components for military weapons or biogenetic systems
ACM/IEEE Code of Ethics Eight 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. Preamble Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shalladhere to the following Eight Principles:
ACM/IEEE Code of ethics - principles 1. PUBLIC - Software engineers shall act consistently with the public interest. 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. 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT- Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 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.
Decide Initial Team Issues One way to ... 0. Set the meeting agenda and time limits. (see ch.1, 2) 1. Choose the team leader. 2. Decide how the team will communicate. 3. Identify the customer 4. Get an understanding of the project in general terms - don t be embarrassed; if project seems too vague, probe until you are comfortable. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Set Team Expectations One way to ... 1. Get everyone s commitment to taking required time Define an expected average number of hours per week Gather dates of planned absences If not forthcoming - alert management, inform instructor; implement written mutual evaluations 2. Choose team emphasis: accomplishment / learning Accomplishment (capable product): get a good mix of leadership, technical, writing, customer relations Learning: sacrifice accomplishment by allowing members to experience new activities. Understand manager s / instructor s emphasis. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Specify How the Team Will Communicate One way to ... 1. General policy: if in doubt, communicate. Redundancy is OK! 2. Meeting: The team will meet each Wednesday from 8 a.m. to 10 a.m. in room 671, unless notified of a change. 3. Meeting alternative: Team members should keep Mondays 4 to 6pm open in case an additional meeting is required. 4. Standards: The word processing used will be MS Word. 5. Preferred mode of electronic communication: Unless a communication is of very limited interest to the group, it should be posted to the group site, axe.acadiau.ca with notification to all members. 6. Alternative mode of electronic communication: For 1-1 communication of very limited group interest, members will use MSN and/or telephone. 7. Acknowledgement: Team members should acknowledge all electronic communication specifically targeted to them, whether asked to acknowledge or not. Senders should follow up on all significant communication that is not acknowledged. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Sample Encounter Screen kitchen COURTYARD living room dressing room Get status Set qualities Graphics reproduced with permission from Corel. End game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
User Interface for Setting Quality Values Shawn Current life points: 100.0 Choose the quality you wish to set Choose the value of the quality selected 16.3 image Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
User Interface for Setting Quality Values Choose the value of the quality selected Shawn Current life points: 100.0 Image Choose the quality you wish to set 16.3 Explanation The values of the qualities not specifically chosen remain in the same proportion to each other. Values less than 1.0 are counted as zero. E.g., before: strength = 10.0, endurance = 60.0, intelligence = 30.0, patience = 0.0 (current life points 10.0 + 60.0 + 30.0 + 0 = 100.0) change: strength from 10.0 to 20.0 after: strength = 20, endurance = 53.33, intelligence = 26.66 OK Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Engage Foreign Character Use Case Details of use case Encounter 1. System displays the foreign character in the same area as the player s. 2. System exchanges data between the two characters. 3. System displays the results of the engagement in a message window. 4. Player dismisses window. Initialize player Actor (agency external to the applicati on) Engage foreign character Name of use case . . . . Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FrameWork / Application Dependency Role-playing game layer Encounter video game layer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
FrameWork / Application Dependency Characters GameEnvironment RolePlayingGame uses Role-playing game layer (framework) Encounter video game layer EncounterGame uses * uses EncounterCast EncounterGame EncounterCharacters EncounterEnvironment * by member classes implemen- ting framework interfaces EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
