SENG201 - Study Guide - Summaries of the course lecture notes PDF

Preview

Summary

Software Engineering IStudy Guide2017Robert FalcasantosUniversity of CanterburyOverviewWhat is software engineering?Small systems can be programmed. Large and complex systems must be engineered. Software engineers must keep in mind quality (bugs, response time), languages, size and complexity (LOC, ...

Description

SENG201 Software Engineering I Study Guide

2017 Robert Falcasantos University of Canterbury !

Overview

SENG201

What is software engineering? Small systems can be programmed. Large and complex systems must be engineered. Software engineers must keep in mind quality (bugs, response time), languages, size and complexity (LOC, files), storage (RDBMS, XML), domain knowledge (physics, electronics, medicine, customers), and communication (socket, COM, file-based). Without engineering, big budget projects, and projects in general, fail due to bad practice. This causes lost money, poor customer value, and stressed employees. Software projects fail due to unmanaged risks from a project’s complexity, unrealistic and unarticulated project goals, poorly defined requirements, poor communication among stakeholders, and inaccurate estimates of resources, among other causes. Software engineering is a discipline that covers all aspects of software production, using a systematic and organised approach that utilises appropriate methods and tools, which depend on the problem, constraints and resources available. It’s all about productivity: working faster using tools and environments, working smarter through processes and methods, and sometimes avoiding work altogether through reuse and simplicity.

Challenges Some of the major issues in software engineering are human-centric. Consider these issues: • • • • •

Dealing with group dynamics, heterogeneous teams Interaction with stakeholders Dealing with cultural differences in global software development Improving communication and knowledge sharing Motivation of software engineers

Course outline This guide assumes that you have previously completed COSC121 and COSC122, with some knowledge of formal languages and compilers in COSC261. • • • • • • • • • • • • •

Processes Design UML Introduction to Java Streams in Java Testing Patterns Collections GUIs & Swing States Scaling Concurrency Principles

3 15 17 24 43 48 52 55 57 59 61 63 65!

2

SENG201

Processes Activities There are five typical and distinct types of activities: • • • • •

Requirements engineering Design Coding Testing Operation and maintenance

The average distribution of resources is as follows: Activities

% excl. maintenance

% incl. maintenance

Requirements engineering

10

3

Specification

10

3

Design

15

5

Coding

20

7

Module test

25

8

Integration test

20

7

Operation and maintenance

-

67

To reduce costs over the entire cycle, the costs of maintenance should be reduced. This requires that software is understandable and easy to change, hence the 40-20-40 rule. 40% of total time should be spent on project analysis and design, 20% on coding, and the remaining 40% on testing.

Resources

The above activities are tied together by process, and act as distinct lifecycle phases. A process is a structured set of activities to develop a software system. It defines I/O, who, what, when, and how to do something to real a goal. This ensures quality assurance instead of ad-hoc work. Phases (activities) may occur in parallel, iterative, or incremental order. This variety gives software engineering processes their different ‘flavours’, and enable various software life cycle designs. Names of phases and activities may vary.! 3

Processes

SENG201

Requirements engineering A requirement is a statement of service or constraint, originating from the stakeholders of a system, which involves anyone interested in, or affected by, or impacting, the system. Requirements of a system are collected by analysing the needs of the user(s). It does not determine how the software will be designed or built. Usually, users are interviewed and the user requirements document is generated. However, requirements can be gathered using soft and hard methodologies including; questionnaires, document analysis, observation, throwaway prototypes, and use cases. This document describes the system’s functional, interface, performance, data, and security requirements, among others, expected by the user(s). Business analysts communicate their understanding of the system to the user(s) through this document. The user(s) review this, as it is used as a guideline by system designers in the next phase. Functional requirements consider the functionality and interactions between the system and the environment. Often phrased as actions, there are various ways of specifying them, e.g. ‘The customer must be able to search for flights.’ It should be independent from implementation, and is not always feasible and reasonable. The options for implementation might affect the requirements. Quality requirements are the non-functional constraints on what the system does. Often phrased as constraints or negative assertions, these are not necessarily uservisible, and not always related to functionality. There are various types: business requirements, which consider time to market, budget, and legal constraints; technical requirements, which consider run-time performance, security, safety, usability, reliability, interoperability, etc.; design-time requirements, which consider modifiability, reusability, portability, etc.; and many other classifications of quality. Quality requirements can be classified as such: • Process requirements: • Delivery requirements • Implementation requirements • Standards requirements • Product requirements: • Usability requirements • Reliability requirements • Safety requirements • Performance requirements • Capacity requirements • External requirements: • Legal constraints • Economic constraints • Interoperability requirements Some of the challenges involving requirements engineering concerns finding the right requirements, dealing with change, and how to better communicate them. 4

Processes

SENG201

Design System design: The user requirements document is studied in order for the business of the system to be analysed and understood by system engineers. If any of the requirements is not feasible, the user(s) is informed of the issue, and the document edited accordingly per a resolution. After figuring out possibilities and techniques by which the user requirements can be implemented, engineers generate the software specification document which serves as a blueprint for the development phase. This contains the general system organisation, menu structures, and data structures, among others. It may also hold example business scenarios, sample windows, and reports for better understanding. Architecture design: Software and computer architecture are selected, with a baseline architecture typically consisting of a list of modules, brief functionality of each module, interface relationships, dependencies, database tables, architecture diagrams, and other technology details. Module design: The designed system is broken up into modules, and each of them explained so that a programmer can start coding directly. The low-level design document or program specifications will contain a detailed functional logic of the module in pseudocode the database tables, with all elements, including their type and size; all interface details with complete API references; all dependency issues; error message listings; and complete input and outputs for a module. Unit test design is developed at this stage.

Coding As an activity, coding requires many considerations. Following techniques for creating understandable source code, including name and source code layout; use of classes enumerated types, variables, named constants and other similar entities; use of control structures; handling of error conditions, both planned and exceptions; prevention of code-level security breaches; resource usage; source code organisation; code documentation; and code tuning. Software construction holds a number of fundamental ideas: • Minimising complexity through simple and readable, as well as making use of standards and numerous specific techniques in coding. • Anticipating change, which allows for extensive software that enhances a product without disrupting the underlying structure. • Constructing for verification by building software in such a way that faults can be sifted out readily by engineers writing the software, as well as during independent testing and operational activities. This can achieved through coding standards, support code reviews, unit testing, organising code to support automated testing, and restricting the use of complex and hard-tounderstand language structures. • Systematic reuse improves software productivity, quality, and cost improvements. Construction for reuse allows for reusable software assets, and construction with reuse enables the reuse of software assets in the construction of a new solution.! 5

Processes

SENG201

Testing

The quality of a product or service is investigated through software testing. There are three considerations to be made while testing: • Does the software work? • Does the software meet its specification? (Validation) • Changes have been made – does the software still work? Software or system components are executed and evaluated to determine whether they meet the requirements that guided its design and development, respond correctly to all kinds of inputs, performs its functions within an acceptable time, are sufficiently usable, can be installed and run in its intended environments, and achieve the general result its stakeholders desire. Software faults are weaknesses in design and/or implementation. They are static, and created when there are mistakes in the code, an incorrect step is made, a process does not work, or a mistake is made in the definition of some data in the program. Faults may cause failure when an exact scenario is met. E.g. the iterator variable in a for loop is initialised to number other than 0. Software errors are incorrect internal states that manifest from some fault. Such errors are likely not visible to the end user (variable values, memory), and may lead to failure. This refers to the difference between the actual output and the expected output. E.g. a point in the program which leads to incorrectness. 6

Processes Software failures are user-visible manifestations of error, where incorrect behaviour is performed with respect to expected behaviour due to an inability to perform required functions within performance requirements. E.g. due to a fault or error in the program, failure is caused through a function outputting the wrong results per its specifications. Unit testing is the testing of a specific functionality of a unit, such as a function, method, or class, but no larger. Any larger, and it becomes module testing. Integration testing tests how things fit together, and the interfaces between components. It looks at low-level and high-level design, and multiple classes and/or modules at a time. Big bang integration testing is conducted when all units and/or modules are ready. Continuous integration testing is testing incrementally as each component as integrated as well. System testing tests the entire program, including hardware. Doing so tests the whole product in a representative environment, and looks at ensuring requirements are met. Acceptance testing, otherwise known as functional testing, tests the whole product in a customer environment. It seeks customer approval, which may be agreed with user story and acceptance criteria, and may be based on use cases and/or scenarios. Other types of testing include regression testing, where an evolving system should pass old tests (or they need to be revised), and must also pass new tests—automated test suites regularly check for regressions. Mutation testing tests the test data to evaluate the quality of the tests. It checks if the tests still detect defective code after the program has been modified.

Activities

Opacity

Tester

Unit

White box

Programmer who wrote code

Integration

White box Black box

Programmers who wrote code" Other programmers, independent testers

System

Black box

Customer

Acceptance

Black box

Customer

Regression

White box Black box

Programmer(s) or independent testers

7

Processes

SENG201

Operation and maintenance Any work done to change the software after it is in operation is considered to be maintenance work. This is to preserve the value of software over time, of which can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, and employing more efficient and newer technology. Maintenance may span for twenty years, whereas development may be less than a quarter of that. Software maintenance can be described in six processes: • The implementation process involves the conception and creation of a maintenance plan, the preparation for handling problems identified during development, and following up on product configuration management. • The problem and modification analysis process is then executed once the application has become the responsibility of the maintenance group. Maintenance programmers must analyse each request, confirm it by reproducing the situation, check its validity, investigate and propose a solution, and document the request and solution proposal. • The modification implementation process after obtaining the required authorisations to apply the modifications. • The modification acceptance process, where the modified work is confirmed with the individual who submitted the request in order to make sure the modification provided a solution. • If the software must be ported to another platform without any change in functionality, the migration process is performed by a maintenance team. • Once a software is no longer to be maintained, the software retirement process retires the software. And can be divided into four categories: • Corrective maintenance is the reactive modification of a software product performed after delivery to correct discovered problems. • Adaptive maintenance is the modification of a software product performed after delivery to correct discovered problems. • Perfective maintenance is the modification of a software product after delivery to improve performance or maintainability. • Preventive maintenance is the modification of a software product after delivery to detect and correct latent faults in the software before they become effective faults.!

8

Processes

SENG201

Waterfall

Created at a time when no formal software development methodologies existed, this is originally a hardware-oriented model adapted for software development. In this sequential and non-iterative model, progress is seen as flowing steadily downwards. Support: Time spent early in the cycle can reduce costs at later stages. For best implementation, project organisation needs to be highly structured. Emphasises documentation (requirements, design, source code). Progress through discrete, easy-to-identify and understand phases and milestones. • Suited to projects where requirements and scope are fixed, the product is firm and stable, and the technology is clearly understood. • • • •

Criticism: • Clients may not know exactly what requirements are before working software and may change their requirements, leading to redesign, redevelopment, retesting, and increased costs. • Designers may not be aware of future difficulties when designing a new software product of feature. In this case, it is better to revise the design than persist, not accounting for any newly-discovered constraints. 9

Processes

SENG201

V-model

Sometimes considered as an extension of the waterfall model, this model has its process steps bent upwards after the coding phase, to form the typical V shape. It demonstrates the relationships between each phase of the development lifecycle and its associated phase of testing. Project completeness is determined left-to-right, and the level of abstraction from highest to lowest, top-to-bottom. Support: • For every single phase in the development cycle, there is a directly associated testing phase. • Works well for small projects where requirements are easily understood. Criticism: • Too simple to accurately reflect software development process, and can lead managers into a false sense of security. Fits the needs of project managers, accountants, and lawyers rather than software developers or users. • Inflexible and encourages a rigid view of development; unable to change. • Encourages testers to look for what they expect to find, rather than discover what is truly there. 10

Processes

SENG201

Rational Unified Process

An iterative software development process framework that is an adaptable process framework. RUP is intended to be tailored by selecting the elements of the process appropriate for the needs of the organisation or software project team. Using RUP, a project lifecycle consists of four phases. Inception scopes the system adequately as a basis for validating initial costing and budgets. Elaboration mitigates key risk items identified by analysis. Construction is where the software is built, and produces the first external release of the software. Transition transits the system from development into production, and involves end user training, beta testing, quality testing, and evaluation. Support: • Complete methodology that emphasises accurate documentation. • Proactively able to resolve project risks associated with the client’s evolving requirements, and requires careful change request management. • Reuse of components allows for less development time. Criticism: • Team members need to be experts in their fields to develop software under this methodology. • Development process is complex and disorganised. • Cutting-edge projects using new technology makes reuse impossible. • Integration throughout the development process on big projects with multiple development streams causes issues during testing. 11

Processes

SENG201

Iterative and incremental development

Created as a response to inefficiencies and problems found in the waterfall model, this model is a combination of both the iterative method and the incremental build model. A system is developed iteratively through repeated cycles, and incrementally in smaller portions at a time, allowing developers to take advantage of what was learned during development of earlier parts or versions of the system. At each iteration, design modifications and are made and new functional capabilities are added. Development is sliced into the same increments as found in the RUP model: inception, elaboration, construction, and transition. Support: • The client is involved at each and every stage. • Every increment is delivered to the user and after their approval, the developer is allowed to move towards the next module. • The operational product is given to the user within a few weeks, rather than being delivered after months. • Best suitable for small as well as large projects. • More flexible, and therefore less costly to change scope and requirements. • Risk management is easier as risky pieces are identified and handled during its iteration. • Easier to test and debug during a smaller iteration. Criticism: • Needs good planning and design. • Needs a clear and complete definition of the whole system before it can be broken down and built incrementally. • Total cost is higher than the waterfall model. • Each phase of an iteration is rigid and do not o...