CS2002 Exam Lecture Notes sdadasaD SDASD PDF

Preview

Summary

CS2002 Exam Lecture NotesLecture 7: Software Development ProcessThe Software Process - A structured set of activities required to develop a software systemMany different software processes, but all involve: - Specification - Design & Implementation - Validation ✔ - Evolution(more details bel...

Description

CS2002 Exam Lecture Notes Lecture 7: Software Development Process The Software Process • A structured set of activities required to develop a software system Many different software processes, but all involve: • Specification • Design & Implementation • Validation ✔ • Evolution (more details below) Software Process Model • An abstract representation of a process, a description of the process from a particular perspective. Plan-Driven Process • A process where all process activities are planed in advance and progress is measured against this plan. Agile Process •

In agile, planning is incremental and it is easier to change the process to accommodate changing customer requirements.

(Note: In practice, most of the processes include elements of both approaches)

➡ Types of Software Process Model •

Waterfall Model

• •

Limitation: Difficulty in accommodating change once the process is under way In principal, a phase has to be completed before moving onto the next phase

• • •

•

Rigid partitioning of a project into distinct stages makes it difficult to respond to changing requirements Used in situations when requirements are well-understood and changes will be limited during the design process In large systems engineering project where a system is developed at several sites, helping coordinate the work

Incremental Development

• Advantages: ✔ Changing requirement is less costly ✔ Easier to get customer feedback on the work that has already been done ✔ More rapid delivery and deployment of useful software to the customer • Disadvantages: ❌ Process is not visible ❌ System structure tends to degrade as new increments are added •

Integration & Configuration

(Reuse-oriented SE)

Based on software reuse where systems are integrated from existing components / application systems • Advantages: ✔ Reduced cost & risks as less software is developed from scratch ✔ Fast delivery & deployment of system • Disadvantages: ❌ Requirement compromises are inevitable, hence, system may not meet real needs of users ❌ Loss of control over evolution of reused system elements •

(Note: In practice, most large systems are developed using a process that incorporates elements from all of these models)

Process Activities • 4 basic process activities of specification, development, validation & evolution are organised differently in different development processes Ex. In waterfall model, they are organised in sequence, where as in incremental development they are interleaved

(General Model of Design Process)

Software Specification The process of establishing what services are required and the constraints on the system's operation & development •

Requirements engineering process: • Requirements elicitation & analysis • Requirements specification • Requirements validation • Software Design & Implementation The process of converting the system specification into an executable system Software Design: design a software structure that realises the specification Implementation: translate this structure into an executable program ( Activities of design & implementation are closely related & may be inter-leaved ) • Software Validation ✔ Verification & Validation (V&V) is intended to show that a system conforms to its specification and meets the requirements of the system customer Testing: most commonly used V&V activity System Testing: involves executing the system with test cases derived from the specification of the real data to be processed by the system

(Stages of Testing)

• Software Evolution Although there has been a demarcation between development and evolution (maintenance), this is increasingly irrelevant as fewer and fewer systems are completely new - software development often becomes an evolution of existing software systems.

Lecture 8: Software Quality & Metrics What is Quality? Different perspectives on Software Quality • Users judge external characteristics (ex. correct functionality, number of failures etc) • Developers judge internal characteristics (ex. types of faults) How do we know that we are designing a good piece of software?

(Software Quality Attributes)

Software "Fit for Purpose" • Has the software been properly tested? • Is the performance of the software acceptable for normal use? • Is the software usable? • Is the software well-structured and understandable? • How programming and documentation standards been followed in the development process?

Software Process Improvement • To enhance the quality of their software, many software companies have turned to software process improvement, reducing costs or accelerating their development processes • Process improvement means understanding existing processes and changing these processes to increase product quality and / or reduce costs and development time

(Software Improvement Cycle)

SOFTWARE MEASURE • a quantitative indication of the extent, amount, dimension or size of some attributes of a product / process (Typically, a single data point, ex. 1118 lines of code) ฀ SOFTWARE METRIC • represents the degree to which a system, component or process possesses a given attribute (Typically connections a few measures, ex. the average number of errors found per person hour) A combination of metrics can provide insight into the quality of software process, project or product

(Causes & Origin of Defects)

• •

Focus on Deliverable Quality Size • Size Oriented: lines of code (LOC) approach • This is easy to measure, but with important limitation: 1. 2. •

• • •

Does it mean that Engineer A who wrote 1000 LOC are more productive than Engineer B who wrote 600 LOC? Does it mean that Engineer A wrote better quality code?

In general, for a specific problem, the more lines of code in a software module, the less understandable and maintainable the module is likely to be

Function McCabe's metric using the Control Flow Graph Structure: Henry & Kafura's metric using the Information Flow

(Static Software Product Metrics)

(OO metrics)

Metrics Guidelines • Use common sense and organizational sensitivity when interpreting metrics data • Don't use metrics to appraise / threaten individuals / teams! • Work with practitioners and teams to set clear goals and metrics that will be used to achieve them • Metrics data that indicate a problem area should not be considered "negative". These data are merely an indicator for process improvement • Don't focus on just a single metric to the exclusion of other important metrics • There is still considerable amount of research that needs to be done to better understand the link between metrics and quality

Lecture 9: Service-Oriented Architecture Architecture vs Architectural Style Architecture Style: General principles informing the creation of an architecture Architecture: Designing a solution to a problem according to given constraints Architectural styles inform & guide the creation of architectures

Distributed System

Service-Oriented Architecture (SOA)

•

a way of developing distributed systems by combining stand-alone, reusable, looselycoupled services.

•

How did we use to write software? •

•

Many components but: • one database • single deployment unit • single language / technology

From monolithic to SOA

• What is a service? SOA centres around the concept of decomposing business problems into services.

SERVICE = BUSINESS CAPABILITY Ex.

•

Principles of SOA

•

Building blocks of SOA

SOA defines an architecture which usually consists of the following roles and the contracts between those roles •

Service Design: Main Issues

• Building Services SOA can be realised through a variety of technologies

Evolution of SOA 1. SOAP-based Web Services • • • •

Based on international standards Service interfaces is exposed through WSDL documents Message exchange using SOAP Client code may be generated from WSDL description

1. Representative State Transfer (RESTful) Web Services • •

•

Everything is a resource Resources are identified by URLs and their state is manipulated through HTTP operations (GET, POST, PUT, DELETE) Rather a set of architectural principals instead of standard

[ SOAP vs REST ]

1. Microservices Evolution of SOA •

Designed for Failure Designed for scale, if a service fails, the system should stay alive. Gave rise to chaos engineering ex. Netflix has a service that runs at production and kills services at randomly to test that the system can stay alive.

•

Deployment & Containerization Independent deployability over reuse Microservices are often placed within a virtual container system (such as Docker)

•

Automation Fast deployment, depends on infrastructure automation, DevOps, Continuous Integration

Lecture 10: Software Testing Learning Objective: • Why testing is important • What are the basic types of testing • How to write unit tests for a program • What is a test coverage and how to improve? Definition: an activity to uncover faults in software Input-Output Model of Software Testing

Example: Suppose the following is meant to calculate the product of the values in an array: int s = 0; int n = 0; while (n < MAX) { s = s * a[n]; n = n + 1; } return s; The program always returns 0! a = {0, 1, 2, 3} a = {1, 2, 3} Types of Software Testing

Specification: inputs an integer parameter and returns half of its value if even, its value otherwise public int fun(int param) { int result; result = param/2; return result; } Stages of Testing •

Development Testing - where the system is tested during development to discover bugs and defects

• •

Release Testing - where a separate testing team test a complete version of the system before it is released to users User Testing - where users or potential users of a system test the system in their own environment

Unit Testing “More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded – indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest.” – Boris Beizer

• • •

Low-level focusing on a small part of the system Written by software developers Should be fast, so that it can be repeated many times

How??? 1. Arrange - setup the test data 2. Act - call your method under test

3. Assert that the expected results are returned

Best Practices ✅ Each unit test should be able to run independent of other tests. ✅ Each test should test just one thing (single behaviour, method, or function) ✅ All external dependencies should be mocked. ✅ The assumptions for each test should be clear and defined within the test method. ✅ Name of the test method should be meaningful. ✅ Unit tests should be fast, so that it could be run as often as required Test Coverage •

Statement Coverage

•

Branch Coverage

•

Condition Coverage

Release Testing • testing a release that is intended for use outside of the development team • usually a black-box testing process - tests are only derived from the specification • done by a team not involved in development • •

The goal is to convince the supplier that the system is good enough for use In contrast, in system testing the development team focus on discovering bugs in the system

User / Customer Testing • a stage in the testing process in which users provide input and advice on system testing • is essential, even when comprehensive system and release testing have been carried out • the influences from the user's working environment have an effect on the reliability, performance, usability and robustness. These cannot be replicated in a testing environment. 2 Types of User Testing: • •

Summary

Alpha Testing: users of the software work with the development team to test the software at the developer's sit Beta Testing: a release of the software is made available to users to experiment at their own site

Testing is an activity designed to uncover faults in software In software testing we: execute the system under test on test input; observe the output produced; compare this output with what is expected • Three stages of testing: development, release, user testing • A unit test should be small, fast, written by the programmer • Unit testing is part of the development testing stage, should be combined with other types of testing, such as integration, system testing, etc. • Writing unit tests will make you a better developer; strive to write testable code • Code coverage measure the efficiency of test implementation • •

Lecture 11: Software Evolution This topic covers: • Evolution processes • Legacy systems • Software Maintenance Software change is inevitable!!! A key problem for all organizations is implementing and managing change to their existing software systems. (ex. Brunel - Wiseflow, eVision) • Unless change is made properly, the results can be catastrophic (ex. Cockpit of an airplane) •

Software Maintenance •

Fault Repairs •

Changing a system to fix faults & vulnerabilities

(Security fears) •

Environmental Adaptation • Changing a system so that it operates in a different way from its initial implementation (ex. New tax laws)

•

Modifying Existing Functionality • Users asking for features to be changed

•

Maintenance Effort Distribution

•

Program Evolution Dynamics • Study of the processes of system change After major empirical studies, Lehman proposed that there were a number of "laws" which applied to all systems as they evolved.

•

Continuing Change • A program that is used in a real-world environment must necessarily change / it becomes progressively less useful in that environment

•

Increasing Complexity • As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure

•

Declining Quality • The quality of systems will decline unless they are modified to reflect changes in their operational environment

•

Feedback System • Evolution processes incorporate multiagent, multiloop feedback systems and you have to treat them as feedback systems to achieve significant product improvement

•

Legacy System Replacement • Risky • Lack of complete original system specification • No means of reusing the old designs • Tight integration of system and business processes • You have to model the business - and that is difficult • Undocumented business rules embedded in the legacy system • Poor upkeep of documentation • New software development is always late and over budget • Replacement will always be over budget and late (Legacy System Assessment)

Legacy System Categories • Low quality, low business value • These systems should be scrapped

•

•

Low quality, high business value • These make an important business contribution but are expensive to maintain • Should be re-engineered / replaced if a suitable system is available

•

High quality, low business value • Scrap completely or maintain?

•

High quality, high business value • Continue in operation using normal system maintenance

Reengineering Cost Factors • The quality of the software to be reengineered • Can software metrics help here to measure quality? •

The tool support available for reengineering • Developers are always moaning about tools • Refactoring tools are poor

•

The availability of expert staff for reengineering • This can be a problem with old systems based on technology that is no longer widely used

•

Time (costs money) • The cost of one developer per day

•

Technical debt

Factors that affect system lifetimes • Investment Cost The costs of a systems engineering project may be tens / even hundreds of millions of pounds • Replacement Cost The cost of replacing a large system is very high

Replacing an existing system can only be justified if this leads to significant cost saving over the existing system • Return on Investment If a fixed budget is available for system engineering, spending this on new systems in some other area of the business may lead to a higher return on investment than replacing an existing system

• Risks of change The danger with a new system is that things can go wrong in the hardware, software and operational processes

The potential costs of these problems for the business may be so high that they cannot take the risk of system replacement • System Dependencies Other systems may depend on a system and making changes to these other systems to accommodate a replacement system may be impractical • Refactoring The process of making improvements to a program to slow down degradation through change

You can think of refactoring as 'preventative maintenance' that reduces the problems of future change. • When you refactor a program, you should not add functionality but rather concentrate on program improvement Example: Move method (reduces coupling) •

•

Smelly Code •

Duplicate Code • The same / similar code may be included at different places in a program • This can be removed & implemented as a single method / function then called when need

•

Long Method •

•

If a method is too long, it should be redesigned as a number of shorter methods

Large Class • •

A class has too many methods Coupling becomes an issue

System Measurement • You may collect quantitative data to make an assessment of the quality of the application system •

• •

The number of system change requests • The higher this accumulated value, the lower the quality of the system The number of faults over a period of time • Higher number of faults, the lower the quality of the system McCabe's Cyclomatic Complexity • Too much complexity reflects a poor quality system

Lecture 12: Software Planning

Estimation Techniques Organisations need to make software effort estimates •

Experience-based Techniques (Informed Judgement)

The estimate of future effort requirements: • Based on a manager's experience of past projects and the application domain • Essentially, the manager makes an informed judgement of what the effort requirements are likely to be It relies on judgement based on experience of past projects and effort expended in these projects: NASA Typically, you would: • Identify the deliverables to be produced in a project and the different software components or systems that are to be developed. • Document these in a spreadsheet, estimate them individually and compute the total effort required It usually helps to get a group of people involved in the effort estimation and to ask each member of the group to explain their estimate. •

A new software project may not have much in common with previous projects

Anal...