CSCE 240 – Intro to Software Engineering Lecture 2

Quote of the Day “Relativity applies to physics, not ethics.” -Albert Einstein

Overview Finish Chapter 1 Begin Chapter 2 Discuss Homework 1

Software Engineering code of ethics(IEEE) Software Engineers shall: Act consistently with the public interest Act in the best interests of their client or employer as long as this is consistent with the public interest Develop and maintain their product to the highest standards possible

SE code of ethics(continued) Maintain integrity and independence when making professional judgments. Promote an ethical approach in management. Advance the integrity and reputation of the profession as long as doing so is with the public interest.

SE code of ethics(continued again) Be fair and supportive of colleagues. Participate in lifelong learning

Types of SE Projects Evolutionary projects – modifying an existing system(maintenance/upgrade) Corrective – fix defects (patches). Adaptive – modifying system to account for changes in its environment(moving from win2k to XP). Enhancement – adding new features Re-engineering – fine tuning the internal workings of the system without changing the features.

Types of SE Projects (continued) “Green field projects” – projects build from scratch with no other system to build on or modify(starting fresh). Component/Framework project – build from existing components which are assembled and modified to the needs of the current project(Lego blocks). Very reuse friendly.

SE project activities Requirements and Specification (What) Design (How) Modeling Programming Quality Assurance (Testing) Deployment Management of Design Process Maintenance

Requirements and Specification Domain Analysis – understand background to better understand problem. Define Problem – detail exact problem(s) to solve with system. Requirements Gathering – get all stakeholders ideas about what the system should do.

Requirements and Specification(continued) Requirements Analysis – organize all requirements gathered in an ordered fashion then decide what software should do. Requirements Specification – produce a precise set of requirements for what the software system SHALL do. (no implementation details included).

Design Systems Engineering – hardware vs. software implementation. Software Architecture – how software is organized and how the various parts (subsystems) interact. Detailed Design – detail how to construction of subsystems User Interface Design – detail how user interacts with system. Data Storage – how data is managed/stored by system.

Modeling Use case modeling (Use case diagrams) Structural modeling (Class Diagrams) Dynamic and behavioral modeling (State/Sequence diagrams)

Quality Assurance Reviews and Inspections – frequent evaluation of designs or code to assure customers requirements are being met. Testing – testing software to assure it behaves as intended.

Quality Assurance (continued) Verification – are the requirements being met? Validation – does the software system solve the customers problem?

Management Estimating Cost Planning – managing people involved in project to avoid wasted or duplicated effort.

SE Problems and Risks Complexity – software systems tend to be complex. Poor understanding of the problem, feature creep and gold plating all contribute to this problem. Technology changes rapidly – computers tend to evolve quickly and systems can often be based upon untried technologies.

SE Problems and Risks (continued) Does software actually match customers needs – never sure until software is delivered. Try to understand problem domain as well as possible. Taking on a job not properly qualified or staffed for – SE firms are intended to make money. This desire for profit can lead to over extending of resources.

SE Problems and Risks (continued) Requirements and Technology always change – carefully document changes and try to manage any risks associated with these changes. Politics – any industry involving people will have people not happy with systems, or who have ulterior motives for wanting to see a software project succeed or fail.

Chapter 2 Object Orientation

What is the object oriented paradigm? “It is an approach to the solution of problems in which all computations are performed in the context of objects. The objects are instances of programming constructs, normally called classes, which are data abstractions and which contain procedural abstraction abstractions that operate on objects.”

Procedural vs. OO

Objects + Classes Object – “A chunk of structured data in a running software system” – also – an instance of a class Class – “A unit of data abstraction in an O-O program.” – also – a set of objects with the same behavior and properties.

Classes Contain: Attributes – data stored within class (variables) Methods – procedures which implement behavior in classes.

Object or Class Fruit? Apple? Food? Dog? Cat? Pet? Animal?

Reading for Next time Read Chapter 2

For next time Finish Chapter 2 on objects and classes Very very brief look at some UML If time permits, begin chapter 3 on reuse.