CS261.md

CS261 Software Engineering

• James liaison to the client

• Seminars act as project briefings

Week 2:

- Specifications
- Pitfalls
- Ideas
- Go about designing requirements and analysis

Week 4

• Going over the documents
  • 3 for each document

Week 6

• Talking about final report and demo video

Sections

Deliverable 1

• Deliverable 1, part 1, Requirements Analysis - 20% ‣

• Deliverable 1, part 2, Design & Planning Document - 20%

• Deadline: Monday, Week 5

• DB will view the video

Choose Sommerville - Soft Eng

Meet up ASAP

• All departments
• Sighn up as mentors or mentees and matches based on preferences
• Will match and support the process
• Creates meetings, and plans of action

have a feedback mechanism

• About both people
• Diversity of services means there are many ranges of skilled professionals and a non-technical person

Rules of Mentoring

expected to follow a protocol, ensuring mentoring is followed

1. Mentee should always drive the relationship
2. Always give time to the Mentee
3. Arrangement based on themes and topics they require help with
4. Should always be from a different business area to the mentee key

Agile methodologies

a principle based off a set of methodologies

• Rapid software development
  • Specification, design and implementation are interleaved
  • System developed as a series of versions with stakeholders providing feedback at each stage

Motivating Agile Methods

• Software systems common to all businesses

  • Businesses need to adapt and evolve rapidly

• Process driven approaches become too cumbersome

  • Focus on the code as opposed to design

  • Aim is to deliver working code quickly in order to meet changing requirements

Principles of Agile

Customer Involvement

• Role of the customer is to provide and prioritise new system requirements and evaluate iterations of the system

Incremental Delivery

• The software developed in increments with the customer specifying the requirements for the next iteration

People not process

• The skills of the development team should be recognised. Team member should be lest to develop their own ways of working

Embrace Change

• Design a system that accommodates requirement change

Maintain Simplicity

• Focus on simplicity in the software being developed and the development process

• Lack of documentation - if someone new is needed, this can become a problem

Software Maintenance

• Most companies spend more money maintaining software than developing it - do agile methods support this
  • Agile focuses on development rather than documentation - could be difficult to pick up a system later on
  • Agile allows continual changes and refinements - makes adding features in the software evolution stage easier - if the original team is still there
• The original team is integral
  • More likely to get burnout, more intense, worse if people end up leaving the project

Plan and Agile Dev

• Plan driven approaches have aspecific stages with outputs from one stage feeding the inputs to the next

• Agile interleaves

Extreme Programming

Incremental delivery with fast iterations

• Versions built several times a day
• Delivered to customers every two weeks
• Automated tests to verify builds - build only accepted if all tests pass
• Code continually refactored to maintain simplicity
• Strong customer involvement

• Incremental planning

  • Requirements recorded on story cards, stories to be included in the next release are selected based off priority

• Small releases

  • Initially, minimum set of functionality developed
  • Following releases add new functionality

• Simple Design

  • Only enough design performed to meet current requirements

• Test driven dev

  • Tests are written before the software, software then evaluated using them

• Refactoring

  • Developers are expected to continually refactor and improve code

• Pair programming

  • Developers work in pairs, checking each others work and providing support - one codes, the other watches

• Collective ownership

  • At least 2 developers have responsibility for any part of the code, any developer can work on any part of the system if they want to make a change.

• Continuous integration

  • Components integrated as soon as they are ready.

• Sustainable Pace

  • Large amounts of overtime is avoided, programming occurs at a sensible pace with support to complete the job well

• On-site Customer

  • Customer always available to work with the team
  • No waiting for response to emails

Scrum

• General agile method that focuses on managing iterative development rather than specific agile process

£ stages

• Outline planning phase - establish general goals
• Sprint cycles - each cycle develops an increment of the system
• Project closure - wrap up the project, documents and delivers

Sprints

Typically development cycles

• Typically 2-4 weeks
• Daily team meeting to discuss current work
• Each sprint completes item on the backlog
• Features selected with the customer, than isolated from the customer for the remainder of the cycle
• Scrum master interfaces between team and customer
• Each cycle reviewed and presented

Protype VS MVP

Requirements Analysis

Requirements are descriptions of what the system should do, the services it provides and the constraints on its operation.

• enable the developers to make software that will correctly fulfil the customer's needs
• Provide a basis for tests, validation and verification
• Enable accurate cost estimation (allegedly)

What are requirements

Distinguish what is build from how it should be built

• How should come much later in the life cycle with plan

Requirements are a bridge between customers and developers

• Documentation should be developed to support both
• Establish a contract between the customer and the developer

C and D requirements

Customer Facing:

• Requirements for the customer
• This comes first

Developer Facing:

• Requirements for the developer to create this requirement

This is all still one requirement, with two separate aspect

Requirements must be unambiguous

User Requirements

• Define how the system should work from a user's point of view
• Described in natural language with diagrams
• List of constraints from the user's point of view

Developer Requirements

• Detailed descriptions fo the functions, services, and operation constraints
• Defines exactly what must be designed and implemented act as a bases for the contract with the developer

Writing Requirments

• Prioritised

  • Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to include it in a particular product release. Customers or their surrogates have the lion’s share of the responsibility for establishing priorities.

• Consistent

  • Consistent requirements do not conflict with other software requirements or with higher level (system or business) requirements

• Modifiable

  • You must be able to revise the set of requriements when necessary

• Traceable

  • Should be able to link each software requirement to its source, which could be a higher level system req. a use case, a voice of the customer statement. Link each to the design elements, source code, and test cases

• Correct

  • Each requirement accurately describes the functionality. And the customers POV

• Feasible

  • Must be possible to implement each requirement within the known capabilities and limitations of the system

• Necessary

  • each requirement should document something the customers really need, or requuired for conformance to an external requirement or an external interface or standard

• Unambiguous

  • Multiple readers of a requirement should arrive at the same interpretation

• Verifiable

  • See whether you can derive tests or use other verification approaches such as inspection or demonstration to determine whether each requirement is properly implemented in the product

MoSCoW requirements

• Must
• Should
• Could
• Won't

General Points

Use:

• Customer
  • Ensure the requirements are met
• Managers
  • To bid for and plan the system
• Engineers
  • A guide to implement the system
• Testers
  • To design the test cases based on the requirements
• Maintainers
  • To understand the relationship between components once the system has been completed

Sections

• Preface
  • Details history of the document and who is expected to read it
• Introduction
  • Justifies the need for the system and outlines what it will do
• Glossary
  • Explains any technical terms used throughout the document
• User Requirements Design
  • Describe the services provided for the users
  • Written in natural language with diagrams
• System architecture
  • Presents a high-level overview of the system, showing the distribution of functions across system modules
• System Requirements Specification
  • Describes functional and non-functional requirements
• System Models
  • Shows relationships between the system components, usually through diagrams (object models, data-flow diagrams etc.)
• System Evolution
  • Describes assumptions on which the system is based and anticipated changes due to changing user needs, hardware evolution
• Appendices
  • Provide detailed, specific information that is related to the application being developed (database schemas, hardware requirements etc.)

Functional Requirements

• Describe what the system should do
• Statements of the servces
• Detail how the system should read in certain scenarios

Non-Functional Requirements

• The qualities of the system - availibility, performance developments

• Constrains on the services or functions offered by the system

• Legislative constraints on the system - laws

• Apply to system rather than components

Requirements Elicitation And Analysis

Discovery

• Stakeholder - anyone who has some influence on the system requirements

• Gathers information about the project and convert into requirements

  • Interviews, domain research

• Conflicting Requirements, imprecise information, legal/ organisational factors

Requirements Classification and Organisation

• Categorises the discovered requirements to groupo similar ones, or similar themes

Prioritisation and Negotiation

• Prioritise the requirements and negotiate between requirements from different stakeholders

Specification

• Place the requirements in a document for stakeholders to read, then begin the process again as new requirements are discovered and old ones changed

Checks

Validity - will the system support the customer’s needs? •

Consistency - are there any conflicts? •

Realism - can the system be produced with the available budget and technologies? •

Verifiability - once complete, can the system be shown to satisfy the requirements?

Validation

Management

Project Roles

Project Manager

• Project management is the application of processes, methods, knowledge, skills and experience to achieve the project objectives”

Business Analyst

• The practice of enabling change in an organisational context, by defining needs and recommending solutions that deliver value to stakeholders

PM Lifetime

Initiation

The process of defining the project, objectives, scope, purpose and deliverables. This is mostly the responsibility of the PM.

• Understand the Business Goals (PM/BA)

  • Identify business needs, problems or opportunities. Justify the investment necessary to deliver solution. Provides a clear vision of the project, and makes it easier to gain approval. Could take the form of a business case.

• Plan the project (PM)

  • Breakdown into manageable pieces of work, ensuring clear definition of responsibilities and dependencies

  • Allows for the project to have a clear structured approach

    • Could take form of a product initiation Document

• Governance (PM)

  • Process and procedures that will support the management decision making
  • Enables efficient delivery and accountability

• Quality management (PM)

  • Standards, processes and procedures to ensure fit for purpose deliverables

  • Have to ensure processes are consistent, predictable and repeatable

  • Quality gates for example

• Risk and issues (PM)

  • Managing risks and issues to stop them from preventing progress
  • Improves pro-activism. May include the creation of a risk and issue log

Project Initiation Document

Contain everything needed to run the project

• provides reference point throughout the project so can be tracked
• The aim of creating a PID is to understand the outcomes of the project, both immediate and longer term.
• The aim of creating a PID is to understand the outcomes of the project, both immediate and longer term.

Analysis

The tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an organisation, and recommend solutions the enable the organisation to achieve its goals.

• Plan Analysis Approach (BA)
  • Identify activities
  • Establish communicatino methods
• Elicit Requirements
  • ID and understand stakeholder’s existing environment, needs and concerns. Ensure underlying needs are understood.
• Document and Validate Requirements (BA)
  • Techniques to organise and formally agree requirements, which allow the BA to define require capabilities of a potential solution that will fulfil stakeholder needs.
  • Techniques to ensure requirements can be traced through to the solution and re-used in future projects / processes.

Design and Build

Design: The process of reviewing, selecting and designing the solution in a way that optimises value delivered to stakeholders

Build: Development of the solution in line with the approved requirements and solution design

• Review Solution Options (BA)
• Document Solution Functionality (BA)
• Communication (PM)
  • Providing clear transparent communication own the progress of the project - good or bad to provide an update on current status. This can take many different forms and not just emails and presentations

Test

• Review Test Plan(BA/PM)

• Monitor Test Execution (PM)

• Prioritise Defects (PM)

• Testing Sign off (BA/PM)

Implement

• Go live (PM)

• Handover to Production and Early Life Support (PM)

• Operational and Maintenance Support (PM)

• Formal Project Acceptance and Sign off (PM)

Closedown

• Review Benefits (PM)
• Archive Project Artefacts (PM)
• End project status report and lessons learnt (PM)
• Reward and Recognition (PM)

System modelling

Class Diagram

Creating a static/structural view of a system requires identifying entities

• Grammatical approach based on a NL description of the system

UML

• shows system classes and relationships

• UML format notation moves requirements closer to mathematical description

• Forces to think carefully about lang. in D requirements

Activity Diagram

• Oblong - Action
• Diamond - Decision
• Black circle - Start
• Double black circle - End

Project Management and Planning

• Why they fail
• Risk Management
• Planning
• Measuring success

Why Might They Fail

• Bad requirement
• Project is unrealistic
• Insufficient budget
• Poor communication

Goals

1. Deliver on time
2. Keep costs within budget
3. Deliver what meets expectations
4. Maintain a happy and well-functioning development team

Managing a Software Team

Depends on three generic factors

1. People in the team - a mix is required, each motivated by different things with different skill sets
2. The group organisation - individuals must be given the opportunity to contribute to the best of their abilities
3. Technical and managerial communications - key to effectively develop software

People Management

4 Factors:

• Consistency - do not make people feel undervalued
• Respect - everyone should be given the opportunity to contribute
• Inclusion - All views, even junior staff should be considered
• Honesty - Covering up ignorance eventually backfires

Motivating People

• People not likely to be the bottom two
• Encourage social networking and face-to-face meetings for social needs
• Achievements, recognitions and salary help satisfy ego
• Demanding but not impossible work can help self-actualisation

Group organisation

Informal

• can be successful when most group members are experienced and competent
• Group decisions are made by concensus
• Lack of experience can lead to project failiure

Hierarchical groups

• Have a leader and levels of management
• Works best when the system can be broken down into subproblems
• Relatively rare due to changing requirements

Cohesive Team

• Group can establish their own quality standards, since established by consensus, more likely to be observed than outside restrictions
• Individuals learn from and support each other - inhibitions caused by ignorance are minimised as mutual learning is encouraged
• Knowledge is shared, continuity can be maintained as members change
• Refactoring and continual improvement is encourage - groups collectively to deliver high-quality results, irrespective of who originally created the design

Design Patterns

Proxy Pattern

• allows us to create placeholders for other objects - often adding another level of indirection
• May wish to reference an entity, without instantiating it

Virtual Proxy

• lazy initialisation, if you have something that is resource heavy, you can delit it being loaded until just before it is needed

Protection proxy

• Provides access control, so your objects are crucial parts of a system, and the users are various client applications, the proxy can prevent access based on credentials

Remote proxy

• Interface offers a client all the functionality of a service object on another server

Logging Proxy

Caching

Smart Referencing

• Essentially garbage collection, if no client is using a [artiularly heavyweight service object, it can be removed to save space

Advantages:

• Can hide away parts of the service object, so it can be changed or controlled without client knowledge
• Manage object lifecycle
• Proxy provides availability even if the servie object isn't ready or available
• New can be introduced without changing the service or clients

Disadvantages

• More classes get introduced
• Adds another step in getting the response, so can result in a slower system

Decorator Pattern

Allow you to add a new behaviour to bojects at runtime

• Could add functinality with subclasses )inheritance), this can end up with v large class hierarchies
• Allow us to do this more transparently

Advantages:

• Extend behaviour without adding several new subclasses
• Responsibilities of an object become dynamic at runtime
• You can combine wrappers
• Promotes the single responsibility principle - divide a large classes responsibilities into several smaller ones

Disadvantages

• Removing wrappers from the stack later is difficult
• Hard to implement in a way that isn't order dependent
• Initial code layout can look messy

Adaptor Pattern

Allows output from one object to be used by another

• May wish to change the data type we're operating in, in order to properly use another framework
• If we update the base class, might need to make lots of changes
• Adaptors let us convert the data format we’re currently operating in to all us to use other services.
• May also need to perfrom a more comp;licated version, where we make a class inherit from one class to get the right interface, but the object we're converting is held inside our new class as a parameter

Adv

• Promotes the single responsibility principle - one object handles the conversion, while the other handles the processing
• New adaptors can be introduced without heavy refactoring of current code

Disadv

• It’s a hit to the complexity of the code
• Depending on the size of your code, converting the original service object may be easier

Flyweight Pattern

• To implement this pattern, we simply identify resources or data that each copy of an object seems to be referencing

• We can then extract that data out into a static class

• Now, instead of holding it 20 times, we only hold it once and can use that freed up memory for more objects!

• As you can imagine, this often used in places such as video games.

Adv

• Saves memory in programs with lots of objects using the same resource

Disadvantages

• Some data may need to be recalculated every time a method is used due to context
• Code becomes more complicated, and tracing the full state of an object can be complicated