Advance Software Engineering

Todays Lecture: Agenda

z

z
z z

Course Outline Mark Distribution Deliverables Lesson 1

Course Outline
z

Text Book: Software Engineering by Ian Sommerville Software Engineering: A practitioners Approach by Roger S. Pressman, Seventh Edition. References: Software Requirements Using The Unified Process: A Practical Approach, Daniel R. Windle and L. Rene Abreo, Prentice Hall, 2002 Mastering the Requirements Process, Suzanne Robertson & James Robertson, Addison-Wesley, 2006. Managing Software Requirements: A Use Case Approach, Dean Leffingwell and Don Widrig , 2nd Edition, Addison Wesley, 2003 Recent research papers Case studies

Course Outline
z

Basic

Introduction to Software Engineering

Software life cycle model.

SRS Document Functional and non-functional requirements Software Design

Course Outline
z

Advance

Module/Functional Design Cohesion/Coupling Coding Debugging Integration White/Black Box Testing Software Maintenance

Course Outline
z

Advance

Formal Methods Software Reuse Software System Re-engineering Software Reverse Engineering Future of Software Engineering

Marks Distribution
z z z z

Quizzes Midterm Assignments Project Final

10 20 (Open book) 10 30 30 (Open book)

Project/Exams
z z z z

Running Software 50-100 Page Document Presentation Examples of Project:

Compiler Library System

Case Study Exams

Word of Caution
z

Copying- multiply by Zero Project must be working

50% REDUCTION of final Mark

Finally
z

This is a advance course

It is expected to be challenging You expect me to teach well I expected you to work hard

Scope and necessity of software engineering

z z

Software engineering is an engineering approach for software development. We can alternatively view it as a systematic collection of past experience. The experience is arranged in the form of methodologies and guidelines. A small program can be written without using software engineering principles. But if one wants to develop a large software product, then software engineering principles are MUST to achieve a good quality software cost effectively.

Scope and necessity of software engineering

z z

z z z

Without using software engineering principles it would be difficult to develop large programs. A program of size 1,000 lines of code has some complexity. But a program with 10,000 LOC is not just 10 times more difficult to develop, but may as well turn out to be 100 times more difficult unless software engineering principles are used. In such situations software engineering techniques come to rescue. Software engineering helps to reduce the programming complexity. Software engineering principles use two important techniques to reduce problem complexity. Abstraction and Decomposition

Abstraction
z z

The principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem.

Abstraction

Decomposition
z z z

z z

In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize interactions among various components. If the different subcomponents are interrelated, then the different components cannot be solved separately and the desired reduction in complexity will not be realized.

Decomposition

Future of Software Engineering

z z z

Microsoft, IBM Any Commercial Software App Development

Apple Store Android

Two Tier Software Engineering

z

Software Life Cycle Model

z

z z z

A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product. It also captures the order in which these activities are to be undertaken. In other words, a life cycle model maps the different activities performed on a software product from its start to retirement.

The need for a software life cycle model

z

Without using of a particular life cycle model the development of a software product would not be in a systematic and disciplined manner. When a software product is being developed by a team there must be a clear understanding among team members about when and what to do. Otherwise it would lead to chaos and project failure.

Different software life cycle models

z

Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows:

Classical Waterfall Model Iterative Waterfall model Prototyping Model or Evolutionary Model Spiral Model

Classical Waterfall Model

z z z

The classical waterfall model is intuitively the most obvious way to develop software. Thus, this model can be considered to be a theoretical way of developing software. But all other life cycle models are essentially derived from the classical waterfall model. So, in order to be able to appreciate other life cycle models it is necessary to learn the classical waterfall model.

classical waterfall model

z

Classical waterfall model divides the life cycle into the following phases.

Feasibility Study Requirements Analysis and Specification Design Coding and Unit Testing Integration and System Testing Maintenance

Activities undertaken during feasibility study

z

The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders try to have a rough understanding of what is required to be done by visiting the client side. Then they examine each of the solutions in terms of what kind of resources required, what would be the cost of development and what would be the development time for each solution. Based on this analysis they pick the best solution and determine whether the solution is feasible financially and technically.

Activities undertaken during requirements analysis & specification

The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely

User Requirements and analysis, and Requirements specification

User Requirements
z z

Get user requirements form the client. The goal is to collect all relevant information from the customer regarding the product to be developed.

Requirements Analysis
z

The aim of requirements analysis is to discover problems with the system requirements, especially incompleteness and inconsistencies Detailed analysis usually takes place after the initial draft of the requirements document is produced
27

Comments on Requirements Analysis

z

Analysts read the requirements, highlight problems, and discuss them in requirements review meetings This is a time-consuming and expensive activity

Requirement Engineers are mostly senior people, when they spend time it becomes expensive activity However, its very important to remove errors from the set of requirements at this stage why? So time and money at this stage is worth28 investing

Requirements Analysis Stages

z z

Necessity checking Consistency and completeness checking

29

Necessity Checking
z z

The need for the requirement is analyzed. In some cases, requirements may be proposed which dont contribute to the business goals of the organization or to the specific problem to be addressed by the system

Here the analytical power , and professionalism of the Requirement Engineer matters a lot Sometimes the customers want to include every thing in the software product which they do not need Analyze in context of budget, schedule, technology and conformance to objectives of client
30

Consistency and Completeness Checking

z z z

The requirements are cross-checked for consistency and completeness. Consistency means that no requirements should be contradictory Completeness means that no services or constraints which are needed have been missed out

31

User Requirement Analysis

z

Premature design

Does the requirement include implementation information?

z

premature

design

or

If the answer is yes, highlight it to the customer and try to exclude it from the requirement

Combined requirements

Does the description of a requirement describe a single requirement or could it be broken down into several different requirements?
z z

If yes, break it down to several different requirements That will help in determining the consistency and completeness aspect of the requirement set and reducing complexity.
32

User Requirement Analysis

z

Unnecessary requirements

Is the requirement gold plating? That is, is the requirement a cosmetic addition to the system which is not really necessary? Does the requirement mean that non-standard hardware or software must be used? To make this decision, you need to know the computer platform requirements

Use of non-standard hardware

33

Activities undertaken during requirements analysis & specification

z

After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document.

Activities undertaken during design

The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document.

Activities undertaken during coding and unit testing:

z

The purpose of the coding and unit testing phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all the individual modules. It involves testing each module in isolation as this is the most efficient way to debug the errors identified at this stage.

Activities undertaken during integration and system testing:

z z

Integration of different modules is undertaken once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated in a planned manner. The different modules making up a software product are almost never integrated in one shot. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out.

Activities undertaken during integration and system testing:

z

System testing usually consists of three different kinds of testing activities:

z z z

testing: It is the system testing performed by the development team. testing: It is the system testing performed by a friendly set of customers. acceptance testing: It is the system testing performed by the client himself after the product delivery to determine whether to accept or reject the delivered product.

System testing is normally carried out in a planned manner according to the system test plan document. The system test plan identifies all testing-related activities that must be performed, specifies the schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for each test case.

Activities undertaken during maintenance

z

Maintenance of a typical software product requires much more than the effort necessary to develop the product itself. Many studies carried out in the past confirm this and indicate that the relative effort of development of a typical software product to its maintenance effort is roughly in the 40:60 ratio.

Activities undertaken during maintenance

z

Maintenance involves performing following kinds of activities:

Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customers requirements. This is called perfective maintenance. Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance.

Shortcomings of the classical waterfall model

z

The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the engineers during any of the life cycle phases. However, in practical development environments, the engineers do commit a large number of errors in almost every phase of the life cycle. The source of the defects can be many: oversight, wrong assumptions, use of inappropriate technology, communication gap among the project engineers, etc. Once a defect is detected, the engineers need to go back to the phase where the defect had occurred and redo some of the work.

Prototype
z z

A prototype is a toy implementation of the system. A prototype usually exhibits limited functional capabilities, low reliability, and inefficient performance compared to the actual software. A prototype is usually built using several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy functions. A prototype usually turns out to be a very crude version of the actual system.

Prototype
z

This is something similar to what the architectural designers of a building do; they show a prototype of the building to their customer. The customer can evaluate whether he likes it or not and the changes that he would need in the actual product. Another reason for developing a prototype is that it is impossible to get the perfect product in the first attempt. Many researchers and engineers advocate that if you want to develop a good product you must plan to throw away the first version. The experience gained in developing the prototype can be used to develop the final product.

When to use prototype model

A prototype of the actual product is preferred in situations such as: user requirements are not complete technical issues are not clear
Example 1: User requirements are not complete : In any application software like billing in a retail shop, accounting in a firm, etc the users of the software are not clear about the different functionalities required. Once they are provided with the prototype implementation, they can try to use it and find out the missing functionalities. Example 2: Technical issues are not clear Suppose a project involves writing a compiler and the development team has never written a compiler. In such a case, the team can consider a simple language, try to build a compiler in order to check the issues that arise in the process and resolve them. After successfully building a small compiler (prototype), they would extend it to one that supports a complete language.

Spiral model
z z z

The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. Each phase in this model is split into four sectors (or quadrants). The following activities are carried out during each phase of a spiral model.

Spiral model

Spiral model
z

First quadrant (Objective Setting)

During the first quadrant, it is needed to identify the objectives of the phase.

Second Quadrant (Risk Assessment and Reduction)

A detailed analysis is carried out for each identified project risk. Steps are taken to reduce the risks. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.

Spiral model

Third Quadrant (Development and Validation)

Develop and validate the next level of the product after resolving the identified risks.

-Fourth Quadrant (Review and Planning)

Review the results achieved so far with the customer and plan the next iteration around the spiral. Progressively more complete version of the software gets built with each iteration around the spiral.

Spiral model

Circumstances to use spiral model

z

The spiral model is called a meta model since it encompasses all other life cycle models. Risk handling is inherently built into this model. The spiral model is suitable for development of technically challenging software products that are prone to several kinds of risks. However, this model is much more complex than the other models this is probably a factor deterring its use in ordinary projects.