Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful.
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. Design modeling where the design model documents the structure of the software. Code refactoring that improves code quality and so makes it more amenable to change. Advantages of process improvement frameworks 1. The approach provides a means of measuring the state of a process and a structured approach to introducing process improvements.
It is useful as a way of building on the experience of others in process improvement. Disadvantages of process improvement frameworks 1. Like any measurement system, there is a tendency to introduce improvements to improve the measured rating rather than concentrate on improvements that meet real business goals.
The maturity model approach is expensive and bureaucratic to operate. It is not really suitable for organisations that use agile development. The principles underlying agile development are: 1.
Individual and interactions over processes and tools. By taking advantages of individual skills and ability and by ensuring that the development team know what each other are doing, the overheads of formal communication and process assurance are avoided.
This means that the team can focus on the development of working software. Working software over comprehensive documentation. This contributes to accelerated development because time is not spent developing, checking and managing documentation.
Customer collaboration over contract negotiation. This allows useful functionality to be developed and delivered earlier than would be possible if contracts were required. Responding to change over following a plan. Agile developers argue rightly that being responsive to change is more effective than following a plan-based process because change is inevitable whatever process is used.
There is significant overhead in changing plans to accommodate change and the inflexibility of a plan means that work may be done that is later discarded. Discuss the advantages and disadvantages of this approach to requirements description. Advantages of stories: 1. They represent real situations that commonly arise so the system will support the most common user operations. It is easy for users to understand and critique the stories. They represent increments of functionality — implementing a story delivers some value to the user.
Disadvantages of stories 1. They are liable to be incomplete and their informal nature makes this incompleteness difficult to detect. They focus on functional requirements rather than non-functional requirements.
Representing cross-cutting system requirements such as performance and reliability is impossible when stories are used. The relationship between the system architecture and the user stories is unclear so architectural design is difficult. Your comparison should be based on the effectiveness of each approach for planning the allocation of people to projects, estimating the cost of projects, maintaining team cohesion and managing changes in project team membership.
Planning allocation of people to projects Scrum Scrum handles people allocation informally. Alternatively, the tasks can be allocated by the Scrum master. There is no formal mechanism in Scrum for planning for project members with very specific expertise to be temporarily allocated to a team. This need must be identified by the Scrum master and he or she has to discuss how the expertise can be made available. The expertise required for each part can then be identified and the allocation of people to projects planned on that basis.
Estimating project costs Scrum Project costs are estimated based on the required delivery date for the software and people working in the Scrum team. The functionality of the system is adjusted so that some working system will always be delivered for the original cost estimation. Of course, this may not be adequate for the customer and they have to become involved in rescheduling the delivery of the system.
Plan-based development Project costs are based on an analysis of the functionality specified in the requirements document as well as the non-functional requirements of the system. They may be adjusted to reflect team size and delivery schedule. It is normal for costs to be underestimated and the final project to cost much more than originally estimated. An average cost for team members is assumed. Maintaining team cohesion Scrum Team member meet daily either face to face or electronically.
Extensive informal discussions and communications are encouraged. Team members negotiate work to be done from the project backlog. This all leads to a shared feeling of product ownership and a very cohesive team. Plan-based development Team cohesion is the responsibility of the project manager and he or she has to take explicit actions to encourage this. The general approach relies on formal meetings that are relatively infrequent and this does not lead to the development of a cohesive team.
Managing changes in project team membership Scrum This is a topic that is rarely discussed in Scrum but is a fundamental problem because so much information is informal and reliant on people remembering what has been agreed. When someone leaves, it can be very difficult to bring a replacement team member up to speed, especially if very little project documentation is available. Therefore, if a team member leaves, then a new team member with comparable expertise can read what has been done and, after understanding this, should be able to serve as a replacement.
Project planning is often essential when developing software with larger teams to a ensure that the right people are available when they are needed to be involved in the development process and b ensure that the delivery schedules of different parts of the system developed by different teams are aligned. Requirements analysis and documentation is important to decide how to distribute the work across teams and to ensure that each team has some understanding of what other teams are doing.
Design documentation especially interface specifications are important so that teams can develop independently without having access to software that is under development. Risk management may be required to ensure that all of the teams understand the risks faced and can organize their work to minimize these risks. Risk management may also be useful to cope with different delivery schedules used by different teams. That is, they adopt the outlook of the development team and lose sight of the needs of their user colleagues.
Suggest three ways how you might avoid this problem and discuss the advantages and disadvantages of each approach. Involve multiple users in the development team. Confirmation of dose to be delivered by operator.
Continuous visual display of dose being delivered. Comparison with delivery site in previous treatment. Light used to illuminate site of radiation delivery. Operator confirmation of site before machine can operate.
Patient asked to verify name, address and age before machine starts by pressing button. Issue patient with a personal treatment card which is handed over to identify patient. Maintain separate list of patients to be treated each day and correlate with patient databases. Force machine operator to verify list and database consistency before starting machine.
Dual display of information in therapy machine and database. Highlighting of differences in operator display. Locking of machine until information is consistent. Use of check digits and other error checking codes in the data.
Duplicate communication channels between machine and database. Give reasons for your choice of metric. Predict the usage of these systems and suggest appropriate values for the reliability metrics. Note that the values in this table are really quite arbitrary and you need to know more about the domain to set accurate values.
Any values which take into account the type of system involved are equally good. Reliability System Suggested value Rationale metric The system needs to be continuously System should be available as patients may be admitted or unavailable for Patient monitoring discharged at any time. The chosen Availability less than 20 system figure is acceptable because, if minutes per necessary, critical system functions can month.
Non-stop system but not critical. Short Refrigeration unit 20 minutes per Availability periods of failure are not a real problem control month as temperature takes some time to rise. Giving reasons for your answer, chose a reliability metric that might be used to specify the required reliability for such a system.
This is the probability that the system will respond correctly when a request is made for service at a given point in time. This metric is used for protection systems where demands for service are intermittent and relatively infrequent over the lifetime of the system.
Assuming that the signal status and the speed limit for the track segment are transmitted to on-board software on the train before it enters the track segment, propose five possible functional system requirements for the onboard software that may be generated from the system safety requirements. There are several different possibilities here.
Some examples: 1. The system shall ensure that the train brakes are applied when a 'red signal' is received. The system shall sound an alarm in the driver's cabin when a 'red signal' is received.
The system shall compare the train speed with the segment speed limit once per second. If the train speed exceeds the segment speed limit and the train throttle position is not zero then the throttle position should be reset to zero. If the train speed exceeds the segment speed limit and the train deceleration is less than the comfortable decleration limit then the train brakes should be applied.
The common characteristics of all styles to support fault tolerance is that there are multiple separate implementations of system functionality and some error detection mechanism that can detect possible software failures.
Giving reasons for your answer, suggest an architectural style that might be used for this system. The clue here is in the question — the system is not safety critical so eliminates protection systems. However, there is a need for availability so the most appropriate architectural pattern is an N-version programming architecture or a replicated server architecture with each server running a different OS.
Comment on whether or not you think this is a good suggestion. Advantages of N-version programming 1. Increases design diversity so probability of faults that result in failures should be reduced 2. Increased cost because of the need to use independent development teams 2.
Increased software complexity because of the need for a fault tolerant controller. Increased complexity increases the probability of error 3.
Improvement in reliability in practice is limited because of the possibility of common errors made by different development teams. N-version programming would not be a good design strategy for this type of software. There is no need for high availability and the increased complexity and cost would make the overall cost of the machine too high.
There may be a specification error that is reflected in both versions. The problem may be a numeric error that has not been explicitly trapped. The specification may be ambiguous and may be misunderstood in the same way by both teams. You should handle all exceptions explicitly because the default exception handler in most systems causes the application system to stop executing.
Obviously, this is unacceptable in systems that have to have a high level of availability. Even where some other exception handling strategy is used, it is unlikely that a single strategy is appropriate for all different types of exception and the strategy used may lead to a loss of services in the application system.
Application security engineering is the responsibility of system designers who have to design security into the system that reflects the security requirements and policies of the system procurer.
Infrastructure security engineering is the responsibility of system managers or administrators whose job is to configure the existing infrastructure software operating systems, databases, middleware, etc.
The use of diverse technologies provides some protection against common vulnerabilities in different elements of the distributed system. Availability is enhanced by distributing assets so that attacks on one element do not disable the entire system. If diverse technologies are used, it reduces the chances that an attack on all elements of the system will be successful.
Why is it difficult to protect against it in large organizations? Social engineering occurs where accredited users of a system are fooled into giving away secret information such as passwords to potential attackers. It is difficult to protect against this in large organisations because these have a hierarchical structure and people are used to obeying instructions from their managers.
Explain how the complementary strategies of resistance, recognition and recovery may be used to enhance the survivability of a system. Resistance: Built-in mechanisms to resist attacks such as the use of firewalls means that many attacks on the system that may threaten its survivability are unsuccessful. Recognition: This is the process of recognising that an attack is underway. Early recognition means that counter-measures can be quickly deployed and that extra protection can be applied to critical assets, thus increasing the overall chances of survival.
Recovery: If the system has built-in features to support recovery, then normal system service can be resumed more quickly after a successful attack. The overall availability of the system is therefore increased. Attack 1: Unauthorised orders are inserted into the system between the system and the external computer system of the stock buyer or seller.
That is, the communications link between the system and the external world is compromised. Thus, additional orders introduced into the system can be detected. Monitor all orders transmitted on communication link and ensure that the number of transmitted orders matches the number of placed orders. Attack 2: Authorised insider places orders that could result in unacceptable losses for the company this has occurred in several real systems.
Counter-strategies: Ensure that authorised users have an order limit and this can only be exceeded with approval from their manager. Monitor transactions of all insiders to ensure that losses do not exceed limit. Provide daily lists of insider transactions for checking. Why do you think that critical systems engineers are against the use of formal methods? Formal methods can be cost-effective in the development of safety-critical software systems because the costs of system failure are very high and so additional cost in the development process is justified.
Most safety-critical systems have to gain regulatory approval before they are used and it is a very expensive process to convince a regulator that a system is safe. The use of a formal specification and associated correctness argument may be less than the costs e. Some developers of systems are against the use of formal methods because they are unfamiliar with the technology and unconvinced that a formal specification can be complete representation of the system.
Furthermore, the problem with formal specifications are that they cannot be understood by system customers so they may conceal errors and give a false picture of the correctness of the system. To measure reliability you need to have statistically valid failure data for the system so you need to induce more failures than are specified in the given time period.
However, because the number of failures is so low, this will take an unrealistically large amount of time. Explain the function of any tools that you think may be useful. Validating a password protection system involves: 1. Identifying possible threats. The principal threats are a. Attacker gains access without a password b.
Attacker guesses a password of an authorised user c. Attacker uses a password cracking tool to discover passwords of authorised users d. Users make passwords available to attackers e. Attacker gains access to an unencrypted password file 2. Developing tests that cover each of these threats a. Test system for all authorised used to check that they have set a password. Test system heuristically for commonly used passwords such as names of users, festivals, other proper names, strings such as '' etc.
Check that all user passwords are not words that are in a dictionary. A password cracking tool usually checks encrypted passwords against the same encryptions of words in a dictionary. This is very hard to check. To stop users writing down passwords you need to allow words that are in the dictionary and are hence easy to remember. Check that access to the password file is very limited. Check that all copy actions on the password file are logged.
Safety cases would normally be required for any system that needs to be certified by a regulator before it is used e. Systems used to control equipment in the nuclear industry where there is a possibility of the release of radioactivity. Signalling and control systems in the railway industry. Software for critical aircraft functions such as flight control systems.
It ensures that entry to the storeroom is only permitted when radiation shields are in place or when the radiation level in the room falls below some given value dangerLevel. So: i If remotely controlled radiation shields are in place within a room, an authorized operator may open the door.
The code shown in Figure Note that the safe state is that entry should not be permitted. Using the approach discussed in section Use the line numbers to refer to specific statements. If you find that the code is unsafe, suggest how it should be modified to make it safe. There are two potential safety problems with this code: 1. Say the door was unlocked when the door entry code was entered. Line 13 checks if the state is safe and, if it is safe then unlocks the door.
However, if the door was unlocked to begin with, there is no locking action if the state is unsafe so therefore a potential safety loop hole exists. If the radiation level is less than the danger level then line 8 sets the state to be safe. However, line 10 checks the shields to see if they are in place.
If they are not in place, the state is unchanged although, in fact, the system is unsafe if the shields are down. Therefore, the door can be opened with the shields down and a safety loophole exists. If savings from reuse were proportional to the amount of code reused, then reusing lines of code would save twice as much as reusing lines of code. However, to reuse lines of code, that code must be understood and the costs of program understanding are not linear — the more code to be understood, the more effort it takes to understand it.
Furthermore, more changes may be required, the larger the amount of code reused so this also adds to the costs of reusing more code. Of course, all this is only true if the code has to be understood before it is reused. If it can be reused without change, then savings from reusing large chunks of code tend to be proportionally greater than savings from reusing small code fragments.
Circumstances where software reuse is not recommended: 1. If the business status of the code provider is dubious. If the provider goes out of business, then no support for the reused code may be available. In critical applications where source code is not available. Testing the code to the required standards may be very difficult.
In small systems where the costs of reuse are comparable to the savings that result if code is reused. In systems where performance is a critical requirement — specially developed code can usually be made more efficient. You should present your architecture as a layered model, showing the components that might be included at each level.
There are various options here. The important characteristic of the solution is to have clear functional separation between the layers. I have suggested a 4-layer system as shown below: 1. Communications the lowest layer. All components that are concerned with interaction with a remote system.
Data storage and management. All components that are concerned with looking after the data that has been collected.
All components that are concerned with managing the specific instruments in the system. Data collection and processing. All components that control the collection, processing and monitoring of the collected data. What steps can a company take to reduce these risks? Risks that can arise when systems are constructed using COTS include: 1. Vendor risks: Failure of vendor to provide support when required Vendor goes out of business or drops product from its portfolio 2.
Process risk: Time required to understand how to integrate product is higher than expected. The risks can be addressed by only dealing with vendors that use an escrow system so that source code is available if they go out of business, by extensive research and testing of product capabilities before use, discussion with other users etc. In general though, because COTS are provided by external vendors, risk reduction is difficult.
Suggest three practical problems that might arise in writing adaptor software to link two COTS application products. Adaptors are usually required because the COTS products are independently developed at different times and, therefore, they are not designed for integration.
There is no reason why the database organisation, user interfaces, APIs, etc. Three practical problems that may arise when integrating COTS application systems are: 1. Missing information. Application A may require information from application B to work properly. However, application B may not need this information or it may be optional and so it cannot guarantee that it can be made available to application A.
Control incompatibilities. Application A and application B may have different control philosophies. For example, application A may be reactive, depending on the user inputs whereas application B may be proactive and use workflow-based, pre-defined interaction. Semantic mismatches. This occurs when different applications use the same name for some kind of information but that actually means different things. It is important to define all interactions through requires and provides interfaces so that the use of the component is completely independent of its implementation.
Differences between components and web services: 1. Once a component is purchased, it is owned by the user whereas the web service is always owned by the provider. This is significant because it means that the owner has no control over changes to the service — if it changes or disappears then this may have adverse consequences for the user.
With components, however, the user decides when newer versions are to be used. There are widely-accepted standards for services against several competing standards for components so service inter-operability is should be much better.
Take, for example, a stack component. This will provide basic operations that are common to all stacks such as Initialise Create a stack , Push an item onto the stack , Pop an item from the stack , Size the number of items currently on the stack , and perhaps others. However, each application will use stacks in different ways and so may require different versions of these operations and additional operations. For example, consider a graphical browsing operation that allows users to browse a digital library.
The library is divided into areas and the identifier for each area points to the books in that area. When the user enters an area, its identifier is pushed onto a stack and popped from the stack when he or she leaves that area and goes back to the previous area.
Thus, the top of the stack always refers to the books in the current area. However, there is a requirement to provide a facility where the user can view all areas visited and this requires an additional stack operation that provides access to all stack elements.
This then has to be added to the stack component. In what ways would a formal component specification simplify the problems of validation? Component validation without source code is very difficult because there is no way of assessing how the component handles exceptions and this is rarely defined in a component specification. The only validation method that can be used is black-box testing so static techniques cannot be used.
Component specifications are rarely complete and this increases the problems of black-box testing. Formal specifications would help because they would precisely define what the component was supposed to do and its actual behaviour could be compared to the specification. However, formal specification rarely cover all exceptions and they do not help with testing performance, dependability or other non-functional characteristics.
In sequential composition, Component C is created by composing A and B in sequence i. For example, in an object oriented system, the code of C would be implemented as a call to method A in object class X followed by a call to method B in object class Y. In an object oriented program, component C could be a method that calls a method X. Within X. B, there is a call to Y. In additive composition, Component C is created by integrating the interfaces of component A and component B to create the interface of component C.
In an object oriented program, this would be implemented by creating a new class C, which includes the interfaces of classes A and B. In a remote procedure call, an executing component on one computer A calls a procedure or method, which is part of a component that is executing on a different computer B.
The role of the middleware is to coordinate this interaction. There are several steps involved in this: 1. The provision of a stub procedure with the same interface as the called component. Calling this stub procedure initiates a call to the system middleware. The middleware running on computer A accepts the call and discovers the location of the called component. It translates the parameters into a standard format and sends these to computer B along with a request to call the required component.
The middleware on computer B converts the parameters into the appropriate format for the language of the called component and then calls that component. After execution, the called component returns the result to the middleware on computer B which then translates this into the middleware standard format.
The result is transmitted to the middleware on computer A, which then translates that into the appropriate language format and returns it to the original calling component.
However, modern web browsers are all javascript enabled which means that code can be downloaded from the web page on the server and executed within the client browser. This means that some of the functionality of fat clients can be replicated without the need to install software on the client system.
Each dealer uses this simulation in a different way, according to his or her experience and the type of stocks in question. Suggest a client—server architecture for this system that shows where functionality is located. Justify the client—server system model that you have chosen. In this case, I would chose a fat client model with company information located on a central server this is critical information and its important that it is consistent for all dealers.
A fat client architecture is required because simulations require considerable processing and it would place an unacceptable load on the server if several dealers started simulations at the same time. Advantages of decentralized p2p architectures: Less vulnerable to denial of service attack Scaleable — system performance should not be adversely affected by adding peers. Disadvantages of decentralized p2p architectures: Peer communications more difficult to organize.
More expensive to discover what peers are available on the network. Advantages of semi-centralised p2p architectures: Easy to keep track of what peers are available.
Disadvantages of semi-centralised p2p architectures: Failure of server results in system unavailability. Vulnerable to denial of service attack on server What additional costs might arise if this deployment model is used? Deploying software as a service has the potential for reducing the IT support costs as there is no need to install and support separate software on each client. Rather, all software is hosted on a server and when e.
There are no support problems with different computers in an organization running different software versions. General help support is provided by the service provider rather than the local IT staff. The additional costs that can arise from this model are: 1. Network costs, as obviously there is a considerable increase in network traffic. Service providers such as Amazon may charge for data uploads and downloads. This is only applicable of the service is provided by a 3rd party rather than in-house.
Server costs, as the servers are responsible for all computation and so must either be more powerful or more numerous. This is most significant if the service is provided in-house. There may in fact be additional support costs from this model in the short- term if it requires users to change the software that they normally use.
This is likely to lead to additional demands for help. Software components are under the control of the buyer of the component whereas services are controlled by the service provider.
Thus, changes can be made to services without the consent of the service user. Services are stand-alone entities that do not normally require users to make any other services available. The temperatures should be represented as integers with an additional field indicating whether the temperature is in degrees Fahrenheit or degrees Celsius. InDataFault should be a simple type consisting of an error code. Embedded applications in devices where a network connection cannot be guaranteed.
These are unlikely to make use of services as there is no guarantee that these services will be available when required. Real-time applications with stringent deadlines, especially those with lots of user interaction e. In these applications, the performance overhead in coding and decoding XML messages is likely to be unacceptable. Compensation actions may have to be included in workflows because the success of the entire workflow may rely on all included workflows successfully completing.
Compensation actions are required when dependent services, offered by different suppliers, are composed to create an integrated service. For example, say a meeting organiser has to book a room for a meeting then organise catering for the people attending the meeting. It may not be possible to do this concurrently as the numbers attending the meeting may not be known. If the room is booked but, subsequently, it transpires that no catering is available that day, then the booking must be cancelled by a compensating action.
They should be given the option of booking either a taxi or a hire car. You may assume that the taxi and car hire companies offer web services to make a reservation. This should display the number of recorded messages on an LED display and should allow the user to dial-in and listen to the recorded messages.
The diagram shows one possible state model. Notice this does not allow for message deletion as this was not asked for in the question. Adding deletion after playback is simple with an additional state that deletes the message and reduces the message count. An object-oriented approach may result in unacceptable timing delays because structuring a system into objects probably means that there will be a large number of small tasks currently active in a system. The overhead of task communications will slow down the system and may cause timing problems.
A further problem with object orientation is unpredictable timing as the time to call a method depends on the inheritance hierarchy. The student may answer this in terms of problems with Java e.
I was really looking for a more general discussion but you may think this is OK. The temperature should be between 10 and 30 degrees Celsius. If it falls below 10 degrees, the heating system should be switched on; if it goes above 30, the windows should be automatically opened. Display Thermometers System Temp.
Students will often over-complicate the diagram by considering situations such as too cold and ventilator open. Details are shown in Figure Identify the stimuli that must be processed by the on-board train control system and the associated responses to these stimuli. Stimulus Associated response Check that the speed is within the speed limit for the Train speed information current segment. Set status of current segment.
Explain how you arrived at your answer. To estimate the period of the process for trackside information collection, we must be able to ensure that the process will always be scheduled during the period can access the trackside information and collect information before it passes out of range of the transmitter.
Simplistically, the train is within 10 m of a transmitter for ms assuming that the distance between the train and the transmitter is negligible. It takes 50 ms to collect the information so collection must start within ms of entering a segment. How can aspects support the implementation of each of these types of concern? Functional concerns which reflect specific functionality required.
The base system should implement core functionality and extensions, implemented as aspects, can implement secondary functionality. Quality of service concerns related to non-functional behaviour of the system. Aspects may be used to implement cross-cutting functionality, such as a cache, which helps these requirements to be met. Policy concerns relating to the overall policies of use of the system. These are inevitably cross-cutting. Aspects may be used to implement these concerns.
System concerns which relate to the attributes of the system as a whole. Aspects may be used to implement monitoring that checks the system attributes. Organisational concerns that are related to organisational goals and priorities such as maintaining reputation. Aspects have limited usefulness in implementing this type of concern. Using examples, explain why tangling and scattering can cause problems when system requirements change.
Tangling arises when one module implements part of several requirements; scattering arises where the implementation of a single requirement is spread across several modules. This is tangled system. If one of these changes so that some change to the confirmation is required, all of the other requirements that issue confirmations are affected by this. If the implementation of each requirement which issues a confirmation is scattered across several modules, then all of these have to be checked that the change will not affect their operation.
What are likely to be the most important cross-cutting concerns? Aspect interference can arise where two or more aspects specify that advice should be woven into the system at the same pointcut. The effect of this is that the system has to decide which aspect should have priority over the other and how the aspects should be composed. To answer this, think about how program testing normally involves comparing the expected output to the actual output produced by a program. If a mistake if made in specifying a poincut pattern specification, the advice will be woven into the system in the wrong place.
You may find it helpful to base your answer on the list of management activities in Section Management activities such as proposal writing, project planning and personnel selection require a set of skills including presentation and communication skills, organisational skills and the ability to communicate with other project team members.
Programming skills are distinct from these indeed, it is a common criticism of programmers that they lack human communication skills so it does not follow that good programmers can re-orient their abilities to be good managers. Other possible risks are: Technology: Communications network saturates before expected transaction limit is reached. People: Level of skill of available people is lower than expected.
Organizational: Organizational changes mean that the project schedule is accelerated. Tools: Software tools cannot handle the volume of data available for large systems. Requirements: New non-functional requirements are introduced that require changes to the system architecture. Estimation: The difficult of the software is underestimated.
If anything goes wrong, the contractor has to pay. Suggest how the use of such contracts may increase the likelihood that product risks will arise. Fixed price contracts increase the chances of product risks because they remove options from the development process.
Because the contract is fixed-price, the contractor is naturally reluctant to increase the effort or time expended on the project as this will reduce their profits on the work. Therefore, if problems arise they will look for ways to reduce the scope of the product or to reduce the costs of product development e. Both of these factors can lead to products that are not as expected by the customer.
While the notion of devolving management decisions to the team is attractive in terms of motivation, there are two types of problem that can arise: 1.
Decisions are liable to be primarily influenced by technical considerations rather than business decisions. This is natural given the type of people on an XP team — it is difficult for them to take a business perspective. Because of the focus on rapid iteration, management decisions tend to be short-term and pay insufficient attention to long-term issues. While this is in keeping with the XP philosophy, there is sometimes a need for a more detached, longer-term perspective which can be taken by a manager.
I assume here that management decisions on e. Given the close knit nature of XP teams, it is difficult for the team to take decisions that censure individual team members. Assume that some team members work remotely and it is not possible to get the whole team together at short notice. There are obviously a range of possible answers here.
The following is one possibility. Her project is going well but in the course of the project, the personal circumstances of two team members changes. This makes her current working arrangements very difficult so she asks if she can work from home most days, spending only 1 day a week in the office. Many modern applications change frequently before they are presented to the end user and then after the first versions have been used.
The few ways to build software to stop deterioration due to change would be: Gather the required information. Designer and customer define the overall objectives for the software. Identify the known requirements. After building a prototype the developer uses an existing program fragment, this will help the working program to complete quickly. To maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations.
Documents should be developed in a timely manner, to do this documentation standards are defined and mechanisms are established.
0コメント