CPSC 871 John D. McGregor MSumS2 Summary – technical issues in software engineering.

Slides:



Advertisements
Similar presentations
Software Development Life Cycle
Advertisements

Unit 2. Software Lifecycle
CS487 Software Engineering Omar Aldawud
Chapter 2 – Software Processes
Ch 3 System Development Environment
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Object-Oriented Analysis and Design
Software Testing and Quality Assurance
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
SwE 313 Introduction to Rational Unified Process (RUP)
Copyright  Larry Dribin, Ph.D. SE470_EngFlows_v1.ppt SE470 EngFlows - 1 Excellence in Software Engineering Repeatable Level Defined Level Manage.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Course Instructor: Aisha Azeem
Chapter 1 The Systems Development Environment
Principles of Object Technology Module 1: Principles of Modeling.
CIS 321—IS Analysis & Design
CPSC 871 John D. McGregor Processes – a first iteration Module 1 Session 1.
UML - Development Process 1 Software Development Process Using UML (2)
Free Mini Course: Applying SysML with MagicDraw
CPSC 871 John D. McGregor Module 7 Session 2 Agile Software Development.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
CPSC 871 John D. McGregor Module 1 Session 2 Requirements Elicitation/analysis.
Object Oriented Analysis and Design Introduction.
Rational Unified Process Fundamentals Module 4: Disciplines II.
Chapter 1: Introduction to Systems Analysis and Design
Software Engineering Chapter 8 Fall Analysis Extension of use cases, use cases are converted into a more formal description of the system.Extension.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
What is a life cycle model? Framework under which a software product is going to be developed. – Defines the phases that the product under development.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
CPSC 372 John D. McGregor Process Module 1 Session 1.
CPSC 2150 August 21, Chapter 1 Object Oriented Software Development This is an introductory course In this chapter we will look at 3 topics Challenges.
Software development process ธนวัฒน์ แซ่ เอียบ. The development process Process –set of rules which define how a development project. Methodology and.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Rational Unified Process Mr Hisham AlKhawar. Iterative versus Waterfall  We need to use a life cycle model in order to approach developing a system easily,
1 What is OO Design? OO Design is a process of invention, where developers create the abstractions necessary to meet the system’s requirements OO Design.
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
CSC480 Software Engineering Lecture 8-9 September 20, 2002.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
The principles of an object oriented software development process Week 04 1.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Chapter 2 – Software Processes Lecture 1 1Chapter 2 Software Processes.
Rational Unified Process (RUP)
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
CS223: Software Engineering
Basic Concepts and Definitions
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Viewpoint Modeling and Model-Based Media Generation for Systems Engineers Automatic View and Document Generation for Scalable Model- Based Engineering.
RATIONAL UNIFIED PROCESS PROCESS FRAMEWORK OVERVIEW.
Industrial Software Development Process Bashar Ahmad RISC Software GmbH.
Software Development. The Software Life Cycle Encompasses all activities from initial analysis until obsolescence Analysis of problem or request Analysis.
Wrap up. Structures and views Quality attribute scenarios Achieving quality attributes via tactics Architectural pattern and styles.
 System Requirement Specification and System Planning.
Chapter 2- Software Development Process  Product Components  Software Project Staff  Software Development Lifecycle Models.
1 Process activities. 2 Software specification Software design and implementation Software validation Software evolution.
Software Development.
John D. McGregor Process Module 1 Session 1
Chapter 1: Introduction to Systems Analysis and Design
UML: Unified modeling language
Introduction to Software Engineering
Rational Unified Process
Chapter 1: Introduction to Systems Analysis and Design
Chapter 1: Introduction to Systems Analysis and Design
Presentation transcript:

CPSC 871 John D. McGregor MSumS2 Summary – technical issues in software engineering

Rational Unified Process

Process models Different “shapes” to the schedules and work decomposition Waterfall – one pass; all requirements Spiral – multiple passes; all requirements but prioritized Iterative – multiple passes; a set of requirements Incremental – a subset of requirements

Processes Most of the models don’t have names Agile methods have names because they get publicity – Extreme Programming – Test-driven development – Scrum – … Planned vs agile

Processes My organization uses an iterative, incremental approach A two week cycle time is as fast as we can move and maintain forward progress

Tools Tool captures human thoughts and actions Uses a specific notation – UML, SySML, AADL Most notations provide a means of making notes outside of the notation Used to communicate with humans or other tools

Tools - 2 A workflow is a series of transformations formed by the output of one tool being the input to another tool Used to automate processes Example: Using Ant to build a product the source code might first go to an analyzer to check coding standards and then if OK on to the compiler and then on to …

Tools - 3 Topcased OSATE Eclipse EPF ASCE SONAR Emulators

Comments on tools? Not enough documentation

Practice areas Rather than try to tie down exactly when requirements will be done it is more effective to layout a rough sequence but let the pros go where they need to when they need to A practice area is broader than just a few specific actions

RUP practices

Business modeling We did not spend much time here Domain modeling using UML class diagrams and sequence diagrams or DSLs to describe business rules Entities and relationships Captures business objects and business rules

Requirements Functional – what the system does Non-functional (aka quality attributes) – properties of the system such as reliability Because some non-functional requirements negate others we use a priority scheme to determine which are most important Requirements come from customers, regulatory agencies, ecosystem partners, competitors, our imagination Some requirements are derived from others – usually design requirements

Requirements - 2 Representations – Statements – human language (English, …) statements of what is expected from the system – Use cases – actor/system dialogue shows inputs and processing of those inputs – Feature models – describes high-level features and their interactions with other features Tools – Topcased

Requirements – 3 Requirements are evaluated in several ways – Reviews and inspections By development staff Customers/domain experts – Consistency checks across the requirements model the architecture model – comparison with test cases

Analysis and Design Requirements are analyzed to group them and to begin to relate them to a design Often there is a need for more detail The use cases may be elaborated using sequence diagrams

Analysis and Design - 2 The architecture is created by paying close attention to the non-functional requirements as the groups of functional requirements are allocated to specific machines or processes There is a body of architecture patterns that have been found to enhance particular qualities The architecture team begins with that and with architectures used in similar systems to select a basic “style”

Analysis and Design - 3 The architecture details the structure of the program, behavior of the program and the error propagations through the program. AADL provides ways of expressing both of these Systems represent modules; ports represent inputs and outputs; connections wire outputs to inputs Annexes are small independent languages

Analysis and Design - 4 Usually there will be a designated architect on a project who has architecting and domain experience This person will participate in all phases of the project with emphasis on architecture

Analysis and Design - 5 Model checking is used during this phase to validate the architecture for such issues as deadlock Using advanced algorithms the model checker explores every path in the architecture to verify the truth of claims such as “deadlock free” Model checking can also be used to check code.

Analysis and Design - 6 Resolute – a language for writing constraints for an AADL model check_position (app : component, actuator : component) <= ** "(R2.3) The app (component " app ") and the actuator (component " actuator ") have the same value for the position" ** true

Implementation This activity is receding in importance as more of the code is auto-generated But much is still hand-written Choose languages that fit the job Use DSLs to get domain experts to write some of the code

Test Testing is gaining in importance as programs become more mission and life critical Reviews and inspections can be structured as tests by providing specific questions that the reviewers have to ask AADL and related tools provide means of simulating program execution so the architecture can be tested

Test - 2 The program code is usually tested in three phases Unit testing – developer of a module also develops tests (maybe before the module) and tests the module in isolation Integration testing – a developer who is using the work of several teams creates tests that examine the interactions among the units System testing – the requirements are used to create tests

Test - 3 System testing takes a different perspective Unit testing determines whether a unit does correctly what it does System testing determines whether a program does what it is required to do Some customers will also test a newly acquired product to assure themselves that the product does what they need done.

Deployment A product is delivered to where it will be used in a variety of ways A deployment package includes the required programs; resources such as pictures, different language files; licenses for included products; installation guides An installer may be used to encapsulate all of the above or a simple zip file

Deployment - 2 The software may be shrink wrapped and sold in a store or downloaded from web

Technical management Practices that are not mentioned in the basic RUP diagram include Configuration management which usually includes version control Build management Test data management License management

Comments?

Conclusion Software engineering involves a wide range of activities in several disciplines Business, psychology, economics, … Small specific languages are key I hope you have been able to make connections between topics beyond just what we talk about in class and understand now why certain things are the way they are I hope that you have a deeper appreciation for the variety as well as being able to actually perform some of those activities

Here is what you are going to do Expand the scenario you started in class on Tuesday Address each of the major areas we discussed Tues/Thur with respect to your app Submit this along with the final release of your app by 11:59 pm, Dec 4 th