INF3705 EXAM SUMMARY (Updated 2021)

INF3705 EXAM SUMMARY. Advanced Systems Development. As an information system developer, explain the following process activities to your co-workers: specification, development, validation and evolution Specification: Software specification or requirements engineering is the process of understanding and defining what services are required from the system and identifying the constraints on the system’s operation and development. Development: The implementation stage of software development is the process of converting a system specification into an executable system. Validation: Verification and validation (V&V) is intended to show that a system both conforms to its specification and that it meets the expectations of the system customer. Evolution: Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change. The principles of agile methods include the following: Principle Customer involvement. Incremental delivery. People not process. Maintain simplicity. 2.2.2 What are the differences between functional and non-functional software requirements?  Functional requirements – Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations – May state what the system should not do  Non-functional requirements – Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, and so forth – Often apply to the system as a whole rather than individual features or services  Domain requirements – Constraints on the system from the domain of operation Example of Functional requirements for the MHc-PMS  A user shall be able to search the appointment lists for all clinics.  The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments on the specific day.  Each staff member using the system shall be uniquely identified by his or her 8-digit employee number. Page 1 of 45 Metrics for specifying non-functional requirements Property Measure Speed Processed transactions/second User/event response time Screen refresh time Size Mbytes Number of ROM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Development testing Development testing includes all testing activities that are carried out by the team developing the system.  Unit testing– where individual program units or object classes are tested. Unit testing should focus on testing the functionality of objects or methods.  Component testing – where several individual units are integrated to create composite components. Component testing should focus on testing component interfaces.  System testing – where some or all of the components in a system are integrated and the system is tested as a whole. System testing should focus on testing component interactions. Importance of dependability  System failures may have widespread effects with large numbers of people affected by the failure.  Systems that are not dependable and are unreliable, unsafe or insecure may be rejected by their users.  The costs of system failure may be very high if the failure leads to economic losses or physical damage.  Undependable systems may cause information loss with a high consequent recovery cost. Page 2 of 45 End of chapter review questions Chapter 1 1. What is the most important difference between generic software product development and custom software development? What might this mean in practice for users of generic software products? Answer: The essential difference is that in generic software product development, the specification is owned by the product developer. For custom product development, the specification is owned and controlled by the customer. The implications of this are significant – the developer can quickly decide to change the specification in response to some external change (e.g. a competing product) but, when the customer owns the specification, changes have to be negotiated between the customer and the developer and may have contractual implications. For users of generic products, this means they have no control over the software specification so cannot control the evolution of the product. The developer may decide to include/exclude features and change the user interface. This could have implications for the user’s business processes and add extra training costs when new versions of the system are installed. It also may limit the customer’s flexibility to change their own business processes. 2. Based on your own knowledge of some of the application types discussed, explain, with examples, why different application types require specialized software engineering techniques to support their design and development. Answer: Different application types require the use of different development techniques for a number of reasons: 1. Costs and frequency of change. Some systems (such as embedded systems in consumer devices) are extremely expensive to change; others must change frequently in response to changing requirements (e.g. business systems). Systems which are very expensive to change need extensive upfront analysis to ensure that the requirements are consistent and extensive validation to ensure that the system meets its specification. This is not cost effective for systems that change very rapidly. 2. The most important ‘non-functional’ requirements. Different systems have different priorities for non-functional requirements. For example, a real-time control system in an aircraft has safety as its principal priority; an interactive game has responsiveness and usability as its priority. The techniques used to achieve safety are not required for Page 3 of 45 interactive gaming; the extensive UI design required for games is not needed in safetycritical control systems. 3. The software lifetime and delivery schedule. Some software systems have a relatively short lifetime (many web-based systems), others have a lifetime of tens of years (large command and control systems). Some systems have to be delivered quickly if they are to be useful. The techniques used to develop short-lifetime, rapid delivery systems (e.g. use of scripting languages, prototyping, etc.) are inappropriate for long-lifetime systems which require techniques that allow for long-term support such as design modelling. 3. Apart from the challenges of heterogeneity, business and social change and trust and security, identify other problems and challenges that software engineering is likely to face in the 21st century (hint: think about the environment). Answer: Problems and challenges for software engineering • Developing systems for multicultural use • Developing systems that can be adapted quickly to new business needs (or market requirement) • Designing systems for outsourced development • Developing systems that are resistant to attack (information security) • Developing systems that can be adapted and configured by end-users (user can design or assemble what they want) • Developing systems that are energy-efficient. 1 Explain why there are fundamental ideas of software engineering that apply to all types of software systems. Because of all software systems have common quality attributes, including availability, modifiability, performance, security and safety, testability and usability, the fundamental software ideas provides common solutions or tactics to support those qualities. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use. What is a software process? A set of activities whose goal is the development or evolution of software. Generic/Basic activities in all software processes are: • Specification - what the system should do and its development constraints • Development - production of the software system • Validation - checking that the software is what the customer wants • Evolution - changing the software in response to changing demands. Page 4 of 45 What is a software process model? A simplified representation of a software process, presented from a specific perspective. Examples of process perspectives are • Workflow perspective - sequence of activities; • Data-flow perspective - information flow; • Role/action perspective - who does what. Generic process models • Waterfall; • Iterative development; • Component-based software engineering What are software engineering methods? Structured approaches to software development which include system models, notations, rules, design advice and process guidance. Model descriptions • Descriptions of graphical models which should be produced; Rules • Constraints applied to system models; Recommendations • Advice on good design practice; Process guidance • What activities to follow. What is CASE (Computer-Aided Software Engineering) Software systems that are intended to provide automated support for software process activities. What are the attributes of good software? The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable. Essential product attributes are: • Maintainability -Software must evolve to meet changing needs; • Dependability - Software must be trustworthy; • Efficiency - Software should not make wasteful use of system resources; • Acceptability - Software must accepted by the users for which it was designed. This means it must be understandable, usable and compatible with other systems. Other attributes of good software • reusability (can it be reused in other applications), • distributability (can it be distributed over a network of processors), • portability (can it operate on multiple platforms, ie different operation system) • inter-operability (can it work with a wide range of other software systems, ie different program language). What are the key challenges facing software engineering? Heterogeneity, delivery and trust. Page 5 of 45 Heterogeneity - Developing techniques for building software that can cope with heterogeneous platforms and execution environments; Delivery - Developing techniques that lead to faster delivery of software; Trust - Developing techniques that demonstrate that software can be trusted by its users. What are methods? Methods are organised ways of producing software. They include suggestions for the process to be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines. Please give three type of software process model? And what the software development model that most software process models are based on? 1. Three types: Workflow model, dataflow/activity model and role/action model. 2. Waterfall approach, Iterative development, and Component-based software engineering. Chapter 2 2.1. Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems: A system to control anti-lock braking in a car A virtual reality system to support software maintenance A university accounting system that replaces an existing system An interactive travel planning system that helps users plan journeys with the lowest environmental impact Answer: a Anti-lock braking system - This is a safety-critical system so requires a lot of up-front analysis before implementation. It certainly needs a plan-driven approach to development with the requirements carefully analysed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages. b Virtual reality system - This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. An agile process may be used. c University accounting system - This is a system whose requirements are fairly wellknown and which will be used in an environment in conjunction with lots of other systems such as a research grant management system. Therefore, a reuse-based approach is likely to be appropriate for this. d Interactive travel planning system - System with a complex user interface but which must be stable and reliable. An incremental development approach is the most appropriate as the system requirements will change as real user experience with the system is gained. 2.2. Explain why incremental development is the most effective approach for developing business software systems. Why is this model less appropriate for real-time systems engineering? Page 6 of 45 Answer: Business software systems are usually complex, software intensive, and frequently being changed when business goals or processes are changed. So incremental development is better. Real-time systems usually involve many hardware components which are not easy to change and cannot be incremental. Also real-time systems usually safety critical which needed be built based on well planned process. 2.3. Explain why it is essential to have two separate requirements engineering activities in the process. Answer: In a reuse based process, you need two requirements engineering activities because it is essential to adapt the system requirements according to the capabilities of the system/components to be reused. These activities are:  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 if a system/component satisfies some of the requirements and so can be reused.  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. 2.4. Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process. Answer: There is a fundamental difference between the user and the system requirements that mean they should be considered separately. • 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. • 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. 2.5. Describe the main activities in the software design process and the outputs of these activities. Using a diagram, show possible relationships between the outputs of these activities. Page 7 of 45 Answer: Main activities: Architectural design – Where you identify the overall structure of the system Interface design – Where you define the interfaces between system components Component design – Where you take each system component and design how it will operate Database design – Where you design the system data structures and how these are to be represented in a database. Outputs: System architecture Database specification Interface specification Component specification 2.6. Explain why change is inevitable in complex systems and give examples (apart from prototyping and incremental delivery) of software process activities that help predict changes and make the software being developed more resilient to change. Answer: Systems must change because as they are installed in an environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence of changes to the business, business goals and business policies. 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. Page 8 of 45 2. Requirements traceability that shows dependencies between requirements and between the requirements and the design/code of the system. 3. Design modelling 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. 2.7. Explain why systems developed as prototypes should not normally be used as production systems. Answer: Prototypes should not normally be used as production systems for the following reasons: a) The user interface may be minimal and not intuitive. b) There may be no error detecting or handling code. c) Such error messages as there are will likely be vague. d) Generally, prototypes are not viewed as high quality products, but just tools to aid the development process. 2.8. Explain why Boehm’s spiral model is an adaptable model that can support both change avoidance and change tolerance activities. In practice, this model has not been widely used. Suggest why this might be the case. Answer: Boehm’s 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. It is not widely used as it might be difficult to apply in some contexts. 2.9. What are the advantages of providing static and dynamic views of the software process as in the Rational Unified Process? Answer: 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. 2.10. Historically, the introduction of technology has caused profound changes in the labour market and, temporarily at least, displaced people from jobs. Discuss whether the introduction of extensive process automation is likely to have the same consequences for software engineers. If you don’t think it will, explain why not. If you think that it will reduce job opportunities, is it ethical for the engineers affected to passively or actively resist the introduction of this technology? Answer: Page 9 of 45 There are obviously different views here and a lot depends on the development of CASE technology in the future. A major difference between the introduction of CASE technology and, for example, the introduction of CAD technology which made draftsmen redundant, is that the routine elements in the design and development of software are relatively minor parts of the whole development process. Therefore, savings are not that large. However, if AI technology develops so that truly intelligent tools can be developed than, obviously, this situation will change. Technology will make some jobs redundant but will also create job opportunities. Chapter 3 3.1. Explain why the rapid delivery and deployment of new systems is often more important to businesses than the detailed functionality of these systems. Answer: A conventional waterfall or specification­based process is usually prolonged and the final software is delivered to the customer long after it was originally specified. In a fastmoving business environment, this can cause real problems. By the time the software is available for use, the original reason for its procurement may have changed so radically that the software is effectively useless. Therefore, for business systems in particular, development processes that focus on rapid software development and delivery are essential. 3.2. Explain how the principles underlying agile methods lead to the accelerated development and deployment of software. The principles underlying agile development are: a Individual and interactions over processes and tools. By taking advantages of individual skills and ability and by ensuring that the development team knows 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. b Working software over comprehensive documentation. This contributes to accelerated development because time is not spent developing, checking and managing documentation. Rather, the programmer’s time is focused on the development and testing of code. c Customer collaboration over contract negotiation. Rather than spending time developing, analyzing and negotiating requirements to be included in a system contract, agile developers argue that it is more effective to get feedback from customer’s directly during the development about what is required. This allows useful Page 10 of 45 functionality to be developed and delivered earlier than would be possible if contracts were required. d 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. 3.3. When would you recommend against the use of an agile method for developing a software system? Answer: Agile methods should probably not be used when the software is being developed by teams who are not co-located. If any of the individual teams use agile methods, it is very difficult to coordinate their work with other teams. Furthermore, the informal communication which is an essential part of agile methods is practically impossible to maintain. Agile methods should probably also be avoided for critical systems where the consequences of a specification error are serious. In those circumstances, a system specification that is available before development starts makes a detailed specification analysis possible. However, some ideas from agile approaches such as test first development are certainly applicable to critical systems. 3.4. Extreme programming expresses user requirements as stories, with each story written on a card. Discuss the advantages and disadvantages of this approach to requirements description. Answer: Advantages of stories:  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:  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. 3.5. Explain why test-first development helps the programmer to develop a better understanding of the system requirements. What are the potential difficulties with test-first development? Answer: Test-first development helps with understanding the requirements because, in order to write a test, you have to analyse the requirements in detail to discover what is intended. In many cases, you may find that writing a test is impossible because the requirements are incomplete. The problem with test-first development is that some tests are very Page 11 of 45 difficult to write because they require a system infrastructure to be in place before anything can be tested. 3.6. Suggest four reasons why the productivity rate of programmers working as a pair might be more than half that of two programmers working individually. Answer: Reasons why pair programming may be more efficient as the same number programmers working individually: 1. Pair programming leads to continuous informal reviewing. This discovers bugs more quickly than individual testing. 2. Information sharing in pair programming is implicit – it happens during the process. This reduces the need for documentation and the time required if one programmer has to pick up another’s work. Individual programmers have to spend time explicitly sharing information and they are not being productive when doing so. 3. Pair programming encourages refactoring (the code must be understandable to another person). This reduces the costs of subsequent development and change and means that future changes can be made more quickly. Hence, efficiency is increased. 4. In pair programming, people are likely to spend less time in fine-grain optimization as this does not benefit the other programmer. This means that the pair focuses on the essential features of the system which they can then produce more quickly. 3.7. Compare and contrast the Scrum approach to project management with conventional plan-based approaches, as discussed in Chapter 23. The comparisons 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. 3.8. You are a software manager in a company that develops critical control software for aircraft. You are responsible for the development of a software design support system that supports the translation of software requirements to a formal software specification (discussed in Chapter 13). Comment on the advantages and disadvantages of the following development strategies: a. Collect the requirements for such a system from software engineers and external stakeholders (such as the regulatory certification authority) and develop the system using a plan-driven approach. b. Develop a prototype using a scripting language, such as Ruby or Python, evaluate this prototype with software engineers and other stakeholders, then review the system requirements. Redevelop the final system using Java. c. Develop the system in Java using an agile approach with a user involved in the development team. 3.9. It has been suggested that one of the problems of having a user closely involved with a software development team is that they ‘go native’; 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. Answer: 1. Involve multiple users in the development team. Advantages are you get multiple perspectives on the problem, better coverage of user tasks and hence requirements and less likelihood of having an atypical user. Disadvantages are cost, difficulties of getting user engagement and possible user conflicts.