Software Engineering

1. Problem analysis and change specification: The process starts with an identified requirements problem or, sometimes, with a specific change proposal. During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the request. 2. Change analysis and costing: The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. The cost of making the change is estimated both in terms of modifications to the requirements document and, if appropriate, to the system design and implementation. Once this analysis is completed, a decision is made whether or not to proceed with the requirements change. 3. Change implementation: The requirements document and, where necessary, the system design and implementation, are modified. You should organize the requirements document so that you can make changes to it without extensive rewriting or reorganization. As with programs, changeability in documents is achieved by minimizing external references and making the document sections as modular as possible. Thus, individual sections can be changed and replaced without affecting other parts of the document.

Describe the change management process.

Product requirements: These requirements specify or constrain the behavior of the software. Examples include performance requirements on how fast the system must execute and how much memory it requires, reliability requirements that set out the acceptable failure rate, security requirements, and usability requirements. Organizational requirements: These requirements are broad system requirements derived from policies and procedures in the customer's and developer's organization. Examples include operational process requirements that define how the system will be used, development process requirements that specify the programming language, the development environment or process standards to be used, and environmental requirements that specify the operating environment of the system. External requirements: This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a central bank; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public.

Describe three main different types of non-functional requirement which may be placed on a system. Give at least one example of each of the types.

They complement testing as they do not require the program to be executed. This means that incomplete versions of the system can be verified and that representations such as UML models can be checked. Software engineers with experience of program testing are sometimes unwilling to accept that inspections can be more effective for defect detection than testing. Managers may be suspicious because inspections require additional costs during design and development. They may not wish to take the risk that there will be no corresponding savings in program testing costs.

Despite of the well-known cost effectiveness, many software development companies are reluctant to use inspections or peer reviews. Motivate why inspections are effective (1 points) and explain why companies are unwilling to have inspections (1 point).

Here, 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 (phases: Objective setting, Risk assessment and reduction, Development and validation, Planning). 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. (PDF p.66)

Give an account of Boehm's spiral model - the risk-driven software process framework.

Risk management is to anticipate possible risks that could affect the project schedule or the final products quality. After the risks have been assessed relevant action is taken to avoid these risks from occurring. It's phases are: Risk identification (what possible risks could be), Risk analysis (the likelihood and consequence of the risk), Risk planning (how to handle the risk either by minimizing the risk or avoiding it), Risk monitoring (learning more about the risks and planning for further risk mitigation).

Give an account of a risk management process and its phases.

Equivalence partitioning is when you partition data into groups that are deemed to act the same way. The input data and output results of a program often fall into a number of different classes with common characteristics. Like positive numbers, negative numbers, or menu options. You expect data of the same form to be equivalent and therefore tested in groups.

Give an account of equivalence partitioning within testing.

Business strategic level, (Scope and business direction over the long-term period): business strategy, customer strategy, product strategy. Tactical level (Strategy for satisfying the business direction): product management strategy, lifecycle process strategy, technology strategy, support strategy. Implementation level (Actual implementation work): development, evolution, maintenance, testing.

Give an account of organizational levels and the strategies that apply on each level.

A manufacturing process involves configuring, setting up, and operating the machines involved in the process. Once the machines are operating correctly, product quality naturally follows. You measure the quality of the product and change the process until you achieve the quality level that you need. There is a clear link between process and product quality in manufacturing because the process is relatively easy to standardize and monitor. Once manufacturing systems are calibrated, they can be run again and again to output high-quality products.

Give an account of process-based quality and its phases in the manufacturing context (2 points). Is there any clear link between process and product quality in manufacturing? Motivate! (1 point).

In the incremental model, functionality is implemented and then released to the customer as it's finalized, which will results in feedback that we can then use in the next iteration of the system. This will help when the customer is not necessarily completely sure about what they want the system to accomplish.

Give an account of the incremental model.

In a reuse-oriented mode, rather than develop everything ourselves we try to identify available components on the market that we can use to fulfill the wishes of the acquirer. This will make our job a lot easier as it will focus on implementing the "glue code" holding the different components together.

Give an account of the reuse-oriented model.

The waterfall model in contrast to the incremental model goes through each phase of the development process only once. In other words, once the design has been set, this result is what will end up as the final design. This works best for systems that needs to have all the functionality implemented from the beginning

Give an account of the waterfall model.

1. Stakeholders often don't know what they want from a computer system and therefore may have a hard time articulating what they want. They might only be able to describe what they want in very general terms. 2. Different stakeholders will have different requirements and may express these in very different ways. It might be hard to find a common ground and to find similarities between these requirements. 3. Stakeholders will use naturally express requirements in their own terms, this may be hard for the requirement engineers to understand if they do not have a lot of past experience. 4. The economic and business environment in which the analysis takes place is dynamic. It inevitably changes during the analysis process. The importance of particular requirements may change. New requirements may emerge from new stakeholders who were not originally consulted 5. Political factors may influence the requirements of a system. Managers may demand specific system requirements because these will allow them to increase their influence in the organization.

Give four reasons for why the elicitation and analysis phase is difficult. (2 points)

1. Start by identifying the increment of functionality, this should be small and is usually only a few lines of code. 2. Write a test for said functionality and make it run automatically which will report if it passed or failed. 3. Run the test along with all your other tests. Initially you will not have implemented the functionality so it will automatically fail. This is to show that the test adds something to the test set. 4. Rerun the test with the functionality implemented, improve and change the functionality if needed. 5. When all tests pass you can go on to the next chunk of functionality. Mention at least its two benefits. (2 points) 1. Code coverage: Code is tested as it is written and will therefore always have been executed. Defects are detected very early. 2. Regression testing: A test suite is developed incrementally and will therefore show if new bugs are introduced when changes are made. 3. Simplified debugging: There will be no need for debugging tools as we already know where the program fails. This is due to our tests. 4. System documentation: The tests themselves will act as some kind of documentation. This will also make the code easier to understand.

Given an account of test-driven development. What are its fundamental steps? (2 points). Mention at least its two benefits. (2 points)

Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

How is software engineering related to computer science and system engineering?

Oscars tankar. I don't believe it is unethical to do so, because you only act upon the information given. However I believe it is very undignified to do so, since you take advantage of the fact that the company who has written the RFP might not be all that invested in software technology and thus doesn't know how ambiguous it is. I do believe that it would be unethical however to hide this fact from the employer in case they ask if there are any problems with the RFP or if they ask if the RFP was clear enough or something alike.

Is it ethical for a company to quote a low price for a software contract knowing that the requirements are ambiguous and that they can charge a high price for subsequent changes requested by the customers? Motivate your answer.

As a group gets bigger, it gets harder for members to communicate effectively. With a larger group, it means that it is quite possible that some people will rarely communicate with each other. Status differences between group members mean that communications are often one-way. Managers and experienced engineers tend to dominate communications with less experienced staff, who may be reluctant to start a conversation or make critical remarks. People in informally structured groups communicate more effectively than people in groups with a formal, hierarchical structure. In hierarchical groups, communications tend to flow up and down the hierarchy. People at the same level may not talk to each other. This is a particular problem in a large project with several development groups. If people working on different subsystems only communicate through their managers, then there are more likely to be delays and misunderstandings. Group composition People with the same personality types may clash and, as a result, communications can be inhibited. Communication is also usually better in mixed-sex groups than in single-sex groups. Women are often more interaction-oriented than men and may act as interaction controllers and facilitators for the group. The physical work environment The organization of the workplace is a major factor in facilitating or inhibiting communications. The available communication channels There are many different forms of communication—face-to-face, e-mail messages, formal documents, telephone, social networking and wikis. As project teams become increasingly distributed, with team members working remotely, you need to make use of a range of technologies to facilitate communications.

It is essential that group members communicate effectively and efficiently with each other and other project stakeholders. However, the effectiveness and efficiency is influenced by (1) group size, (2) group structure, (3) group composition, (4) the physical work environment, and (5) the available communication channels. Motivate why these issues impact group communication?

In a cohesive group, members think of the group as more important than the individuals who are group members. Members of a well-led, cohesive group are loyal to the group. They identify with group goals and other group members. They attempt to protect the group, as an entity, from outside interference. This makes the group robust and able to cope with problems and unexpected situations. The benefits of creating a cohesive group are: 1. The group can establish its own quality standards Because these standards are established by consensus, they are more likely to be observed than external standards imposed on the group. 2. Individuals learn from and support each other People in the group learn from each other. Inhibitions caused by ignorance are minimized as mutual learning is encouraged. 3. Knowledge is shared Continuity can be maintained if a group member leaves. Others in the group can take over critical tasks and ensure that the project is not unduly disrupted. 4. Refactoring and continual improvement is encouraged Group members work collectively to deliver high-quality results and fix problems, irrespective of the individuals who originally created the design or program.

It is important to create a team that has the right balance of personalities, experience and skills. This however does may not always lead to successful and cohesive groups. What does it mean that the group is cohesive? (2 points). What are the benefits of a cohesive group? (3 points)

1. To achieve a common understanding of the process. Process models enable us to capture our experiences and pass them along to others. 2. To impose consistency and structure on a set of activities. This ensures the same result every time. 3. To guide our actions. 4. To allow us to examine, understand, control, and improve the activities. We can make it more effective by finding inconsistencies, redundancies, and omissions in the process.

Lari Lawrence Pfleeger (see Mira's slides) lists reasons for modelling processes. List and explain them.

Confidentiality: You should normally respect the confidentiality of your employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence: You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence. Intellectual property rights: You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse: You should not use your technical skills to misuse other people's computers. Computer misuse ranges from relatively trivial (game playing on an employer's machine, say) to extremely serious (dissemination of viruses or other malware).

Like other engineers, software engineers must accept that their job involves wider responsibilities than simply the application of technical skills, the professional and ethical responsibilities. Some of the professional and ethical responsibilities are: Confidentiality Competence Intellectual property rights Computer misuse. Describe briefly in what way the software engineers may misuse their responsibilities.

1. The project is intangible: It's easier , for example, seeing if a building is being schedule than software. Software is intangible and it's harder to see if it is behind schedule or not. Software project managers have to rely on others to produce evidence of its progress as the development cannot be seen or touched without knowledge about it. 2. Large software projects are often 'one-off' projects: Large software are usually different from past projects. This can make a lot of experience obsolete due to fast evolution of technology. 3. Software processes are variable and organization-specific: The engineering process for some types of system, such as bridges and buildings, is well understood. However, software processes vary quite significantly from one organization to another. Although there has been significant progress in process standardization and improvement, we still cannot reliably predict when a particular software process is likely to lead to development problems.

Most projects have important goals such as 1. Deliver the software to the customer at the agreed time. 2. Keep overall costs within budget. 3. Deliver software that meets the customer's expectations. 4. Maintain happy and well-functioning development team. These goals are not unique to other engineering projects. However, software engineering differs in a number of ways from other engineering projects. List and explain three such differences.

Stand-alone applications: Systems that are run on a local computer, for example a PC. They include all necessary functionality and do not require a network connections, examples are CAD. Interactive transaction-based application: These are applications that execute on remote computers and are accessed via your own computer or terminals. Web applications are examples of these, for example a chat site. Embedded control systems: Software control systems that manage the hardware. Probably the most common type of software, for example microwaves, cell phones etc. Batch processing systems: Business systems made to process data in large batches. They process large amounts of individual inputs to create corresponding outputs. Examples are phone billing systems or salary payment systems. Entertainment systems: Systems primarily for personal use and for entertaining the user. Most of these are games of some kind. Systems for modelling and simulation: These are systems for scientists and engineers who use them for modelling physical processes or situations. This includes many separate, interacting objects. These require high-performance parallel systems for computation and simulation. Data collection systems: These are systems that collect data from their environments using a set of sensors and send that data to other systems for processing. System of systems: These are systems that are composed of a number of other software systems. Some of these may be generic software products, such as a spreadsheet program. Other systems in the assembly may be specially written for that environment.

One of the most significant factor in determining software engineering methods is the type of application that is being developed. Sommerville lists eight such types. List and explain six of them.

To satisfy social needs, you need to give people time to meet their co-workers and provide places for them to meet. This is relatively easy when all of the members of a development team work in the same place but, increasingly, team members are not located in the same building or even the same town or state. They may work for different organizations or from home most of the time. Social networking systems and teleconferencing can be used to facilitate communications but my experience with electronic systems is that they are most effective once people know each other. You therefore need to arrange some face-to-face meetings early in the project so that people can directly interact with other members of the team. Through this direct interaction, people become part of a social group and accept the goals and priorities of that group. To satisfy esteem needs, you need to show people that they are valued by the organization. Public recognition of achievements is a simple yet effective way of doing this. Obviously, people must also feel that they are paid at a level that reflects their skills and experience. Finally, to satisfy self-realization needs, you need to give people responsibility for their work, assign them demanding (but not impossible) tasks, and provide a training programme where people can develop their skills. Training is an important motivating influence as people like to gain new knowledge and learn new skills.

Project managers need to motivate their people. Using Maslow's hierarchy of human needs, explain what employee needs project managers should focus on and how they may be satisfied.

1. At the proposal stage, when you are bidding for a contract to develop or provide a software system. You need a plan at this stage to help you decide if you have the resources to complete the work and to work out the price that you should quote to a customer. 2. During the project startup phase, when you have to plan who will work on the project, how the project will be broken down into increments, how resources will be allocated across your company, etc. Here, you have more information than at the proposal stage, and can therefore refine the initial effort estimates that you have prepared. 3. Periodically throughout the project, when you modify your plan in light of experience gained and information from monitoring the progress of the work. You learn more about the system being implemented and capabilities of your development team. This information allows you to make more accurate estimates of how long the work will take. Furthermore, the software requirements are likely to change and this usually means that the work breakdown has to be altered and the schedule extended. For traditional development projects, this means that the plan created during the startup phase has to be modified. However, when an agile approach is used, plans are shorter term and continually change as the software evolves.

Project planning takes place at three stages in a project lifecycle. Describe these stages.

The most commonly used agile approaches such as Scrum (Schwaber, 2004) and extreme programming (Beck, 2000) have a two-stage approach to planning, corresponding to the startup phase in plan-driven development and development planning: 1. Release planning, which looks ahead for several months and decides on the features that should be included in a release of a system. 2. Iteration planning, which has a shorter-term outlook, and focuses on planning the next increment of a system. This is typically 2 to 4 weeks of work for the Team. A major difficulty in agile planning is that it is reliant on customer involvement and availability. In practice, this can be difficult to arrange, as the customer representative must sometimes give priority to other work. Customers may be more familiar with traditional project plans and may find it difficult to engage in an agile planning project. Agile planning works well with small, stable development teams that can get together and discuss the stories to be implemented. However, where teams are large and/or geographically distributed, or when team membership changes frequently, it is practically impossible for everyone to be involved in the collaborative planning that is essential for agile project management. Consequently, large projects are usually planned using traditional approaches to project management.

Question: Agile planning (5 points) Most of the agile approaches such as Scrum and extreme programming have a two-stage approach to planning. What are the two stages (2 points) and how do they correspond to traditional planning (2 points)?

Both plan-based and agile processes need an initial project schedule, although the level of detail may be less in an agile project plan. This initial schedule is used to plan how people will be allocated to projects and to check the progress of the project against its contractual commitments. In traditional development processes, the complete schedule is initially developed and then modified as the project progresses. In agile processes, there has to be an overall schedule that identifies when the major phases of the project will be completed. An iterative approach to scheduling is then used to plan each phase. Scheduling in plan-driven projects involves breaking down the total work involved in a project into separate tasks and estimating the time required to complete each task. Tasks should normally last at least a week, and no longer than 2 months. Finer subdivision means that a disproportionate amount of time must be spent on replanning and updating the project plan. The maximum amount of time for any task should be around 8 to 10 weeks. If it takes longer than this, the task should be subdivided for project planning and scheduling. Some of these tasks are carried out in parallel, with different people working on different components of the system. You have to coordinate these parallel tasks and organize the work so that the workforce is used optimally and you don't introduce unnecessary dependencies between the tasks. It is important to avoid a situation where the whole project is delayed because a critical task is unfinished.

Question: Project scheduling (5 points) Give an account of a project scheduling process.

Ethnography is an observational technique that can be used to understand operational processes and help derive support requirements for these processes. An analyst immerses himself or herself in the working environment where the system will be used. The day-to-day work is observed and notes made of the actual tasks in which participants are involved. The value of ethnography is that it helps discover implicit system requirements that reflect the actual ways that people work, rather than the formal processes defined by the organization.

Question: Requirements engineering discovery process phase (2 points) Describe(1 point) and motivate (1 point) the role of ethnography within requirements engineering process?

1. Validity checks A user may think that a system is needed to perform certain func- tions. However, further thought and analysis may identify additional or different functions that are required. Systems have diverse stakeholders with different needs and any set of requirements is inevitably a compromise across the stake- holder community. 2. Consistency checks Requirements in the document should not conflict. That is, there should not be contradictory constraints or different descriptions of the same system function. 3. Completeness checks The requirements document should include requirements that define all functions and the constraints intended by the system user. 4. Realism checks Using knowledge of existing technology, the requirements should be checked to ensure that they can actually be implemented. These checks should also take account of the budget and schedule for the system development. 5. Verifiability To reduce the potential for dispute between customer and contrac- tor, system requirements should always be written so that they are verifiable. This means that you should be able to write a set of tests that can demonstrate that the delivered system meets each specified requirement.

Question: Requirements engineering discovery process phase (3 points) During the requirements validation phase, different types of checks should be carried out on the requirements in the requirements document. Sommerville suggests five types of checks. List and describe three of them.

Requirements reviews The requirements are analyzed systematically by a team of reviewers who check for errors and inconsistencies. Prototyping In this approach to validation, an executable model of the system in question is demonstrated to end-users and customers. They can experiment with this model to see if it meets their real needs. Test-case generation Requirements should be testable. If the tests for the requirements are devised as part of the validation process, this often reveals requirements problems. If a test is difficult or impossible to design, this usually means that the requirements will be difficult to implement and should be reconsidered. Developing tests from the user requirements before any code is written is an integral part of extreme programming.

Question: Requirements engineering discovery process phase (3 points) There are a number of requirements validation techniques which can be used. These are requirements reviews, prototyping, and test-case generation. Describe each of them.

1. Avoidance strategies Following these strategies means that the probability that the risk will arise will be reduced. An example is to replace potentially defective components with bought-in components of known reliability. 2. Minimization strategies Following these strategies means that the impact of the risk will be reduced. An example would be to reorganize team so that there is more overlap of work and people therefore understand each other's jobs. 3. Contingency plans Following these strategies means that you are prepared for the worst and have a strategy in place to deal with it. An example would be to prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business and presenting reasons why cuts to the project budget would not be cost-effective.

Question: Risk strategies (3 points) The risk planning process considers each of the key risks that have been identified and develops strategies for managing these risks. Sommerville identifies three strategies. What are they? Provide an example for each strategy.

Pre-review activities: These are preparatory activities that are essential for the review to be effective. Typically, pre-review activities are concerned with review planning and review preparation. The review meeting: During the review meeting, an author of the document or program being reviewed should 'walk through' the document with the review team. The review chair should sign a record of comments and actions agreed during the review. Post-review activities: After a review meeting has finished, the issues and problems raised during the review must be addressed. This may involve fixing software bugs, refactoring software so that it conforms to quality standards, or rewriting documents. In agile: The review process in agile software development is usually informal. In Scrum, for example, there is a review meeting after each iteration of the software has been completed (a sprint review), where quality issues and problems may be discussed. Most appropriate: The lack of formal quality procedures in agile methods means that there can be problems in using agile approaches in companies that have developed detailed quality management procedures. Quality reviews can slow down the pace of software development and they are best used within a plan-driven development process.

Reviews are quality assurance activities that check the quality of project deliverables. Give an account of a software review process and its phases in a traditional software development context (3 points). What does the review process look like in agile development (1 point)? In what context (traditional or agile) is it more appropriate to use reviews? Motivate your answer (1 point)

Should or should not quality management and software development be separated? Motivate your answer! (1 point) Quality management should be separated from software development so they remain independent. When is it practically impossible to separate them in smaller companies? Motivate your answer! (1 point) Because they have to be completely separate from development, this means in a small company this is less likely to be possible. They should be independent and report to management above the project manager level. The reason for this is that project managers have to maintain the project budget and schedule. If problems arise, they may be tempted to compromise on product quality so that they meet their schedule.

Should or should not quality management and software development be separated? Motivate your answer! (1 point) When is it practically impossible to separate them in smaller companies? Motivate your answer! (1 point)

Functional requirements are things we need the system to do while nonfunctional requirements are restrictions from the outside. Things like budget, performance, accessibility. Alternatively, they may define constraints on the system implementation such as the capabilities of I/O devices or the data representations used in interfaces with other systems.

Software requirements are often grouped into functional, non-functional requirements. Describe briefly each requirements type and exemplify it.

Project risks Risks that affect the project schedule or resources. An example of a project risk is the loss of an experienced designer. Finding a replacement designer with appropriate skills and experience may take a long time and, consequently, the software design will take longer to complete. Product risks Risks that affect the quality or performance of the software being developed. An example of a product risk is the failure of a purchased component to perform as expected. This may affect the overall performance of the system so that it is slower than expected. Business risks Risks that affect the organization developing or procuring the software. For example, a competitor introducing a new product is a business risk. The introduction of a competitive product may mean that the assumptions made about sales of existing software products may be unduly optimistic. The reason that they might overlap is that losing an experienced developer for example might effect the schedule set and thus is a project risk. But it can also be a product risk as a replacement may not be as good and thus result in programming errors. It can finally also be a business risk as this programmer might have been crucial to us winning contracts.

Sommerville categorizes risks into three groups: 1. Project risks 2. Product risks 3. Business risks. Explain each risk category and provide an example (3 points). Why do the risk types overlap sometimes? (1 point)

User Requirements - User requirments stated by the customer (parent) System Requirements - Developers together with the customer develop lower level requirments (child)

Sommerville describes two levels of requirements. What are they? (1 point) Why do you need to write requirements on different levels of detail? (1 point) How are these requirements structured into hierarchies? (1 point)

1. Alpha testing: Where users of the software work with the development team to test the software at the developer's site. 2. Beta testing: Where a release of the software is made available to users to allow them to experiment and to raise problems that they discover with the system developers. 3. Acceptance testing: Where customers test a system to decide whether or not it is ready to be accepted from the system developers and deployed in the customer environment.

Sommerville distinguishes three types of user testing. What are they and what do they imply?

1. Define acceptance criteria: This takes place early in the process, possibly before the contracts have been signed. The acceptance criteria should be part of the system contract and be agreed upon between the customer and the developer. It might be hard to define clear criteria this early in the development phase and this will probably be changed quite a bit during development. 2. Plan acceptance testing: This involves deciding resources, time, and budget for the acceptance testing and establishing a testing schedule. Define the order in which the system features are to be tested. Also define risks in the testing, like system crashes or bad performance. 3. Derive acceptance tests: When acceptance criteria has been established, tests have to be designed to check if a system is okay or not. Acceptance tests should aim to test both functional and nonfunctional parts of the systems. 4. Run acceptance tests: The agreed acceptance tests are to be run on the system, this should ideally be run in the actual environment where the system will be used. This is to ensure it works where it needs to, this can however be impractical and disruptive. Sometimes it's better to have a test environment to run the tests on instead. 5. Negotiate test results: Most likely not all of the acceptance tests will be passed and there will have to be negotiations on if the system is okay to be run. The developer also has to give responses to the identified problems. 6. Reject/accept system: This stage determines if the developed system is accepted or not. If it is not accepted, further development is needed and then the whole acceptance test is repeated.

Sommerville identifies six stages in the acceptance testing process. These are (1) define acceptance criteria, (2) plan acceptance testing, (3) derive acceptance tests, (4) run acceptance tests, (5) negotiate test results, and (6) reject/accept system. Give an account of these phases.

The consequences of not making the change: What happens if the change is not implemented? The benefits of the change: Is the change something that will benefit many users of the system or is it simply a proposal that will primarily be of benefit to the change proposer? The number of users affected by the change: If only a few users are affected, then the change may be assigned a low priority. The costs of making the change: If making the change affects many system components (hence increasing the chances of introducing new bugs) and/or takes a lot of time to implement, then the change may be rejected, given the elevated costs involved. The product release cycle: If a new version of the software has just been released to customers, it may make sense to delay the implementation of the change until the next planned release.

Sommerville lists five factors that should be taken into account in deciding whether or not a change should be approved. List and describe three of them.

1. During testing, errors can mask/hide other errors. When a program stops because of an error you can never know of a later part of that program also will produce an error as well. Inspection does not bother with the connections of errors, just the finding of them. 2. Inspection does not have to have a complete program to be used. In testing a fully operational tester must be developed, this takes both time and money. 3. Not only do you find program defects, but you can also find broader quality attributes of a program when doing an inspection. Such as if it complies with programming standard, portability, and maintainability.

Sommerville provides three advantages of program inspections. What are they?

Software engineers often have strong technical skills but may lack the softer skills that enable them to motivate and lead a project development team. As a project manager, you should be aware of the potential problems of people management and should try to develop people management skills.

The people working are the greatest assets in a software organization. Therefore, to ensure that the organization gets the best possible return on investment, it is important to manage people with respect. Explain and motivate why it may not always be optimal to assign software engineers to the roles of project managers? (2 points)

Requirements identification Each requirement must be uniquely identified so that it can be cross-referenced with other requirements and used in traceability assessments. A change management process This is the set of activities that assess the impact and cost of changes. I discuss this process in more detail in the following section. Traceability policies These policies define the relationships between each requirement and between the requirements and the system design that should be recorded. The traceability policy should also define how these records should be maintained. Tool support Requirements management involves the processing of large amounts of information about the requirements. Tools that may be used range from specialist requirements management systems to spreadsheets and simple database systems.

The requirements for software systems are always changing. Hence, one must define a process of understanding and controlling changes to system requirements. Describe the requirements management process.

1. Software purpose: The more critical the software, the more important that it is reliable. For example, the level of confidence required for software used to control a safety-critical system is much higher than that required for a prototype that has been developed to demonstrate new product ideas. 2. User expectations: In the start a user is more likely to expect bugs and issues with the software. As times goes on, however, they will demand more of the system and it will therefore be more required to have more testing in the finished product when their expectations are higher. 3. Marketing environment: When a system is marketed, the sellers of the system must take into account competing products, the price that customers are willing to pay for a system, and the required schedule for delivering that system. When in a highly competitive market one might release a software without testing everything as much just to release it faster, in a less competitive one a more secure and stable version is required. If the system is cheap more bugs are tolerated.

The ultimate goal of verification and validation is to establish confidence that the software system is "fit for purpose". However, the level of confidence depends on (1) software purpose, (2) user expectations, and (3) marketing environment. Motivate how the level of confidence varies with respect to the three above-listed reasons.

1. Interface misuse: A calling component calls some other component and makes an error in the use of its interface. This type of error is common with parameter interfaces, where parameters may be of the wrong type or be passed in the wrong order, or the wrong number of parameters may be passed. 2. Interface misunderstanding: A calling component misunderstands the specification of the interface of the called component and makes assumptions about its behavior. The called component does not behave as expected in the calling component. 3. Timing errors: These occur in real-time systems that use a shared memory or a message-passing interface. This may make the producer of data work in a different speed than the caller of data. This can make it so you get out of date information.

There are different classes of interface errors. Sommerville lists (1) interface misuse, (2) interface misunderstanding, and (3) timing errors. Explain them.

1. Parameter interfaces: These are interfaces in which data or sometimes function references are passed from one component to another. Methods in an object have a parameter interface. 2. Shared memory interfaces: These are interfaces in which a block of memory is shared between components. Data is placed in the memory by one subsystem and retrieved from there by other subsystems. This is often used in embedded systems. 3. Procedural interfaces: These are interfaces in which one component encapsulates a set of procedures that can be called by other components. Objects and reusable components have this form of interface. 4. Message passing interfaces: These are interfaces in which one component requests a service from another component by passing a message to it. A return message includes the results of executing the service. An example would be a client-server system.

There are different types of interface between program components. These are (1) parameter interfaces, (2) shared memory interfaces, (3) procedural interfaces, and (4) message passing interfaces. Explain them.

Consistency People in a project team should all be treated in a comparable way. No one expects all rewards to be identical but people should not feel that their contribution to the organization is undervalued. Respect Different people have different skills and managers should respect these differences. All members of the team should be given an opportunity to make a contribution. In some cases, of course, you will find that people simply don't fit into a team and they cannot continue, but it is important not to jump to conclusions about this at an early stage in the project. Inclusion People contribute effectively when they feel that others listen to them and take account of their proposals. It is important to develop a working environment where all views, even those of the most junior staff, are considered. Honesty As a manager, you should always be honest about what is going well and what is going badly in the team. You should also be honest about your level of technical knowledge and willing to defer to staff with more knowledge when necessary. If you try to cover up ignorance or problems you will eventually be found out and will lose the respect of the group.

There are four critical factors that must be considered while managing people. These are consistency, respect, inclusion and honesty. (3 points). Explain and motivate three of them.

Change management: This involves keeping track of requests for changes to the software from customers and developers, working out the costs and impact of making these changes, and deciding if and when the changes should be implemented. Version management: This involves keeping track of the multiple versions of system components and ensuring that changes made to components by different developers do not interfere with each other. System building: This is the process of assembling program components, data, and libraries, and then compiling and linking these to create an executable system. Release management: This involves preparing software for external release and keeping track of the system versions that have been released for customer use.

There are four principal configuration management activities: · Change management · Version management · System building · Release management Choose and describe two of these activities

Where customers and engineers define the software that is to be produced and the constraints on its operation. Here is where we restrict what things we want and need, this identifies constraints. Requirements engineering is a particularly critical stage of the software process as errors at this stage inevitably lead to later problems in the system design and implementation There are four main activities in the requirements engineering process: Feasibility study An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more detailed analysis. Requirements elicitation and analysis This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified. Requirements specification Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided. Requirements validation This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.

There are many different process models, but all must include four fundamental software engineering activities. These are: Software specification Software design and implementation Software validation Software evolution. Give an account of software specification phase and its inclusive requirements engineering process.

What are they? (1 point) Task-oriented, Self-Oriented and Interaction-oriented Explain how each personality type is motivated while doing the work? (1 point) A Task-oriented person is motivated by the task or the assignment itself, while the Self-oriented sees the work as a of realizing themselves, for example in order to become famous. Finally the Interaction-oriented person is motivated by the relationships formed with their colleagues. What personality types would you choose when creating a team? (1 point). Motivate why? (1 point). I would choose a mixture of different personalities, because a group that has complementary personalities may work better than a group that is selected solely on technical ability. People who are motivated by the work are likely to be the strongest technically. People who are self-oriented will probably be best at pushing the work forward to finish the job. People who are interaction-oriented help facilitate communications within the group. I think that it is particularly important to have interaction-oriented people in a group. They like to talk to people and can detect tensions and disagreements at an early stage, before these have a serious impact on the group. In case it is impossible to choose people with the right personality types, how should you manage people so that the organizational and group objectives are met? (1 point) If this is the case, the project manager has to control the group so that individual goals do not take precedence over organizational and group objectives. This control is easier to achieve if all group members participate in each stage of the project. Individual initiative is most likely when group members are given instructions with- out being aware of the part that their task plays in the overall project.

There are three different personality types that must be considered when choosing team members. ● What are they? (1 point) ● Explain how each personality type is motivated while doing the work? (1 point) ● What personality types would you choose when creating a team? (1 point). Motivate why? (1 point). ● In case it is impossible to choose people with the right personality types, how should you manage people so that the organizational and group objectives are met? (1 point)

1. Standards capture wisdom that is of value to the organization. They are based on knowledge about the best or most appropriate practice for the company. This knowledge is often only acquired after a great deal of trial and error. Building it into a standard helps the company reuse this experience and avoid previous mistakes. 2. Standards provide a framework for defining what 'quality' means in a particular setting. Software quality is subjective, and by using standards you establish a basis for deciding if a required level of quality has been achieved. Of course, this depends on setting standards that reflect user expectations for software dependability, usability, and performance. 3. Standards assist continuity when work carried out by one person is taken up and continued by another. Standards ensure that all engineers within an organization adopt the same practices. Consequently, the learning effort required when starting new work is reduced.

There are three reasons why software standards are important. What are they? (3 points)

Generic products: These are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them. Ex. word, skype, spotify etc. Customized (bespoke) products: These are systems that are commissioned by a particular customer. Examples of this type of software include control systems for electronic devices, systems written to support a particular business process, and air traffic control systems.

There are two types of software products. What are they? (0,5) Provide an example of each type. (0,5)

Heterogeneity: The challenge here is to develop techniques for building dependable software that is flexible enough to cope with different types of devices, computers and environments. Business and social change: Many traditional software engineering techniques are time consuming and delivery of new systems often takes longer than planned. They need to evolve so that the time required for software to deliver value to its customers is reduced. Security and trust: We have to make sure that malicious users cannot attack our software and that information security is maintained.

There is no universal software engineering method or technique that is applicable for all different types of software. However, there are three general issues that affect different types of software. These are heterogeneity, business and social change and security and trust. Explain in what way these issues provide challenge to software developers?

Verification and validation processes are concerned with checking that software being developed meets its specification and delivers the functionality expected by the people paying for the software. Validation is the question "Are we building the right product?" and Verification is the question "Are we building the product right?". The aim of verification is to check that the software meets its stated functional and nonfunctional requirements. Validation, however, is a more general process. The aim of validation is to ensure that the software meets the customer's expectations. Validation is hard because requirements specifications do not always reflect the real wishes or needs of system customers and users.

Verification and validation are not the same thing. What is the difference? Explain why validation is a particularly difficult process.

What are the fundamentals of quality management in manufacturing industry (1 point) Quality assurance and quality control. Quality assurance (QA) is the definition of processes and standards that should lead to high-quality products and the introduction of quality processes into the manufacturing process. Quality control is the application of these quality processes to weed out products that are not of the required level of quality. Why are they not directly comparable with software quality (2 points)? They are not directly comparable for a few reasons. Software is developed not manufactured, i.e it's harder to see if the process is working as intended. It is difficult to write unambiguous software specifications which is not the case in real manufacturing. Specifications are usually compromises integrating requirements from different stakeholders. It is impossible to measure certain quality demands. The assessment of quality is subjective.

What are the fundamentals of quality management in manufacturing industry (1 point) and why are they not directly comparable with software quality (2 points)?

A Change Control Board (CCB) is the group of people who make the analysis from a business perspective if a change should be done or not. They are the ones responsible for the decisions on how the software should evolve. They also review and approve all possible change requests.

What is Change Control Board and what is its function?

Configuration management (CM) is concerned with the policies, processes, and tools for managing changing software systems. You need to manage evolving systems because it is easy to lose track of what changes and component versions have been incorporated into each system version. It is useful for individual projects as it is easy for one person to forget what changes have been made. It is essential for team projects where several developers are working at the same time on a software system.

What is configuration management and why is it important?

Software engineering is an engineering discipline that is concerned with all aspects of software production. Engineering - "The profession of applying scientific principles to the design, construction and maintenance of various artifacts" Key phrases? Engineering discipline entails that they must work within the frames of the task, taking time and money into consideration. All aspects of software production means that you are not just interested in the technical processes of development. It also includes activities such as software project management and the development of tools, methods, and theories to support software production.

What is the definition of software engineering (0,5 points) and what two key phrases does this definition include? (2 points)

Use cases: In their simplest form, a use case identifies the actors involved in an interaction and names the type of interaction. This is then supplemented by additional information describing the interaction with the system. The additional information may be a textual description or one or more graphical models such as UML sequence or state charts. Use cases identify the individual interactions between the system and its users or other systems. Ethnography: Ethnography is an observational technique that can be used to understand operational processes and help derive support requirements for these processes. An analyst immerses himself or herself in the working environment where the system will be used. The day-to-day work is observed and notes made of the actual tasks in which participants are involved. Interviews: Is when you interview a person of what they do on a regular day, and then analyze all the components in the systems. What their experience with the system is and what might be lacking. Ethnography can be better than use cases when the person is very used to a system but has a hard time describing exactly what they do in a process. Use cases however can be better to get keywords and names of programs than ethnography. Ethnographic studies can reveal critical process details that are often missed by other requirements elicitation techniques. However, because of its focus on the end-user, this approach is not always appropriate for discovering organizational or domain requirements. Interviews are also not an effective technique for eliciting knowledge about organizational requirements and constraints because there are subtle power relationships between the different people in the organization.

When discovering requirements, you may use different techniques such as 1. Use cases 2. Interviewing 3. Scenarios 4. Ethnography Describe (2 points) and compare two of them (2 points).

Generic products: the organization that develops the software controls the software specification. In this case the organization is intending to make a profit and therefore sell the product to an open market. Customized (bespoke) products: the specification is usually developed and controlled by the organization that is buying the software. The software developers must work to that specification. In this case the buyer is the customer, and therefore is in charge.

Who is in the control of the specification of each product type? Motivate? (1 point)

Testing is difficult because faults might only appear in very certain circumstances. One object might only fault if another one has done so before it, or maybe if you overflow a storage unit. These are therefore harder to find.

Why is interface testing difficult?

Software is computer programs and associated documentation. This may be developed for a specific company or for the general market.

What is Software?

A process is a set of performed activities and associated results which produce a software product. A process model represents a process from a particular perspective, and thus provides only partial information about that process.

What is a process and process model? (1 point)

In this activity, software engineers work with customers and system end-users to find out about the application domain, what services the system should provide, the required performance of the system, hardware constraints, and so on. Requirements discovery: This is the process of interacting with stakeholders of the system to discover their requirements. Requirements classification and organization: This activity takes the unstructured collection of requirements, groups related requirements, and organizes them into coherent clusters. Requirements prioritization and negotiation: Inevitably, when multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation. Requirements specification: The requirements are documented and input into the next round of the spiral.

After initial feasibility studies, the next stage of the requirements engineering process is requirements elicitation and analysis. Describe the process and each of its phases. (2 points

Natural language is often vague and general and can therefore easily be misunderstood. Not knowing the client's knowledge level can cause misunderstandings due to them using the "wrong" words to describe things. Using forms limits this vagueness by adding describing fields and therefore keeping the answers associated with that specific thing. It can show a condition and then show a respective action, this makes it more clear in what should be done. Requirements are organized more clearly and variability is reduced.

Discuss the problem of using natural language for defining user and system requirements and show, using small examples, how structuring natural language into forms can help avoid some of these difficulties.