Recently MeroSpark is lunched with more features and services, now you can ask your question, sell your books, share your notes and many more. Visit now and create your account to take full advantage of MeroSpark.

System engineering process with 7 phases | Software Engineering | BSc.CSIT 6th Sem

Download our Android App from Google Play Store and start reading Reference Notes Offline.

system engineering process7 phases of system engineering process,
Software Engineering Notes | Sixth Semester,
BSc.CSIT | Tribhuvan University (TU)

System engineering process
A system engineering process is a set of activities whose goal is the development or evolution of software. It usually follows a ‘waterfall’ model because of the need for parallel development of different parts of the system. There is little scope for iteration between phases because hardware changes are very expensive. Software may have to compensate for hardware problems. It Inevitably involves engineers from different disciplines who must work together. There is much scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfill.phases of system engineering process

1. System requirements definition
System requirements definitions specify what the system should do (its functions) and its essential and desirable system properties. Creating system requirements definitions involves consultations with system customers and end-users.
This phase concentrates on three types of requirements:

  • Abstract functional requirements: The basic function that the system must provide are defined at an abstract level. More detailed functional requirements specification takes place at the sub-system level.
  • System properties: These are non-functional emergent system properties such as availability, performance and safety. These properties affect the requirements for all sub-systems.
  • Characteristics that the system must not exhibit: It is sometimes as important to specify what the system must not do as it is to specify what the system should do.

An important part of the requirements definition phase is to establish a set of overall objectives that the system should meet. These should not necessarily be expressed in terms of the system’s functionality but should define why the system is being procured for a particular environment.

System requirements problems:

  • Changing as the system is being specified
  • Must anticipate hardware/communications developments over the lifetime of the system
  • Hard to define non-functional requirements (particularly) without an impression of component structure of the system

2. The system design process
System design is concerned with how the system functionality is to be provided by the components of the systems. The activities involved in this process are:system design process

  • Partition requirements:
    Organize requirements into related groups
  • Identify sub-systems:
    Identify a set of sub-systems which collectively can meet the system requirements
  • Assign requirements to sub-systems:
    Causes particular problems when COTS (Commercial Off-the-Shelf )are integrated
  • Specify sub-system functionality:
    Specify the specific function provided by each sub-system and also try to identify relationships between subsystems.
  • Define sub-system interfaces:
    Critical activity for parallel sub-system development

System design problems

  • Requirements partitioning to hardware, software and human components may involve a lot of negotiation
  • Difficult design problems are often assumed to be readily solved using software
  • Hardware platforms may be inappropriate for software requirements so software must compensate for this

3. Sub-system development

  • Typically, parallel projects developing the hardware, software and communications
  • May involve some COTS (Commercial Off-the-Shelf) systems procurement
  • Lack of communication across implementation teams
  • Bureaucratic and slow mechanism for proposing system changes means that the development schedule may be extended because of the need for rework

4. System integration

  • It is the process of putting hardware, software and people together to make a system
  • It should be tackled incrementally so that sub-systems are integrated one at a time
  • Interface problems between sub-systems are usually found at this stage
  • May be problems with uncoordinated deliveries of system components

5. System installation
System installation is the organizational process of changing over from the current system to a new one.
Four approaches of installation;

  • Direct Installation:
    Changing over from the old system to a new one by turning off the old system when the new one is turned on
  • Parallel Installation:
    Running the old system and the new one at the same time until management decides the old system can be turned off
  • Single location installation:
    Trying out a system at one site and using the experience to decide if and how the new system should be deployed throughout the organization
  • Phased Installation:
    Changing from the old system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system.

Problems in installation:

  • Environmental assumptions may be incorrect
  • May be human resistance to the introduction of a new system
  • System may have to coexist with alternative systems for some time
  • May be physical installation problems (e.g. cabling problems)
  • Operator training has to be identified

6. System evolution

  • Large, complex systems have a very long lifetime. They must evolve to meet changing requirements i.e. during their life, they are changed to correct errors in the original system requirements and to implement new requirements that have emerged.
  • System Evolution is inherently costly, like software evolution for several reasons:
    • Changes must be analyzed from a technical and business perspective
    • Sub-systems interact so unanticipated problems can arise
    • There is rarely a rationale for original design decisions
    • System structure is corrupted as changes are made to it
  • Existing systems which must be maintained are sometimes called legacy systems

7. System decommissioning

  • It means taking the system out of service after its useful lifetime
  • May require data to be restructured and converted to be used in some other system
  • If the data in the system that is being decommissioned is still valuable to your organization or you may have to convert it for use by other systems.
(Visited 210 times, 1 visits today)

Posted By : Digvijay | Comment RSS | Category : Sixth Semester
Tag :

Post a Comment

Your email is never published nor shared. Required fields are marked *


Wordpress DMCA
Community | Toolbar | Android App | Founder/Developer : Hari Prasad Chaudhary | CSIT Portal Manager : Digvijay Chaudhary