Post on 27-Dec-2015
transcript
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?
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!