• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Sanjay
 

Sanjay

on

  • 412 views

capital structure of NTPC

capital structure of NTPC

Statistics

Views

Total Views
412
Views on SlideShare
411
Embed Views
1

Actions

Likes
0
Downloads
9
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Sanjay Sanjay Presentation Transcript

    • The Spiral Model of Software Development and Enhancement Barry W. Boehm, TRW Defense Systems Group Victor Velez Group # 5 April 05/04
    • Outline
      • • Introduction
      • • Previous Models
      • • The Spiral Model
      • • TRW-SPS Application
      • • Advantages and Difficulties
      • • Risk Management
      • • Conclusions
      • • Future of the Spiral Model
      • • Discussion
    • Introduction
      • Basically, the idea of Spiral Model is evolutionary development, using the waterfall model for each step; it's intended to help by a Risk-Driven Approach . Don't define in detail the entire system at first. The developers should only define the highest priority features. Define and implement those, then get feedback from users/customers (such feedback distinguishes "evolutionary" from "incremental" development). With this knowledge, they should then go back to define and implement more features in smaller chunks.
    • A Risk-Driven Approach
      • • Different idea of software development.
      • • How does this project affect the
      • developers and the clients?
      • • How does each step in the project affect
      • its overall development?
      • • Not used in previous development models.
      • – Usually code-driven or document-driven.
    • Software Process Model
      • As opposed to a software methodology .
      • – How to navigate through each phase (Data,
      • Control)
      • – How to represent phase products (Diagrams)
      • • Used to determine the order of the stages
      • and to establish the transition criteria.
      • – What do we do next?
      • – How long shall we continue doing it?
      • • Provides guidance between the different
      • phases of a project.
    • Previous Software Process Models
      • An evolution of models
      • – Code & Fix
      • – Stagewise & Waterfall
      • – Evolutionary Development
      • – Transform Model
    • Spiral Model
      • A different approach born out of the evolution of the Waterfall Model.
      • • Encompasses the previous models as special
      • cases, and can make use of a combination of
      • models.
      • • Risk analysis asks, “ What are the areas of
      • uncertainty, and what is the probability that
      • they will slow the progress of development?”
    • Initiating/Terminating the Process
      • • Initiating the process
      • – Hypothesize that a particular operational mission(s)
      • can be improved by software effort.
      • • Test this hypothesis throughout.
      • • Terminating
      • – If a spiral violates its hypothesis then the
      • spiral is terminated.
      • – Otherwise it ends with the installation of a
      • new or modified software product.
    • Cycle Requirements
      • If alternatives or uncertainties are found
      • they must be resolved.
      • • Risk-driven “subsetting” allows a mixture of
      • other software process models, as
      • necessary, until a high-risk situation is
      • resolved.
      • – Specification-oriented (Transform or Stagewise)
      • – Prototype-oriented (Waterfall)
      • – Automatic-transformation oriented (Transform)
      • – Simulation-oriented (Evolutionary)
    • Cycle Requirements…Cont
      • Each cycle is completed by a review by
      • the people concerned with the project.
      • • Plans for the next cycle should be
      • introduced.
      • • With each succeeding level in the spiral
      • the level of detail increases.
    • Applied to TRW-SPS
      • An example of how the Spiral model works in a
      • large system.
      • • Software Productivity System (SPS) – a group of integrated software development tools for use within TRW, as well as for other clients.
      • • Spiral Model rounds
      • – Rounds correspond to a level in the spiral.
      • – In this case, a Round 0 was needed to determine
      • initial feasibility of the TRW-SPS project, but is not
      • necessary for all projects.
    • More Rounds??
      • Succeeding rounds may be necessary.
      • • Depends on the amount of risk.
      • – Ex. The risk alleviation of the RTT
      • preliminary design specification.
      • • More attractive alternatives may be found.
      • – Ex. The change in UDF tool requirements.
    • Spiral Model Features
      • Balances all of the risk elements, i.e. the
      • high-risk elements must be lowered first.
      • • Offers prototyping as a risk-reduction
      • option at any stage of development.
      • • It allows reworks of earlier stages as more
      • attractive alternatives are identified.
      • • Detail isn’t necessary until detail is
      • needed. (Round 0)
    • Results
      • • The Software Productivity System (SPS)
      • has grown to over 300 tools and 1.3
      • million instructions.
      • • Over 25 projects have used SPS with
      • overall productivity up 50%; most projects
      • have doubled productivity.
      • • One underestimation of Unix compatibility
      • led to some TRW projects not using SPS.
    • Advantages
      • 􀀹It promotes reuse of existing software in
      • early stages of development.
      • 􀀹Allows quality objectives to be formulated
      • during development.
      • 􀀹Provides preparation for eventual
      • evolution of the software product.
      • 􀀹Eliminates errors and unattractive
      • alternatives early.
    • Disadvantages
      • 􀂙 Spiral model not yet complete (in 1988).
      • 􀂙 Matching to contract software
      • – Internal projects have more freedom.
      • – Contract software demands total control and a full
      • picture of the deliverables in advance.
      • 􀂙 Relying on risk-assessment expertise.
      • 􀂙 Need for further elaboration of spiral model steps.
      • – Milestones and specifications.
      • – Guidelines and checklists.
    • Conclusions
      • The paper draws four conclusions:
      • 1. The risk-driven nature provides adaptability
      • for a full range of software projects.
      • 2. The model has been successful in a large
      • application, the TRW-SPS.
      • 3. The model is not yet fully elaborated.
      • 4. Even partial implementations of the model,
      • such as the risk management plan, are
      • compatible with the other process models.
    • Evaluating Software Engineering Standards Shari Lawrence Pfleeger, Norman Fenton, and Stella Page Centre for Software Reliability
    • Introduction
      • This article reports on the results for:
      • the Smartie project ( S tandards and M ethods
      • A ssessment using R igorous T echniques in
      • I ndustrial E nviroments).
      • Smartie :
      • - uses standards (some of those have not been
      • patented) to reflect the user’s needs and
      • builder’s practices to improve software
      • development processes and products.
      • - Identifies the benefits of using the standard.
    • What is a Good Standard
      • It involves at least three aspects:
      • 1 What attributes of the final product are supposed to
      • improve by using the standard.
      • 2 Cost of applying the standard.
      • 3 How the standard is being complied with requirements
      • - Reference-only : no way to determine compliance
      • - Subjective : only a subjective measure of conformance
      • - Partially objective : Objective, but still requires objectivity
      • - Completely objective : most desirable kind
    • To what do our standards apply
      • It apply to:
        • Process:
      • validation of specifications vs. requirements
        • Internal product:
      • refers to the code
        • External product:
      • user experiences( e.g. reliability)
        • Resources:
      • staff, tools and support software
    • Are Software Standards like other Standards?
      • No are not.
      • Software engineering standards are heavy on process and light on product , while other engineering standards are the reverse
      • Most other engineering include in their standard a description of the method to be used to asses compliance. Software one, lack objective assessment criteria. So, are not always based on rigorous experimental results
    • Conclusions
      • The Smartie framework is practical and effective in identifying problems with standards and making changes that are needed on them
      • Some standards apply to certain types of modules. So notions of conformance must be adjusted to consider only that part of the system
      • Software engineering standards should be better balanced, with more product requirements in relation to process and resource requirements
    • Thank you