1

INF160 IS Development Environments AUBG, COS dept

Lecture 02Title:

Information Systems Life Cycle

(Extract from ISDE Syllabus)

Reference: Baltzan, Chap 9; Doar, pp 2, 10-14

2

Lecture Contents:

Systems Development Life CycleSW Development Methodologies

Traditional Agile

Managing SW Development Project

3

Developing software

Kind of understanding terminology as of The INF160 course

Information System /IS/ == Computer Program = = Software Product == Software Package

4

Alternate terminology on SDLC

Software Development Method Software Life Cycle Program Development Cycle

Many programmers plan their programs using a sequence of steps, referred to as

SDLCor SDM orSLC or PDC

Following such a step-by-step process enables developers to use their time efficiently and helps them design error-free programs that produce the desired output.

5

SDLC / SDM / SLC / PDC

Version 1: Specify the problem requirements; Analyze the problem; Design the algorithm to solve the problem; Implement the algorithm; Test and verify the completed program; Maintain and update the program.

6

SDLC / SDM / SLC / PDC

Version 2: Systems Analysis; Systems Design; Systems Implementation; Systems Support.

7

SDLC / SDM / SLC / PDCVersion 3:

Problem Analysis - (Correct Problem)• Identify data objects• Goal to model properties• Determine Input/Output data• Constraints on the problem

Design• Decompose into smaller problems• Top-down design (Divide and Conquer)• Develop Algorithm (Desk Check)

Implementation• Writing the algorithm

Testing• Verify the program meets requirements• System test and Unit test

Documentation• Key part in the development process

8

Systems Development Life Cycleafter [Baltzan]

Version 4: Planning Analysis Design Development Testing Maintenance

9

Software Life Cycle after Malik

Ver 5: SW Life Cycle – 3 time periods/intervals:Program Conception

Initial idea to build programActual Existence - three fundamental stages

Development - First and most important phase Use Maintenance

Program Retirement Program too expensive to maintain, No new version released

Data Structures Using C++ 2E 9

10

Software Development Phase

Four sub phases /steps/ Analysis Design Implementation Testing and debugging

Data Structures Using C++ 2E 10

11

Software Development Phase

Analysis Analysis requirements

• Thoroughly understand the problem• Understand the problem requirements• Divide problem into sub problems (if complex)

Data Structures Using C++ 2E 11

12

Software Development PhaseDesign

Design an algorithm to solve the problem or sub problem

Algorithm• Step-by-step problem-solving process• Solution obtained in finite amount of time

Structured design Object-Oriented design

Data Structures Using C++ 2E 12

13

Reminder: Algorithms

Basic idea: the solution to any computing problem involves executing a series of actions in a specific order.

Definition 1: A step-by-step problem-solving process in which a

solution is arrived at in a finite amount of time.

Definition 2: A procedure for solving a problem in terms of

• 1.   the actions to be executed, and• 2.  the order in which these actions are to be executed

is called an algorithm.

Definition 3: An algorithm is a list of steps for solving a problem.

14

Software Development PhaseDesign

Structured design• Dividing problem into smaller sub problems• Also known as: top-down design, stepwise

refinement, and modular programming Thinking in Routines /procedures,

functions/ Algorithms + Data Structures = Programs

Data Structures Using C++ 2E 14

15

Software Development Phase

Design Object-oriented design (OOD)

• Identifies components called objects• Determines how objects interact with one another• Object specifications:

– relevant data;– possible operations performed on that data

Object-oriented design principles• Encapsulation, Inheritance, Polymorphism

Thinking in Objects Classes + Objects = Programs

Data Structures Using C++ 2E 15

16

Software Development Phase

Implementation Write and compile programming code

• Implement classes and functions discovered in the design phase

Final program consists of several functions• Each accomplishes a specific goal

Precondition• Statement specifying condition(s) must be true before

function called Postcondition

• Statement specifying true items after function call completed

Data Structures Using C++ 2E 16

17 Data Structures Using C++ 2E 17

Software Development PhaseTesting and debugging

Testing• Testing program correctness• Verifying program works properly

Increase program reliability• Discover and fix errors before releasing to user

Test case• Set of inputs, user actions, other initial

conditions, and the expected output• Document properly

Black-box testing and white-box testing

18

Systems Development Life Cycle12 distinct activities after [Doar]

Version 6: Product marketing Gathering requirements Writing functional specifications Implementation – INF160 topic Testing – INF160 topic Documentation – INF160 topic Release – INF160 topic Marketing Sales Support Maintenance – INF160 topic End of support

19

Systems Development Life Cycle12 distinct activities after [Doar]

Product marketing Involves creating initial ideas for the project, i.e.

what might actually be wanted by customers

Gathering requirements Collecting info what exactly the product is

supposed to do.

Writing functional specifications Describe how the product can be created to fulfill

the requirements.

20

Systems Development Life Cycle12 distinct activities after [Doar]

Implementation – INF160 topic Product is actually created. Surprisingly Small

amount of time to develop a product is spent.Testing – INF160 topic

Implementation is compared with requirements. Surprisingly large amount of time to develop a product is spent. Yet this is the first thing to remove from busy schedules.

21

Systems Development Life Cycle12 distinct activities after [Doar]

Documentation – INF160 topic Describes how to use the product. Internal

documentation describes how to maintain the product for future developers.

Release – INF160 topic The process of shipping the product to

customers, Also making sure that the product will work properly outside the environment in which it was developed.

22

Systems Development Life Cycle12 distinct activities after [Doar]

Marketing Creating/controlling the market for the

product.Sales

Persuading the customers to use the product with expectation that they will pay money for it.

23

Systems Development Life Cycle12 distinct activities after [Doar]

Support Help the customer to use product when

documentation does not answer the questionsMaintenance – INF160 topic

If product is widely used, then as world around it changes, the product will need work to keep it work properly in the changed environment

End of support Customers need to be told when product

support will end. All documentation and source files are to be carefully archived.

24

Open and Closed SW Development

Traditionally, SW development is closed, i.e. source files used to create the product are confidential. Sometimes you can purchase the source, but it’s extra.

Open SW development refers to different ideas: source files for product are openly and freely available, so customers can change source files and then rebuild product themselves.

25

Open and Closed SW Development

Open SW products allow anyone to redistribute source files subject to requirement that if you make changes, you must make changes publicly available.

If you distribute changes, you create a fork of the original product.

Fork is an accepted part of open SW development

26

Open and Closed SW Development

Web server Apache www.apache.orgC compiler GCC gcc.gnu.orgUnix based OS GNU/Linux www.linux.orgWeb browser Mozilla www.mozilla,orgScripting language Perl www.perl.orgScripting language Python

www.python.org

27

Open and Closed SW Development

Open source development was pioneered by the Free Software Foundation in 1984 which developed SW products under the GNU project, FSF prefers free SW rather than open SW.

Open Source Initiative /OSI/ was founded 1998 and describes itself as a marketing program for free SW. OSI prefers term open SW.

28

The Parts of a single Project

Project has source files that become products.Those products have customers who use the

products.Project has project members /developers,

testers, technical writers, managers, etc/ who are also customers for their own products.

Development Environment for this project is made of both the tools and the local processes and policies for using those tools.

29

SW Configuration Management

SCM is the ability to keep track of different versions of the project source files used to create SW products.

30

Building Software

SW products are built from their source files, or source code. It is a collection of files located into a folder.

A build tool uses the source files and follows some specified build rules to run other tools such as compiler to create the product. These build rules are usually specified in a config file, known as a build file which is part of the source files for the product.

31

Building Software

Build tools have to know which source files and which libraries are to be used to build the product.

Build tools have to know which parts of the product depend on which other parts, so that if one source file is changed, then not all but only the other affected parts will also be rebuilt.

32

Building Software

Popular Build tools: The make utility The Java associated ant utility

33

Testing Software

Testing a product spans the range from individual developers writing Unit

tests to check small parts of the application to

System tests that use the whole application to demonstrate its functionality to customers

34

Testing Software

One of the corner stones of XP /eXtreme Programming/ methodology is the importance of extensive unit tests written before the functionality that they test has been written

Known as Test Driven Programming

35

Testing Software

Of course, running all different tests and interpreting results quickly becomes tedious.

If testing is not automated, it is often postponed and finally abandoned.

You need a test environment where tests can be added easily and run easily.

36

Tracking Bugs

Bug is the common term to describe issue, or defect, or incident when running product

Testing a product provides info which parts of it are working or not. This info has to be available to developers, testers, managers ,,,

So, info has to be collected, saved, stored into a repository. Bug tracking tools do this job.

37

Tracking Bugs

Bug tracking tools store info about bugs in a database and provide convenient GUIs and CLIs /command line interface/ for Adding info about bugs Changing info recorded about bugs Creating reports about different

kinds of bugs

38

Tracking Bugs

What info on bugs is saved to DB? Description what happened and what

should happen Identifier that is unique for that type of a

bug Who found the bug Steps to reproduce the bug Who is working on the bug Which release the bug exists in Which release the bug has been fixed in

39

Tracking Bugs

Each bug is associated with a state depending on the stage the bug is in: New bug is in an Open state. Then move to an Accepted state Then move to a Fixed state Then move to a Closed state.

40

Writing Documentation

Ideal product needs no documentation.Ideal product appears rarely. So,

documentation is must.Whether documentation is

simple README file, or a large manual, or Interactive help available at run time,

documentation contents are to be created usually by a technical writer.

41

Writing Documentation

Documentation is part of the product.Similarities btw writing SW and writing D.

Large documents are made of smaller ones Different parts of a document depend on other

parts of the document Both SW and D. are transformed from one file

format to another file format as part of being released. Source file is compiled to executable. A document file is often written in MS Word and then converted to another release format as HTML or PDF, for example.

42

Releasing Products

Once a product is developed, tested and documented, it eventually becomes ready to release.

One essential part of releasing process is to assure customers that the files that they download are just the same as the ones that you release. Use of digital signatures and checksums comes to help customers.

Installing SW product is first experience and first impression for the customers.

43

Maintenance

Maintenance of a product after it has been released takes up a large part of a product’s life span.

Typical maintenance activities: Understanding Code Reproducing a Build Handling product Changes

44

SW Development Methodologies

.

45

SW Development Methodologies

Methodology is a set of Policies, Procedures, Standards, Practices, Tools, Techniques, and Tasks

That people apply in SDLC.

46

SW Development Methodologies

Traditional SW Development Methodologies

Agile SW Development Methodologies

47

Traditional SW Development Methodology [Baltzan]: Waterfall

Waterfall methodology; a sequence of phases in which the output of one phase becomes the input for the next phase

48

Software Development Process Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

49

Requirement Specification Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

A formal process that seeks to understand the problem and document in detail what the software system needs to do. This phase involves close interaction between users and

designers.

Most of the examples in INF160 are simple, and their requirements are clearly stated. In the real world, however, problems are not well defined. You need to study a problem carefully to identify its requirements.

50

System AnalysisRequirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

Seeks to analyze the business process in terms of data flow, and to identify the system’s input and output.

Part of the analysis entails modeling the system’s behavior. The model is intended to capture the essential elements of the system and to define services to the system.

51

System Design Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

The process of designing the system’s components.

This phase involves the use of many levels of abstraction to decompose the problem into manageable components, identify classes and interfaces, and establish relationships among the classes and interfaces.

52

Implementation Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

The process of translating the system design into programs. Separate programs are written for each component and put to work together.

This phase requires the use of a programming language like Java or C#. The implementation involves coding, testing, and debugging.

53

Testing Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

Ensures that the code meets the requirements specification and weeds out bugs.

An independent team of software engineers not involved in the design and implementation of the project usually conducts such testing.

54

Deployment Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

Deployment makes the project available for use.

For a Java applet, this means installing it on a Web server; for a Java application, installing it on the client's computer.

55

Maintenance Requirement Specification

System Analysis

System Design

Testing

Implementation

Maintenance

Deployment

Maintenance is concerned with changing and improving the product.

A software product must continue to perform and improve in a changing environment. This requires periodic upgrades of the product to fix newly discovered bugs and incorporate changes.

56

Agile SW Development Methodologies:

Rapid Application Development (RAD)Also rapid prototyping: emphasizes

extensive user involvement in the rapid construction of working prototypes of a system to accelerate the systems development process.

Prototype is a smaller-scale representation of working model of the user’s requirements

57

Agile SW Development Methodologies:

Rational Unified Process (RUP) (IBM) provides a framework for breaking down the SW development into four “gates”

InceptionElaborationConstruction: building/developing productTransition

58

RUP: Project Life Cycle

59

RUP: Project Life Cycle Phases

Dan Rawsthorne explained the phases meaning: The core of the phases is state-based, and the state is determined by what fundamental questions you are trying to answer:

Inception - do you and the Customer have a shared understanding of the system?

Elaboration - do you have an architecture to be able to build the system?

Construction - are you developing product? Transition - are you trying to get the Customer

to take ownership of the system?

60

RUP: Project Life Cycle

61

Agile SW Development Methodologies: Scrum methodology

The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

Scrum breaks projects down into chunks called stories, allowing the development team to tackle each story as an independent project. The team works on these stories in set time increments, called sprints. For example, a team may be given a two-week sprint to work on a specific story, and a one-month sprint to work on the next, more challenging story. One of the larger stories could be something like developing a new module for users to quickly find out which policies tie into which accreditation standard(s). A story with a smaller sprint could be something very simple, like having to correct a typo in a field title.

62

Developing Successful Software

Developing projects within budget and on time

Primary reasons for project failure include: Unclear or missing business requirements Skipping phases Changing technology The cost of finding errors in the SDLC

63

Managing SW Development Project

The Triple ConstraintRelationships btw the three primary and

interdependent variables in any project Time Cost Scope

64

Quiz 1

Scheduled next class!

65

Thank You For

Your Attention!