What is the definition of Success in the SDLC?

There are many software development projects that are classed as successful because they delivered on time and/or on budget and delivered the functionality requested – but survived a short while in the production environment due to their lack of scalability, and high maintenance costs due to lack of planning and foresight during the software’s initial production. These projects often require a complete rewrite, that is not successful. Every opportunity must be taken to make sure that software is written with maintenance, readability, skills availability, and scalability in mind so the software lasts for many years – future proof.

Keeping the maintenance cost down is paramount to a software project being successful; it is no use being a one hit wonder. A project must also be able to implement fixes and/or enhancements and release these speedily and in isolation to on-going development, this means having at least two separate streams of development. Firstly, there is the on-going development stream where we can create new features without impacting the ability to produce fixes. Secondly, there is a maintenance stream where we can fix any problems that arise in the production environment and release these without also releasing any work included in on-going development. Thirdly, we must make sure that fixes and enhancements made in each stream can be included in the other so one release does not overwrite fixes in the previous release.

With a good Software Development Manager and Systems Development Lifecycle (SDLC) the following will be achieved.

  • Prevent Failure
  • Have knowledge of the true state of any project
  • Enables far more accurate planning and costing
  • Better Management of expectation
  • Improved Communication
  • Less disputes
  • Better vision of what is expected
  • Better efficiency, less duplicity
  • More control – top down
  • Interoperability between projects and the business
  • Prevention of Process Creep – where one process takes authority from another

Common Problems for Leaders in the SDLC

  • Lack of support for multiple streams i.e. production and new development – versioning. Lack of knowledge how versioning works
  • Lack of integration with related projects
  • Development processes overlap into production processes and are not compatible.
  • Lack of clear input and output at each step.
  • Lack of clear ownership
  • Constantly changing release dates – forward and backward
  • Inability to deal with late requests
  • Crunch testing – development overruns into time allocated for testing, testing reduced. Can happen with many processes.
  • Management without technical expertise who override decisions made by technologists, and pressurising technologists to make change to fast

Common Problems for Software Engineers in the SDLC

Before getting into defining a Systems Development Lifecycle (SDLC) lets look at some of the main problems experienced by Software Engineers when it is done badly.

  • No time allocated for good design and architecture
    • Code becomes unreadable and unmaintainable
    • Code is disorganised limiting amount of software engineers and/or changes to be active at any time.
    • Makes full and patch releases difficult or impossible without severe downtime or refactoring of code.
    • Simple configuration or system administration requires a code change not variable/parameter change.
    • Makes change extremely difficult – not scalable or object orientated.
      Duplication of solutions i.e. not sharing such as application and hardware servers
    • Makes releases extremely difficult i.e. No thought how to release the project – to many manual processes in a release. Releases take several hours and even days. Build an object to large to get through the door.
  • Lack of necessary documentation or to much unnecessary documentation
  • No or very little enterprise development, testing, or security standards
  • Don’t manage what you don’t understand. Non technical staff getting involved in making technical decisions causes the two most common features in struggling and/or failing technology projects:
    • Pressure from business to implement change fast. Management scheduling without understanding impact and risk
    • Inability of IT to explain and the business to understand the intricate nature of technology projects.