Iuse-se- 008 #2.docx

  • Uploaded by: Pro League
  • 0
  • 0
  • December 2019
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Iuse-se- 008 #2.docx as PDF for free.

More details

  • Words: 1,749
  • Pages: 5
NAME: Abdullah Israr Course Title: Introduction to Software Engineering Submitted To: Mam Afza Kazmi Reg No. iUSE-SE-008 Semester: 2nd Assignment No. #2 Date: 25/04/2017

Email: [email protected]

Answer No. 2.1:

A system to control anti-lock braking in a car. I think the Waterfall Model is the most appropriate model for this kind of system. A system to control anti-lock braking in a car is considered a safety-critical system; therefore, it requires an extensive analysis and heavy requirements documentation prior to implementation.

A university accounting system that replaces an existing system. For a university accounting system that replaces an existing system we could use the Waterfall Model. Primarily because the requirements are already known and the technology is well understood since we are replacing the existing accounting system with a new version. Depending on how much of the code from the existing accounting system could be reusable, then the integration and configuration model may also be acceptable.

A virtual reality system to support software maintenance. I believe the incremental development model would be the most appropriate for a virtual reality system to support software maintenance because the requirements cannot easily be predicted or identified in advance and are highly likely to evolve over time. This virtual reality system will be high maintenance with complex programming and update intensive, therefore will likely go through several iterations and release versions.

An interactive travel planning system that helps users plan journeys with the lowest environmental impact. I think the Incremental development model is the most appropriate for an interactive travel planning system because most of the requirements are known up-front but are likely to evolve over time. For that reason, incremental development is better for system's requirements that are likely to change. In the travel industry changes always occur, thus e²ecting requirements. It’s also likely that the method of lowest environmental impact may change frequently. The incremental development model also makes it easier to capture customer feedback. Answer No. 2.2: Incremental software development is a fundamental approach of agile approaches and it is better approach than waterfall model and the most suitable for business software system. Since the business e software system is usually the complex, and need frequent changes when the goalsand process are changed. By developing the software incrementally, the cost is cheaper and easier to make changes to the software as it being developed. This model is less appropriate for real-time systems engineering since it usually involve many hardware components which are not easy to change incrementally. Also, real-time system usually safety critical which need be built based on well planned process. Answer No. 2.3: Benefits of incremental development: Lower cost of changes

The cost of accommodating changing customer requirements is reduced. The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. Frequent feedback

It is easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented.

Faster delivery

More rapid delivery and deployment of useful software to the customer is possible. Customers are able to use and gain value from the software earlier than is possible with a waterfall process. Problems with incremental development: (from the management perspective) The process is not visible

Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. System structure tends to degrade as new increments are added

Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. These activities are:

1. An initial activity where you understand the function of the system and set out broad requirements for what the system should do. These should be expressed in sufficient detail that you can use them as a basis for deciding of a system/component satisfies some of the requirements and so can be reused. 2. Once systems/components have been selected, you need a more detailed requirements engineering activity to check that the features of the reused software meet the business needs and to identify changes and additions that are required. Answer No. 2.4: 1. The user requirements are intended to describe the system’s functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the user’s environment and application domain. 2. The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established. Answer No. 2.5: ADL  Architecture Description Language CBD  Component-Based Design CRC  Class Responsibility Collaborator DFD  Data Flow Diagram ERD  Entity Relationship Diagram IDL  Interface Description Language MVC  Model View Controller OO  Object-Oriented PDL  Program Design Language

Answer No. 2.6: There are many reasons that change is inevitable in complex systems. As the software process progresses system requirements change as the business procuring the system responds to external pressures and management priorities. Therefore, whatever software process model is user, it is essential that it can accommodate changes to the software being developed. System prototyping and incremental delivery help deal with change effectively. In addition, considering change avoidance and change tolerance enables us to reduce the costs of dealing with change. Let us consider a real example to get a better grasp of these concepts. Consider a mine producing oil in Alberta an oil sands. Changes in the price of oil, depletion of reserves, cash flow of the company and market activities are just a few of the reasons of change in a complex software system put in place at the mine to control the equipment. To help deal with these changes we should initially develop effective prototyping models for the software to avoid the change. Furthermore, the system should be dynamically designed to have an acceptable amount of change tolerance. Incremental delivery of the software during mine start-up will allow any changes to be made before final delivery and ensure the customers’ requirements are met. Examples of process activities that support change are:

1. Recording of requirements rationale so that the reason why a requirement is included is known. This helps with future change. 2. Requirements traceability that shows dependencies between requirements and between the requirements and the design/code of the system. 3. Design modeling where the design model documents the structure of the software. 4. Code refactoring that improves code quality and so makes it more amenable to change. Answer No. 2.7: Here one should note that prototypes are often used as complete systems, due to the pressures of development. However, they have several faults. 1. The user interface may be minimal and not intuitive. 2. There may be no error detecting or handling code. 3. Such error messages as there are will likely be vague. 4. Generally, prototypes are not viewed as high quality products, but just tools to aid the development process Answer No. 2.8: Barry Boehm (Boehm, 1988) proposed a risk-driven software process framework (the spiral model) that integrates risk management and incremental development. The software process is represented as a spiral rather than a sequence of activities with some backtracking from one activity to another. Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be concerned with system feasibility, the next loop with requirements definition, the next loop with system design and so on. The spiral model combines

change avoidance with change tolerance. It assumes that changes are a result of project risks and includes explicit risk management activities to reduce these risks. Answer No. 2.9: The advantages of providing static and dynamic views of the software process as in the Rational Unified process are that it leads to development of software iteratively and that it helps verify software quality. Another advantage is that it helps control changes of software and that it leads to use of component-based architecture. An approach to process modeling which is simply based on static activities, such as requirements, implementation, etc. forces these activities to be set out in a sequence which may not reflect the actual way that these are enacted in any one organization. In most cases, the static activities are actually interleaved so a sequential process model does not accurately describe the process used. By separating these from the dynamic perspective i.e. the phases of development, you can then discuss how each of these static activities may be used at each phase of the process. Furthermore, some of the activities that are required during some of the system phases are in addition to the central static activities. These vary from one organization to another and it is not appropriate to impose a particular process in the model. Answer No. 2.10: Due to the introduction of extensive process automation, they have the potential to reduce the human error in creation of code and made it meet the precise syntax and other constrains. It also has the potential to produce similar or better software than that produced conventionally by relatively scarce skills software development talent and of course will reduce the cost. Automation will lead to a huge use of standardized components, and thus increasing software reliability and lessen the cost for future software maintenance. Software e engineers will be recognized because of the production of the lessinteresting, reduce more mechanical task software that engineers have to perform and thus can lead them to be more creative in the task they were assigned. Not to be forgotten, automation also assists software to address the primary issues in the software development process such as complexity, reliability and productivity. This effect is different when mention about labor market. Since the automation will lessen the need of human sensory and mental requirements of work. In a wide range industries beyond manufacturing like telephone operators, the electrocardiography or radiography used in medical process and Automated teller machine have reduced the need of human intervention.

Regards: Abdullah Israr Qureshi

Related Documents

008
May 2020 27
008
June 2020 25
008
November 2019 39
008
November 2019 40
008
November 2019 42
008
December 2019 27

More Documents from "B.I"

Iuse-se- 008 #2.docx
December 2019 8
Pai Jawaban.docx
June 2020 8
May 2020 17
Corfo_guia_incub
May 2020 13