- Software development lifecycle Blog

---

Taskscape implements its own process for planning, creating, testing, and deploying an information system, also known as Software Development Lifecycle (SDLC). SDLC is composed of several clearly defined and distinct work phases which are used by software engineers and software developers to plan, design, build, test, and deliver software in a predictable manner. Each change starts as a change request and initial analysis documents. Later in the process change request is producing multiple design documents, like business requirements, functional requirements, non-functional requirements, user interface, system architecture. Each change request is converted into multiple user stories and each user story is then specified with a number of administrative, development and quality assurance tasks.

Analysis
Analysis is a multi part step that involves many business and technical aspects of every project, as well as every change implemented in the product

• Preliminary analysis: Discover the organization's objectives and the nature and scope of the problem. This is where we provide initial insights and rough estimates how long would it take to deliver a solution given how many parts of the system are involved in the change.
• Feasibility study: discover a range of potential solutions to a problem to work out which are feasible given projects, teams and organization limitations, like: operational feasibility, economic feasibility, technical feasibility, human factors feasibility, Legal feasibility.
• Cost benefit analysis: estimate potential gains and potential costs of implementing each solution under analysis. The goal is to establish if the proposed project or change is worth pursuing.
• Systems analysis. We obtain end user requirements through documentation, client interviews, observation, and questionnaires. Scrutiny of the existing system: Identify pros and cons of the current system in-place, to carry forward the pros and avoid the cons in the new system. Analysis of the proposed system: Find solutions to the shortcomings described in step two and prepare the specifications using any specific user proposals.

Design
At this stage we develop initial specifications, with the preliminary focus on business requirements, user interface design and systems architecture. These are subject to change as we do in agile, however are still produced given the level of detail required to get the working product done at the end of each sprint. Rough sketches and design documents are subject to review with product stakeholders to make sure we have the same idea about the direction we want to pursue current iteration of the product.

Coding
At this stage we employ common patterns and best practices to produce the most maintainable code while still taking the performance into account. The maintainability factor is the most important part of coding as we often work for third party clients, so the goal is rarely pure performance on the get go. Instead we take iterative approach to developing performance as a separate feature.

Testing
At this stage we run all unit and integration tests to demonstrate working product in action. Working demonstrable product is the priority over any specific functionality that was not deemed as essential topic for the sprint. At the end of every sprint every client must receive a working product, even if not feature complete. Therefore, testing often comes in line with the coding efforts. Just as we never ship code that fails unit tests, we never ship product failing integration or functionality testing. Instead we go back to the code, or even requirements, to make fixes in the preceding stages of the process to deliver product free of known issues.

Deployment
At this stage a complete product is handed over to production. This is often being done by the same developers who created the product. In larger projects this responsibility might be delegated to the special deployment team that also configures the software for the specific needs of each client and each version shipped to production.

Maintenance
Software in production is configured and monitored in terms of performance and capabilities to provide insights into areas worth further improvements. Each improvement in the system. Maintenance also might involve fixing issues that were discovered in the production system. To this effect, each bugfix must go through the same planning and design process as every other change. For critical issues worth taking chances we allow a “fast track” process that takes a hotfix with no design documents straight to production. If any design changes are required they’re retrofitted promptly.

Workflow
The whole process is put together in parallel to the ongoing development, so that every sprint iteration we're ready with a number of change request for the next sprints to choose from. The whole process for every change requests is progressed with a number of distinct phases:

Interestingly you should never expect the whole software development lifecycle workflow to be completed in one sprint, as each workflow can be initiated with just stating the change request and analysis done. Workflows can be progressed as far as change request with analysis completed well ahead of the sprint, whereas the design, coding and testing phases must to be completed in a single sprint.

Coding issues - these are task created during the software development phase by senior peer developers. Code review tasks never change the scope of the change request, instead they only specify issues from the codebase maintenance standpoint and development standards. Coding issues trigger another round in the coding phase.

Testing issues - these are tasks that don't change the scope of the design, instead quality issues (also known as bugs) only specify issues with the product against change request requirements or acceptance criteria for each user story. Testing issues trigger another round in the coding phase in order to bring the product in line with requirements.

Release notes - these are lists of changes deployed to the production system that can be distributed among end users and system administrators, also noting some implementation features and requirements as well as providing some maintenance and configuration instructions.

One should note that naturally, each phase can provde the whole change request invalid and requiring the team to go back to the drawing board in order to re-evaluate the whole design of the change, or indeed even question motivation of change or its estimates.