INTRODUCTION software engineering by SanjuDudeja

VIEWS: 21 PAGES: 35

									1. Introduction


   N.L. Hsueh




                  1
                      Objectives

 To understand the notion of software engineering and why it
  is important
 To understand the similarities and different between software
  engineering and other engineering disciplines
 To know the major phases in a software development project
 To appreciate the technical, managerial, and psychological
  aspects of software engineering




                                                                  2
                     Motivation

 Applications from the early years were quite small
 Present-day application are often large and complex
    Programming is art or craft?
 Software Crisis
    Deliver too late
    Programs did not behave as user expected
    Programs      were     rarely   adaptable    to  changed
     circumstances
    Many errors were detected only after had been delivered
     to the customer
 Software Engineering is proposed
    NR68, BR69




                                                                3
                               Cost

 Cost of software is crucial importance
    Cost of developing software
    Cost of keeping the software operational once it has been
     delivered to the customer


                    hardware




                                 maintenance


             1950                              1990


    Figure 1.1 Relative Distribution of hardware/software cost

                                                                 4
Failure
   rate
                                     Wear out
          Infant mortality




                                                Time

               Failure Curve for Hardware


                                                       5
                                   Software doesn’t wear
                                       out, but it does
                                         deteriorate




Idealized and actual failure curves for
              software
                                                           6
                   Productivity

 Demand on software system >> supply on software system
    Backlog of maintenance will slow down the development
     of new applications




                                                             7
                          Quality

 Software crisis examples
    June 9, 1980
        … a alarm indicated that Soviet Union had started a missile
         attack
    US airline
        lost 50M because of an error in their seat reservation system
    April 1983
        The court discharged a woman (54), who was on trial for
         murdering her daughter…




                                                                         8
             Brooks: No Silver Bullet

 Essence: the difficulties inherent in the nature of software
    complexity: development process, application domain,
     internals of the system (e.g., number of states, size of
     software, functionality, structures, and management).
    conformity: software must adapt to interact with people
     according to their diverse needs; therefore, software
     cannot be completely represented formally.
    changeability: software component is usually the easiest
     one to modify.
    invisibility: software structure is hidden, only behavior can
     be observed when executing the software.



                            http://www.cs.unc.edu/~brooks/

                                                                     9
                         Conti.

 Accidental: difficulties arise in representing, testing the
  conceptual constructs (SW) (e.g., software development
  process)
    examples of accidental difficulties:
        accidental   complexity: abstract program vs concrete
         machine program; solved by HLL.
        slow turnaround: batch programming vs time-sharing
         (shortest response time); solved by time-sharing.
        no standard formats: individual programs vs integrated
         library, standard formats; solved by unified programming
         environment.




                                                                    10
The most likely way for the world to be destroyed, most
experts agree, is by accident. That’s where we come in;
We’re computer professionals. We cause accidents

Nathaniel Borenstein




                                                      11
        What is software engineering

 Software engineering is the establishment and use of sound
  engineering principles in order to obtain economically
  software that is reliable and works efficiently on real
  machines

 Software engineering is the application of a systematic,
  disciplined, quantifiable approach to development,
  operation, and maintenance of software; that is, the
  application of engineering to software




                                                               12
Software is both a product and a vehicle for delivering
a product

R.S. Pressman




                                                          13
                                 Conti.

          Essential characteristics of the field of software engineering
             Software engineering concerns the construction of large
              programs
             The central theme is mastering complexity
             Software evolves
             The efficiency with which software is developed is of
              crucial importance
 Cost and
developme  Regular cooperation between people is an integral part of
  nt time     programming in the large
             The software has to support its users effectively




                                                                            14
Computers make it easy to do a lot of things, but most of the things
that they make it easier to do don’t need to be done

Andy Rooney




                                                                       15
Did you really need a scheduling software?


                                             16
                        Conti.

 Software is difficult to manage
     Visibility
         “almost finished”, “90% finished”
     Continuity
         Small changes in the specification lead to small changes
          in the product – it is not true in software engineering


 Software engineering is   not as same as programming
     Techniques, management, psychology




                                                                     17
                          Conti.

 Software engineering vs. building engineering
    Same
        Developed in a number of phases
        A careful planning of these phases
        Continuous audit of the whole process
        Construction from a clear and complete design
        Accident may happen
    Different
        Cost
           Software: developing, maintenance
           Building: constructing
        Wear out
           Software: maintenance by errors              or   changing
            requirements of the users

                                                                         18
                           Conti.

 Software engineering vs. computer science
    Computer science
        Emerge in 1960
        Split from mathematics and has been heavily influenced by
         the mathematics
            Algorithm complexity, formal language, semantics of
             language
    Software engineering
        Has a similar inclination to focus on mathematics
            Software development should be formalized
            Ignore the reality of trading off quality aspect against the
             available budget, and changeability…

        SE has to concern about management of huge project,
         human factor, cost estimation and control



                                                                            19
Phases in The Development Of Software

 Process model

      Reqt.                                     Waterfall
      engineering   design   code      test




      Prototyping
                               Rapid application development
                                                               20
Incremental




              Spiral model
                             21
                          Conti.

 Requirement engineering
    The goal of the requirement engineering phase is to get a
     complete description of the problem to be resolved and the
     requirements posed by and on the environment in which
     the system is going to function
    Includes
        The functions of the software to be developed
        Possible future extensions to the system
        Documentation
        Performance requirement
    Feasibility study
    Communication


    Output: requirements specification




                                                                  22
                          Conti

 Design
    A model of the whole system is developed
    The problem is decomposed into modules
    The interface between modules must be specified
    Define architecture


    Output: technical specification (design model)



Pipeline? Layered?
MVC? 3-tier? Client
      server?



                                                       23
                         Conti.

 Implementation
    Individual module programming
        Pseduo-code
    The    first goal of a programming should be the
     development of a well-documented, reliable, easy to read,
     flexible, correct program
    The goal is not to produce a very efficient program full of
     tricks
    Integration of modules


    Output: executable program




                                                                   24
                           Conti

   Testing
      You should test your system from requirement engineering
       to implementation
      Verification and validation
      Output: testing report
   Maintenance
      Repair errors, requirements changed or extended
   40-20-40 rule
   Approach to 60-15-25
Modeling-Coding-Testing




                                                                  25
Figure 1.3 Relative Effort for the Various Activities



                                                        26
                  Maintenance

 The only thing we maintain is user satisfaction
 Changes in both the system’s environment and user
  requirements are inevitable
     Software models pat of reality, and reality changes
     Maintenance = Evolution
 Kinds of maintenance activities
     Corrective
     Adaptive
     Perfective
     Preventive




                                  The Impact of Change
                                                            27
             corrective
                21%

perfective
   50%           adaptive
                  25%

             4%
             rest



                            28
        Software Failure Case Studies

 Historical case studies contain a wealth of wisdom about the
  nature of design and the engineering method
 Failures in software engineering are multi-dimensional
    Technical slip
    Bad management
    Bad communication
 Ariane 5, Flight 501
    Failure was caused by reusing a flawed component
 Therac-25
    Bad usability (bad user interface)
    Bad exception handling
    Over-confidence on software



                                                                 29
                           Conti.

 The London Ambulance Service
    Bad communication
    Bad schedule (too tight)
    Less experience in complex system (bad management)
    Bad risk management
        Wrong expectation on hardware (bad feasibility study)




                                                                 30
                        Conti.

 Why projects Fail?
    an unrealistic deadline is established
    changing customer requirements
    an honest underestimate of effort
    predictable and/or unpredictable risks
    technical difficulties
    miscommunication among project staff
    failure in project management




                                              31
     Software Myth

In the absence of meaningful standards, a new industry
like software comes to depend instead on folklore

Tom Demarco




                                                    32
                         Conti.

 Management myths
    We already have a book that’s full of standards and
     procedures for building software, won’t that provide my
     people with everything they need to know?
    My people have state-of-art software development tools,
     after all, we buy them the newest computers
    If we got behind schedule, we can add more programmers
     and catch up
    If I decide to outsource the software project to a third
     party, I can just relax and let firm build it




                                                                33
                         Conti.

 Customer myths
    A general statement of objectives is sufficient to begin
     writing programs – we can fill in the details later
    Project requirements continually change, but change can
     be easily accommodated because software is flexible
 Practitioner’s myths
    Once we write the program and get it to work, our job is
     done
    Until I get the program “running” I have no way of
     assessing its quality
    The only deliverable work product for a successful project
     is the working program
    Software engineering will make us create voluminous and
     unnecessary document and will invariably slow us down

                                                                  34
                    Reference

 Transaction on Software Engineering (IEEE)
 Software (IEEE)
 Software Engineering Notes (ACM)
 Transactions on Software Engineering and Methodology
  (ACM)
 The Journal of System and Software (Elsevier)
 Proceedings of International Conference on Software
  Engineering (ACM/IEEE)
 Proceedings of International Conference on Maintenance
  (ACM/IEEE)
 Annals of Software Engineering (Kluwer)




                                                           35

								
To top