1.1.C. Software Engineering Overview - Activities

1.1. Software Engineering Overview

Part c: Activities

Who Does Software Engineering?

• Customer: the company, organisation, or person who pays for the software system.
  • They are not just there to sponsor the system, but they need to provide a lot of information and participate in the requirements.
  • Software engineers must confer with them to find out more about the requirements.
  • Customer participation is a key part of software engineering, therefore they do participate in the software engineering process.
• Developer: the company, organisation or person who is building the software system.
  • These are the people that we see as 'the software engineers', those who will talk to the customer, understand the requirements, design the software, program it, test it, deliver it, etc.
  • They are the core part of the process, but they cannot work alone. They must work alongside the customer and the users.
• User: the person or people who will actually use the system.
  • It is very difficult to develop a piece of software just by talking to the person who pays for the software, it is very important to understand how users will use it, and what kind of users will use the application in order to cater for what they need.
  • This is not usually the customer, but it could be in smaller-scale.
  • In typical products, someone is in charge who releases the money to pay for a piece of software, but there are other people who will actually use it. For example, users in a call centre using a piece of software that their company decided to implement.

These three roles need to interact. For example:

• The customer must negotiate with the developing company to find out the mode of development, how much it will cost, etc.
• The devloper will need to liase with the customer to find out more about the requirements as time goes by.
  • Especially in the Agile development metholodoligy
• The users will need to provide information to the developers, and the developers will need to provide the software to the users in the end.

Engineering Approach

Building a System

• The overall approach in software engineering was originally based on the general engineering approach, but it has evolved.
  • Engineering is not just software engineering, it includes civil engineering, chemical engineering, etc.
• In software development, we rarely jump straight to programming.
  • It is not viable to do that unless what we were asked was very straightforward and could be done in a single script.
• We need to consider what comes before programming. What is key from an engineering perspective to develop good software?
• Also, we must consider what comes after programming.

Requirement analysis and definition

• The first thing we need to do before programming is requirement analysis and definition.
  • The customer initially comes up with an idea for something that can be solved through software engineering.
  • This is not a full list of requirements, just a general high level idea which needs to be drilled down later.
  • This is where analysis comes in, the overall set of requirements we will need to have in more detail, the impact to the users, and then we need to define them.
  • There must be a simple way to explain the requirements to the developer or the software designer.

System design

• Then, there is system design or the architecture.

Program design

• After, we work on a more detailed program design.
  • Here, we consider more programming language dependent elements. We start adding dependencies such as the concrete way we will develop software.

Writing the programs

• The requirements are now known sufficiently, we have a blueprint and we have planned things more lower-level in the program design, so we can now begin to code.

Unit testing

• In order to garuntee a level of quality for the product, we must conduct a nuhmber of testing such as unit testing. This should be done concurrently to developing the main program.

Integration testing

• If during development we develop things in terms of several modules, they all need to be intergrated.
• If what we've built then needs to interact with systems that already exist, we need to do intergration and intergration testing at that level as well.

System testing

• This is the final testing, which could also involve user acceptance tests.

System delivery

• Once we are satisfied that the quality of the product is good, we can finally deliver the system.
• This is not automatic, we can't just 'press a button', although there are some systems for automating delivery such as continuous delivery, which will be discussed later on.

Maintenance

• Even after we develop, test and deliver our system, we must consider maintenance.
• Nothing is perfect, there will be problems which hopefully we should find most of them during our testing, but some of them will still make it to production. This is an eventuality in any complex system, and we must have maintenance.
• We will have some maintenance methods so when a user finds a bug in production, we can fix it.
• Maintenance can also be seen as improvements to a system, not necessarily fixing a problem but enhancing it.
  • This could be through adding features.
  • This is where most of the time is spent. If a piece of software took 1 year to build for instance, it is expected that the software will be in production for many years, so maintenance will take place over a longer period of time.
  • This is why it is important to ensure that our software is easy to maintain, otherwise it will represent a big area of cost within the lifetime of our product.

Members of the Development Team

• Requirement analysts: work with the customers to identify and document the requirements.
• Designers: generate a system-level description of the system's structure and what it is supposed to do
• Programmers: write programs to implement the design
• Testers: catch faults
  • Although programmers themselves should test the software concurrently to development, testers can often take a different view to find many types of problems independently.

Additionally...

• Trainers: show users how to use the system

  • Ideally the system would be obvious and easy-to-use and anyone could quickly find out how something works, but this not always the case.
  • Often what the solving is so complex that the system has to have some level of complexity as well, therefore we need people who are able to train the users on how to use the system well.

• Maintenance team: fix faults that show up in production

  • This is quite often not the original development team of the originally programmers, there may be some overlap, but they could be a completely seperate team that was trained by the original development team in order to provide maintenance.

• Librarians: manage and store documents such as software requirements

  • These are people who will manage documents. In a large software development process, there will be some documents that are kept, so we need people to manage documents if the application is of that sufficient complexity.

• Configuration management team: maintain correspondence among various artefacts

  • They are concerned with the artefacts from the software production.
  • In a large piece of software, there will be a number of modules to be developed which could represent different files, libraries, etc.
  • The configuration management team will try to make sure that there is a correspdondance between these artifacts and also the documents. They are a key team in large software systems and in large corporations.

• Typical roles in a development team:
  

• Depending on the process and context, the same person can have several of these roles (common in agile processes)