Software Engineering

Version management (VM) is the process of keeping track of the different versions of software components or systems and of the changes made to them, and of making sure that changes by different developers do not interfere with each other. It is a part of configuration management, and uses a version control system (VCS) such as Git or Subversion.

How it is carried out

1. Version and release identification: each version gets a unique identifier (number or attributes), e.g. 2.1.3.
2. Repository (storage): all components and their versions are held in a central or distributed repository; to save space only the differences (deltas) between versions may be stored.
3. Change history recording: every change is logged with author, date and reason, so changes can be traced or rolled back.
4. Check-in and check-out: a developer checks out a copy, changes it in a private workspace and checks it in as a new version. Centralised systems may lock the file; distributed ones (Git) allow everyone to have a full copy of the repository.
5. Independent development (branching and merging): several developers work on the same component in parallel branches; branches are later merged and conflicts are resolved.
6. Project support: a project can retrieve all components of a given release, or compare two versions.

Example Git commands: git clone, git commit, git branch, git merge, git push.

Version management is the process of tracking the versions of software components and systems and the changes made to them, and ensuring that changes made by different developers do not interfere with each other.

Carried out through a version control system (e.g. Git, Subversion), with the following features

1. Version and release identification: every version of a component gets a unique identifier, either by number (e.g. 1.2.4) or by attributes.
2. Storage management: all versions are held in a repository; to save space, the system stores only the differences (deltas) from a master version.
3. Change history recording: every change is recorded with who changed what, when and why, so previous versions can be recovered.
4. Check-out and check-in: a developer checks out a component from the repository to a private workspace, edits it and checks it in as a new version.
5. Independent development: several developers can work on the same component at the same time using branching; the branches are later merged, and conflicts are resolved manually.
6. Project support: the system can retrieve all the files of a given system release for building or comparison.

In centralised systems (SVN) there is one repository and components are locked; in distributed systems (Git) each developer has a complete copy of the repository and shares changes by push/pull.

Event-driven modeling shows how a system responds to external and internal events. It is based on the assumption that the system has a finite number of states and that an event (a stimulus) may cause a transition from one state to another. It is used for real-time and embedded systems, and is drawn with UML state machine (statechart) diagrams.

Key concepts

• State: a condition of the system at a time (e.g. Waiting, Running).
• Event/stimulus: something that triggers a transition (e.g. button press, timer expiry).
• Transition: movement from one state to another, written event [guard] / action.
• Action: the response executed on a transition or in a state.
• Initial and final states: start and end of the model.

The model shows the system's reaction to events and does not describe data flow. It suits systems such as embedded controllers, ATMs and vending machines.

Example: microwave oven

States: Waiting, Set Time, Cooking, Disabled (door open), Done.

[*] -> Waiting
Waiting --number--> Set Time
Set Time --start--> Cooking
Cooking --timer expired--> Done
Cooking --door open--> Disabled
Disabled --door closed--> Waiting
Done --door open--> Waiting

Advantages: clear view of behaviour, easy to find missing events, suitable for real-time systems. Disadvantage: the number of states grows quickly for complex systems (state explosion), which is handled by hierarchical (super) states.

Pipe and filter architecture is a data-processing architectural pattern in which processing is divided into independent components called filters, each of which transforms its input data into output. Filters are connected by pipes, channels that carry the data from the output of one filter to the input of the next. The system is a data-flow (batch sequential or stream) model.

Input -> [Filter 1] --pipe--> [Filter 2] --pipe--> [Filter 3] -> Output

Features: each filter works independently and knows nothing about the others; filters can run concurrently; the same filters can be reused in different pipelines.

Example 1: compiler Source code -> Lexical analyser -> Syntax analyser -> Semantic analyser -> Code generator -> Object code.

Example 2: payment processing Read invoices -> Identify payments -> Issue receipts -> Find payments due -> Generate reminders (and similar filters for bank transfers).

Example 3: Unix pipe: cat data.txt | grep error | sort | uniq -c

Advantages

• Easy to understand: overall behaviour is the composition of filters.
• Reuse of filters; easy to add, remove or replace one.
• Supports concurrent execution, so good throughput.
• Natural fit for transformation workflows.

Disadvantages

• Not suitable for interactive systems, since there is no user interaction mid-stream.
• Common data format is needed between filters, causing parsing/unparsing overhead.
• Error handling is difficult because a filter does not know about others.
• Sharing global state between filters is awkward, and a slow filter limits the whole pipeline.

Incremental development builds the system in increments. The requirements are divided into parts; the product is developed, tested and delivered part by part, and each increment adds functionality to the previous ones. Initial customer needs are outlined, then each increment is specified, designed, coded, tested and given to users for feedback.

Outline description -> Define outline requirements -> Assign requirements to increments
-> Design architecture -> [Develop increment -> Validate increment -> Integrate increment -> Validate system] (repeat)
-> Final system

How it helps software production

• Early delivery of the most important functions gives the customer value quickly.
• Early increments act as prototypes that help elicit requirements for later ones.
• Customer feedback is received after each increment, so wrong directions are corrected early.
• Changing requirements are easier to accommodate, since only the current and later increments are affected.
• High-priority services get the most testing because they are delivered first.
• Reduces the risk of total project failure.

Advantages

• Cost of requirement changes is lower than in waterfall.
• Easy to get customer feedback on work done.
• Faster delivery and usable software earlier.
• Lower risk and easier testing and debugging of small units.

Disadvantages

• Process is not visible: managers need regular deliverables and documents for each small increment are costly.
• System structure degrades as increments are added unless time is spent on refactoring.
• Common facilities used by all increments are hard to identify early and may be redesigned later.
• Not ideal for very large systems with many teams, or where an overall specification is needed up front (e.g. contracts).

Software is a collection of computer programs together with the associated documentation and configuration data required to make them operate correctly (design documents, user manuals, test data). It can be generic (sold to many customers) or customised (developed for one client).

Attributes of good software

1. Maintainability: it can evolve to meet changing customer needs; this is critical because change is unavoidable.
2. Dependability and security: reliable, safe and secure; it should not cause damage in failure and must resist malicious users.
3. Efficiency: it should not waste system resources such as memory and processor time; includes responsiveness and processing time.
4. Acceptability (usability): it must be understandable, usable and compatible with the systems its users use, and acceptable to the intended users.

Transaction processing system (TPS)

A TPS is a business system designed to process user requests for information or database updates. A transaction is a unit of work (e.g. withdraw money, book a ticket) that is either fully completed or not done at all. The user makes a request; the system checks it, updates the database and returns a response. TPS follow the ACID properties (Atomicity, Consistency, Isolation, Durability) and are usually interactive, with many concurrent users.

Typical structure: I/O processing -> Application logic -> Transaction manager -> Database.

Examples: ATM banking, airline reservation, online shopping, billing.

Language processing system

A language processing system accepts a natural or artificial (programming) language as input and generates another representation of it, or executes it directly. Compilers translate a source program into target machine code; interpreters execute instructions directly.

Components: lexical analyser, syntax analyser, semantic analyser, symbol table, syntax tree/abstract tree, code generator. In a compiler, the source passes through these stages to produce object code. Examples: C compiler, Java compiler/JVM, Python interpreter, command interpreters and natural language processors.

Structural model vs dynamic model

Aggregation in UML

Aggregation is a "has-a" (whole-part) relationship in which a part can exist independently of the whole. It is a weaker form of association and is drawn as a line with an empty diamond at the end of the whole (container). Example: a Department has Teachers; if the department is deleted, teachers still exist.

Department <>------- Teacher
(whole)               (part)

It differs from composition (filled diamond), where the parts cannot exist without the whole.

Types of risk

• Project risks: affect the schedule or resources, e.g. staff turnover, management change, hardware unavailability, requirements change.
• Product risks: affect the quality or performance of the software, e.g. a purchased component fails to perform as expected, CASE tool underperforms.
• Business risks: affect the organisation developing the software, e.g. a competitor launches a product first, a change in technology.

Risk management process

1. Risk identification: find possible project, product and business risks (technology, people, organisational, tools, requirements, estimation).
2. Risk analysis: assess the probability (very low to very high) and the seriousness of consequences (catastrophic, serious, tolerable, insignificant) of each risk.
3. Risk planning: make plans to address each risk by avoidance (reduce probability), minimisation (reduce impact) or contingency (plan for when it occurs).
4. Risk monitoring: regularly assess each risk, watch its probability and effects, and review the plans; discuss key risks at progress meetings.

The output is a risk register that is revised throughout the project.

Classes and relationships

+----------------+ 1      * +----------------+ 1     * +----------------+
|     User       |----------|     Vote       |---------|   Candidate    |
|----------------|  casts   |----------------|  for    |----------------|
| userId         |          | voteId         |         | candidateId    |
| name           |          | timestamp      |         | name           |
| email          |          |----------------|         | party          |
| password       |          | validate()     |         | voteCount      |
| isValidated    |          +----------------+         |----------------|
|----------------|                                     | addVote()      |
| register()     |                                     | getVoteCount() |
| login()        |                                     +----------------+
| castVote()     |
+----------------+

+----------------+ 1      * +----------------+      +----------------+
|     Admin      |----------|  Registration  |----->|     User       |
|----------------|validates |----------------|      +----------------+
| adminId        |          | status         |
| validateUser() |          +----------------+
| generateResult()|
+----------------+
                       +----------------+
        Admin ------>  |     Result     |  1 ---- * Candidate
                       |----------------|
                       | totalVotes     |
                       | winner         |
                       | generate()     |
                       +----------------+

Explanation

• User registers (register()) and is eligible to vote only when isValidated is true; Admin validates users with validateUser().
• A validated User casts at most one Vote per election; each Vote is for exactly one Candidate (User 1 - 0..* Vote, Vote * - 1 Candidate).
• Candidate keeps voteCount, updated by addVote().
• Result is generated by Admin from all candidates' vote counts and holds the totals and winner.

Requirements elicitation is the process of gathering requirements from stakeholders (users, customers, domain experts) by understanding the application domain, the services needed and the constraints. Main techniques:

1. Interviews: formal or informal question sessions with stakeholders. Closed interviews use a pre-set list of questions; open interviews explore issues freely. They give domain knowledge but analysts may miss tacit knowledge and jargon.
2. Questionnaires/surveys: written questions given to many users; good for large groups and statistics, but lack depth and follow-up.
3. Observation/ethnography: the analyst observes users at work to learn how the work is actually done; reveals implicit requirements and social factors.
4. Scenarios and use cases: descriptions of how users interact with the system in real situations, including normal flow and exceptions; they help stakeholders react to concrete examples.
5. Stories (user stories): short narratives of how the system will be used, popular in agile.
6. Prototyping: a quick working model is shown to users to get feedback and clarify unclear requirements.
7. Brainstorming/JAD workshops: group sessions to generate ideas and agree requirements.
8. Document analysis: studying existing manuals, forms, reports and similar systems.

In practice a combination is used, because each technique finds different types of requirement.

The waterfall model is a plan-driven, linear sequential software process in which each phase must be completed before the next begins, and the output of one phase is the input to the next.

Phases

1. Requirements analysis and definition: services, constraints and goals are fixed with users.
2. System and software design: the architecture and the software components are designed.
3. Implementation and unit testing: the design is coded as programs, each unit tested.
4. Integration and system testing: units are integrated and the system is tested as a whole.
5. Operation and maintenance: the system is installed and used; errors are corrected and enhancements are made.

Requirements -> Design -> Implementation -> Testing -> Maintenance

Each phase produces approved documents (sign-off). Iteration is costly because returning to an earlier phase means redoing documentation.

When to use

• Requirements are well understood, stable and unlikely to change.
• The system is large and developed at several sites, so a clear plan helps coordination.
• Safety-critical or embedded systems that need a thorough analysis before implementation, or fixed-price contracts that need a complete specification.
• Technology is well known and the project is short or simple.

It is not suitable where requirements change frequently, since feedback only comes late, after testing.

Test-driven development (TDD) is an approach in which tests are written before the code. The developer writes a small automated test for a new piece of functionality, runs it (it fails), writes just enough code to pass it, and then refactors. The cycle is Red -> Green -> Refactor.

Why it is productive

• Better understanding of requirements: writing the test first forces the developer to think about expected behaviour.
• Code coverage: every code segment has at least one test, so coverage is high.
• Regression testing: the growing test suite is rerun after each change, so new changes that break old features are found immediately.
• Simplified debugging: when a test fails, the fault is in the code just written.
• System documentation: tests describe what the code is supposed to do.
• Early defect detection: bugs are cheap to fix when found minutes after being introduced.
• Cleaner design: code written to be testable is modular and loosely coupled; refactoring is safe because tests protect behaviour.
• Confidence and less rework in later phases, with fewer defects delivered.

TDD is a core practice of agile methods such as Extreme Programming.

(a) Software quality assurance (SQA)

SQA is a set of activities that ensures that the software processes and products conform to the required standards and meet the quality goals. It covers the whole development cycle, not only testing.

• Defines quality standards and procedures (product and process standards).
• Quality planning: selects the standards and quality attributes (reliability, maintainability, usability, efficiency) for the project.
• Quality control: reviews, inspections and testing to check that the standards are followed and defects are found.
• Reviews and audits of documents and code, measurement of metrics, and reporting.
• Handled by an independent quality team that reports to management, and may follow standards such as ISO 9001 and CMMI.

(b) Version management

Version management (version control) keeps track of the different versions of software components and the changes made to them, and ensures that changes by different developers do not interfere. Its key features are:

• A repository stores all versions, with version and release identification.
• Change history is recorded (who, when, why).
• Check-in/check-out of components with independent development using branching and merging.
• Storage management by storing differences (deltas).
• Tools: Git, Subversion, Mercurial.

Incremental delivery is an approach in which the system is not delivered all at once. The requirements are divided into increments, and each increment, a subset of the functionality, is developed and delivered to the customer in turn. Delivered increments are put to real use while later ones are developed. The highest-priority services are delivered first.

Diagram

Define outline requirements
        |
Assign requirements to increments
        |
Design system architecture
        |
   +-------------------------------------------+
   |  Develop system increment                 |
   |        |                                  |
   |  Validate increment                       |
   |        |                                  |
   |  Integrate increment (with earlier ones)  |
   |        |                                  |
   |  Validate system                          |
   +-------------------------------------------+
        | (repeat for next increment)
   Deploy increment ---> Final system (when all increments are complete)

Process

1. Customer identifies the services needed and sets their priority; outline requirements are defined.
2. Services are assigned to increments (increment 1 holds the highest priority ones), and the overall architecture is designed.
3. Each increment is developed with its own detailed requirements, design, code and test.
4. The increment is integrated with previous ones, the whole system is validated, and the increment is delivered and deployed.
5. Requirements for later increments can be refined as users give feedback.

Advantages: early delivery of value, early prototype for feedback, lower risk of failure, changes are cheaper, high-priority services are tested most.

Disadvantages: hard to see progress without regular documents, structure degrades unless refactored, common facilities are difficult to identify, and it conflicts with contracts that need a full specification at the start.

Architectural views

Architecture of a system is too complex to show in one diagram, so different views are used. The 4+1 view model (Kruchten) proposes:

1. Logical view: shows the key abstractions (objects or object classes) of the system and their relationships; links to functional requirements.
2. Process view: shows how the system is composed of interacting processes at run time; useful for performance and availability.
3. Development (implementation) view: shows how the software is decomposed for development into components and modules, useful for programmers and managers.
4. Physical (deployment) view: shows the hardware and how software components are distributed across processors; useful for system engineers.
5. +1 Scenarios (use cases): relate the four views and validate the design.

Conceptual architecture views are also used for informal communication, and Hofmeister's conceptual, module, execution and code views are an alternative.

Fundamental questions when designing a system architecture

1. Is there a generic application architecture that can act as a template for the system?
2. How will the system be distributed across hardware cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into sub-components?
6. What strategy will be used to control the operation of the components?
7. What architectural organisation is best for delivering the non-functional requirements (performance, security, safety, availability, maintainability)?
8. How should the architecture be documented?

Algorithmic cost modeling

Algorithmic cost modeling uses a mathematical formula to predict project cost from estimates of project size, number of software engineers, process and product factors. The general form is

$\text{Effort} = A \times \text{Size}^{B} \times M$

where $A$ is a constant that depends on the organisation, $B$ reflects the disproportionate effort for large projects ($B$ is usually between 1 and 1.5), $M$ is a multiplier combining process, product, personnel and project attributes, and size is in KLOC or function/application points. Its accuracy depends on the quality of the size estimate and on calibration with historical data. The estimates must be refined as the project proceeds.

COCOMO (Constructive Cost Model)

Basic COCOMO (Boehm) estimates effort in person-months ($E$) and development time in months ($D$) from size in KLOC:

$E = a \, (\text{KLOC})^{b}, \qquad D = c\,E^{d}$

Intermediate COCOMO multiplies the nominal effort by 15 cost drivers (product, hardware, personnel and project attributes) giving an effort adjustment factor.

Detailed COCOMO applies the drivers for each phase.

COCOMO II has sub-models suited to modern development:

1. Application composition model: for prototyping with reusable components; uses object points.
2. Early design model: after requirements, uses function points and 7 cost drivers: $\text{PM} = A \times \text{Size}^{B}\times M$ with $A=2.94$.
3. Reuse model: effort for integrating reusable components.
4. Post-architecture model: most detailed, with 17 cost drivers and scale factors for $B$, once the architecture is designed.

The exponent is $B = 1.01 + 0.01\sum \text{scale factors}$ (precedentedness, flexibility, risk resolution, team cohesion, process maturity).

Project management ensures that software is delivered on time, within budget and to the required standard. The fundamental activities are:

1. Project planning: planning, estimating and scheduling the project, and assigning people to tasks; the plan is revised as the project progresses.
2. Project scheduling: deciding the tasks, their dependencies, durations, milestones and deliverables (shown with bar charts or activity networks).
3. Risk management: assessing risks to the project or product, monitoring them and acting when problems arise.
4. People management: choosing the people for the team and organising it to work effectively; motivation, communication and team structure.
5. Reporting: reporting on progress to customers and the organisation's managers, in short written documents and presentations.
6. Proposal writing: writing a proposal to win a contract to develop software, describing objectives, how it will be done, costs and schedule.
7. Cost estimation and budgeting: estimating effort and cost and controlling expenditure.

Actors: Student, Teacher, Director, Admin, Parent, (System).

Use cases: Login, Vote for teacher, Calculate votes, Notify teacher of status, Generate class routine, View routine, Manage users.

                    +---------------------------------------------+
                    |        Online Voting and Routine System      |
 Student  --------> |  (Login)                                    |
    |               |  (Vote for teacher) --<<include>>--(Login)  |
    +-------------> |  (Vote for teacher)                         |
                    |  (Calculate votes) <-- Admin                |
 Admin  ----------> |  (Manage users)                             |
    |               |  (Generate class routine) <<include>> (Calculate votes)
    +-------------> |  (Notify teacher status) <<include>> (Calculate votes)
 Teacher <--------- |  (Notify teacher status)                    |
 Teacher ---------> |  (View routine)                             |
 Student ---------> |  (View routine)                             |
 Parent  ---------> |  (View routine)                             |
 Director ---------> |  (View routine)                             |
 Admin  ----------> |  (View routine)                             |
                    +---------------------------------------------+

Description

• Student logs in and votes for teachers (Vote includes Login), and views the routine.
• Admin manages users, triggers vote counting, and views the routine.
• Calculate votes is included by both Notify teacher status and Generate class routine; the system counts votes, notifies each Teacher of status (selected or not) and generates the routine.
• The generated routine is sent to Director, Admin, Teachers, Students and Parents, each of whom can use View routine.

Requirements elicitation is the process of discovering the requirements of a system by communicating with customers, users and other stakeholders. Techniques include:

1. Interviews: the team asks stakeholders questions about what they need. Closed interviews use fixed questions; open interviews are exploratory. Good for overall understanding, but domain jargon and unstated knowledge can be missed.
2. Questionnaires: a set of written questions given to many people; efficient but not detailed.
3. Observation (ethnography): watching users work in their environment to discover real practices and implicit requirements.
4. Use cases and scenarios: describing interactions between users (actors) and the system step by step, including exceptions, to discover functional requirements.
5. User stories: short descriptions of a feature from the user's view, used in agile.
6. Prototyping: a mock-up or early version to test understanding and get feedback.
7. Workshops and brainstorming: group sessions to generate and prioritise requirements.
8. Document and existing system analysis: reviewing forms, reports, manuals and similar systems.

The techniques are combined, and the result is validated with stakeholders.

Software engineering issues vary with the type of application. Common issues affecting software in general are heterogeneity, business and social change, security and trust, and scale, and each type of software is affected differently.

• Heterogeneity: systems must work across different computers, devices, operating systems and older legacy systems (distributed and mobile systems).
• Business and social change: business and society are changing rapidly, so software must change and be delivered quickly (web and enterprise systems).
• Security and trust: as software is accessed over networks, it must be secure and trusted (web, banking, e-commerce).
• Scale: software must work from tiny embedded devices to large cloud systems, which needs different techniques.

By application type:

• Stand-alone applications: run on a PC; include all functionality; issues are usability and compatibility.
• Interactive transaction-based: accessed remotely; issues are concurrency, response time, availability and security.
• Embedded control systems: real-time, hardware-linked; issues are reliability, safety, timing and resource limits.
• Batch processing systems: large data volumes; issues are throughput and recovery.
• Entertainment/games: performance and user experience.
• Modelling and simulation: computation and accuracy.
• Data collection/sensor systems: reliability and data volume.
• Systems of systems: integration of many systems.

Other factors include the cost, delivery time, and legal and ethical constraints.

Model-driven architecture (MDA) is a model-focused approach to software design and implementation using a subset of UML. Models are defined at different levels of abstraction:

• Computation independent model (CIM): domain concepts and the business, independent of any system.
• Platform independent model (PIM): operation of the system without reference to any platform.
• Platform specific model (PSM): a transformation of the PIM for a particular platform (e.g. Java EE, .NET).

Need for transformations

• Allow the same PIM to be targeted to several platforms and languages (portability).
• Bridge the gap between abstract business models and executable code, with less manual coding.
• Reduce effort and errors by automating repetitive work and keep models consistent with code.
• Make adaptation to new technologies easy: only the transformation is changed, and the design is reused.

How they are carried out

1. CIM is refined to a PIM by adding system design detail.
2. A transformation tool (with transformation rules and mappings for the target platform) converts the PIM into one or more PSMs; the rules may be extended with platform details.
3. The PSM is then transformed to executable code (or a series of PSMs, each moving closer to code).
4. The generated code is completed and tested, often with manual additions.

Limitations: the tools are expensive and still immature, and models for non-functional features are difficult to transform.

(a) Agile software development

Agile development is an incremental approach, based on rapid delivery of working software in short iterations, in which plan, design, code and test are interleaved. It was developed in response to frequently changing requirements and heavy documentation of plan-driven methods. It is guided by the Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan.

Principles: customer involvement, incremental delivery, people not process, embrace change, maintain simplicity. Methods: Extreme Programming (user stories, pair programming, TDD, refactoring, continuous integration) and Scrum (sprints, product backlog, scrum master, daily scrum). It suits small and medium sized product development where customers are involved.

(b) Context model

A context model shows the operational context of a system: what lies inside the system boundary and what lies outside it, i.e. other systems in the environment. It helps to decide which functions belong to the system being developed and which are in neighbouring systems.

It is usually drawn as a simple architectural block diagram or UML activity diagram, with the system in the middle and the other systems connected by lines. Example: a mental health care system (MHC-PMS) in the centre linked to a patient database, an appointment system, a reporting system and an admissions system. Social and organisational concerns, which decide where the boundary falls, are a factor.

Program inspection is a static review technique in which a team of people formally examines source code (or other documents) line by line to find defects, without executing it. It is done as a peer review with the aim of detecting faults, not correcting them. Inspections can find 60-90% of defects and are often more cost-effective than testing alone.

Roles: author/owner, inspector(s), reader, scribe (recorder), chairman/moderator (usually 4-6 members).

Process

1. Planning: the moderator selects the team and the code and sets entry criteria (the code must be compiled and complete).
2. Overview: the author presents the context and goals of the code to the team.
3. Individual preparation: each member studies the code and checks it against a checklist of common errors.
4. Inspection meeting: a reader paraphrases the code line by line; the team looks for defects, which are recorded by the scribe. The meeting is limited to about 2 hours, and defects are not fixed in the meeting.
5. Rework: the author corrects the defects found.
6. Follow-up: the moderator checks that all issues are resolved; re-inspection is done if there were many changes.

Checklist examples: uninitialised variables, loop termination, array bounds, undeclared variables, memory leaks, wrong interface parameters, exception handling, control flow errors.

Benefits: early detection, knowledge sharing, and improved code quality and standards.

Prototype is an initial version of a software system used to demonstrate concepts, try out design options and find out more about the problem and its solutions. Prototype development is a process model used to reduce risk and improve requirements.

Process model

Establish prototype objectives
          |
Define prototype functionality
          |
Develop prototype
          |
Evaluate prototype
          |
   Prototyping plan / Outline definition / Executable prototype / Evaluation report

Stages

1. Establish prototype objectives: decide what the prototype is for (user interface, requirements validation, feasibility, demonstration to management). Without objectives, management may misjudge it.
2. Define prototype functionality: select what to include and what to leave out (error handling, performance, reliability and standards are usually omitted) to cut cost and time. Outline definition is produced.
3. Develop the prototype: built rapidly using fast tools: scripting languages, fourth-generation languages, GUI builders, reusable components, or even paper prototypes. It may be throw-away or evolutionary.
4. Evaluate the prototype: users try it out on realistic tasks; feedback and training plans are prepared. The evaluation report states whether objectives were met and what changes are needed in the requirements.

Benefits: better usability, close match to needs, better design quality, reduced development effort, and fewer requirements problems. Problems: users may expect the prototype to become the product, it may not match non-functional requirements, and it is typically undocumented and its quality is poor, so it is usually thrown away.

Importance of architectural patterns

An architectural pattern is a stylised description of good design practice that has been tried and tested in different environments. Patterns are important because they:

• capture and reuse proven solutions to common design problems;
• communicate the system structure to stakeholders using a shared vocabulary;
• help meet non-functional requirements (performance, security, safety, availability, maintainability);
• reduce risk and design effort, and help in choosing and evaluating the architecture.

1. Model-View-Controller (MVC) Separates presentation and interaction from the system data.

• Model: manages the data and operations on it.
• View: defines and manages how data is presented to the user.
• Controller: manages user interaction (key presses, clicks) and passes it to the view and model. Used when the same data can be viewed in several ways (web applications). Advantage: data can change independently of its presentation, and the same model supports several views. Disadvantage: extra code and complexity when the data model and interactions are simple.

2. Layered architecture Organises the system into layers, each providing services to the layer above and using services of the layer below (e.g. user interface / application logic / system utilities / core database or OS). Used when building new facilities on top of existing systems, and when development is spread across teams. Advantage: a layer can be replaced if the interface is maintained; supports incremental development and multi-level security. Disadvantage: clean separation is hard in practice, and performance suffers as a request passes through multiple layers.

3. Repository architecture All shared data is held in a central database (repository) that all subsystems access; subsystems do not exchange data directly. Used when large amounts of data are shared (IDEs, CASE tools, information systems). Advantage: components are independent and data is managed consistently (backup, security). Disadvantage: the repository is a single point of failure; communication through it can be inefficient; distribution is difficult.

Testing in development proceeds in three stages.

1. Unit testing (defect testing of individual program units) The lowest-level testing of individual functions, methods or object classes in isolation.

• Test each operation of an object, set and check all attributes, and exercise the object in all possible states.
• Design test cases using equivalence partitioning (valid and invalid input classes) and boundary values; choose cases that exercise all paths (coverage).
• Use mock objects for dependencies, and automated frameworks (JUnit, PHPUnit) with set-up, call and assertion parts.
• Inherited operations must be retested in the context of the subclass.

2. Component (integration) testing Several units are combined into composite components, and the tests focus on component interfaces, i.e. the behaviour of the combination.

• Interface types: parameter, shared memory, procedural, and message passing interfaces.
• Check interface misuse (wrong parameter type or order), misunderstanding (wrong assumptions about the called component), and timing errors.
• Guidelines: test extreme parameter values, null pointers, make components fail, stress test message passing, and vary the order of activation in shared memory systems.

3. System testing Components are integrated to create a complete version of the system, which is then tested as a whole.

• Checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces.
• Tests emergent behaviour of the system and reuses components built by different teams.
• Includes tests derived from use cases and sequence diagrams, tests on the combinations of functions, performance, security, stress and recovery testing, usually by an independent testing team.

Unit testing is done by developers, while system testing by a separate team, with later acceptance testing by customers.

Software configuration management (SCM) is the management of an evolving software system through policies, processes and tools to control changes, so that the product remains consistent and traceable. It is needed when many people work on a system and many versions exist.

Main activities (process)

1. Configuration identification/planning: identify the items to be controlled (code, documents, test data) and give each a unique name and version.
2. Version management: keep track of the multiple versions of components, with a repository and branching and merging, so that changes by different people do not interfere.
3. Change management: keep track of requests for changes; assess cost and impact, decide to approve or reject; implement and validate the change, and update the records. Steps: submit change request form, analysis, approval by a change control board, implementation, and testing.
4. System building: assemble the components, libraries, and configuration files into an executable system, using build tools (make, Ant, Maven); the build should be reproducible, with automated, incremental builds, and the build checks that all dependencies are met.
5. Release management: prepare software for external release (planning when to release, preparing documentation, and distribution media) and keep track of the releases delivered to customers.
6. Configuration status accounting and audit: report the status of all items and changes, and verify that the product meets its configuration.

Tools: Git, Subversion, Jenkins.

Software review is a static examination of software products by a group of people to find faults, check conformance to standards and requirements, and improve quality. Reviews are carried out before and alongside testing, and they can find errors that testing cannot, for example in requirements and design documents.

Review process

1. Pre-review activities: planning the review, selecting the review team and preparing review material; the author gives the documents in advance. The review team has roles: author, chair, reviewers, and scribe.
2. Review meeting: the author takes the team through the document (code, design, requirements); reviewers raise questions and issues; all comments and decisions are recorded by the scribe. Meetings usually last 1-2 hours.
3. Post-review activities: the issues are addressed: fix the software or the document, change the requirements, or note the issue as acceptable. The reviewers check that the revisions are correct (follow-up) and a review report is written.

Types: informal review (walkthrough), technical review, management review, and formal inspection.

Benefits: early detection of defects at low cost, shared understanding, compliance with standards, and better quality and maintainability.

Software price is not simply cost plus profit; many organisational and project factors affect it.

1. Market opportunity: a developer may quote a low price to enter a new market or to gain experience, accepting a loss for future gains.
2. Cost estimate uncertainty: if the cost is uncertain, the organisation may add a contingency, raising the price.
3. Contractual terms: a customer may agree to own the source code, so the developer must charge more; if the developer keeps the code and can reuse it, a lower price is possible. Fixed price or time-and-materials contracts also change the price.
4. Requirements volatility: if requirements are likely to change, the developer may quote low to win the contract and make money from the changes later.
5. Financial health: a developer in financial difficulty may cut the price to win a contract; it is better to make a small profit than to go out of business.
6. Development cost: effort, hardware, software, travel, training and overheads (cost of facilities and support) define the base price.
7. Pricing to win: the price is set at what the customer is believed to be able or willing to pay, and the functionality is adapted to the budget.
8. Quality and scope of the product (reliability, support, warranty), and the development schedule (rush delivery costs more).

Participants (lifelines): User, Online Food System, Restaurant, Payment Gateway.

Sequence diagram (text form)

User            FoodSystem            Restaurant           PaymentGateway
 |  browseRestaurants() |                  |                     |
 |--------------------->|                  |                     |
 |                      | getMenus()       |                     |
 |                      |----------------->|                     |
 |                      |<-----menus-------|                     |
 |<----restaurants & foods----|            |                     |
 |  selectFoods(items)  |                  |                     |
 |--------------------->| calculateTotal() |                     |
 |                      |                  |                     |
 | alt [amount > Rs 3000]                                        |
 |                      | applyDiscount(10%)                     |
 | end alt              |                  |                     |
 |<-----show total------|                  |                     |
 |  makePayment(total)  |                  |                     |
 |--------------------->| processPayment() |-------------------->|
 |                      |<----------------paymentConfirmed------|
 |                      | placeOrder()---->|                     |
 |<--order confirmed----|                  |                     |
 |                      |                  |                     |
 | opt cancelOrder()    |                  |                     |
 |--------------------->| checkTime()      |                     |
 |                      | alt [within 30 min]                    |
 |                      | cancelOrder()--->|                     |
 |                      | refund()-------------------------->    |
 |<--cancelled, refunded|                  |                     |
 |                      | else [after 30 min]                    |
 |<--cancelled, no refund|                 |                     |
 | end opt              |                  |                     |

Explanation

1. The user browses restaurants and selects foods; the system retrieves menus from restaurants and computes the total.
2. In an alt fragment, if the amount exceeds Rs 3000, a 10% discount is applied ($\text{payable} = 0.9 \times \text{total}$; e.g. for Rs 4000, the payable is Rs 3600).
3. The user pays online through the payment gateway; after confirmation the order is placed with the restaurant and confirmed to the user.
4. If the user cancels (opt), the system checks the elapsed time: within 30 minutes the cancellation is approved and the amount is refunded; otherwise, the order is cancelled without refund.

Requirements engineering (RE) is the process of finding out, analysing, documenting and checking the services a system should provide and the constraints on it. The main activities are:

1. Feasibility study – decides whether the proposed system is technically, financially and operationally worth building. The output is a short feasibility report.
2. Requirements elicitation and analysis – the engineers work with stakeholders (users, managers, domain experts) using interviews, questionnaires, observation, use cases and prototypes to discover requirements. The requirements are then classified, prioritised and negotiated to remove conflicts.
3. Requirements specification – the agreed requirements are written down as user requirements (natural language, for customers) and system requirements (detailed, for developers) in the SRS document.
4. Requirements validation – the requirements are checked for validity, consistency, completeness, realism and verifiability, using reviews, prototyping and test-case generation.
5. Requirements management – changes to requirements during development are tracked and controlled, with traceability between requirements and design.

The activities are iterative: problems found during validation send the team back to elicitation or specification.

Agile methods (XP, Scrum etc.) are incremental approaches that deliver software quickly and cope with changing requirements. Their basic principles are:

• Customer involvement – customers are closely involved throughout, supplying and prioritising requirements and evaluating each increment.
• Incremental delivery – software is developed in small increments, and the customer specifies the requirements to be included in each one.
• People, not process – the skills of the team are recognised and exploited; team members develop their own ways of working without prescriptive processes.
• Embrace change – the system is designed expecting requirements to change, so that change is easy to accommodate.
• Maintain simplicity – both the software and the development process are kept simple, and complexity is actively removed from the system.

Together these principles favour working software, frequent feedback, face-to-face communication and sustainable pace over heavy documentation and rigid plans.

Good software is judged by its professional attributes, not only by what it does. The essential attributes are:

1. Maintainability – the software can be changed easily to meet changing customer needs, since change is unavoidable in a business environment. It must be written so it can evolve.
2. Dependability and security – includes reliability (works as expected), safety (does not cause physical or economic damage on failure) and security (resists malicious access or attack). Dependable software should not fail catastrophically.
3. Efficiency – it should not waste system resources such as memory and processor cycles. It includes responsiveness, processing time and memory utilisation.
4. Acceptability (usability) – it must be understandable, usable and compatible with the other systems its users employ, so that the users it is designed for accept it.

The relative importance of these attributes depends on the application; for example, safety is critical in a control system, while efficiency may dominate in an embedded device.

Model-driven architecture (MDA) is the OMG's model-focused approach to software design and implementation. It uses models, rather than program code, as the primary output of development. The system is described by a set of models at different abstraction levels, and the code is generated from them by tools, so the models stay independent of any specific platform.

Abstract system models produced by MDA:

1. Computation independent model (CIM) – models the important domain abstractions (domain models) and the environment, without describing how the system will be implemented. It may be developed with several different CIMs, each describing a different view.
2. Platform independent model (PIM) – models the operation of the system without reference to its implementation, usually with UML static models (class diagrams) and dynamic models (state or sequence diagrams).
3. Platform specific models (PSM) – transformations of the PIM, one for each target platform (for example Java/J2EE or .NET). They add platform detail and may be built at several levels.

Transformations (PIM to PSM, PSM to code) are done by tools, which reduces effort and lets one PIM be reused on many platforms. The limits are that models of the hardware platform may not suit a quickly-evolving agile approach and that the cost of tools and skills may outweigh the gains.

(a) Open-source development

Open-source development makes the source code of a system publicly available so that anyone can inspect, use, modify and redistribute it, under licences such as GPL, LGPL or BSD. Volunteers and companies collaborate to extend and fix the software. Examples are Linux, Apache, MySQL and Firefox.

• Companies use it to reduce cost and get fast fixes, and often sell support and services around the product.
• Licences matter: the GPL is "reciprocal" (derived work must be released under GPL), while BSD allows proprietary reuse.
• Good practice is to establish a policy on open-source use, track licences and take part in the community.
• Benefits include peer review, low cost and rapid evolution; risks include licence conflict and unclear support.

(b) Test-driven development (TDD)

TDD is an approach in which tests are written before the code. The cycle is: identify a small increment of functionality, write an automated test for it, run it (it fails), write code to pass the test, run all tests, and refactor. This repeats for the next increment.

Benefits are code coverage (every segment has at least one test), regression testing, simplified debugging, and tests acting as system documentation. It is a core practice of Extreme Programming.

A software process is a set of related activities that leads to the production of a software product. Whatever the process model (waterfall, incremental, integration-and-configuration), four fundamental activities are present.

Activities in the software process

1. Software specification – defines what the system should do and its constraints. It has these stages: feasibility study, requirements elicitation and analysis, requirements specification and requirements validation. The output is the requirements document (SRS).
2. Software design and implementation – converts the specification into an executable system.
   • Design covers architectural design, interface design, component design and database design.
   • Implementation is programming, along with debugging to find and fix defects.
3. Software validation (verification and validation) – shows that the system conforms to its specification and meets the customer's needs. It involves reviews and inspections, and testing at the levels of component (unit) testing, system testing and customer (acceptance) testing.
4. Software evolution – software is flexible and must change as business needs change. Existing systems are modified and maintained to adapt to new requirements, so development and maintenance form a continuum.

These activities are organised differently in different models: sequentially in waterfall, interleaved in incremental development, and around reuse in integration and configuration.

Techniques to improve the process

• Process improvement models/standards such as CMMI and ISO 9001, with the process measured and compared against maturity levels.
• Process measurement and analysis – collect data such as defect rates, effort and schedule to find weaknesses.
• Process modelling and analysis – document the current process, find bottlenecks, then redesign.
• Process change – introduce new tools and practices, and train staff.
• Agile practices – short iterations, continuous integration, retrospectives.
• Reviews, inspections and automated testing – to find defects early.
• Configuration management and reuse – to control change and reduce rework.
• Risk management and project monitoring – to adjust the process during the project.

Improvement is itself cyclic: measure, analyse, change, then measure again.

Assumptions

• Actors: Student, Administrator, Examiner (Teacher).
• Students register, log in, take a timed exam of MCQ questions, submit, and view the result.
• The administrator manages exams and candidates; the examiner creates question banks.
• The system evaluates MCQ answers automatically and publishes results.

Use case diagram

                +-------------------------------------------+
                |        Online Entrance Examination        |
  Student ------|  (Register), (Login), (View Instructions) |
     |          |  (Take Exam) --<<include>>--> (Submit)    |
     |          |  (View Result)                            |
  Examiner -----|  (Manage Question Bank), (Set Exam)       |
  Administrator-|  (Manage Candidates), (Schedule Exam),    |
                |  (Publish Result)                         |
                |  (Take Exam) --<<include>>--> (Login)     |
                +-------------------------------------------+

Main use cases: Register, Login, Take Exam, Submit Answers, View Result (Student); Create Question, Set Exam (Examiner); Manage Candidates, Schedule Exam, Publish Result (Administrator). "Take Exam" includes "Login" and "Submit Answers"; "Evaluate" is triggered by submission.

Class diagram

User                      Student                     Exam
-userId                   -regNo                      -examId
-name                     -email                      -title
-password        <|----   +register()                 -date
+login()                  +takeExam()                 -duration
+logout()                 +viewResult()               +schedule()
   ^                                                  +start()
   |                                                  +end()
Administrator, Examiner                                   |1
+manageCandidates()                                       | has
+createQuestion()                                         |1..*
                                                      Question
Result                    Answer                      -qId
-resultId                 -selected                   -text
-score          *---1     -isCorrect  *---1 Question  -options[]
-status                   +check()                    -correctOption
+calculate()                                          -marks
+publish()

Relationships: User is generalised into Student, Examiner and Administrator; Exam 1 -- 1..* Question (composition); Student 1 -- * Answer; Student 1 -- * Result; Result belongs to one Exam.

Sequence diagram (taking an exam and getting the result)

Student     UI        ExamController     Database     Evaluator
  |--login-->|--verify-->|--query user---->|            |
  |          |<--ok------|<----------------|            |
  |--startExam->|--loadExam-->|--get questions->|        |
  |<--questions (timer starts)--|<---------------|        |
  |--answer(q,opt)->|--save answer-->|--store-->|         |
  |--submit-------->|--submit------->|--------->|         |
  |                 |                |--evaluate(answers)->|
  |                 |                |<----score-----------|
  |                 |<--save result--|                      |
  |<--show result---|                |                      |

The sequence is: the student logs in; the controller checks credentials with the database; the exam is loaded and the timer starts; answers are saved as given; on submission (or timeout) the evaluator computes the score, the result is stored and displayed to the student.

Test-driven development (TDD)

TDD is a program development approach in which testing and code development are interleaved, with the test written before the code. Code is developed incrementally along with a test for that increment, and the developer does not move to the next increment until the code passes its test. It is a core part of Extreme Programming but is used in other methods as well.

Process

1. Identify the increment of functionality needed, usually small and implementable in a few lines of code.
2. Write a test for this functionality and implement it as an automated test.
3. Run the test, along with all other tests. The new test fails because the functionality is not yet implemented.
4. Implement the functionality and re-run the test.
5. Once all tests pass, move on to the next piece of functionality (refactoring as needed).

Advantages

• Code coverage – every code segment has at least one associated test, so all code is tested.
• Regression testing – a test suite is built incrementally, so changes can be checked quickly for side effects.
• Simplified debugging – when a test fails, the problem is likely in the newly written code.
• System documentation – the tests describe what the code should do.
• Leads to simpler design and better understanding of requirements before coding.

Disadvantages

• Takes extra time and effort at the start, and test code must be maintained along with the product.
• Programmers may write tests that are too easy or incomplete, and miss tests for complex or exceptional conditions.
• Difficult for code with UI, databases or network dependencies, which need mocks.
• Passing all tests gives false confidence; it does not replace system or acceptance testing.
• Poor tests or a poor design decision made early can be costly to change.

Software price is not just development cost plus profit. Several ways of pricing are used:

1. Cost-based (cost plus margin) pricing – estimate the total effort and expense of development (staff, hardware, travel, overhead) and add a profit margin. It is simple but depends on a good estimate.
2. Fixed price – a price is agreed in the contract for specified requirements. The developer carries the risk of cost overrun, so a contingency is included.
3. Time and materials (cost-plus) contract – the customer pays for actual effort and expenses at agreed rates. The customer carries the risk, and it suits changing requirements.
4. Pricing to win – the price is set to what the customer is believed to be willing to pay or what will beat competitors, and the functionality is then adjusted to fit that price.
5. Market-driven pricing – for products, the price depends on what the market will bear, the number of expected sales, competition and licensing (per user, per copy, subscription).

Other factors affecting the final price: market opportunity (low price to enter a market), contractual terms (who owns the source code), requirements volatility, financial health of the developer, and cost estimate uncertainty.

Release testing is a form of system testing in which a separate team tests a complete version of the system that is intended for release to customers or users. Its aim is to convince the supplier that the system is good enough for use, that is, that it delivers the specified functionality, performance and dependability and does not fail during normal use.

It is usually black-box testing: the tests derive only from the system specification and the testers do not know the implementation. It is also called functional testing.

Guidelines/approaches:

• Requirements-based testing – at least one test for every requirement.
• Scenario testing – tests built around typical usage scenarios.
• Performance testing – checks load and stress behaviour.

Example: A library management system has the requirement "a user shall be able to borrow a book if they have no overdue items and fewer than five books on loan." Release testing derives test cases from it: (1) a user with no overdue items borrows a book, so the loan is recorded; (2) a user with one overdue book tries to borrow, so the loan is refused with a message; (3) a user already holding five books tries to borrow a sixth, so it is refused. The testers run these through the user interface of the complete build and compare actual with expected output, without looking at the source code.

Software quality assurance (SQA) is the set of activities that ensures software processes and products conform to the required standards and quality. It is critical for these reasons:

• Defects are costly – the later a fault is found, the more expensive it is to fix; SQA finds them early, through reviews, inspections and testing.
• Customer satisfaction and reputation – poor quality software leads to dissatisfied users, lost business and legal claims.
• Safety and security – failures in critical systems (banking, health, aviation) can cause loss of life or money, and so reliability must be assured.
• Lower maintenance cost – good quality software is easier to understand and change, and maintenance is the largest part of lifecycle cost.
• Process control and predictability – standards and procedures (ISO 9001, CMMI) make schedules, costs and outputs predictable and repeatable.
• Team consistency – standards for documents, coding and reviews give uniform results from large, distributed teams.
• Compliance – contracts and regulations often require demonstrated quality processes.

SQA activities include defining standards, quality reviews, software measurement, process monitoring and audits, and test management. Since quality cannot be added at the end, SQA must run through the whole life cycle.

Software configuration management (SCM) is the management of changing software systems so that the many versions and variants of the system and its components are controlled. Its main activities are:

1. Version management – keeping track of the different versions of software components and ensuring that changes made by different developers do not interfere (check-in/check-out, branching and merging, using a repository such as Git).
2. System building – assembling program components, data and libraries, then compiling and linking them to create an executable system. Automation (build tools) ensures that the right versions are used.
3. Change management – keeping track of requests for change, assessing their cost and impact, deciding which to accept, and tracking their implementation. Change requests are recorded on a form, analysed by a change control board, and implemented if approved.
4. Release management – preparing software for external release and keeping track of released versions, so that customers can be supported and a rebuild of any release is possible.

Configuration identification and status reporting/auditing support these, so that the state of all items (configuration items) is known at any time. SCM is essential in team development, and for agile methods that use continuous integration.

A design pattern is a description of a proven solution to a commonly occurring design problem, abstracted so that it can be reused in different settings. Examples are Observer, Singleton, Factory, Adapter and MVC.

Design patterns help in software development in these ways:

• Reuse of experience – they capture the knowledge of experienced designers, so a team does not need to reinvent solutions.
• Common vocabulary – names such as "Observer" let developers communicate complex design ideas quickly.
• Better design quality – patterns apply principles like loose coupling, encapsulation and separation of concerns, so the software is more flexible and maintainable.
• Faster development – a ready-made, tested structure shortens design time and reduces defects.
• Documentation – a pattern used in a system explains the intent of its structure to later maintainers.
• Support for change – patterns such as Strategy or Observer let behaviour be changed or extended without modifying existing code.

A pattern description normally contains a name, problem, solution and consequences. The problem is that patterns must be understood and applied appropriately; overuse can lead to over-complex designs.

An architectural model can be presented from several views. Kruchten's 4+1 view model is the best known:

1. Logical view – shows the key abstractions in the system as objects or object classes; it relates system requirements to entities.
2. Process view – shows how, at run time, the system is composed of interacting processes; useful for judging performance and availability.
3. Development (implementation) view – shows how the software is decomposed for development into components or subsystems to be built by developers.
4. Physical (deployment) view – shows the system hardware and how software components are distributed across the processors in the system.
5. +1 Scenarios (use case view) – related use cases/scenarios that tie the four views together.

                 +-------------------+
                 |   Logical view    |
                 | (object classes)  |
                 +---------+---------+
                           |
+----------------+   +-----+------+   +------------------+
|  Process view  |---| Use case / |---| Development view |
| (run-time      |   |  scenarios |   | (components,     |
|  processes)    |   |    (+1)    |   |  modules)        |
+----------------+   +-----+------+   +------------------+
                           |
                 +---------+---------+
                 |  Physical view    |
                 | (hardware nodes)  |
                 +-------------------+

Hofmeister et al. likewise propose conceptual, module, execution and code views. In practice the architect uses informal diagrams (boxes and lines) in each view, and not every view is needed for every system.

Model-driven architecture (MDA) is a model-focused approach to software design and implementation, proposed by the Object Management Group (OMG). It uses a subset of UML models to describe a system at different levels of abstraction, and code is generated from the models.

Models used:

• Computation independent model (CIM) – the domain and requirements without implementation detail.
• Platform independent model (PIM) – the system's operation, independent of any platform (UML class and state diagrams).
• Platform specific model (PSM) – a transformation of PIM for a particular platform such as Java EE or .NET; code is then generated from it.

CIM  -->  PIM  -->  PSM (Java)  -->  Java code
                \->  PSM (.NET)  -->  C# code

The transformations between models are automated by tools. Advantages: designs are portable across platforms, models are the main asset and code is a by-product, and development effort is reduced. Disadvantages: tool support is limited, abstract models may not suit implementation concerns, and the savings can be less than the cost of building the models.

Software engineers have wider responsibilities than just technical skills. The ACM/IEEE-CS Code of Ethics and Professional Practice sets out eight principles, which professionals should follow:

1. Public – act consistently with the public interest.
2. Client and employer – act in the best interests of the client and employer, consistent with the public interest.
3. Product – ensure that products and modifications meet the highest professional standards.
4. Judgment – maintain integrity and independence in professional judgment.
5. Management – managers and leaders subscribe to and promote an ethical approach to development and maintenance.
6. Profession – advance the integrity and reputation of the profession.
7. Colleagues – be fair to and supportive of colleagues.
8. Self – participate in lifelong learning and promote an ethical approach to the practice of the profession.

Ethical issues commonly faced include:

• Confidentiality – respect the confidentiality of employers and clients.
• Competence – do not accept work beyond your ability.
• Intellectual property rights – respect patents, copyright and licences.
• Computer misuse – do not use technical skills to misuse others' computers (viruses, unauthorised access).

Good practices include following standards and reviews, testing thoroughly, documenting honestly, and reporting risks to the public interest.

(a) Non-functional requirements

Non-functional requirements (NFRs) are constraints on the services or functions offered by the system, rather than specific services. They often apply to the system as a whole and are more critical than individual functional requirements; failing to meet one may make the whole system useless.

Types:

• Product requirements – usability, efficiency (performance, space), dependability (reliability, safety), security.
• Organisational requirements – delivery, implementation and standards requirements.
• External requirements – legal, ethical and interoperability requirements.

They should be written to be verifiable and measurable, for example "response time under 2 seconds for 95% of transactions", rather than "the system shall be fast".

(b) Principles of agile

• Customer involvement in requirements and evaluation.
• Incremental delivery of working software.
• People not process – trust and empower the team.
• Embrace change in requirements.
• Maintain simplicity in both software and process.