Software Engineering Lecture 1 ASPI8-4 Anders P. Ravn, Feb 4, 2004.

Slides:



Advertisements
Similar presentations
Software Engineering Implementation Lecture 3 ASPI8-4 Anders P. Ravn, Feb 2004.
Advertisements

Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
Ch 3 System Development Environment
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
CH02: Modeling the process and life cycle Process of developing software (organization and discipline in the activities) contribute to the quality of the.
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Object-Oriented Analysis and Design
Software Engineering Lecture 2 ASPI8-4 Anders P. Ravn, Feb
© 2010 University of California, Irvine – André van der Hoek1June 10, 2015 – 06:18:06 Informatics 121 Software Design I Lecture 10 André van der Hoek &
Software Testing and Quality Assurance
Project Management and Communication Represented by: Latifa Jaber Al-Ghafran.
Lecture 13 Revision IMS Systems Analysis and Design.
Lecture 11: Chapter 22 Topics –Object Oriented Modeling –UML –Use case.
Process ITV Model-based Analysis and Design of Embedded Software Techniques and methods for Critical Software Anders P. Ravn Aalborg University August.
Use cases and requirement specification - 1 Use case diagrams 3 use cases System boundaries Remember: Use case diagramming is a tool, not the requirements.
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
Working on a Project Anders P. Ravn Computer Science Aalborg University April 2007.
© Copyright Eliyahu Brutman Programming Techniques Course.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
6. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain how events can be used to identify use cases that define requirements.
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
Chapter 7: The Object-Oriented Approach to Requirements
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Software Engineering 1 The Life Cicle of Software Lesson 5.
Lesson 7 Guide for Software Design Description (SDD)
Understand Application Lifecycle Management
Introduction to the Unified Modeling Language “The act of drawing a diagram does not constitute analysis or design. … Still, having a well-defined and.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Basic of Project and Project Management Presentation.
Introduction To System Analysis and Design
Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Object Oriented Programming Lecture 9: OO Design.
Software Development Cycle What is Software? Instructions (computer programs) that when executed provide desired function and performance Data structures.
Illustrations and Answers for TDT4252 exam, June
L9 - April 5, 2006copyright Thomas Pole , all rights reserved 1 Lecture 9: Reuse Driven Processes and Text Ch. 7: Programming with Models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Software Architecture and Specification 2 Derived from Dr. Fawcett’s slides Phil Pratt-Szeliga Fall 2009.
Lecture 9-1 : Intro. to UML (Unified Modeling Language)
UML: A notation for capturing work products
Introduction to UML Todd Bacastow Rational Unified Process A process for the effective implementation of key “Best Practices” Control Changes Manage.
Overview of Socio-cognitive Engineering General requirements Theory of Use Design Concept Contextual Studies Task model Design space System specification.
04 - OOD Intro.CSC4071 Software Design ‘Requirements’ defines –The goals the system needs to satisfy. ‘Specification’ defines –The externally-observable.
CONNECTING COMPONENT Pertemuan Matakuliah: M Analisis dan Perancangan Sistem Informasi Lanjut Tahun:
Your Interactive Guide to the Digital World Discovering Computers 2012 Chapter 12 Exploring Information System Development.
Rational Rose For System Design What is Rational Rose? Rational Rose is the visual modeling software solution that lets you create, analyze, design,
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Object Oriented Analysis & Design By Rashid Mahmood.
 System Requirement Specification and System Planning.
The Software Lifecycle Stuart Faulk. Definition Software Life Cycle: evolution of a software development effort from concept to retirement Life Cycle.
Process 4 Hours.
Project management Software development typically includes:
Object-Oriented Analysis and Design
Review for Midterm, Fall 2009
Anders P. Ravn Computer Science Aalborg University April 2007
UML: Unified modeling language
CIS 210 Systems Analysis and Development
University of Houston-Clear Lake
Chapter 20 Object-Oriented Analysis and Design
Software Engineering Lecture #14.
Appendix A Object-Oriented Analysis and Design
Copyright 2007 Oxford Consulting, Ltd
PPT4: Requirement analysis
Remarks on Software Design
Presentation transcript:

Software Engineering Lecture 1 ASPI8-4 Anders P. Ravn, Feb 4, 2004

Overview The development process Documents OAD in Requirements Analysis 1.Problem Domain Analysis 2.System Definition 3.Class, Association, Dependency 4.Behaviour, Event

The project mainstays Journal – Agendas, Minutes, Notes Report – Work Items Schedule – Milestones, Activities

Organization - Players Customer – has the problem and has to be satisfied with the solution Project Team – works to find a solution Boss – defines the resources and monitors progress Consultant – contributes ideas and expertise

Team - roles Designer – develops solutions Integrator (tester) – ensures consistent releases Developer – develops components Documenter – ensures documentation Organizer (planner) – keeps orderly progress

Planning – why bother? Customer expectations Project progress The solution space

Planning – why! To be able to act rationally when – forseeable - events happen. Livet forstås baglæns, men må leves forlæns Søren Kierkegaard

Planning – how? Time Activity Deadline Milestone

Gant Chart Activity A B C …

Pert Diagram A 14 B 7 C 10 D 13 F 7 E 14 G 5 H 6 I 24

Status WP1

Literature (incomplete) Fred. P. Brooks: The Mythical Man-month G. Weinberg: The Psychology of Programming N.E. Andersen, et al.: Professionel Systemudvikling H. Mills: Chief Programmer Teams D. Gibbs: Extreme Programming

A Development Process (V-model) Requirements Spec Accpt. Test Report Acceptance Test Spec Architectural Spec Integr. Test Report Integration Test Spec Module Interface Spec Module Spec Module Test Report Module Test Spec Program Source text A rational Design Process – or how to fake it Heninger & Parnas, 1979

Your Report! 1.Requirements Specification 1.1 System Definition 1.2 Problem Domain Structure 1.3 Application Domain Structure 1.4 Acceptance Test Specification 2.Architecture 3.Modules 4.Implementation 5. Test

Example: Computer Vison based implement guidance in row crops A rich picture

System Definition A concise description of a computerized system expressed in natural language Example: A computer system which guides an implement through crops in rows. The system must not be slower than the traditional guidance methods, and must relieve human operators of local monitoring and control tasks.

Example:The prototype software

FACTOR A concise description of a computerized system expressed in natural language FACTOR: Functionality for end use Application Domain of end use Conditions for success Technology to be used Object System Realization conditions

Example: FACTOR A computer system which guides an implement through crops in rows. (Application Domain). The system must not be slower than traditional guidance methods (Conditions), and must relieve human operators of local monitoring and control tasks (Functionality). The final system must be implemented on a TriMedia TRS8XX with a simple display and button user interface (Technology and Object System) The system shall be very dependable and inexpensive to produce (Realization Constraints).

Problem Domain Description Class Diagrams (things and their relations) Selected Behaviours (events and their sequence) Notes - text (interpretation of concepts )

Example: Problem Domain Structure

Example: Tractor Behaviour Outside row In row ManualAuto start stop

Example: Interaction of Tractor and Row Weeder :Tractor:RowWeeder lower engage no_row

Summary: Problem Domain Analysis Rich Picture System definition - FACTOR Structure - Class Diagrams Behaviour - Statechart Diagrams Interaction - Sequence Diagrams Notes

Your Report - 1! 1.Requirements Specification 1.1 System Definition 1.2 Problem Domain Structure 1.3 Application Domain Structure 1.4 Acceptance Test Specification 2.Architecture 3.Modules 4.Implementation 5. Test

UML Notation Class Object Association Dependency Package

Class and Object Class name attributes methods Object: Class name 1* Association

Superclass Generalization Subclass

Aggregation the whole the part [arity]

Association [name] [arity]

Dependency ”uses”

Package (cluster) related classes > name

Summary: Diagrams Class and Object Generalization Aggregation Association Dependency Package Statechart DiagramStatechart Diagram Sequence DiagramSequence Diagram