Download
1 / 23
230 likes | 485 Views
Software Engineering 2. Mark J. Christensen. Software and Society. Presented by: Feras Batarseh. Importance of Software. Pure Software: pharmacy. Software controlled products: braking system. People earn a living from building software. Software by itself.
E N D
Software Engineering 2 Mark J. Christensen Software and Society Presented by: Feras Batarseh
Importance of Software Pure Software: pharmacy. Software controlled products: braking system. People earn a living from building software.
Software by itself The world cannot function as it does, Without software. BUT SW does nothing except moving electrons from one computer to another. Like all eng. Activities it derives importance from the world.
Software by itself 2 SW is the Key enabler, but not the final effecter. Ex. Decision making.
Software Importance SW importance depends on the number of: -Individuals. -Entities that are involved in the process. -Size of the business.
Software impact Software industry and impact are not isolated to one part of the world. SW development and research centers all around the world, with people, Governments and companies involved in the process.
My opinion Software is still limited to a number of places in the world, there is a lot of places that software didn’t reach yet! GUI is a major factor in spreading PC’s around the world, if the user interface wasn’t that friendly, just the specialists would use the computers.
Success is avoiding failure Knowing what doesn’t work and Past SW failures, helps us avoid repeating mistakes. Expect any un expected behavior from the SW if not build on scientific and technical knowledge.
Code of Conduct Short version and Long version. Describes the relation for SW engineer with the surrounding: 1-Society 2-employer 3-work activities and products 4-SW engineering profession
Code of Conduct 2 Engineer is asked to balance between the different sides of the code, as they may conflict sometimes. Ex: Faithfulness to the public and to the employer.
Code of Conduct 3 Short version with 8 points. Long version with 6 to 15 sub points for the 8 points. Available at the IEEE CS and ACM websites.
Law Issues 80% of individuals working for licensed companies are not licensed! They can still work but cannot take major decisions.
Law Issues 2 British and American courts developed rules for such cases. Plaintiff must present expert testimony to proof the deviation from the standards from the defendant engineer. Or proof the design criteria that the product didn’t meet to sue the manufacturer.
Engineer against Manufacturer The engineer doesn’t guarantee the results, his only responsibility is to work in accordance to the standards . The manufacturer must provide a non defected product and is responsible for the results.
Example You are transferred into a new work unit, although their work is legal, you concluded that its not for the public good. What do you do? 1-Leave the job. 2-Continue to work in the business with your best effort. 3-Continue to work and complain to your colleagues and friends about it.
Example cont. 1-you left your job, didn’t benefit your society or your company or even your self. 2-continue your work! You are harming your society. 3-you are dragging down your colleagues morale. In all the cases you are violating the code!
Example cont. In such cases you should balance your action, and do it with your best of honesty and professionalism. By respecting your colleagues judgments, the society and your employer.
My opinion In my opinion, I think the software engineer must contact his employer, to discuss about making the society a priority, without harming the profit of the company.
Colleagues Respect your colleagues. Two main problems (occur frequently): Immaturity. Technical Arrogance.
IEEE IEEE provided standards for working in SW engineering threw all the stages like: -IEEE standard for software test documentation. -IEEE standard for software Maintenance. -IEEE standard for software Unit testing -IEEE standard for software verification and validation. -IEEE standard for software safety plans.
Codes are not Magic Many professions had codes for decades, but problems still occur. Ex: • Doctors make surgical mistakes. • Structural engineers design bridges that fail during storms. So: Codes must provide guidance about what should be done.
Much to do Average user of software is still expecting a great deal of bugs, failures!! Does that mean that we failed? NO! Even if the underlying science is well known, a great deal of work is needed to apply it to domain of engineering. That is the case with all engineering disciplines.
