The software process is the cornerstone of successful software engineering. It is the Life Cycle that the software goes through from conception to retirement. The process can be thought of as a set of activities that covers the complete life span of a piece of software. Activities commence when the software is envisaged, and give structure to its development stage. However, they also continuing through its operational lifetime until the product is finally ‘retired’. Life cycle models links these activities.

You should be familiar with the main life cycle models from the Fundamentals of Software Engineering course. We will use some of these slides during this lecture

Some Life Cycle Models include the following …..

The Waterfall Model

The “traditional” approach to software development is to use the waterfall model. The expectation is to complete each step before proceeding to the next step in the process.

The steps in this model are as follows:

Incremental Approach

There are alternatives to the Waterfall model. These alternatives come under the name “Agile”. Agile approaches utilise a different “ordering” of the development steps.

Agile Development

The fundamental characteristics of agile development are:

Specification, Design and implementation are interleaved

The system being built is developed in a series of versions

An interactive approach is used to develop the User Interface

The key then is to develop the system in increments

Ideally increments should be made available to customers every 2 or 3 weeks involving customers in the development process.

Systems Analysis activities:

Gather detailed information

Define requirements

Prioritize requirements

Develop user-interface dialogues

Evaluate requirements with users

1. Gather Detailed Information

Systems analysts obtain information from people who will be using the system, either by interviewing them or by watching them work. Analysts also study existing systems, including their documentation. They try to understand an existing system by identifying and understanding the activities of all users

Information-Gathering Techniques

Interviewing users and other stakeholders

Distributing and collecting questionnaires

Reviewing inputs, outputs, and documentation

Observing and documenting business procedures

Researching vendor solutions

Collecting active user comments and suggestions

2. Define Requirements

The analyst uses information gathered from users and documents to define requirements for the new system.

functional requirements

the activities that the system must perform (i.e., the business uses to which the system will be applied).

non- functional requirements

related issues such as user interface formats and requirements for reliability, performance, and security

Functional Requirements :

Functions     Business rules and processes

Non-functional Requirements :

Usability               User interface, ease of use
Reliability             Failure rate, recovery methods
Performance        Response time, throughput
Security                Access controls, encryption
Implementation     Development tools, protocols
Physical                Size, weight, power consumption.
                             Installation and updates

3. Prioritize Requirements

Once the system requirements are well understood, it is important to establish which requirements are most crucial for the system. Sometimes, users suggest additional system functions that are desirable but not essential. However, users and analysts need to ask themselves which functions are truly important and which are fairly important but not absolutely required.

4. Develop User-Interface Dialogues

To most users, the user interface is all that matters. Thus, developing user-interface dialogs is a powerful method of eliciting and documenting requirements A user-interface prototype developed in an early iteration can be expanded in later iterations to become a fully functioning part of the system.

5. Evaluate Requirements with Users

Analysts usually use an iterative process in which they :

obtain user input

work alone to model requirements

return to the user for additional input or validation,

work alone to incorporate the new input and refine the models.

Prototypes of user interfaces and other parts of the system may also be developed

System Modelling

This is the process of developing abstract models of the system that is being developed. This approach will involve some form of diagram …. UML Diagram. Models are used at different points in the development process.

Models and Modelling

UML@Classroom Chapter 1

Natural Language is not a good choice as it is imprecise and ambiguous and consequently can lead to misunderstandings between technical (analyst/designers) and non-technical (users). Modelling is an important part of analysis and design. Analysts build models to describe system requirements and use those models to communicate with users and designers. By developing a model and reviewing it with a user, an analyst demonstrates an understanding of the user’s requirements. If the user spots errors or omissions, they can be updated into the model before it becomes the basis for subsequent design and implementation activities.

Unified Modeling Language (UML) is a standardized general-purpose modelling language in the field of software engineering and is one of the most widespread graphical object-Oriented Modelling languages. UML includes a set of graphical notation techniques to create visual models of software-intensive systems. UML is used to specify, visualize, modify, construct and document the artifacts (e.g. use cases, class diagrams etc.) of an object-oriented software system under development.

Brief History of UML

Designed by G. Booch, J. Rumbaugh, I. Jacobson (3 amigos)

Started in 1994, version 1.0 finished in 1997

They put aside their own methods and notations to end the OO method wars

Previously there was a lack of standardization : every method, tool, practice has their own set of symbols and terminology

For several years UML maintained by OMG (Object Management Group) revision task force which produced versions 1.3, 1.4, and 1.5 from 2000 to 2003

Official version of UML 2.0 adopted by OMG early 2005 (this is a major revision of UML1 and includes many additional features and many changes were made to previous constructs based on experience with the previous version).

Current version is 2.4.1

The 1st three steps (Analysis/Design/Coding) in the Software Process can be viewed as a Series of model transforms.

For each of the models (boxes), the UML has its own models and diagrams. This Module will deal with the UML modelling of the Analysis (Requirements) Model and the Design Model. The order in which the module deals with these UML models will be the order that an analyst might when analysing and designing a system.

UML diagrams represent two different views:

Structural (Static) View

emphasizes the static structure of the system using objects, attributes, operations and relationships.

Behavioural (Dynamic) View

emphasizes the dynamic behaviour of the system by showing collaborations among objects and changes to the internal states of objects.

In this module – we will only cover the following diagrams :

Structural (Static) View

Class Diagrams

Object Diagrams

Component Diagrams

Behavioural (Dynamic) View

Use Case Diagrams

Activity Diagrams

State Machine Diagrams.

Sequence Diagrams

Communication Diagrams