Introduction To Software Development CSC Spring 2019 Howard Rosenthal

Similar documents
Dilbert Scott Adams. CSc 233 Spring 2012

ITE 205 Software Design and Programming I

System Development Life Cycle Methods/Approaches/Models

SOFTWARE LIFE-CYCLE MODELS 2.1

Introduction to Software Engineering

Introduction to Software Engineering (ESE : Einführung in SE) Prof. O. Nierstrasz

Generic Collections CSC Spring 2019 Howard Rosenthal

OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis

CSC Advanced Object Oriented Programming, Spring Overview

Examples. Object Orientated Analysis and Design. Benjamin Kenwright

Adopting Agile Practices

Topic 01. Software Engineering, Web Engineering, agile methodologies.

Lecture 7: Software Processes. Refresher: Software Always Evolves

Modern Software Engineering Methodologies Meet Data Warehouse Design: 4WD

Systems Analysis and Design in a Changing World, Fourth Edition

Software Engineering Lifecycles. Controlling Complexity

CS487 Midterm Exam Summer 2005

Incremental development A.Y. 2018/2019

Lecture 2: Software Engineering (a review)

Level: M.Ed. Credit Hour: 3 (2+1) Semester: Second Teaching Hour: 80(32+48)

Testing in Agile Software Development

Inheritance CSC 123 Fall 2018 Howard Rosenthal

User-Centered Development

Testing in the Agile World

Introduction To Programming Using Java: An Object- Oriented Approach (2nd Edition) By David Arnow, Scott Dexter

Introduction to Software Engineering (ESE : Einführung in SE)

Optimize tomorrow today.

Software Development Methodologies

CS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS

Process of Interaction Design and Design Languages

*ANSWERS * **********************************

Designed in collaboration with Infosys Limited

Administrivia. Added 20 more so far. Software Process. Only one TA so far. CS169 Lecture 2. Start thinking about project proposal

Approaches for Auditing Software Vendors

The Design Space of Software Development Methodologies

Applying ISO/IEC Quality Model to Quality Requirements Engineering on Critical Software

UNIT-I Introduction of Object Oriented Modeling

THE OBJECT-ORIENTED DESIGN PROCESS AND DESIGN AXIOMS (CH -9)

A STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN

Software Development Process Models

Software Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution

Object-Oriented Systems Development: Using the Unified Modeling Language

How Can a Tester Cope With the Fast Paced Iterative/Incremental Process?

Interfaces CSC 123 Fall 2018 Howard Rosenthal

PROCESS DEVELOPMENT METHODOLOGY The development process of an API fits the most fundamental iterative code development

Agile Development

Object Oriented Programming

Review of Basic Software Design Concepts. Fethi Rabhi SENG 2021

Activities Common to Software Projects. Software Life Cycle. Activities Common to Software Projects. Activities Common to Software Projects

SE420 - Software Quality Assurance

Chapter 5. The Database Life Cycle. Class 04: Topic 3.1: The Database Life Cycle

History of object-oriented approaches

A Case Study of Requirements Specification in an Agile Project

The Process of Software Architecting

02291: System Integration

Agile Accessibility. Presenters: Ensuring accessibility throughout the Agile development process

Agile Software Development Agile UX Work. Kati Kuusinen TUT / Pervasive / IHTE

ISSN: [Kaur* et al., 6(10): October, 2017] Impact Factor: 4.116

Introduction to Software Engineering

Schedule(3/3) March 18th 13:00 Unified Process and Usecase-Driven Approach. (problem definition, use case model)

The software lifecycle and its documents

SOFTWARE LIFE-CYCLE PROCESSES From Waterfall to Extreme Programming

Kanban One-Day Workshop

11/8/ th IEEE Requirements Engineering Conference 27-Sep to 1-Oct, 2010

Lecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802

Object-Oriented Systems Analysis and Design Using UML

Object Oriented Programming

SE310 Analysis and Design of Software Systems

Software Development Methodologies

Unit 6 - Software Design and Development LESSON 7 CODE STRUCTURES

An Expert System for Design Patterns Recognition

Best Practices for Collecting User Requirements

RUP for Systems Z and other Legacy Systems

Study Of Feature Driven Development Using The Concepts Of Object Oriented Programming System

The Design Patterns Matrix From Analysis to Implementation

Abstract Classes and Polymorphism CSC 123 Fall 2018 Howard Rosenthal

Second. Incremental development model

Agile Software Development The Cooperative Game 2nd Edition

Final Exam CISC 475/675 Fall 2004

SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION

Agile Architecture. The Why, the What and the How

Test Driven Development. René Barto SES Agile Development - Test Driven Development

Software Design Using CRC Cards

Lecture 34 SDLC Phases and UML Diagrams

Chapter 8 Visualization and Optimization

Agile Manifesto & XP. Topics. Rapid software development. Agile methods. Chapter ) What is Agile trying to do?

Strategies for Rapid Development in Internet Time. William A. Cunningham December 5, 2000 NYOUG New York, NY

Software Engineering

DevOps in an ITIL Shop. Not just compatible; DevOps achieves ITIL s promise.

Object-Oriented and Classical Software Engineering DESIGN 11/12/2017. CET/CSC490 Software Engineering Design CHAPTER 14. Stephen R. Schach.

Objectives. Connecting with Computer Science 2

MTAT Software Engineering Management

Software Engineering Chap.7 - Design and Implementation

Rapid Application Development [RAD]

Software Verification and Validation (VIMMD052) Introduction. Istvan Majzik Budapest University of Technology and Economics

Session 8: UML The Unified Modeling (or the Unstructured Muddling) language?

Chapter 12 Object-Oriented Programming. Starting Out with Games & Graphics in C++ Tony Gaddis

Creating an Intranet using Lotus Web Content Management. Part 2 Project Planning

A Proposal to Develop a Testing Framework for Agile Software Process

RightNow Technologies Best Practices Implementation Guide. RightNow Technologies, Inc.

Transcription:

Introduction To Software Development CSC 295-01 Spring 2019 Howard Rosenthal

Course References Materials for this course have utilized materials in the following documents. Additional materials taken from web sites will be referenced when utilized. 1. http://www.programmedlessons.org/java9/index.html 2. Anderson, Julie and Franceschi, Herve, Java Illuminated 5 TH Edition,, Jones and Bartlett, 2019 3. Bravaco, Ralph and Simonson, Shai, Java programming From The Ground Up, McGraw Hill, 2010 4. Deitel, Paul and Deitel, Harvey, Java, How To Program, Early Objects, Tenth Edition, Pearson Publishing, 2015 5. Gaddis, Tony, Starting Out With Objects From Control Structures Through Objects, Pearson Publishing, 2016 6. Horstmann, Cay, Core Java For The Impatient, Addison Wesley- Pearson Education, 2015 7. Schmuller, Joseph, Teach Yourself UML In 24 Hours Second Edition, SAMS Publishing, 2002 8. Urma, Raoul-Gabriel, Fusco, Mario and Mycroft, Alan, Java 8 in Action: Lambdas, Streams, and Functional-Style Programming, Manning Publishing, 2014 9. Wirfs-Brock, Rebecca, Wilkerson, Brian and Wiener, Laura, Designing Object- Oriented Software, Prentice Hall, 1990 2

Lesson Goals Discuss good software development practices Describe software complexity Describe software methodologies Describe object-oriented programming 3

4

Good Software Development Writing good software is much more than sitting down and starting to code You need a methodology You need a structure You need to thoroughly test Every loop and branch must be thoroughly tested You need to strive towards simplicity This makes testing easier You need to refactor on a regular basis Refactoring is improving the software without adding new functionality Improvements can include performance improvement, bug fixes, etc.) You need well-documented software (see reference SoftwareDocumentation.pdf) You must document all logic, parameters, and test results You would like to develop reusable software whenever possible This requires data-driven software that can serve multiple similar purposes 5

Software Complexity (1) Cyclomatic complexity in code is a software metric used to indicate the complexity in the program. It is a quantitative measure of the number of linearly independent paths through program's source code. In normal terms, the cyclomatic complexity measure tells how complex your code is. The cyclomatic complexity of a method (or constructor) is the number of possible linearly-independent execution paths through that method A method with high cyclomatic complexity is typically difficult to understand and test. Good software design keeps the complexity of any method low, limiting the levels of nesting by creating and invoking new methods. Note: The government has strong limits on the level of complexity of any individual piece of software. When you have lowered complexity you may have more methods Therefore good and complete documentation of each method, as well as each class, it extremely important 6

Software Complexity (2) Mathematically, the cyclomatic complexity of a structured program is defined with reference to the control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second. The complexity M is then defined as M = E N + 2P, where E = the number of edges of the graph. N = the number of nodes of the graph. P = the number of connected components. 7

Example Of Complexity Calculation A control flow graph of a simple program. The program begins executing at the red node, then enters a loop (group of three nodes immediately below the red node). On exiting the loop, there is a conditional statement (group below the loop), and finally the program exits at the blue node. This graph has 9 edges, 8 nodes, and 1 connected component, so the cyclomatic complexity of the program is 9-8 + 2*1 = 3 8

9

Classic Traditional Program Management Uses The Waterfall Model 10

The Waterfall In Reality In reality there are almost always unknowns and changes This leads to the potential to circle back at any step to a prior step in the life cycle 11

The V-Shaped Model Is A Variation On The Waterfall Advantages Disadvantages Early development of test plans during the corresponding analysis and design processes during the life cycle improves the possibility of acceptance test success. Software is developed during the implementation phase, so no early prototypes of the software are produced Each phase has specific deliverables Little flexibility and adjusting scope is difficult Simple and easy to use Very rigid like the waterfall model Works well for small projects where requirements are easily understood This model does not provide a clear path for problems found during testing phases 12

The Spiral Model Combines The Traditional and Predictive Lifecycle Model With Prototyping It Is Iterative 13

The Spiral Model Uses Prototyping As A Key Tool During Requirements Discovery (1) The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: Evaluating the first prototype in terms of its strengths, weaknesses, and risks Defining the requirements of the second prototype Planning and designing the second prototype Constructing and testing the second prototype. 14

The Spiral Model Follows A Path That Leads To Requirements Discovery (2) At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime. 15

The Agile Manifesto Agile methodologies embrace the concept of incremental development and delivery of workable software The Agile Manifesto encompasses four basic values PMBOK V6 Agile Fig. 2-1 16

The Twelve Principles Of The Agile Manifesto PMBOK V6 Agile Fig. 2-2 17

Many Different Lean Methods Are Considered Agile Often people mean different methods when talking about Agile Any method that embraces the the Agile Manifesto and Principle may be considered an Agile method PMBOK V6 Agile Fig. 2-4 18

What Is A Scrum? Scrum is a single-team process framework used to manage product development The framework consists of roles, events, artifacts and rules that uses an iterative Agile delivery approach to deliver working products within timeboxes of one month or less Scrum is the most widely used methodology for Agile development. Key advantages include: Relatively easy to train and implement Reflects the truly incremental delivery approach used for in-house improvements Keeps the customer satisfied and sold Keeps together for a longer time, improving efficiency Through the retrospectives provides a mechanism for continuous process improvement. Not appropriate for new large scale projects Scrum defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal It challenges assumptions of the "traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) There will be unpredictable challenges for which a predictive or planned approach is not suited Scrum adopts an evidence-based empirical approach accepting that the problem cannot be fully understood or defined up front It instead focuses on how to maximize the team's ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions 19

The Scrum Framework 20

The Scrum Process Is Built Around Daily Standups and Rapid Delivery Of New Capabilities 21

22

Some Key Practices In Software Development That Are Widely Agreed Upon (1) Good design and definition of interfaces Well-defined interfaces between software objects is important to ensure that the code is usable Automated testing is something almost universally agreed upon as a laudable goal. Tools capture test scenarios for playback so that they can be run multiple times. Continuous integration, as opposed to developing in silo branches and then having extensive merging efforts, is also largely viewed as a benefit. Use of object-oriented design patterns Software Patterns describe how to solve typical problems that appear in many application scenarios in similar ways. An abstract class has patterns that may be applied to multiple child classes These patterns can be seen as abstracted knowledge, that guides you in better solving your concrete problems For instance, all polygons have their perimeters calculated in a similar way. A more complex example all cars start in a similar way. 23

Some Key Practices In software Development That Are Widely Agreed Upon (2) Code reviews are widely considered to be indispensable ways of promoting code quality. Pair programming takes code reviews to the next level and has development performed in a constant state of review. Two persons teams continuously review and consult on each others code. One click, automated builds are considered an important goal for most organizations, in stark contrast to the practice of having someone labor for half a day to get the software into a deployable state. Low complexity makes the code much easier to test and maintain Good documentation is essential unless you want to own the same piece of code for its entire lifetime 24

25

What Is Object-Oriented Programming The purpose of OOP is to organize a program's structure so that one can build programs using abstract models called "objects" that encapsulate data and behavior into one unit Object-oriented programming is based upon theories from the field of cognitive science about how information is represented in the human mind. Cognitive science is a multidisciplinary field where psychiatrists, neurologists, computer scientists, and others try to understand the nature of human thought. Computer scientists are particularly interested in this field because understanding human thought is helpful in the field of artificial intelligence as well as human-computer interaction. Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self"). In OOP, computer programs are designed by making them out of objects that interact with one another. 26

Classes And Objects Classes The definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contain the data members and member functions Objects Instances of classes Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as "circle", "square", "menu". An online shopping system might have objects such as "shopping cart", "customer", and "product Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric. The use of classes and objects allow us to model all forms of real world documentation 27

Why Use Object-Oriented Programming Object-0riented programming has great advantages over other programming styles: Code Reuse and Recycling: Objects created for object-oriented Programs can easily be reused in other programs. Encapsulation: Once an object is created, knowledge of its implementation is not necessary for its use. In older programs, coders needed understand the details of a piece of code before using it (in this or another program). Objects have the ability to hide certain parts of themselves from programmers. This prevents programmers from tampering with values they shouldn't. Additionally, the object controls how one interacts with it, preventing other kinds of errors. For example, a programmer (or another program) cannot set the width of a window to -400. Design Benefits: Large programs are very difficult to write. Object-oriented programs force designers to go through an extensive planning phase, which makes for better designs with less flaws. In addition, once a program reaches a certain size, object-oriented Programs are actually easier to program than non-object-oriented ones. Software Maintenance: Programs are not disposable and legacy code must be dealt with on a daily basis, either to be improved upon (for a new version of an exist piece of software) or made to work with newer computers and software. An object-oriented program is much easier to modify and maintain than a non-objectoriented program. So although a lot of work is spent before the program is written, less work is needed to maintain it over time. 28