introkiras by A2u4DNV


									Software Engineering: An
             Software costs
• Software costs often dominate computer system
  costs. The costs of software on a PC are often
  greater than the hardware cost.
• Software costs more to maintain than it does to
  develop. For systems with a long life,
  maintenance costs may be several times
  development costs.
• Software engineering is concerned with cost-
  effective software development.
            What is software?
• Software products may be developed for a
  particular customer or may be developed for a
  general market.
• Software products may be
  – Generic - developed to be sold to a range of different
    customers e.g. PC software such as Excel or Word.
  – Bespoke (custom) - developed for a single customer
    according to their specification.
• New software can be created by developing new
  programs, configuring generic software systems
  or reusing existing software.
      Challenge in large projects
• Developing large/complex software application
  is very challenging
  –   Effort intensive
  –   High cost
  –   Long development time
  –   Changing needs for users
  –   High risk of failure, user acceptance, performance,
      maintainability, …
   Successful software system
• Software development projects have not always
  been successful
• When do we consider a software application
  –   Development completed
  –   It is useful
  –   It is usable, and
  –   It is used
• Cost-effectiveness, maintainability implied
           Reasons for failure

•   Cost over-runs
•   Does not solve user’s problem
•   Poor quality of software
•   Poor maintainability
          Reasons for failure
• Ad hoc software development results in such
  – No planning of development work (e.g. no milestones
  – Deliverables to user not identified
  – Poor understanding of user requirements
  – No control or review
  – Technical incompetence of developers
  – Poor understanding of cost and effort by both
    developer and user
           The Software Crisis

• The term was used to describe the impact of
  rapid increases in computer power and the
  complexity of the problems which could be
  tackled. In essence, it refers to the difficulty of
  writing correct, understandable, and verifiable
  computer programs. The roots of the software
  crisis are complexity, expectations, and change.
• The most visible symptoms of the software crisis
   – Late delivery, over budget
   – Product does not meet specified requirements
   – Inadequate documentation
                Engineering …
• Requires well-defined approach : repeatable,
• Large projects requires managing the project
   – Manage people, money (cost), equipment, schedule

• “engineering” a solution:
   – To design, develop (build, fabricate) an artifact that
     meets specifications efficiently, cost-effectively and
     ensuring quality
   – Using scientific principles.
• Quality extremely important : relates to failures,
  efficiency, usability
                   Large Projects
• Involve different types of people
   – Large building : architect, civil engineer, electrical engineer,
     workers (masons, carpenters), ….
• Continuous supervision for quality assurance
   – On site supervisors (check cement/steel quality, ensuring proper
     mix of sand & cement, ….)
• Many deliverables : architecture plan, model, structure
  diagrams, electrical cabling layouts, …
• Standards, regulations, conventions need to be followed
• Steps, milestones defined and reviews are carried out;
  progress is visible
• Project planning and project management essential
 What is software engineering?
• Software engineering is an engineering
  discipline that is concerned with all aspects of
  software production.
• Software engineers should adopt a systematic
  and organised approach to their work and use
  appropriate tools and techniques depending on
  the problem to be solved, the development
  constraints and the resources available
 What is software engineering?
• Software Engineering is Not an Isolated Activity!
• Successful Software Engineering Must:
  – Involve group of individuals with diverse backgrounds,
    skills, and expertise all geared towards a common
  – engineering methods that promote accurate and
    precise specification, design, development, testing,
    integration, maintenance, evolution, etc.
      Software engineers should
          –adopt a systematic and organised approach to their work
          –use appropriate tools and techniques depending on
              •the problem to be solved,
              •the development constraints and
              •the resources available
Why is Software Engineering
– Financial, security, and safety critical systems
  rely on software
– Software mediates every aspect of our
  Internet experience
– The economies of all developed nations are
  dependent on software
– There is an increasing need to cost effectively
  develop high-quality software
          Software projects
• Software is different from other products
  – Cost of production concentrated in
  – Maintenance consists of making corrections
    and enhancing or adding functions
  – Progress in development is difficult to
   Apply Engineering Approach
• Hence planning and control even more important in
  software development  engineering approach:
   –   Attempt to estimate cost/effort
   –   Plan and schedule work
   –   Involve user in defining requirements
   –   Identify stages in development
   –   Define clear milestones so that progress can be measured
   –   Schedule reviews both for control and quality
   –   Define deliverables
   –   Plan extensive testing
What is the difference between software
 engineering and system engineering?
• System engineering is concerned with all
  aspects of computer-based systems
  development including hardware, software and
  process engineering. Software engineering is
  part of this process concerned with developing
  the software infrastructure, control, applications
  and databases in the system.
• System engineers are involved in system
  specification, architectural design, integration
  and deployment.
What is the difference between software
 engineering and system engineering?
 • Software engineering is part of System engineering
 • System engineering is concerned with all aspects of
   computer-based systems development including
    – hardware,
    – software and
    – process engineering
 • System engineers are involved in
      system specification,
      architectural design,
      integration and deployment
    Job of Software Developer is
• Dealing with users
  – Ill-defined requirements
  – Concern with ease-of-use and response time
• Dealing with technical people
  – Concerned with coding, databases, file structures,
• Dealing with management
  – Concerned with return on their investment
  – Cost-benefit analysis
  – Schedule
        Product and Process
• Product : What is delivered to the
  customer is the product. Basically it is a
  set of deliverables only.
• Process: Process is the way in which we
  produce software. An efficient process is
  required to produce good quality products
                Software Process
• A software process is a set of activities and their output,
  which result in a software product
• A set of activities whose goal is the development or evolution of
• Generic activities in all software processes are:
   – Specification - what the system should do and its development
   – Development - production of the software system
   – Validation - checking that the software is what the customer wants
   – Evolution - changing the software in response to changing
      demands Process consists of activities/steps to be carried out in a
      particular order
• Software process deals with both technical and management issues
• Consists of different types of process
• Process for software development: produces software as end-result
   – multiple such processes may exist
   – a project follows a particular process
Software Engineering Layers

                 process model
                a “quality” focus

     The bedrock that supports software engineering is a quality
     focus. Software engineering process is the glue that holds
     the technology layers together and enables rational and
     timely development of computer software
Common Process Framework

    Common process framework
      Framework activities
         work tasks
         work products
         milestones & deliverables
         QA checkpoints
      Umbrella Activities
            Umbrella Activities
•   Software project management
•   Formal technical reviews
•   Software quality assurance
•   Software configuration management
•   Document preparation and production
•   Reusability management
•   Measurement
•   Risk management
 The Primary Goal:
   High Quality


   High quality = project timeliness!


               Less rework!
               Process Types
• Process for managing the project
  –   defines project planning and control
  –   effort estimations made and schedule prepared
  –   resources are provided
  –   feedback taken for quality assurance
  –   monitoring done.
• Process for managing the above processes
  – Improving the processes based on new techniques,
    tools, etc.
  – Standardizations and certifications (ISO, CMM)
           Step in a Process
• Each step has a well-defined objective
• Requires people with specific skills
• Takes specific inputs and produces well-defined
• Step defines when it may begin (entry criteria)
  and when it ends (exit criteria)
• Uses specific techniques, tools, guidelines,
                 Process step
• Step must be executed as per project plan that
  gives duration, effort, resources, constraints, etc.
• It must produce information for management so
  that corrective actions can be taken
   – E.g., adding more resources
• A step ends in a review (V&V)
   – Verification: check consistency of outputs with inputs
     (of the step)
   – Validation: check consistency with user needs
              Process step

(entry criteria)                            (exit criteria)
  (entry criteria)                            (exit criteria)
                 actions to
                 beactions to
                    carried       Review
 inputs            be carried     V&V      outputs
   inputs            out           V&V      outputs

                                       info for
                                         info for
                 Project                 management
                 Control info
                  Control info
 Characteristics of a Good Process
• Should be precisely defined – no ambiguity
  about what is to be done, when, how, etc.
• It must be predictable – can be repeated in other
  projects with confidence about its outcome
  – Predictable with respect to effort, cost:
    Project A: Web-based library applications done by 3
    persons in 4 months
     another project B (guest house bookings), similar in
    complexity should also take about 12 person months.
              A Good Process
   – Predictable for quality: with respect to number and
     type of defects, performance, …
• Predictable process is said to be ‘under
  statistical control’ , where actual values are close
  to expected values
• It supports testing and maintainability
   – Maintenance by third party
   – Follow standards, provide necessary documentation
   – This characteristic differentiates between prototype
     and product
             A Good Process
• Facilitates early detection of and removal of
  – Defects add to project cost
  – Late detection/correction is costly
• It should facilitate monitoring and improvement
  – Based on feedback
  – Permit use of new tools, technologies
  – Permit measurements
       Process Assessment

                                  Is examined
                         Software Process                  capabilities
                         Assessment                        and risk of

                                                Leads to
                     Leads to

  Software Process
  Improvement                   motivates
     Deliverables and Milestone
• A software development milestone is a scheduled
   – for which some project member or manager is accountable.
   – is used to measure progress.
• A milestone typically includes:
   – a formal review.
   – the issuance of documents.
   – the delivery of a (sometimes intermediate) product.
• Deliverables: Different deliverables are generated during
  software development . The examples are source code,
  user manuals
  The Development Life-Cycle
• A project is a set of activities,
  interactions and results.
• A life-cycle or a software process is
  the organisational framework for a
 Software Development Life Cycle
• Software Development Life Cycle (SDLC) is the
  process of developing information systems
  through analysis, planning, design,
  implementation, integration maintenance and
  testing of software applications. SDLC is also
  known as information systems development or
  application development. The development of
  quality software involves the usage of a
  structured approach towards the design and
  development of the end product
  Software Development Life Cycle
• Software Development Life Cycle (SDLC) is a methodology that is
  typically used to develop, maintain and replace information systems
  for improving the quality of the software design and development
  process. The typical phases are analysis, estimation, design,
  development, integration and testing and implementation. The
  success of software largely depends on proper analysis, estimation,
  design and testing before the same is implemented.
•   The Software Development Life Cycle is the cycle in which the
  business analysts, the software developers, the database designers
  and/or the database developers, and end users collaborate to build
  the application software. Basically, it involves designing the
  application from scratch, documenting everything, adding the
  improvements and fixing the bugs that occur in the SDLC. It is the
  lifecycle of Software from concept to obsolescence.
• Broadly, the SDLC steps can be
  categorized into:
• ·     Requirement Specification and
  Analysis and Design
• ·     Coding and Testing
• ·     Deployment and Support
  The Development Life-Cycle
• A life-cycle…
  – is a finite and definite period of time.
  – starts when a software product is conceived.
  – ends when the product is no longer available
    or effective for use.
• Any life-cycle is organised in (composed
  of) phases
  Waterfall Model for Development
• Here, steps (phases) are arranged in linear order
   – A step take inputs from previous step, gives output to next step
     (if any)
   – Exit criteria of a step must match with entry criteria of the
     succeeding step
• It follows ‘specify, design, build’ sequence that is
  intuitively obvious and appears natural
• Produces many intermediate deliverables, usually
   – Standard formats defined
   – Act as ‘baseline’ used as reference (for contractual obligations,
     for maintenance)
   – Important for quality assurance, project management, etc.
• It is widely used (with minor variations) when
  requirements are well understood
                Waterfall Model
Requirement Analysis           • is the root of all other models
and Specification
                               • still prevalent in general

            Implementation &
            Unit Testing

                  Integration &
                  System testing

                           Installation &
               Waterfall Model
• The phases always occur in this order and do not
  overlap. The developer must complete each phase
  before the next phase begins. This model is called the
  waterfall model because its diagrammatic representation
  resembles a cascade of waterfalls.
• 1. Requirement analysis & Specification :
The goal of this phase is to understand the requirements of
  the user. The requirements describe the “what “ of the
  system and not the “how”. This phase produces a large
  document ,written in natural language ,which contains
  the description of what the system will do without
  describing how it will be done. The resultant document is
  called : Software Requirement Specification (SRS)
2.Design : The SRS document is produced in the previous
  phase, which contains the exact requirements of the
  customer. The goal of this phase is to transform the
  requirements into a structure that is suitable for
  implementation in some programming language.
              Waterfall Model
• 3. Implementation and Unit testing:
During this phase the actual implementation of the
  system proceeds. The small modules are tested
  in isolation from the rest of the software product
4. Integration and System testing :
The small modules are integrated and the
  objective is to test the entire system as a whole,
  because effective testing will contribute to the
  delivery of higher quality software product, more
  satisfied users ,lower maintenance costs and
  more accurate results. It is a very expensive
  activity and consumes one third to one half of a
  typical development project
           Waterfall Model
• 5. Operation and Maintenance phase :
Finally, after rigorous testing the product is
  delivered to the client, the release of the
  software inaugurates the operation and
  Software maintenance phase of the life
  cycle. Maintenance includes enhancement
  of the capabilities, deletion of obsolete
  capabilities and optimization
 Deliverables in Waterfall Model
• Project plan and feasibility report
• Requirements document (SRS : Software Requirement
• System design document
• Detailed design document
• Test plans and test reports
• Source code
• Software manuals (user manual, installation manual)
• Review reports
    Advantages of the Waterfall
• The following are the advantages of the
  Waterfall Model.
• ·     It is very simple and easy to implement
  meaning it is well suited for small projects.
• · The model is rigid and each of the phases
  has certain deliverables and a review process
  immediately after a particular phase is over.
 Shortcomings of Waterfall Model
• Requirements may not be clearly known,
  especially for applications not having
  existing (manual) counterpart

• Requirements change with time during
  project life cycle itself
• Considered documentation-heavy: so
  much documentation may not be required
  for all types of projects.
    Shortcomings of Waterfall Model
    – late feedback
      to both customer and developer
    – minimal risk management
      for both customer and developer
• late testing maturity
• This model is not suitable for accommodating any change
• A working model is seen very late in the project’s life
• It cannot be guaranteed that one phase of this model is perfec
  before we move on to the immediate next phase in the model.
• ·      It is not suited for long or complex projects or projects
  where the requirements can change.
     Cost/Effort Distribution
                Total accumulated cost

Problem Feasibility Analysis   System    Detailed Implemen- Mainten-
definition study               design    design   tation    ance

    • Accumulated cost increases dramatically as programmers,
      operators, technical writers and computer time is committed.
    • Cost of discovering and fixing errors also increases with steps
Prototyping Model
    Requirement Analysis
    and Specification

      Quick design


    Customer Evaluation        Refinements


    Implementation &       Not accepted by customer
    Unit testing

    Integration &
    System testing

   Operation &
   A prototype is a partial implementation of a system, constructed
     primarily to enable customer, end-user, or developer to learn
     about the problem and/or its solution.
• When customer or developer is not sure
   – Of requirements (inputs, outputs)
   – Of algorithms, efficiency, human-machine interaction
• A throwaway prototype built from currently known user
• Working or even ‘paper’ prototype
• Quick design focuses on aspects visible to user; features
  clearly understood need not be implemented
• Prototype is tuned to satisfy customer needs
   – Many iterations may be required to incorporate changes and
     new requirements
• Final product follows usual define-design-build-test life
                Prototyping Model
• The basic idea here is that instead of freezing the requirements
  before a design or coding can proceed, a throwaway prototype is
  built to understand the requirements. This prototype is developed
  based on the currently known requirements. Development of the
  prototype obviously undergoes design, coding and testing. But each
  of these phases is not done very formally or thoroughly. By using
  this prototype, the client can get an "actual feel" of the system, since
  the interactions with prototype can enable the client to better
  understand the requirements of the desired system. In such
  situations letting the client "plan" with the prototype provides
  invaluable and intangible inputs which helps in determining the
  requirements for the system. It is also an effective method to
  demonstrate the feasibility of a certain approach.
           Prototyping Model
• The developers use this prototype to refine the
  requirements and prepare the final specification
  document .Because the prototype has been
  evaluated by the customer ,it is reasonable to
  expect that the resulting specification document
  will be correct
• It is true that both the customers and the
  developers like the prototype paradigm. Users
  get the feel that the actual system and
  developers get to build something immediately
               Prototyping Model
• Advantages of Prototyping
• Users are actively involved in the development
• It provides a better system to users, as users have natural tendency
  to change their mind in specifying requirements and this method of
  developing systems supports this user tendency.
• Since in this methodology a working model of the system is
  provided, the users get a better understanding of the system being
• Errors can be detected much earlier as the system is mode side by
• Quicker user feedback is available leading to better solutions.
• Disadvantages
• Leads to implementing and then repairing way of building systems.
• Practically, this methodology may increase the complexity of the
  system as scope of the system may expand beyond original plans.
     Limitations of Prototyping
• Customer may want prototype itself !
• Developer may continue with implementation
  choices made during prototyping
  – may not give required quality, performance, ….
• Good tools need to be acquired for quick
• May increase project cost
      Iterative Enhancement Model
                         Implementation &       Integration &         Operation
Requirements   Design                           System testing
                         Unit testing                                  (install)

                                                                      RELEASE 1
                             Implementation &      Integration &       Operation
                Design       Unit testing          System testing      (install)

                                                                        RELEASE 2

                    Design       Implementation &    Integration &       Operation
                                 Unit testing        System testing      (install)

                                                                        RELEASE 3
  Iterative Enhancement Model
• Iterative development slices the
  deliverable business value (system
  functionality) into iterations. In each
  iteration a slice of functionality is delivered
  through cross-discipline work, starting
  from the model/requirements through to
  the testing/deployment.
  Iterative Enhancement Model
• The phases occur in the same order as in the waterfall
  model but these may be conducted in several cycles. A
  useable product is released at the end of each cycle, with
  each release providing additional functionality.
• This model does deliver an operational quality product at
  each release , but one that satisfies only a subset of the
  customer’s requirements . The complete product is divided
  into releases and the developer delivers the product
  release by release
• Early version with limited feature important to establish
  market and get customer feedback
• Initial version may follow any method
• A list of features for future versions maintained
• Each version is analyzed to decide feature list for next
   Iterative Enhancement Model
• The basic idea is that the software should be developed in
  increments, where each increment adds some functional capability
  to the system until the full system is implemented. At each step
  extensions and design modifications can be made. An advantage of
  this approach is that it can result in better testing, since testing each
  increment is likely to be easier than testing entire system like in the
  waterfall model. Furthermore, as in prototyping, the increments
  provides feedback to the client which is useful for determining the
  final requirements of the system. In the first step of iterative
  enhancement model, a simple initial implementation is done for a
  subset of the overall problem. This subset is the one that contains
  some of the key aspects of the problem which are easy to
  understand and implement, and which forms a useful and usable
  system. A project control list is created which contains, in an order,
  all the tasks that must be performed to obtain the final
  implementation. This project control list gives an idea of how far the
  project is at any given step from the final system.
                   Spiral Model
• As the name suggests, the activities in this model can be
  organized like a spiral. The spiral has many cycles. The
  radial dimension represents the cumulative cost incurred
  in accomplishing the steps dome so far and the angular
  dimension represents the progress made in completing
  each cycle of the spiral. The structure of the spiral model
  is shown in the figure given below. Each cycle in the
  spiral begins with the identification of objectives for that
  cycle and the different alternatives are possible for
  achieving the objectives and the imposed constraints.
  The next step in the spiral life cycle model is to evaluate
  these different alternatives based on the objectives and
  constraints. This will also involve identifying uncertainties
  and risks involved. The next step is to develop strategies
  that resolve the uncertainties and risks
                  Spiral Model
• Activities are organized in a spiral having many cycles
• Boehm recognized and tried to incorporate the “project
  risk “ factor into a life cycle model
• The development spiral consists of four quadrants
  Quadrant 1: Determine objectives, alternatives, and
• Quadrant 2: Evaluate alternatives, identify, resolve risks.
• Quadrant 3: Develop, verify, next-level product.
• Quadrant 4: Plan next phases.
• Although the spiral, as depicted, is oriented toward
  software development, the concept is equally applicable
  to systems, hardware, and training, for example. To
  better understand the scope of each spiral development
  quadrant, let’s briefly address each one.
                      Spiral Model
• The Spiral Model or the Spiral Development Model is specifically
  risk-driven. It combines the features of both the prototyping and the
  waterfall models. In essence the Spiral Model is a combination of
  the classic Waterfall Model and Risk Analysis. It is iterative, but
  each iteration is designed to reduce the risk at that particular stage
  of the project. The Spiral Model provides a rapid development and
  at the same time, incremental versions of the software
  application. The Spiral model is better than the Waterfall Model in
  the sense that it emphasizes more on risk management while the
  Waterfall Model emphasizes more on the project management
• The spiral model has four phases. These phases are as follows:
• ·      Planning: determination of objectives
• ·      Risk Analysis : identify the risk and try to resolve them
• ·     Development : Product development and testing product
• ·     Assessment : Customer Evaluation
Spiral Model
                      Spiral Model
•   Advantages
•   The following are the advantages of the Spiral Model.
•   ·       It has strong support for Risk Analysis.
•   ·       It is well suited for complex and large projects.
•   ·       The deliverable is produced early in the software
    development life cycle.
•   ·       It uses prototyping as a risk reduction technique and
    can reduce risks in the SDLC process considerably.
•   Disadvantages
•   The following are the disadvantages of the Spiral Model.
•   ·       It is high in cost and Risk Analysis is also very
•   ·       It is not suited for small projects.
•   ·       Needs considerable Risk Assessment
            Which model to use ?
• We should choose the right type of the Model to
  implement based on the scope of the software
  project. This depends on a number of factors, some of
  which are given below.
• ·     The Scope of the Project
• ·     The Project Budget
• ·     The organizational environment
• ·     Available Resources
• The paradigm used for development of software depends
  on a number of factors
   –   People - staff & users
   –   Software product
   –   Tools available
   –   Environment
• Existing models makes development process clearer, but
  they can be evolved to become new paradigms
          What is CASE?

– Computer Assisted Software Engineering,
  used to provide automated support for
  software process activities
– Often used for method support
– Upper-CASE tools support requirements
  gathering and design activities
– Lower-CASE tools support implementation,
  debugging, and testing activities

To top