You are on page 1of 32

1

MANAGEMENT OF INFORMATION BY SYSTEMS


SLC

Nitin Chikhale / +91 99870 45460 / nichi1112@yahoo.com

Software Life Cycles and Projects


2

Concepts and tools

Software Life Cycle


3

Models Cyclical Systems Development Life Cycle Classical Life Cycle / Waterfall Model Prototype V-Shaped Model Spiral Model Iterative Model Incremental Approach

Cyclical Systems Development Life Cycle


4

Review vis--vis Terms of reference Benefits management Scope for further work

Terms of reference Preliminary Study Detailed Systems Study Requirement Specifications

Coding Unit Testing Module & Integration Testing Data Conversion UAT Training Documentation Parallel Run Go-Live

Functional Specifications Logical Design Detailed Physical Design Design Optimization Design Documentation and Program Specifications

Software Life Cycle

Systems Development Life Cycle


5

Central to all projects is the concept of a lifecycle. A life cycle is the series of steps which need to be taken which leads to the completion of the project. Software development is a complex process which involves various steps.

Systems Development Life Cycle


6

Steps:
1. 2.

Terms of reference which initiates the project A preliminary study / feasibility study which may lead to a go ahead for the project A detailed systems study

3.

detailed understanding about the present systems, its shortcomings, the business logic and the transactions involved, the people, roles, etc. and the purpose of the systems in the context of the organization. includes phases of requirements gathering.

Systems Development Life Cycle


7

4.

A logical systems design


create a conceptual design of a new system to meet the present-day requirements of the users and the organization overcome the limitations of the existing systems

5.

A physical design
visualizes the new systems in the context of the real life organization structure, form, the actual process, the departments involved, equipment used for processing and the location and other consideration gives the conceptual design a physical form which can be implemented on the target hardware and for the stated users.

Systems Development Life Cycle


8

6.

Coding involves coding of the necessary software programs as per the specifications.
Program is an important aspect of the physical implementation of a software. The program specifications mention the purpose of a the program, the input used, the output expected, the precise logic used for transforming inputs to outputs, the database used, the precise controls and checks to be performed, etc. The code so developed has to be tested by the programmer against set test cases which usually represent the real life business situation under which the program is going to operate. These days, apart form the programmer testing his/her program Peers, i.e. the programmers colleague is also asked to test these programs for functional requirements as well as for software quality, etc. This is known as peer review.

Systems Development Life Cycle


9

7.

Integration testing the individual pieces viz. the programs have to work together in order to deliver the complete functionality expected of a software package.

involves the integration and testing of all the modules and individual programs which constitute the software.

8.

Parallel runs and user acceptance testing (UAT) this test involves putting the new software systems under real life conditions in terms of data, transactions and actual users.

Once the user is satisfied with the outcome of the systems in terms of the processing which it does, other performance parameters such as speed, accuracy, etc. and the reports and screens which it has, the user accepts the software. The UAT is done with live sample data so as to do a reality check on the software.

Systems Development Life Cycle


10

9.

Go Live
Once the user has gained confidence in the system and runs it parallel with his existing system, he decides to cut off his old systems (whether manual or computerized). This term is more popular in the context of large integrated applications such as an ERP or a core banking software but could be used to represent such a condition for any software.

10.

Review
Involves validation whether the software has achieved the stated purpose in terms of reference and the subsequent systems study.

Systems Development Life Cycle


11

The above stages of software development are indicative. In a real life software development, related steps are

project charter, project planning, sizing & procurement of the necessary hardware & system software, intermediate project reviews, documentation, data conversion, codification (i.e. developing codes for various things such as item numbers, employee numbers etc.) are all examples of other activities which are performed as part of a software project.

Systems Development Life Cycle


12

The type of stages involved, the sequencing of these and the manner in which the software development proceeds is known as a Software Life Cycle Model. There are various kinds of software life cycles models. These have evolved with time and human experience with various situations and various technologies involved in developing software.

Classical Life Cycle / Waterfall Model


13

This is one of the oldest models for a software life cycle.


the development of software moves from step to step in a sequential manner. This stepping through appears to be like a waterfall. It assumes that there is no overlap between each stage nor is there any backtracking. Thus, when we move from analysis to design phase it is assumed that the analysis is completed and then we move to design. There is no possibility of going back from design to analysis.

The advantage of this model is its simplicity. For smaller software projects where it is easy to grasp the entire requirement, design and then code and implement this offers a simple way of managing the project.

Classical Life Cycle / Waterfall Model


14

Analysis Design

Coding Testing Implementation

Review

Classical Life Cycle / Waterfall Model


15

However for larger software projects it is often not possible to study and grasp all aspects of the requirements and the flow through to design and implementation.

In such cases, the conventional waterfall model becomes inadequate.

In such projects, the requirements of the users are either taken in phases and implemented or the requirements are evolved over time in the form of a continuous improvement of the software product. In either case, the waterfall is not representative of the flow of work in these kinds of projects.

Classical Life Cycle / Waterfall Model


16

The waterfall represents the Big Bang approach, i.e. we study the entire requirement, design the entire requirement etc.

Big Bang approach is not favored for large projects due to higher risk.

Many times a long drawn project also leads to a solution which may become irrelevant from the users point two years down the line when it goes for implementation. Thus in the present-day situation we need a software life cycle which can help us quickly deliver solutions and perhaps helps us to incrementally evolve the solutions into a much larger product.

Classical Life Cycle / Waterfall Model


17

Waterfall does not directly meet these mew requirements. However, at the heart of all life cycle, i.e. even in a phased development process as discussed above, each phase has to flow through a waterfall-like lifecycle. Thus waterfall as a concept is still worthwhile to study and apply in practice as a part of a larger methodology.

Prototype
18

The prototype is a mock-up of the final product. In software, a prototype could be in the form of the screens that need to be presented to the user linked in a way so as to simulate the real software.

Prototype
19

The benefits of a prototype are: It helps the developer as well as the user to visualize how the software would look like in terms of its interface with the user. The user can check the usability and functionality in terms of the fields on the screen the sequence of the screen, etc. It facilitates communication between the user and developer. Once the user sees a prototype he is able to visualize his requirements better. It is also a means of reducing risk in many complex projects. If prototype approach is used along with the extensive use of generic software components, it is easier to tune the prototype based on the suggestions of the user and then take it further into a completed software. However, this cannot be done in all cases and the prototype has to be then used only as a guideline while the actual software has to be redeveloped.

Prototype
20

The steps involved in prototyping are iterative. E.g. a prototype is made based on basic requirements expressed / communicated. Subsequent feedback leads to many such iterations which lead to completion of the project. The life cycle steps would look quite different and require different milestone and deliverables.

V-Shaped Model
21

The V-Shaped model is an extension of the waterfall model. It involves matching of an appropriate test phase for each of the stages in the waterfall model. Requirements matched with system/functional testing High-level design matched with integration testing Detailed design matched with unit testing

V-Shaped Model
22

Requirements

System test plan

System testing

Preliminary Design

Integration test plan

Integration testing

Detailed Design

Unit test plan

Unit testing

Coding

Spiral Model
23

The Spiral model combines the benefits of the waterfall, the prototyping methods and is evolutionary in nature. The software is visualized in the initial prototype after carrying out a proper risk analysis. Once this level of prototype is accepted, the spiral of functionality expands into another cycle with its own risk analysis phase, requirement analysis and design phases.

Spiral Model
24

Engineering

Evaluation

Planning Risk Analysis

Spiral Model
25

The four quadrants of a spiral: Planning: Determining objectives, alternatives and constraints Risk Analysis: Analysis of alternatives and identification / resolution of risks Engineering: Development of the next level product Customer evaluation: Assessment of the results of engineering

Spiral Model
26

Each iteration involves following steps: Evaluate alternatives Develop deliverables and verify the correctness Plan the nest iteration Commit to an approach for the next iteration The Spiral is very useful where the user and/or developer are not very clear about the solution to be evolved. Both can revisit the functionality of the solution developed so far in each successive spiral.

Iterative Model
27

Iterative approach involves growing a software to its full functionality in successive iterations. Each successive iteration adds more detail to the previously implemented functionality, e.g. if we were to design a website with all its pages giving only the title of the page in the first iteration. This iteration helps understand the relationship and navigation between pages. In subsequent iterations details of each page are added thereby completing the website.

Iterative Model
28

Requirement analysis High Level Design


Iteration 1 Iteration 1
Detailed Design Coding Testing Implementation

Iteration 1
Detailed Design Coding Testing Implementation

Detailed Design Coding Testing Implementation

Iterative Model
29

The advantage of this approach is that the entire system is visualized at the initial stage and over a period the details are filled in. When done in the presence of a user, it makes it easier for the user to visualize the complete systems as well as help add the detail as the development progresses.

Incremental Approach
30

Here the developer develops the software in small increments. This approach helps in many ways:

It helps the user and developer prioritize those features which are more urgent from the business standpoint. It helps the user and developer limit the scope to a smaller increment which is easier to visualize thereby reducing the risk associated with requirements analysis. It helps the user and developer to manage within lesser resources (People or Cost) as compared to the big bang approach.

Incremental Approach
31

E.g. break-up of a branch software into the following increments: Take Input and print invoice Generate sales analysis reports based on the invoice data Take input and Print receipts for payments made by customer Generate account receivable statements including aging analysis of debtors, etc. Stock update based on invoice and generate a receipt thereby completing the stock transactions. Generate inventory related statements.

Incremental Approach
32

Each of the above increments could be planned analyzed, designed and implemented in a waterfall style. Once one increment is complete the software is moved on to next increment. Incremental approach to software development involves the breaking up of the overall software delivery into smaller modules/deliveries. The essential difference between incremental and iterative is that iteration successively improves upon the existing functionality whereas incremental adds newer modules to the previous piece of the software. Many of the newer methodologies tend to be a mix between incremental and iterative

You might also like