0% found this document useful (0 votes)
2 views16 pages

Introduction

The document outlines the course and instructor policies for Object Oriented Software Engineering, emphasizing attendance, project submission guidelines, and grading criteria. It defines software engineering as a modeling, problem-solving, knowledge acquisition, and rationale-driven activity, detailing the importance of models and decision-making processes. Additionally, it covers essential concepts such as projects, roles, work products, and methodologies used in software development.

Uploaded by

e.yob.9h
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views16 pages

Introduction

The document outlines the course and instructor policies for Object Oriented Software Engineering, emphasizing attendance, project submission guidelines, and grading criteria. It defines software engineering as a modeling, problem-solving, knowledge acquisition, and rationale-driven activity, detailing the importance of models and decision-making processes. Additionally, it covers essential concepts such as projects, roles, work products, and methodologies used in software development.

Uploaded by

e.yob.9h
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Object Oriented Software

Engineering
Course & Instructor Policies

• You are expected to attend class. More than 25% absence will
result in repeating the course
• Entrance is not allowed after 5 minutes of class starting time
• Project deliverables should be submitted through online platform.
• Late work (for projects) will be penalized 10% per day and given a
zero after 5 days.
• Computers should NOT be used in the classroom during sessions.
Grading policy

• Mid-term exam – (30%)


• Project(UML Design)- (20%)
• Final Exam – (50%)
• Part 1
• Introduction to software engineering
• Modeling using UML
• Project Organization and communication
• Part 2
• Dealing with Complexity –requirement, analysis, design, testing
• Part 3
• Managing change
What Is Software Engineering?

• Software engineering is a modeling activity.


• Software engineering is a problem-solving activity.
• Software engineering is a knowledge acquisition activity
• Software engineering is a rationale-driven activity
Modeling Activity

• Software engineers deal with complexity through modeling, by


focusing at any one time on only the relevant details and ignoring
everything else

• In the course of development, software engineers build many


different models of the system and
of the application domain.
Problem-solving activity

• Models are used to search for an acceptable solution


• This search is driven by experimentation.
• Software engineers do not have infinite resources and are constrained
by budget and deadlines
• Given the lack of a fundamental theory, they often have to rely on
empirical methods to evaluate the benefits of different alternatives.
knowledge acquisition activity

• In modeling the application and solution domain, software engineers


collect data, organize it into information, and formalize it into
knowledge.
• Knowledge acquisition is not sequential, as a single piece of additional
data can invalidate complete models.
Rationale-driven activity.

• When acquiring knowledge and making decisions about the system or


its application domain, software engineers also need to capture the
context in which decisions were made and the rationale behind these
decisions.
• Rationale information, represented as a set of issue models, enables
software engineers to understand the implication of a proposed
change when revisiting a decision.
Software Engineering Concepts
• Project
• Activities
• Tasks
• WorkProduct
• System, Model, Document
Participants and Roles

• Persons involved in the project as participants


• Responsibilities in the project or the system as a role
• A role is associated with a set of tasks and is assigned to a
participant.
Systems and Models

• What is a system?
• What is model and modeling ?
• Relation between the two
Work Products

• A work product is an artifact that is produced during the


development, such as a document or a piece of software for other
developers or for the client.
• A work product for the project’s internal consumption as an internal
work product.
• A work product that must be delivered to a client as a deliverable
Activities, Tasks, and Resources

• An activity is a set of tasks that is performed toward a specific


purpose
• A task represents an atomic unit of work that can be managed: A
manager assigns it to a developer, the developer carries it out, and
the manager monitors the progress and completion of the task
• Resources are assets that are used to accomplish work
Notations, Methods, and Methodologies

• A notation is a graphical or textual set of rules for representing a


model
• A method is a repeatable technique that specifies the steps
involved in solving a specific problem
• A methodology is a collection of methods for solving a class of
problems and specifies how and when each method should be
used

You might also like