Skip to content

Phases or workflows in the SDLC

INF4817 - Software Engineering

Phases/workflows in the SDLC

As in the Waterfall Model or the agile development model, there are different phases that developers goes through when developing software. It is important to note that these phases don't necessarily need to be completed before the next one is started. It is better to think of them as workflows or modes of work that occur throughout the project lifecycle.

Requirements workflow

Aim:

To determine the client's needs. (Done in a language clients understand)

Major considerations:

  • deadline
  • reliability (uptime, accuracy etc.)
  • size/load of executable image (eg. must run on a desktop)
  • cost

Engineering concepts:

Application domain understanding - engineers need to have a basic understanding of the specific business environment which the software will operate.

Artefacts:

  • Business case: a document which demonstrates the cost-effectiveness of the target product.
  • Requirements: a document which details the clients requirements in easy to understand terms.

Issues

Common issues are that the client can't define what they need: - Either the client may ask for a software solution that does not actually fix the problem. i.e. the client doesnt understand what the nature of the problem is in their organisation. (Schach 2011:79). (faster OS when the problem is the DB, or a sales management app when a stock management would help). This is an organizational factor. - Or the software is too complex for the client to understand. Software is complex even for software engineers, for a client with little software knowledge, knowing what they want can be a large obstacle.(Schach 2011:80)

Analysis workflow

Sometime broken into two workflows: specs and analysis of specs.

Aim:

  1. Analyse and refine the requirements to have a detailed understanding of what the end product needs to do. (specification)
  2. Produce a detailed SPMP (analysis)

Artefacts:

  • A detailed specification document - a document that has taken user requirements into consideration and filled details that do not concern the client (which DB structures to use)
  • SPMP (software project management plan) including:
    • Time analysis
    • Deliverables
    • Milestones
    • Budget

Issues

Ambiguity - specifications are interpretted differently by the client and the design team.

Incompleteness - not all cases may be noted in the specs docs.

Contradictions - two sections of the specs doc may contradict each other.

Incorrect time/cost estimations

Design workflow

Aim

  • To determine exactly how the product is going to work. (through further refinement of the specifications document).

Artefacts

  • Architectural Design - the decomposition of the software product into modules with distinct responsibilities for each module. Each module should have a well defined API (containing function headers, parameters and returns).
  • Detailed Design - algorithms selected for each modules as well as data structures.

Issues

  • Engineers do not keep a record of design decisions and have to rethink this when refactoring the product.
  • Poor architectural design can lead to impossible refactoring later on in the process.

Implementation workflow

Aim

To implement the target software in the chosen programming language(s).

Artefacts

Code modules

Issues

  • Unintended regression faults
  • Design decisions that are too ambitious or not well suited for the real world application may come to light

Testing workflow

Aim

There is no real "testing phase". Testing is done throughout each phase.

Artefacts

Requirements, Analysis and Design testing

Requirements must have traceability - each item in the analysis (or specs) must be traced back to a requirement and similarly for design and implementations artefacts.

This is accomplished through proper numbering, cross referencing and indexing.

Implementation testing
  • Unit testing - testing of a component to achieve a specific set of outcomes. Testing of the component in isolation.
  • Code review - a powerful way to screen software for faults.
  • Integration testing - how does the new component effect the system as a whole (in particular interface checking must be done).
  • Product testing - testing against the specification document to see if the product meets the requirements.
  • Acceptance testing - the testing with real data on the clients machines to determine if it passes their tests.

Issues

Specification faults that are only detected when installed on the clients computer and used in the clients organization.(Schach 2011:84)

Maintenance workflow

Aim

This phase includes all the previous phases. It is additional requirements and maintenance post delivery.

Issues

  • Lack of documentation and high staff turnover can lead to a difficult to understand code-base.
  • Regression faults are something to look out for. Does this fix break other parts of the code?

See also