Softengg Lec 1

Embed Size (px)

Citation preview

  • 8/3/2019 Softengg Lec 1

    1/51

    Advance Software Engineering

  • 8/3/2019 Softengg Lec 1

    2/51

    Todays Lecture: Agenda

    z Course Outline

    z Mark Distribution

    z Deliverables

    z Lesson 1

  • 8/3/2019 Softengg Lec 1

    3/51

    Course Outline

    z Text Book:Software Engineering by Ian SommervilleSoftware Engineering: A practitioners Approach by Roger S.

    Pressman, Seventh Edition.z References:

    Software Requirements Using The Unified Process: A PracticalApproach, 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, AddisonWesley, 2003

    Recent research papers Case studies

  • 8/3/2019 Softengg Lec 1

    4/51

    Course Outline

    z Basic Introduction to Software Engineering

    Software life cycle model.

    SRS Document

    Functional and non-functional requirements

    Software Design

  • 8/3/2019 Softengg Lec 1

    5/51

    Course Outline

    z Advance

    Module/Functional Design

    Cohesion/Coupling

    Coding

    Debugging Integration

    White/Black Box Testing

    Software Maintenance

  • 8/3/2019 Softengg Lec 1

    6/51

    Course Outline

    z Advance

    Formal Methods

    Software Reuse

    Software System Re-engineering

    Software Reverse Engineering Future of Software Engineering

  • 8/3/2019 Softengg Lec 1

    7/51

    Marks Distribution

    z Quizzes 10

    z Midterm 20 (Open book)

    z Assignments 10

    z

    Project 30z Final 30 (Open book)

  • 8/3/2019 Softengg Lec 1

    8/51

    Project/Exams

    z Running Software

    z 50-100 Page Document

    z Presentation

    z

    Examples of Project: Compiler

    Library System

    z Case Study Exams

  • 8/3/2019 Softengg Lec 1

    9/51

    Word of Caution

    z Copying- multiply by Zero

    z Project must be working

    50% REDUCTION of final Mark

  • 8/3/2019 Softengg Lec 1

    10/51

    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

  • 8/3/2019 Softengg Lec 1

    11/51

    Scope and necessity of softwareengineering

    z Software engineering is an engineering approach forsoftware development.

    z We can alternatively view it as a systematiccollection of past experience. The experience isarranged in the form of methodologies andguidelines.

    z A small program can be written without usingsoftware engineering principles. But if one wants todevelop a large software product, then softwareengineering principles are MUST to achieve a goodquality software cost effectively.

  • 8/3/2019 Softengg Lec 1

    12/51

    z Without using software engineering principles it would bedifficult to develop large programs.

    z A program of size 1,000 lines of code has some complexity. Buta program with 10,000 LOC is not just 10 times more difficult todevelop, but may as well turn out to be 100 times more difficultunless software engineering principles are used.

    z In such situations software engineering techniques come to

    rescue.z Software engineering helps to reduce the programming

    complexity.

    z Software engineering principles use two important techniquesto reduce problem complexity.

    z Abstraction and Decomposition

    Scope and necessity of softwareengineering

  • 8/3/2019 Softengg Lec 1

    13/51

    Abstraction

    z The principle of abstraction implies that a problemcan be simplified by omitting irrelevant details.

    z In other words, the main purpose of abstraction is toconsider only those aspects of the problem that arerelevant for certain purpose and suppress otheraspects that are not relevant for the given purpose.

    z Once the simpler problem is solved, then the omitteddetails can be taken into consideration to solve thenext lower level abstraction, and so on.

    z Abstraction is a powerful way of reducing thecomplexity of the problem.

  • 8/3/2019 Softengg Lec 1

    14/51

    Abstraction

  • 8/3/2019 Softengg Lec 1

    15/51

    Decomposition

    z In this technique, a complex problem is divided into several smallerproblems and then the smaller problems are solved one by one.

    z However, in this technique any random decomposition of a probleminto smaller parts will not help.

    z The problem has to be decomposed such that each component of thedecomposed problem can be solved independently and then thesolution of the different components can be combined to get the fullsolution.

    z A good decomposition of a problem should minimize interactionsamong various components.

    z If the different subcomponents are interrelated, then the differentcomponents cannot be solved separately and the desired reduction incomplexity will not be realized.

  • 8/3/2019 Softengg Lec 1

    16/51

    Decomposition

  • 8/3/2019 Softengg Lec 1

    17/51

    Future of Software Engineering

    z Microsoft, IBM

    z Any Commercial Software

    z App Development Apple Store

    Androidz Two Tier

    Software

    Engineering

  • 8/3/2019 Softengg Lec 1

    18/51

    Software Life Cycle Model

    z A software life cycle model (also called processmodel) is a descriptive and diagrammaticrepresentation of the software life cycle.

    z A life cycle model represents all the activitiesrequired to make a software product.

    z It also captures the order in which these activitiesare to be undertaken.

    z In other words, a life cycle model maps the differentactivities performed on a software product from itsstart to retirement.

  • 8/3/2019 Softengg Lec 1

    19/51

    The need for a software life cyclemodel

    z Without using of a particular life cycle modelthe development of a software product wouldnot be in a systematic and disciplinedmanner.

    z

    When a software product is being developedby a team there must be a clearunderstanding among team members aboutwhen and what to do. Otherwise it wouldlead to chaos and project failure.

  • 8/3/2019 Softengg Lec 1

    20/51

    Different software life cycle models

    z Many life cycle models have been proposedso far. Each of them has some advantagesas well as some disadvantages. A fewimportant and commonly used life cyclemodels are as follows: Classical Waterfall Model

    Iterative Waterfall model

    Prototyping Model or Evolutionary Model

    Spiral Model

  • 8/3/2019 Softengg Lec 1

    21/51

    Classical Waterfall Model

    z The classical waterfall model is intuitively themost obvious way to develop software.

    z Thus, this model can be considered to be atheoretical way of developing software.

    z But all other life cycle models are essentiallyderived from the classical waterfall model.So, in order to be able to appreciate other lifecycle models it is necessary to learn theclassical waterfall model.

  • 8/3/2019 Softengg Lec 1

    22/51

    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

  • 8/3/2019 Softengg Lec 1

    23/51

  • 8/3/2019 Softengg Lec 1

    24/51

    Activities undertaken during feasibilitystudy

    z The main aim of feasibility study is to determine whether itwould be financially and technically feasible to develop theproduct.

    z At first project managers or team leaders try to have a roughunderstanding of what is required to be done by visiting theclient side.

    z Then they examine each of the solutions in terms of what kind

    of resources required, what would be the cost of developmentand what would be the development time for each solution.

    z Based on this analysis they pick the best solution anddetermine whether the solution is feasible financially andtechnically.

  • 8/3/2019 Softengg Lec 1

    25/51

    Activities undertaken duringrequirements analysis & specification

    z The aim of the requirements analysis and

    specification phase is to understand the

    exact requirements of the customer and to

    document them properly. This phaseconsists of two distinct activities, namely

    User Requirements and analysis, and

    Requirements specification

  • 8/3/2019 Softengg Lec 1

    26/51

    User Requirements

    z Get user requirements form the client.

    z The goal is to collect all relevant information

    from the customer regarding the product to

    be developed.

  • 8/3/2019 Softengg Lec 1

    27/51

    27

    Requirements Analysis

    z The aim of requirements analysis is todiscover problems with the systemrequirements, especially incompletenessand inconsistencies

    z Detailed analysis usually takes place afterthe initial draft of the requirementsdocument is produced

  • 8/3/2019 Softengg Lec 1

    28/51

    28

    Comments on Requirements Analysis

    z Analysts read the requirements, highlightproblems, and discuss them in requirementsreview meetings

    z This is a time-consuming and expensive

    activity Requirement Engineers are mostly senior people,

    when they spend time it becomes expensiveactivity

    However, its very important to remove errors fromthe set of requirements at this stage why?

    So time and money at this stage is worth

  • 8/3/2019 Softengg Lec 1

    29/51

    29

    Requirements Analysis Stages

    z Necessity checking

    z Consistency and completeness checking

  • 8/3/2019 Softengg Lec 1

    30/51

    30

    Necessity Checking

    z The need for the requirement is analyzed.

    z 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

  • 8/3/2019 Softengg Lec 1

    31/51

    31

    Consistency and CompletenessChecking

    z The requirements are cross-checked for

    consistency and completeness.

    z Consistency means that no requirements

    should be contradictory

    z Completeness means that no services or

    constraints which are needed have been

    missed out

  • 8/3/2019 Softengg Lec 1

    32/51

    32

    User Requirement Analysis

    z Premature design Does the requirement include premature design or

    implementation information?

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

    z Combined requirements Does the description of a requirement describe a single

    requirement or could it be broken down into several differentrequirements?

    z If yes, break it down to several different requirements

    z That will help in determining the consistency andcompleteness aspect of the requirement set and reducingcomplexity.

  • 8/3/2019 Softengg Lec 1

    33/51

    33

    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 reallynecessary?

    z Use of non-standard hardware

    Does the requirement mean that non-standard hardware orsoftware must be used? To make this decision, you need toknow the computer platform requirements

  • 8/3/2019 Softengg Lec 1

    34/51

    Activities undertaken duringrequirements analysis & specification

    z After all ambiguities, inconsistencies, and

    incompleteness have been resolved and all

    the requirements properly understood, the

    requirements specification activity can start.

    z During this activity, the user requirementsare systematically organized into a Software

    Requirements Specification (SRS) document.

  • 8/3/2019 Softengg Lec 1

    35/51

    Activities undertaken during design

    z 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.z In technical terms, during the design phase

    the software architecture is derived from the

    SRS document.

  • 8/3/2019 Softengg Lec 1

    36/51

    Activities undertaken during codingand unit testing:

    z The purpose of the coding and unit testing phase(sometimes called the implementation phase) ofsoftware development is to translate the softwaredesign into source code.

    z Each component of the design is implemented as a

    program module. The end-product of this phase is aset of program modules that have been individuallytested.

    z During this phase, each module is unit tested todetermine the correct working of all the individualmodules. It involves testing each module in isolationas this is the most efficient way to debug the errors

    identified at this stage.

  • 8/3/2019 Softengg Lec 1

    37/51

    Activities undertaken duringintegration and system testing:

    z Integration of different modules is undertaken once they havebeen coded and unit tested.

    z During the integration and system testing phase, the modulesare integrated in a planned manner. The different modulesmaking up a software product are almost never integrated inone shot.

    z Integration is normally carried out incrementally over a numberof steps. During each integration step, the partially integratedsystem is tested and a set of previously planned modules areadded to it.

    z Finally, when all the modules have been successfully integratedand tested, system testing is carried out.

  • 8/3/2019 Softengg Lec 1

    38/51

    Activities undertaken duringintegration and system testing:

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

    z testing: It is the system testing performed by the developmentteam.

    z testing: It is the system testing performed by a friendly set ofcustomers.

    z acceptance testing: It is the system testing performed by the clienthimself after the product delivery to determine whether to accept or

    reject the delivered product.z System testing is normally carried out in a planned manner

    according to the system test plan document. The system testplan identifies all testing-related activities that must beperformed, specifies the schedule of testing, and allocatesresources. It also lists all the test cases and the expectedoutputs for each test case.

  • 8/3/2019 Softengg Lec 1

    39/51

    Activities undertaken duringmaintenance

    z Maintenance of a typical software product

    requires much more than the effort

    necessary to develop the product itself.

    z Many studies carried out in the past confirm

    this and indicate that the relative effort ofdevelopment of a typical software product to

    its maintenance effort is roughly in the 40:60

    ratio.

  • 8/3/2019 Softengg Lec 1

    40/51

    Activities undertaken duringmaintenance

    z Maintenance involves performing following kinds ofactivities: Correcting errors that were not discovered during the

    product development phase. This is called correctivemaintenance.

    Improving the implementation of the system, and enhancing

    the functionalities of the system according to the customersrequirements. This is called perfective maintenance.

    Porting the software to work in a new environment. Forexample, porting may be required to get the software towork on a new computer platform or with a new operatingsystem. This is called adaptive maintenance.

  • 8/3/2019 Softengg Lec 1

    41/51

  • 8/3/2019 Softengg Lec 1

    42/51

    Shortcomings of the classical waterfallmodel

    z The classical waterfall model is an idealistic one since itassumes that no development error is ever committed by theengineers during any of the life cycle phases.

    z However, in practical development environments, the engineersdo commit a large number of errors in almost every phase ofthe life cycle.

    z The source of the defects can be many: oversight, wrongassumptions, use of inappropriate technology, communicationgap among the project engineers, etc.

    z Once a defect is detected, the engineers need to go back to thephase where the defect had occurred and redo some of thework.

  • 8/3/2019 Softengg Lec 1

    43/51

    Prototype

    z A prototype is a toy implementation of the system.

    z A prototype usually exhibits limited functional

    capabilities, low reliability, and inefficient

    performance compared to the actual software.

    z

    A prototype is usually built using several shortcuts.The shortcuts might involve using inefficient,

    inaccurate, or dummy functions.

    z A prototype usually turns out to be a very crude

    version of the actual system.

  • 8/3/2019 Softengg Lec 1

    44/51

    Prototype

    z This is something similar to what the architecturaldesigners of a building do; they show a prototype ofthe building to their customer. The customer canevaluate whether he likes it or not and the changesthat he would need in the actual product.

    z Another reason for developing a prototype is that it isimpossible to get the perfect product in the firstattempt.

    z Many researchers and engineers advocate that ifyou want to develop a good product you must plan tothrow away the first version. The experience gainedin developing the prototype can be used to develop

    the final product.

  • 8/3/2019 Softengg Lec 1

    45/51

    When to use prototype model

    z A prototype of the actual product is preferred in situations such as:

    user requirements are not complete

    technical issues are not clear

    z Example 1: User requirements are not complete : In any applicationsoftware like billing in a retail shop, accounting in a firm, etc the users of thesoftware are not clear about the different functionalities required. Once they areprovided with the prototype implementation, they can try to use it and find out

    the missing functionalities.

    z Example 2: Technical issues are not clearSuppose a project involves writinga compiler and the development team has never written a compiler. In such acase, the team can consider a simple language, try to build a compiler in orderto check the issues that arise in the process and resolve them. Aftersuccessfully building a small compiler (prototype), they would extend it to onethat supports a complete language.

  • 8/3/2019 Softengg Lec 1

    46/51

    Spiral model

    z The diagrammatic representation of this modelappears like a spiral with many loops.

    z The exact number of loops in the spiral is not fixed.

    z Each loop of the spiral represents a phase of thesoftware process. For example, the innermost loopmight be concerned with feasibility study. The nextloop with requirements specification, the next onewith design, and so on.

    z Each phase in this model is split into four sectors (orquadrants). The following activities are carried outduring each phase of a spiral model.

  • 8/3/2019 Softengg Lec 1

    47/51

    Spiral model

  • 8/3/2019 Softengg Lec 1

    48/51

    Spiral model

    z First quadrant (Objective Setting) During the first quadrant, it is needed to identify the

    objectives of the phase.

    z 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 arisk that the requirements are inappropriate, a prototypesystem may be developed.

  • 8/3/2019 Softengg Lec 1

    49/51

    Spiral model

    z Third Quadrant (Development and Validation)

    Develop and validate the next level of the product after

    resolving the identified risks.

    z -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.

  • 8/3/2019 Softengg Lec 1

    50/51

    Spiral model

  • 8/3/2019 Softengg Lec 1

    51/51

    Circumstances to use spiral model

    z The spiral model is called a meta model since it

    encompasses all other life cycle models.

    z 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.

    z However, this model is much more complex than the

    other models this is probably a factor deterring its

    use in ordinary projects.