Patient Information System in a Hospital - Research Paper Example

Software Engineering 56D: Section 8 The following is the context model of a patient information system in a hospital. Section 11 It isnecessary to design the system architecture before writing the specifications as the former is concerned with establishing a basic structural framework that identifies the main components of the system and the communication between them. The architectural design forces the software engineers to design the key aspects early in the process. It serves as a design plan that is used to negotiate system requirements and as a means of structuring discussions with clients, developers and managers. If specifications are written early then it will not allow the designers to focus on system abstractions and that would affect performance, robustness and maintainability of the system. The architecture may have to be designed before specifications are written to provide a means of structuring the specification and developing different sub-system specifications concurrently, to allow manufacture of hardware by sub-contractors and to provide a model for system costing. Section 14.1: There are two major problems encountered when modifying systems. Understanding which entities in a program are logically part of some greater entity. Ensuring that changes do not have unanticipated side-effects i.e. a change to one entity has an undesirable effect on some other entity. Object-oriented development helps to reduce these problems as it supports the grouping of entities (in object classes) so therefore simplifies program understanding. It also provides protection for entities declared within objects so that access from outside the object is controlled (the entity may not be accessible, its name may be accessible but not its representation or it may be fully accessible). This reduces that probability that chances to one part of the system will have undesirable effects on some other part. Section 16.2: A consistent user interface may be impossible to produce for complex systems with a large number of interface options. In such systems, there is a wide imbalance between the extent of usage of different commands so for frequently used commands, it is desirable to have short cuts. Unless all commands have short cuts, then consistency is impossible. It may also be the case in complex systems that the entities manipulated are of quite different types and it is inappropriate to have consistent operations on each of these types. An example of such a system is an operating system interface. Even MacOS which has attempted to be as consistent as possible has inconsistent operations that are liked by users. For example, to delete a file it is dragged to the trash but dragging a disk image to the trash does not delete it but unmounts that disk. Section 22.2: A program need not be completely free of defects before delivery if: Remaining defects are minor defects that do not cause system corruption and which are transient i.e. which can be cleared when new data is input. Remaining defects are such that they are recoverable and a recovery function that causes minimum user disruption is available. The benefits to the customer's business from the system exceed the problems that might be caused by the remaining system defects. Testing cannot completely validate that a system is fit for its intended purpose as this requires a detailed knowledge of what that purpose will be and exactly how the system will be used. As these details inevitably change between deciding to procure a system and deploying that system, the testing will be necessarily incomplete. In addition, it is practically impossible for all except trivial system to have a complete test set that covers all possible ways that the system is likely to be used. Section 22.4: Program inspections are effective for the following reasons: They can find several faults in one pass without being concerned about interference between program faults. They bring a number of people with different experience of different types of errors. Hence, the team approach offers greater coverage than any individual can bring. They force the program author to re-examine the program in detail - this often reveals errors or misunderstandings. The types of errors that inspections are unlikely to find are specification errors or errors that are based on a misunderstanding of the application domain (unless there are domain experts in the team). Section 11.5: Here are some suggestions. Ticket issuing system: Should have a centralized database with sub-systems to handle communications, route information and price information. Also sub-systems for statistical processing. Each ticket machine should be connected to this. Video conferencing system: Should include a network with a range of clients/servers on it. These should include a floor controller, video server, display clients, etc. Robot floor cleaner: Should include a centralized repository with sensors adding information to it, decision systems taking information from it and actuators using sensor information to move the machine. Section 8.8: Section 8.9: Figure 1: Sequence Diagram of the student registration using an electronic catalog Section 14.4: Section 16.5: Advantages are "at a glance", meaning that it need not be required to read word by word or concentrated with maximum energy, magnitude indication and relative magnitude indication. Temperature control Speed indicators Weather statistics Relative comparisons of cars, etc. Section 22.1: Verification is demonstrating conformance to the specification whereas validation is checking that the system meets the customer's needs. Validation is difficult because there are many different stakeholders who may use the system with different needs. Therefore, a system that meets one user's needs may not meet the needs of a different user. Furthermore, needs change as a system is developed so the needs as identified when the system was specified may be different by the time that the system is tested. Section 11.9: If given two integrated CASE toolsets and asked to make a comparison then the following levels of service may be called for action: 1. Data repository services: The storage and management of data items between the two. 2. Data integration services: The facilities provided in managing groups of entities. 3. Task management services: Definition and enaction of process models used in the two toolsets. 4. Messaging services: Tool-tool and tool-environment communication of both. 5. User interface services: User interface development of two of them. Section 22.7: The conditions that could be detected by a static analyzer for C++ programming language are as follows: 1. Variables used before initialization, 2. Variables declared but never used, 3. Variables assigned twice but never used between, 4. Possible array bound violations, 5. Undeclared variables, 6. Unconditional braches into loops, 7. Parameter type mismatch, 8. Parameter number mismatch, 9. Non-usage of results of functions, 10. Uncalled functions and procedures 11. Unassigned pointers. 12. Pointer arithmetic performed. 13. De-allocation of memory not done. 14. Exceptions are not all implemented. 15. Dynamic allocation not properly made. Compared to the list given in figure 22.7 almost 90% of the detections match with it and it is particular to a programming language only. All the conditions may not match as programming languages changes implementing in-built code deficiency handlers which are capable of managing most the above list and never thrown errors. Such a programming language is Visual basic. References Sommerville, Ian. Software Engineering. Pearson Education, 2004. Read More