NEW SE UNIT 1 _2_ by prabhunathan

VIEWS: 3 PAGES: 67

									SOFTWARE ENGINEERING
      SOFTWARE ENGINEERING
• What is Software Engineering ?
      The process of building a software
  product.
• SE requires the identification of a problem, a
  computer to carry execute a software product,
  and a user environment (composed of people,
  tools, methodologies, etc.)
  The task of software engineers?

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
   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
   Software characteristics

• software is engineered or developed

• software doesn’t wear out

• Although the industry is moving toward component based
  assembly, most software continues to be custom built.
                        Hardware Failure Curve

                                   infant
                                                     wear
                                  mortality
                                                     out
         failure rate




                                              time


Reference: Pressman, Figure 1.1                             CFICSE 2002 / SF01 - 6
IDEALIAZED AND ACTUAL FAILURE CORVE
             FOR S/W
    Software Applications or categories


•   system software
•   application software
•   engineering/scientific software
•   embedded software
•   product-line software
•   WebApps (Web applications)
•   AI software
A Layered Technology

     Software Engineering

              tools

           methods

        process model

        a “quality” focus
      What is a software process?
• SP is a set of activities whose goal is the development or
  evolution of software
• Fundamental activities in all software processes are:

   – Specification - what the system should do
                          and its development constraints
   – Development - production of the software system
                          (design and implementation)
   – Validation - checking that the software is what the customer wants
   – Evolution - changing the software in response to changing demands
          Common Process Framework




TCS2411 Software Engineering   11
Framework Activities
    • Communication
    • Planning
    • Modeling
       – Analysis of requirements
       – Design
    • Construction
       – Code generation
       – Testing
    • Deployment
       Umbrella Activities
•   Software project management
•   Formal technical reviews
•   Software quality assurance
•   Software configuration management
•   Work product preparation and production
•   Reusability management
•   Measurement
•   Risk management
              The CMMI
• The CMMI defines each process area in terms
  of “specific goals” and the “specific practices”
  required to achieve these goals.
• Specific goals establish the characteristics
  that must exist if the activities implied by a
  process area are to be effective.
• Specific practices refine a goal into a set of
  process-related activities.
                         CMM Levels
Level 1 : Initial
• few process defined, success depends on individual effort
Level 2 : Repeatable
• keep track with cost, schedule and functionality
• Repeat earlier success on project with similar applications
Level 3 : Defined
• sw process standardized, documented and integrated into
   organization wide sw process.
Level 4 : Managed
• sw process and products are understood and controlled using
   detailed measures.
Level 5 : Optimized
• Continuous process improvement is enabled by quantitative
   feedback from the process
• testing innovative ideas and technologies are included.
               SOFTWARE ENGINEERING
                    PARADIGM




                         The phases of a problem solving loop


TCS2411 Software Engineering                   16
The phases within phases of the problem
solving loop
    Software life cycle models
     – Waterfall model / Linear sequential model
INCREMENTAL PROCESS MODEL
     – Incremental model
     – RAD (Rapid Application Development) Model
EVOLUTIONARY DEVELOPMENT MODEL
     Prototyping model
     Spiral model
     Win Win spiral model
     Concurrent Development model
SPECIALIZED PROCESS MODEL
UNIFIED PROCESS MODEL
                     The Waterfall Model /
                    Linear sequential model
Communicat ion
project init iat ion     Planning
requirement gat hering    estimating   Modeling
                          scheduling
                                        analysis   Const ruct ion
                          tracking
                                        design                      Deployment
                                                     code
                                                     t est          delivery
                                                                    support
                                                                    f eedback




                                         19
            Water fall model
• It is called classical life cycle
• Systematic sequential approach to software
  development
• It is the oldest paradigm for software
  engineering.
                 Waterfall model
 Advantages
• Easy to use
• Easy to implement
• Understood by non technical persons also
• Proper planning due to proper definition of the problem
 Disadvantages
• Inflexible partitioning of the project into distinct stages
• This makes it difficult to respond to changing customer
  requirements
• Model is only appropriate when the requirements are well-
  understood
• Not Suits for complex , large and new projects.
                                         The Incremental Model

                                                                                                                                                       increment # n
                                                                                                                                                                  Co m m u n i c a t i o n
                                                                                                                                                                                             Pla nning
                                                                                                                                                                                                         M ode ling
                                                                                                                                                                                                           a na ly s i s   Co n s t ru c t i o n
                                                                                                                                                                                                           d es ig n
                                                                                                                                                                                                                              c od e               De p l o y m e n t
                                                                                                                                                                                                                              t es t                 d e l i v e ry
                                                                                                                                                                                                                                                     fe e dba c k




                                                                                                                                                                                                                                                   deliv ery of
                                                                                                                                                                                                                                                   nt h increment
                                                          increment # 2

                                                              Co m m u n i c a t i o n
                                                                                          Pla nning
                                                                                                              M ode ling
                                                                                                               a nal y s i s        Co n s t ru c t i o n
                                                                                                               d es i g n              c o de               De p l o y m e n t
                                                                                                                                       t es t                 d e l i v e ry
                                                                                                                                                              fe e dba c k
                                                                                                                                                                                        deliv ery of
increment # 1                                                                                                                                                                           2nd increment

  Co m m u n i c a t i o n
                             Pla nning
                                         M ode ling
                                          a na l y s is      Co n s t ru c t i o n
                                          d es i gn             c od e                   De p l o y m e n t
                                                                t es t                     d e l i v e ry        deliv ery of
                                                                                           fe e dba c k
                                                                                                                 1st increment




                                                                                                     project calendar t ime
                                                                                                                               22
           INCREMENTAL MODEL PHASES

•   Communication
•   Planning
•   Modeling ( analysis & design)
•   Construction ( code & test)
•   Deployment (delivery & feedback)
• It combines Element of waterfall model
  applied in an iterative fashion.
• First increment is “core product” – basic
  requirements are addressed
• Core product is used by the customer & plan
  developed for next increment.
• Plan modifies core product to customer needs
  & delivers additional features & functionality.
• Process is repeated following delivery of each
  increment until complete product produced.
• Model is used when staffing is unavailable.
• Early increment implemented by fewer people
• Increment planned to manage risk.
• Plan & increment avoids delay in project.
                    The RAD Model
                                       Team # n
                                           M o d e lin g
                                            business m odeling
                                            dat a m odeling
                                            process m odeling




                                                              Co n st ru ct io n
                                                                 com ponent reuse
                               Team # 2                          aut om at ic code
Communicat ion                                                       generat ion
                                                                 t est ing
                                   Mo d eling
                                    business m odeling
                                    dat a m odeling
                                    process m odeli ng

                 Planning
                                                     Co nst ruct io n                De ployme nt
                            Team # 1                       com ponent reuse            int egrat ion
                                                           aut om at ic code
                                                              generat ion
                                                                                       deliv ery
                            Mode ling                      t est ing                   feedback
                             business modeling
                             dat a modeling
                             process modeling



                                              Const ruct ion
                                                 component reuse
                                                 aut omat ic code
                                                     generat ion
                                                 t est ing




                                   6 0 - 9 0 days


                                  26
                        RAD

• It is an increment software development model.
• It is high speed adaption of waterfall model.
1. Communication - Understand business problem &
   information
2. Planning – Multiple software teams work in parallel
   in different system functions.
3. Modeling – Design representation.
    business modeling , data modeling, process
   modeling.
4. Construction- Reusability of s/w components.
5. Deployment- Integration, delivery , feedback.
Disadvantages:
   Needs sufficient human resource for RAD team.
   Requires developer & customers to be committed .
   Not applicable when technical risk is high.
   RAD is problematic if system is not properly
    modularized.
Prototyping Model

                       Qu ick p lan
                          Quick
 Communicat ion
                           plan
 communication

                                  Mo d e lin g
                                   Modeling
                                    Qu ick d e sig n
                                  Quick design




Deployment
 Deployment
  De live ry
  delivery &                Const ruct ion
  & Fe e dback              Construction
  feedback                  of
                            of prototype
                            prot ot ype




                  29
• It is stand alone process model.
• It serve as “the first system”.
• It assist s/w engineer & customer to build &
  understand Requirements.
1. Communication – Define overall objectives.
2. Quick plan
3. Quick design – Focus on representation of software
    visible to customer.
   It leads to construction of prototype.
• Disadvantages:
1. Customer unaware that prototype is held together
   & don’t consider overall quality.
2. Developer makes implementation compromises in
   order to get prototype working quickly.
          SPIRAL MODEL
                       planning
                           estimation
                           scheduling
                           risk analysis

communication

                                                      modeling
                                                       analysis
                                                       design
                   start




      deployment
                                       construction
        delivery                           code
        feedback                           test




                              32
• It couples iterative nature of prototyping with
  controlled & systematic aspect of waterfall.
• It is divided in to no. of frame work activities.
       1. concept development project
       2. New product development project
       3. Product enhancement project
       4. Product maintenance project
• ADVANTAGES
1. Requirement changes can be made at every
   stage.
2. Risk can be identified & rectified before they
   get problematic
• DISADVANTAGES
1. If customer communication is not proper
   then s/w product will not be up to the mark.
2. If risk assessment not done properly,
   successful product can’t be obtained.
      WIN-WIN SPIRAL MODEL
• Customer & developers undergo through the
  process of negotiation.
• Successful negotiation occurs when both sides
  WIN.
• Customer wins by getting the product that
  satisfy majority of the customer needs.
• Developers wins by getting the work done
  with realistic & achievable budgets &
  deadlines
WinWin Spiral Model
                 Win Win Spiral
1.Identifying the system's stakeholders
2. Identification of their win conditions
3.Reconciling win conditions through negotiation to arrive
    at a mutually satisfactory set of objectives, constraints,
    and alternatives for the next level.
4.Evaluate Product and Process Alternatives. Resolve Risks
5.Define next level of product and process - including
    partitions
6.Validate Product and Process Definitions
7.Review, commitment
Concurrent Development Model
                                                   none

  Modeling act ivit y


                                                             represent s t he st at e
                                   Under                     of a sof t ware engineering
                                                             act ivit y or t ask
                                development




          A wait ing
           changes




                                                      Under review

                        Under
                       revision


                                                 Baselined




                                     Done



                                            38
    SPECIALIZED PROCESS MODEL
• Component Based Development Model
           development—the process to apply
  when reuse is a development objective
• Formal Methods Model
           methods—emphasizes the
  mathematical specification of requirements
• Aspect-Oriented s/w Development Model
           AOSD—provides a process and
  methodological approach for defining,
  specifying, designing, and constructing
  aspects
      UNIFIED PROCESS MODEL

• Process—a “use-case driven, architecture-
  centric, iterative and incremental” software
  process closely aligned with the Unified
  Modeling Language (UML)
 Phases of the Unified Process
Inception                              Elaboration



                   planning


                                      modeling
 communication


                              construction
                                                 Construction

             deployment


Production                          Transition
                                                           41
                    Inception Phase

• Encompasses both customer communication and planning activities of the
  generic process
• Business requirements for the software are identified
• A rough architecture for the system is proposed
• A plan is created for an incremental, iterative development
• Fundamental business requirements are described through preliminary use
  cases
    – A use case describes a sequence of actions that are performed by a user




                                                                            42
                      Elaboration Phase
• Encompasses both the planning and modeling activities of the generic process
• Refines and expands the preliminary use cases
• Expands the architectural representation to include five views
    –   Use-case model
    –   Analysis model
    –   Design model
    –   Implementation model
    –   Deployment model
• Often results in an executable architectural baseline that represents a first cut
  executable system
• The baseline demonstrates the viability of the architecture but does not
  provide all features and functions required to use the system



                                                                             43
                   Construction Phase

• Encompasses the construction activity of the generic process
• Uses the architectural model from the elaboration phase as input
• Develops or acquires the software components that make each use-case
  operational
• Analysis and design models from the previous phase are completed to reflect
  the final version of the increment
• Use cases are used to derive a set of acceptance tests that are executed prior to
  the next phase




                                                                          44
                      Transition Phase

• Encompasses the last part of the construction activity and the first part of the
  deployment activity of the generic process
• Software is given to end users for beta testing and user feedback reports on
  defects and necessary changes
• The software teams create necessary support documentation (user manuals,
  trouble-shooting guides, installation procedures)
• At the conclusion of this phase, the software increment becomes a usable
  software release




                                                                           45
                     Production Phase

•   Encompasses the last part of the deployment activity of the generic process
•   On-going use of the software is monitored
•   Support for the operating environment (infrastructure) is provided
•   Defect reports and requests for changes are submitted and evaluated




                                                                          46
  Unified Process Work Products


• Work products are produced in each of the first four
  phases of the unified process




                                                         47   
 Incept ion phase

                             Elaborat ion phase
Vision document
Init ial use-case model
Init ial project glossary                                        Construct ion phase
                             Use-case model
Init ial business case       Supplement ary requirement s
Init ial risk assessment .    including non-funct ional          Design model
                                                                                             Transit ion phase
Project plan,                Analy sis model                     Soft ware component s
  phases and it erat ions.   Soft ware archit ect ure                                        Deliv ered soft ware increment
                                                                 Int egrat ed soft ware
Business model,               Descript ion.                        increment                 Bet a t est report s
  if necessary .             Execut able archit ect ural                                     General user feedback
                                                                 Test plan and procedure
One or more prot ot y pes     prot ot y pe.
I nc e pt i o                                                    Test cases
n                            Preliminary design model            Support document at ion
                             Rev ised risk list                    user manuals
                             Project plan including                inst allat ion manuals
                              it erat ion plan                     descript ion of current
                              adapt ed workflows                     increment
                              milest ones
                              t echnical work product s
                             Preliminary user manual




                                                            48
    System Engineering
         - Computer-based system
         - System engineering process
         - Business process engineering
         - Product engineering




(Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)
• Software engineering occurs as a consequence of system
  engineering
• System engineering may take on two different forms
  depending on the application domain
   – “Business process” engineering – conducted when the
     context of the work focuses on a business enterprise
   – Product engineering – conducted when the context of the
     work focuses on a product that is to be built
• Both forms bring order to the development of computer-
  based systems
• Both forms work to allocate a role for computer software and
  to establish the links that tie software to other elements of a
  computer-based system


                                                                50
        Computer-based System
• Defined: A set or arrangement of elements that are
  organized to accomplish some predefined goal by
  processing information
• The goal may be to support some business function or
  to develop a product that can be sold to generate
  business revenue
• A computer-based system makes use of system
  elements
• The role of the system engineer is to define the
  elements of a specific computer-based system in the
  context of the overall hierarchy of systems

                                                    51
               Computer-based System

• A computer-based system makes use of the following four
  system elements

•   Software
•   Hardware
•   People
•   Database

• The uses of these elements are described in the following:

    – Documentation
    – Procedures

                                                               52
System Engineering Process
      System Engineering Process
• The system engineering process begins with a world view; the business or
  product domain is examined to ensure that the proper business or
  technology context can be established
• The world view is refined to focus on a specific domain of interest
• Within a specific domain, the need for targeted system elements is
  analyzed
• Finally, the analysis, design, and construction of a targeted system
  element are initiated
• At the world view level, a very broad context is established
• At the bottom level, detailed technical activities are conducted by the
  relevant engineering discipline (e.g., software engineering)




                                                                       54
System Engineering Hierarchy
         Business or        World
         product domain     View



                               Domain
                               View



                               Element
                               View

                           Detailed
                           View

                                  55
                    System Modeling
• Defines the processes (e.g., domain classes in OO terminology) that serve
  the needs of the view under consideration
• Represents the behavior of the processes and the assumptions on which
  the behavior is based
• Explicitly defines intra-level and inter-level input that form links between
  entities in the model
• Represents all linkages (including output) that will enable the engineer to
  better understand the view
• May result in models that call for one of the following
    – Completely automated solution
    – A semi-automated solution
    – A non-automated (i.e., manual) approach




                                                                             56
        Factors to Consider when
          Constructing a Model
• Assumptions
    – These reduce the number of possible variations, thus enabling a model to reflect
      the problem in a reasonable manner
• Simplifications
    – These enable the model to be created in a timely manner
• Limitations
    – These help to bound the maximum and minimum values of the system
• Constraints
    – These guide the manner in which the model is created and the approach taken
      when the model is implemented
• Preferences
    – These indicate the preferred solution for all data, functions, and behavior
    – They are driven by customer requirements




                                                                                         57
         System Modeling with UML
• The Uniform Modeling Language (UML) provides diagrams for analysis and
  design at both the system and software levels
• Examples
    –   Use case diagrams
    –   Activity diagrams
    –   Class diagrams
    –   State diagrams




                                                                      58
“Business Process” Engineering
Business Process Engineering Hierarchy
                              Information strategy
         The Enterprise       planning
                              (world view)


      BUSINESS AREA                   BAA
                                      (domain
                                      view)
        INFORMATION
                                    BSD
        SYSTEM
                                    (element
                                    view)


                                   Construction &
                                   integration
                                   (detailed view)

                                                 60
    Business Process Engineering
• “Business process” engineering defines architectures that will enable
  a business to use information effectively
• It involves the specification of the appropriate computing architecture
  and the development of the software architecture for the
  organization's computing resources
• Three different architectures must be analyzed and designed within
  the context of business objectives and goals
    – The data architecture provides a framework for the information needs of
      a business (e.g., ERD)
    – The application architecture encompasses those elements of a system
      that transform objects within the data architecture for some business
      purpose
    – The technology infrastructure provides the foundation for the data and
      application architectures
        • It includes the hardware and software that are used to support the
          applications and data



                                                                                61
Product Engineering
                Product Engineering
• Product engineering translates the customer's desire for a set of defined
  capabilities into a working product
• It achieves this goal by establishing a product architecture and a support
  infrastructure
    – Product architecture components consist of people, hardware, software, and
      data
    – Support infrastructure includes the technology required to tie the components
      together and the information to support the components
• Requirements engineering elicits the requirements from the customer and
  allocates function and behavior to each of the four components
• System component engineering happens next as a set of concurrent
  activities that address each of the components separately
    – Each component takes a domain-specific view but maintains communication
      with the other domains
    – The actual activities of the engineering discipline takes on an element view
• Analysis modeling allocates requirements into function, data, and
  behavior
• Design modeling maps the analysis model into data/class, architectural,        63
  interface, and component design
Product Engineering Hierarchy
                Product Requirements
                Engineering
                                                               System
Human         Hardware      Software          Database         Component
Engineering   Engineering   Engineering       Engineering      Engineering

                            Data and                            Analysis
               Function                       Behavior
                            Classes                             Modeling


       Data/Class   Architectural Interface        Component    Design
       Design       Design        Design           Design       Modeling



                                                               Construction

                                                                     64
Verification and Validation
   Verification and Validation




Assuring that a software system
 meets a user's needs
       Verification vs validation
• Verification:
     "Are we building the product right"
  – The software should conform to its specification


• Validation:
      "Are we building the right product"
  – The software should do what the user really
    requires

								
To top