Introduction To Software DevelopmentCSC 295-01Spring 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.html2. Anderson, Julie and Franceschi, Herve, Java Illuminated 5TH Edition,, Jones and

Bartlett, 20193. Bravaco, Ralph and Simonson, Shai, Java programming From The Ground Up,

McGraw Hill, 20104. Deitel, Paul and Deitel, Harvey, Java, How To Program, Early Objects, Tenth

Edition, Pearson Publishing, 20155. Gaddis, Tony, Starting Out With Objects From Control Structures Through

Objects, Pearson Publishing, 20166. Horstmann, Cay, Core Java For The Impatient, Addison Wesley- Pearson

Education, 20157. Schmuller, Joseph, Teach Yourself UML In 24 Hours Second Edition, SAMS

Publishing, 20028. 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

11

In reality there are almost always unknowns and changesThis leads to the potential to circle back at any step to a prior step in the life cycle

The V-Shaped Model Is A Variation On The Waterfall

12

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

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

13

IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 5, September 2010 ISSN (Online): 1694-0814 www.IJCSI.org

99

x Spiral model sectors 1. Objective setting :Specific objectives for the phase are

identified. 2. Risk assessment and reduction: Risks are assessed and

activities are put in place to reduce the key risks. 3. Development and validation: A development model

for the system is chosen which can be any of the general models.

4. Planning: The project is reviewed and the next phase of the spiral is planned [1].

Fig. 7 Spiral Model of the Software Process[1].

x WinWin Spiral Model The original spiral model [Boehm 88] began each cycle of the spiral by performing the next level of elaboration of the prospective system's objectives, constraints and alternatives. A primary difficulty in applying the spiral model has been the lack of explicit process guidance in determining these objectives, constraints, and alternatives. The Win-Win Spiral Model [Boehm 94] uses the theory W (win-win) approach [Boehm 89b] to converge on a system's next-level objectives, constraints, and alternatives. This Theory W approach involves identifying the system's stakeholders and their win conditions, and using negotiation processes to determine a mutually satisfactory set of objectives, constraints, and alternatives for the stakeholders. In particular, as illustrated in the figure, the nine-step Theory W process translates into the following spiral model extensions: 1. Determine Objectives: Identify the system life-cycle stakeholders and their win conditions and establish initial system boundaries and external interfaces. 2. Determine Constraints: Determine the conditions

under which the system would produce win-lose or lose-lose outcomes for some stakeholders. 3. Identify and Evaluate Alternatives: Solicit suggestions from stakeholders, evaluate them with respect to stakeholders' win conditions, synthesize and negotiate candidate win-win alternatives, analyze, assess, resolve win-lose or lose-lose risks, record commitments and areas to be left flexible in the project's design record and life cycle plans. 4. Cycle through the Spiral: Elaborate the win conditions evaluate and screen alternatives, resolve risks, accumulate appropriate commitments, and develop and execute downstream plans [8]. 3.5 Extreme Programming

An approach to development, based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pair wise programming . It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.

Fig. 8 The XP Release Cycle

x Extreme Programming Practices Incremental planning: Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development "Tasks". Small Releases: The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release.

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

16

PMBOK V6 Agile Fig. 2-1

The Twelve Principles Of The Agile Manifesto

17

PMBOK V6 Agile Fig. 2-2

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

18

PMBOK V6 Agile Fig. 2-4

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-object-oriented program.

� So although a lot of work is spent before the program is written, less work is needed to maintain it over time. 28