NEW SE UNIT 1 _2_ by prabhunathan


• What is Software Engineering ?
      The process of building a software
• 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
     • 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

         failure rate


Reference: Pressman, Figure 1.1                             CFICSE 2002 / SF01 - 6
             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



        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.

                         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 model
     – RAD (Rapid Application Development) Model
     Prototyping model
     Spiral model
     Win Win spiral model
     Concurrent Development model
                     The Waterfall Model /
                    Linear sequential model
Communicat ion
project init iat ion     Planning
requirement gat hering    estimating   Modeling
                                        analysis   Const ruct ion
                                        design                      Deployment
                                                     t est          delivery
                                                                    f eedback

            Water fall model
• It is called classical life cycle
• Systematic sequential approach to software
• It is the oldest paradigm for software
                 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
• Model is only appropriate when the requirements are well-
• 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

•   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

                                                     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


• It is an increment software development model.
• It is high speed adaption of waterfall model.
1. Communication - Understand business problem &
2. Planning – Multiple software teams work in parallel
   in different system functions.
3. Modeling – Design representation.
    business modeling , data modeling, process
4. Construction- Reusability of s/w components.
5. Deployment- Integration, delivery , feedback.
   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
Prototyping Model

                       Qu ick p lan
 Communicat ion

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

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

• 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
                           risk analysis



        delivery                           code
        feedback                           test

• 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
1. Requirement changes can be made at every
2. Risk can be identified & rectified before they
   get problematic
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.
• Customer & developers undergo through the
  process of negotiation.
• Successful negotiation occurs when both sides
• Customer wins by getting the product that
  satisfy majority of the customer needs.
• Developers wins by getting the work done
  with realistic & achievable budgets &
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
6.Validate Product and Process Definitions
7.Review, commitment
Concurrent Development Model

  Modeling act ivit y

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

          A wait ing

                                                      Under review




• 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

• 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





Production                          Transition
                    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
    – A use case describes a sequence of actions that are performed by a user

                      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

                   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
• 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

                      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

                     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

  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

    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
• 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

        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
• 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

               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

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
• 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)

System Engineering Hierarchy
         Business or        World
         product domain     View




                    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

        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

         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

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

      BUSINESS AREA                   BAA

                                   Construction &
                                   (detailed view)

    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
    – 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

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
    – Product architecture components consist of people, hardware, software, and
    – 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
• Design modeling maps the analysis model into data/class, architectural,        63
  interface, and component design
Product Engineering Hierarchy
                Product Requirements
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


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

To top