Advanced systems development assignment 1 PDF

Preview

Summary

Semester 2 Assignment 1INF 3705Due Date 21 August 2018Question 1Briefly discuss why it is usually cheaper in the long run to use software engineering methods and techniques for software systemsAnswer Software is Computer programs and associated documentation to perform specific tasks. Software produ...

Description

Semester 2 Assignment 1 INF 3705 Due Date 21 August 2018

Question 1 Briefly discuss why it is usually cheaper in the long run to use software engineering methods and techniques for software systems

Answer Software is Computer programs and associated documentation to perform specific tasks. Software products may be developed for a particular customer or general market While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of systems. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can't, therefore, say that one method is better than another. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use.

Question 2 Based on your own knowledge of some of the application types discussed in section 1.1.2, 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 interactive gaming; the extensive UI design required for games is not needed in safety-critical 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 Question 3 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. Question 4 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. 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. Question 5

Explain how the principles underlying agile methods can lead to the accelerated development and deployment of software. Answer

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 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.

Question 6

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.

Question 7 The way in which a system boundary is defined, and an appropriate context model is created may have serious implications on the complexity and cost of a project. Give two examples where this may be applicable

Answer Context model is the immediate external environment of the system defining the system's context and the dependencies that a system has on its environment. The context model shows what is outside of the system boundary.

To this day, most projects still do not meet their objectives, even with all the knowledge and best practices learned so far. According to The Standish Group (2009), just 32% of all projects surveyed were successful in delivering the required product with all its features and functions, and on time and on budget. This statistic includes any type of project, whether complex or not. Recent studies are increasingly suggesting that highly complex projects are adding significant challenge due to the impact of complexity and its different factors, hereon called dimensions. A conclusion is that complex problems do not have one single solution that can be effectively used. Each situation might need a different form of resolution, and different complex systems perspectives might also be needed. One example of looking at complexity suggests that there are different possible approaches that would result in failure, but a very limited number (if not only one) that will result in success. The more complex a situation is, the harder it is to find the limited options that may lead to success. This is applicable in the Cost Estimation Process Cost overruns are common in modern-day projects. These statistics show the reality of how the traditional cost estimation process fails when dealing with complexity and complex projects. Even though different approaches for cost estimation can be found, The only dimension of complexity that is present is risk, which has been an aspect of traditional project management for several decades.One aspect that seems relevant is that estimates are normally produced by technical people (i.e.,engineers), who, by nature, are optimistic They normally think that the work can be done, that a solution can be found, even though there are several complexity factors like interdependency of elements, uncertainty, innovation Currently, a cost estimate is often produced based on a standard, “one-size-fit-all” approach. Hence the chances for that estimate to be accurate are low, often leading to projects cost overruns. For that reason, it is important to take into consideration the potential dimensions of project complexity. Another application is overestimation of benefits, underestimation of costs, failure to meet client requirements, misalignment between stakeholders with different and competing views and goals, the lack of right resources to manage the project, and the lack of proper tools to manage complex projects, leading to overwork and low performance,...