Software Engineering. How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000.

Slides:



Advertisements
Similar presentations
Prescriptive Process models
Advertisements

2003 Mateusz Żochowski, Marcin Borzymek Software Life Cycle Analysis.
Computer Science Department
1 Software Processes A Software process is a set of activities and associated results which lead to the production of a software product. Activities Common.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Chapter 2 Modeling the Process and Life Cycle Shari L. Pfleeger
CS487 Software Engineering Omar Aldawud
The software process A software process is a set of activities and associated results which lead to the production of a software product. This may involve.
Modeling the Process and Life Cycle CSCI 411 Advanced Database and Project Management Monday, February 2, 2015.
Introduction to Software Engineering Lecture 3 André van der Hoek.
Software Life Cycles ECE 417/617: Elements of Software Engineering
Software Engineering.
Introduction to Software Engineering Dr. Basem Alkazemi
Object-oriented Analysis and Design
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Software lifecycle. CS351 - Software Engineering (AY2004)2 Software lifecycle “student view” Design & Specification Coding Testing (optional) Hand it.
Iterative development and The Unified process
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
Diane Pozefsky. 1960’s  60’s “Cowboys” wrote software anyway that they could Difference between best programmers and worst as high as 28:1 (many sources)
CIS 321—IS Analysis & Design
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
1 CSE 403 Software Lifecycle Models Reading: Rapid Development Ch. 7, 25 (further reading: Ch. 21, 35, 36, 20) These lecture slides are copyright (C) Marty.
Chapter 2 The process Process, Methods, and Tools
Software Process and Models
THE PROTOTYPING MODEL The prototyping model begins with requirements gathering. Developer and customer meet and define the overall objectives for the software.
Lecture # 04 & 05 CS314 Introduction To Software Development Software Development Process (SDP) Instructor :Muhammad Janas khan
Software Project Failure Software Project Failure Night Two, Part One CSCI 521 Software Project Management.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Unified Process versus Extreme Programming. Outline Compare and contrast UP and XP  Processes / Disciplines  Management  Artefacts Risk management.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Capability Maturity Models Software Engineering Institute (supported by DoD) The problems of software development are mainly caused by poor process management.
Software Engineering Management Lecture 1 The Software Process.
10 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser
Software Life Cycle Models. Waterfall Model  The Waterfall Model is the earliest method of structured system development.  The original waterfall model.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
13-January-2003cse LifeCycle © 2003 University of Washington1 Lifecycle CSE 403, Winter 2003 Software Engineering
Introduction to Systems Analysis and Design
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
September 10, 2009COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
Software Engineering Lecture # 1.
September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser
Software Development Life Cycle (SDLC)
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Software Development Life Cycle (SDLC)
Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project.
By : Hisham Kahlifa Shreef Foda Khaled monir Tamer medhat Supervisor : Dr Doaa Nabil.
CS 4500: Software Development Software Process. Materials Sommmerville Chapters 1, 2 and 3 Software Cycle and Models:
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Industrial Software Development Process Bashar Ahmad RISC Software GmbH.
Review of Definitions Software life cycle: –Set of activities and their relationships to each other to support the development of a software system Software.
Chapter 2- Software Development Process  Product Components  Software Project Staff  Software Development Lifecycle Models.
SOFTWARE DEVELOPMENT Presented By : Emporiumtech This presentation is brought you by
Software Development - Methodologies
Object-oriented Analysis and Design
Methodologies and Algorithms
SNS College of Engineering Coimbatore
Chapter 2 SW Process Models
Introduction to Software Engineering
Software Lifecycle Models
Chapter 2 Software Processes
Chapter 2 – Software Processes
Presentation transcript:

Software Engineering

How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000 lines Microsoft Windows Vista: 50,000,000+ lines

What is Software Engineering? NOT just programming NOT just programming [part of] a large software system NOT just programming as a member of a large team

What is Software Engineering? “The practice of creating and maintaining software applications by applying technologies and practices from engineering, computer science, project management, application domains and other fields.” -Wikipedia

Over 50% of software projects fail Fred Brooks : IBM’s OS/360 “was late, took more memory than was planned, costs were several times the estimate, and it did not perform very well until several releases after the first”

Why do software projects fail? Difficult to accurately estimate how long something will take

Why do software projects fail? Developers typically overestimate/overstate their productivity

Why do software projects fail? Requirements are not always clearly defined

Why do software projects fail? Requirements are not always realistic

Why do software projects fail? Requirements are always changing

Software development = tradeoffs Cost vs Scope vs Quality vs Time Security vs Performance Specialization vs Generalization Specificity vs Flexibility

Software Engineering Processes: –Project management (resources, time, etc.) –Requirements gathering & management –Software design & architecture –Software development –Testing and quality assurance Tools: –Software design, development, and testing –Communication –Requirements and defect tracking –Version control

Why Study Software Engineering? Writing a program is easy –Program = code (possibly with comments) Developing a software system is harder –System = program plus technical documentation sufficient such that someone other than original developers can maintain, typically involving environmental interoperation (beyond just UI and file system) Developing a software product is very hard –Product = system plus customers, fulfilling the business needs of those customers, with customer- oriented documentation and support

Why Study Software Engineering? Software Engineering aims at supporting the development of high-quality software products –High-quality software products are more robust, efficient and effective –High-quality software products are easier to use, understand, modify, and compose with other high-quality software products

But I just want to learn Java!!!

Software Engineering is still important! “Software Engineers” aren’t the only ones who should know about software engineering Creating high-quality software is necessary in any case in which you or someone else will need to maintain and/or modify your code

Software Engineering Activities System Engineering Process Selection and Training Requirements –Eliciting –Analysis –Recording Technology Selection and Training Design –Architecture –Components –Modules Coding –Unit Testing –Debugging Integration –Build –Integration Testing –Configuration Management System Testing –Performance Testing & Optimization –Acceptance Testing –Beta Testing Deployment –Delivery –Installation Operations –System Management –Maintenance –Upgrades Support Activities –Project Planning and Tracking –Customer Interaction –Process Improvement –Training –Documentation –Personnel Management

In the Beginning…

Build First Version Retirement Operations Modify until Customer satisfied Code-and-Fix

Discussion of Code-and-Fix Really Bad Really Common Advantages –No Overhead –No Expertise Disadvantages –No means of assessing progress –Difficult to coordinate multiple programmers Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works

Requirements Validate Retirement Operations Test Implementation Verify Design Waterfall

More Detailed Waterfall REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

Discussion of Waterfall Articulated by Win Royce, ~1970 Widely used today Advantages –Measurable progress –Experience applying steps in past projects can be used in estimating duration of “similar” steps in future projects –Produces software artifacts that can be re-used in other projects The original waterfall model (as interpreted by many) disallowed iteration –Inflexible –Monolithic –Requirements change over time –Maintenance not handled well The “waterfall with feedback” model was, however, what Royce had in mind

Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

Prototyping Initial Concept Complete and Release Prototype Refine Prototype Until Acceptance Design and Implement Initial Prototype

Discussion of Prototyping Mock-ups allow users to visualize an application that hasn't yet been constructed Used to help develop requirements specification –Useful for rapidly changing requirements –Or when customer won’t commit to specification Once requirements “known”, waterfall (or some other process model) used Prototypes discarded once design begins –Prototypes should not be used as a basis for implementation, since prototyping tools do not create production quality code –Customer (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%

Incremental (Staged) Detailed Design, Implement, Test, Deliver Feature Set Requirements Validate Retirement Operations Verify Architectural Design

Discussion of Incremental Iterations are classified according to feature sets –e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next Series of increasingly “complete” releases

The Basic Problem: Risk Some modern approaches view “risk” as the main problem of software development –Schedule slips –Business changes –Staff turnovers –New technologies –…

Spiral Model PLANDEVELOP AND TEST DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES AND RISKS Requirements, life-cycle plan Budget 1 Alternatives 1 Constraints 1 Risk analysis Constraints Budget Alternatives Prototype 1 Proto- type 2 Proto- type 3 Proto- type 4 Concept of operation Software requirements Validated requirements Development plan Integration and test plan Software design Validated, verified design Detailed design Code Unit test System test Acceptance test Implementation plan start

Discussion of Spiral Model Proposed by Barry Boehm, ~1986 Similar to Incremental Model, but each iteration is driven by “risk management” and/or customer feedback Determine objectives and current status Identify risks and priorities Next iteration addresses (current) highest risk and/or highest priority items Repeat

Agile Programming Initial Concept Operations Acceptance Testing and Delivery Requirements and Iteration Planning Next Iteration Design and Implement

Discussion of Agile Each iteration a mini-project –Each iteration’s deliverable is not a prototype, but an operational system –Understand risk vs. business value in planning iterations –Put some working functionality into user’s hands as early as possible Timeboxing: –Set the date for delivering an iteration –Date cannot change –Only functionality (scope) can change –Short duration iterations (weeks, not months)

eXtreme Programming

Created by Kent Beck in late 1990s “Takes best practices to extreme levels” Focuses on five values: –Communication –Simplicity –Feedback –Courage –Respect

What does this mean for me?

Software Engineering in CS1007 The programs you write in this class will graded as much on their “quality” as on their functionality This means that they should be: –Well-designed –Robust and well-tested You need to come up with your own personal “software process” to ensure the quality of the code you write