<<

3rd Stage Subject: Software

Lecture time: 8:30 AM- 2:30 PM Lecture No. : 6 Class room no.:

Instructor: Ali Kadhum AL-Quraby Department of computer science

The ways of coping with change and changing system requirements, These are:

First. Prototyping

A prototype is an initial version of a software system that is used to demonstrate/ examine options, and finding out/getting information/يختبر present concepts, try out more about the problem and its possible solutions. Rapid, iterative development of the can experiment مالكينprototype is essential so that costs are controlled and system stakeholders with the prototype early in the software process. A prototype supports change avoidance as it allows users to experiment with the system before delivery and so refine their requirements.

A software prototype can be used in a software development process to help anticipate changes that may be required:

1. In the requirements engineering process, a prototype can help with the elicitation .and validation of system requirementsاستنباط 2. In the system design process, a prototype can be used to explore particular software solutions and to support .

System prototypes allow users to see how well the system supports their work by getting new ideas for requirements, finding areas of strength and weakness in the software, and proposing new system requirements. Furthermore, as the prototype is developed, it may reveal errors and omissions in the requirements that have been proposed. A function described in a specification may seem useful and well defined. However, when that function is combined with other functions, users often find that their initial view was incorrect or incomplete. The system specification may then be modified to reflect their changed understanding of the requirements.

A system prototype may be used while the system is being designed to carry out design experiments to check the feasibility of a proposed design. For example, a may be prototyped and tested to check that it supports efficient data access for the most common user queries. Prototyping is also an essential part of the user interface design process.

A process model for prototype development is in the next figure. The objectives of prototyping should be made explicit from the start of the process. These may be to develop a

system to prototype the user interface, to develop a system to validate functional system requirements, or to develop a system to demonstrate the feasibility of the application to managers. The same prototype cannot meet all objectives. If the objectives are left unstated, management or end-users may misunderstand the function of the prototype. Consequently, they may not get the benefits that they expected from the prototype development.

The process of prototype development

The next stage in the process is to decide what to put into and what to leave out of the prototype system. To reduce prototyping costs and accelerate the delivery schedule, the software engineer may leave some functionality out of the prototype. The software engineer may decide to relax non-functional requirements such as response time and memory utilization. Error handling and management may be ignored unless the objective of the prototype is to establish a user interface. Standards of reliability and program quality may be reduced.

must be made بند/فقرة The final stage of the process is prototype evaluation. Provision during this stage for user training and the prototype objectives should be used to derive a plan for evaluation. Users need time to become comfortable with a new system and to settle into a normal pattern of usage. Once they are using the system normally, they then discover requirements errors and omissions.

A general problem with prototyping is that the prototype may not necessarily be used in the same way as the final system. The tester of the prototype may not be typical of system users. The training time during prototype evaluation may be insufficient. If the prototype is slow, the evaluators may adjust their way of working and avoid those system features that have slow response times. When provided with better response in the final system, they may use it in a different way.

ع ظ ل Software Engineering 2 ل ي كا م ا غرا ب ي

Second. Incremental delivery

Incremental delivery is an approach to software development; where some of the developed increments are delivered to the customer and deployed for use in an operational environment. The Incremental delivery supports both change avoidance and change tolerance. In an incremental delivery process, customers identify, in outline, the services to be provided by the system. They identify which of the services are most important and which are least important to them. A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality. The allocation of services to increments depends on the service priority, with the highest-priority services implemented and delivered first.

Once the system increments have been identified, the requirements for the services to be delivered in the first increment are defined in detail and that increment is developed. During development, further for later increments can take place but requirements changes for the current increment are not accepted.

Once an increment is completed and delivered, customers can put it into service. This means that they take early delivery of part of the system functionality. They can experiment with the system and this helps them clarify their requirements for later system increments. As new increments are completed, they are integrated with existing increments so that the system functionality improves with each delivered increment.

Incremental delivery has a number of advantages:

1. Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments. Unlike prototypes, these are part of the real system so there is no re-learning when the complete system is available. ع ظ ل Software Engineering 3 ل ي كا م ا غرا ب ي

2. Customers do not have to wait until the entire system is delivered before they can gain value from it. The first increment satisfies their most critical requirements so they can use the software immediately. 3. The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system. 4. As the highest-priority services are delivered first and increments then integrated, the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system.

However, there are problems with incremental delivery: 1. Most systems require a set of basic facilities that are used by different parts of the system. As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.

2. Iterative development can also be difficult when a replacement system is being developed. Users want all of the functionality of the old system and are often unwilling to experiment with an incomplete new system. 3. The essence of iterative processes is that the specification is developed in conjunction with the software. However, this conflicts with the procurement model of manyباالتحاد organizations, where the complete system specification is part of the system development contract. In the incremental approach, there is no complete system specification until the final increment is specified. This requires a new form of contract, which large customers such as government agencies may find difficult to accommodate.

There are some types of system where incremental development and delivery is not the best approach or can use the incremental development and delivery in conjunction with another approach These are very large systems where development may involve teams working in different locations, some embedded systems where the software depends on hardware development and some critical systems where all the requirements must be analyzed to check for interactions that may compromise the safety or security of the system.

ع ظ ل Software Engineering 4 ل ي كا م ا غرا ب ي