- Information
- AI Chat
More About Systems engineering
Software Engineering (CS391)
Fayoum University
Recommended for you
Preview text
More About Systems engineering
designs are being worked on at the same time. Existing systems may impose constraints that limit design options, and these constraints may be described in the requirements. These choices may also be specified in the requirements. It is possible that you will need to carry out some preliminary design work in order to properly structure and manage the requirements engineering process. As the process of design progresses, it is possible that you will find issues with the previously established needs and that new requirements will surface. As a consequence of this, you might consider these interconnected processes to be a spiral, as depicted in Figure 19.
The spiral represents the reality that requirements influence design decisions and vice versa, and hence it makes sense to interleave both processes. This reality is reflected in the fact that the spiral has a spiral shape. Beginning in the middle, each turn of the spiral may add a new element of complexity to the specifications as well as the design. Following the identification of each subsystem in the architecture, choices are taken regarding the roles of these subsystems with regard to the provision of the system requirements. The requirements may be the focus of some rounds of the spiral, while the design may be the focus of others. When new information is uncovered in the course of the requirements gathering and design process, it is possible that the problem statement itself will need to be revised.
Nearly every system has multiple potential designs that could work to satisfy the criteria. They encompass a variety of approaches that mix manual labour, computer programmes, and physical components.
It's possible that the solution you choose for further development will turn out to be the most suitable technological option available that satisfies the requirements. On the other hand, the choice of solution could be influenced by bigger organisational and political factors. For instance, a government customer may favour using domestic rather than international suppliers for its system, even if the quality of the domestic products is lower than that of their global counterparts.
In most cases, these factors become apparent during the review and evaluation phase of the spiral model. This is the phase of the model in which designs and requirements are either accepted or denied. The procedure comes to a close when it is determined through evaluation that the requirements and the high-level design are sufficiently defined to allow for the specification and design of the subsystems.
Engineering a subsystem entails both the design and construction of the various hardware and software components that make up the system. In the course of the development process for certain kinds of systems, like spaceships, it is possible that each individual hardware and software component will be designed and constructed.
On the other hand, in the majority of systems, certain components are purchased rather than produced. Rather than developing components specifically tailored to a need, it is typically more cost-effective to simply purchase things that already exist. Nevertheless, if you buy huge off-the-shelf systems like ERP systems, there is a significant expense associated with customising these systems for usage in their operating context. This cost can be avoided by purchasing custom-built solutions.
The difference between implementation and integration is becoming less clear as a growing number of systems are produced by combining off-the-shelf hardware and software application systems. This is contributing to the blurring of the boundary between the two. There are several circumstances in which it is not necessary to design new software or hardware. The phase of the system's development that most closely resembles "implementation" is called "systems integration."
Testing of the system takes place both during and after the integration phase. When carrying out this testing, the primary focus should be on validating the interfaces between the various components as well as the operation of the system as a whole. Testing will invariably uncover issues with certain subsystems, which will need to be fixed after they are identified. Because testing takes a significant amount of time, one of the most typical issues that arises during the creation of a system is the possibility that the testing team will run out of either money or time. This issue might result in the delivery of systems that are prone to errors and will require maintenance once they have been put into operation.
Faults in individual subsystems that are the result of making incorrect assumptions about other subsystems frequently become apparent throughout the system integration process. It is possible that this will result in disagreements amongst the contractors who are in charge of developing the various subsystems. When faults are found in the interaction of subsystems, the contractors may debate over which subsystem is at fault. It can take a few weeks or perhaps a few months to negotiate a solution to the problems.
The process of delivering and deploying the finished system is the very last step in the system development life cycle. The software has been installed on the hardware, and everything is now set up and ready to go. This can require additional
configuration of the system so that it reflects the local environment in which it is used.
the migration of data from previously used systems, in addition to the creation of user documentation and the provision of training. At this point, you may also need to change other systems in the environment to ensure that the new system is able to work in tandem with the existing ones.
Even while the deployment of a technology is easy to understand in theory, in practise it is frequently more challenging than expected. It is possible that the user environment would differ from what the creators of the system had envisioned. It may be challenging to modify the system so that it functions properly in an unanticipated context. The data from the previous system might need a significant amount of tidying up, and certain aspects of it might require more work than anticipated. It's possible that the documentation for the interfaces to the other systems is lacking. It's possible that you'll find that the planned operational procedures need to be altered in order to make them compatible with the operational processes used by other systems. User training is frequently difficult to organise, and as a result, users are frequently unable to access the features and functionality of the system, at least in the beginning. Because of this, the deployment of the system may take significantly more time and result in significantly higher costs than expected.
More About Systems engineering
Course: Software Engineering (CS391)
University: Fayoum University
