Development Lifecycle (SDLC)

"Software development lifecycle" (SDLC) describes the processes used to plan, test, and deploy a software solution. There are various SDLC models commonly acknowledged in the IT industry. To describe how EAS has created its own innovative SDLC, we must first define the most popular traditional SDLCs:

  • Waterfall: A highly-sequential model in which the process cascades through the various phases in a "waterfall" like fashion. This SDLC has its origins in the manufacturing industry. At a high level, the various phases would include conception, initiation, analysis, design, construction, testing, implementation, and maintenance. Once the process has "flowed" through all stages and has thus reached the "maintenance" phase, many project managers consider the waterfall cycle to "restart" when the first maintenance request/change is made (as handling each change or improvement to the software would conceptually require each of the waterfall phases to be completed.) Thus, in an evolving system, the "waterfall" repeats. Although this SDLC is highly ordered, its major disadvantage are the fact that its rigidity makes it difficult to incorporate changes "midstream" once the conceptual phases are complete and also the fact that it takes quite a long time for results (first prototype) to be seen or usable.
  • Spiral: An eclectic model that combines aspects of other prior models. For example, the project as a whole can be considered a sequence of waterfall events ("mini-waterfalls"), and thus, the project as a whole will pass through the planning, risk analysis, engineering, and evaluation phases multiple times as each module or conceptual unit is developed. Thus, it does allow for incremental work to be completed, and thus, developers and testers are not expected to wait until the very end to see the first working edition. The most unique aspect of the spiral model is its emphasis on "risk." The order, priority, attention to detail, and time devoted to each task is determined by its risk factor. The advantages of the spiral model include the fact that it ensures the project is well-planned and well-documented, encourages incremental work, and allows for changes/unplanned events. However, it is rather complicated, can be costly to use (as it requires expertise to prepare), and can be cumbersome for smaller projects.
  • Rapid Prototyping: A model that focuses on the concept of getting a "concrete" iteration available to stakeholders as quickly as possible. In some extreme cases, prototypes are started with the assumption they will later be discarded and completely reworked, or may serve as only the starting point for a more mature system (referred to as "throwaway prototyping"). This model is often employed when a given project is driven heavily by user requirements (especially ones that are uncertain or may change), because the model allows a preliminary or prototype UI to be demonstrated after a very brief planning and development cycle. Once the stakeholders or end users see the prototype and interact with it to the extent possible, feedback is received and implemented by the developers to refine the model and add additional desired functionality. The cycle would continue until a suitable system is created. As the name implies, this model provides a prototype to the stakeholders as quickly as possible, and this can be a plus in certain cases. It also requires minimal planning or organizational skills. However, the model can become rather haphazard for larger projects and larger teams, and can create "dead ends" or tightly-coupled modules that lack future expandability.
  • Agile Development: Agile development is a newer model that is quite popular in modern companies. As the name implies, the overall attitude of the model is flexibility and adaptability. There are a variety of specific disciplines that all fall under the "agile" umbrella, such as Scrum, Unified Process, Adaptive Software Development, Feature-Driven Development, and others. Generally speaking, all of the disciplines are quick to respond to change and incorporate continuous development concepts. Additionally, most models emphasize the importance of getting "working software" to stakeholders quickly, thus providing a series of frequent iterations with each more mature or feature-rich than the last. Most agile models focus on respecting the end user's perspective, sometimes using "user stories" or specific features as the starting point of the requirements for the system. The model is praised for its flexibility, friendliness, and focus on the end user's perspective. However, it can be sometimes difficult to implement with larger teams, and also can be inappropriate for highly critical tasks due to the less formal emphasis on requirements.
  •  

    How does Essential Algorithms view SDLC differently?

    It is indeed true that "one size does not fit all," and there is no single model that is ideal for each system and use case. For example, the formal and long-running Waterfall model would not be the best fit for a small convenience application that would be used primarily by internal staff. To contrast, the agile development model would likely struggle to coordinate the activities of a 200-unit development team writing software for a public utilities firm. Through experience and ingenuity, the leadership at E.A.S. has created an internal SDLC that combines various previous and new ideas that is appropriate for many projects as-is, and can easily be adapted to become more specific to a particular project if needed.

    The philosophies behind E.A.S's internal SDLC are as follows:

  1. Emphasize business needs rather than technical needs. Most firms are focused more on their overall business process than which specific features they'd like to see in their software systems and algorithms. We strive to obtain a strong grasp of the client's organizational philosophy and business process prior to focusing on software specifics. Many times, the staff at E.A.S. can add valuable and fresh input to the software requirements simply because of the time taken to understand the underlying needs and processes.
  2. Prepare a well-defined but flexible project requirements sheet. After gaining adequate understanding of the underlying business process and needs, the second step of our SDLC is much like the first step of most other SDLCs: we begin our project requirements planning. Various aspects of planning including user experiences, data modelling requirements, organizational criteria, and management expectations are combined to produce a spec sheet that embodies the technical requirements of the project while maintaining an overall understanding of the business processes and needs identified in Step 1. Generally, when time permits, we like to allow a "rest" period between this phase and the next step of the lifecycle so that the requirements sheet can be modified or added to as new information comes to light.
  3. Begin coding and prototyping the solution, using the Relevant Abstract Classing (RAC) system where appropriate. At this stage, work is divided amongst the development staff and the coding process begins. Unit tests are conducted throughout the development process, allowing the same developer who wrote a given contribution to test and debug it on his own and permitting the dedicated testing team to focus on larger modular or end-to-end functional tests. Although there are certainly many details about the coding process itself that can be discussed at length, one key differentiating factor at E.A.S. that warrants specific discussion is the RAC (Relevant Abstract Classing) system. The topic of abstract classes -- that is to say, a class that provides an open-ended definition to be "filled in" or implemented by a future inheriting class -- is important to object oriented programming, but various developers have differing stances on it. In some extreme cases, programmers will provide an abstract interface for every functional class, providing a near 1:1 link between the quantity of abstract classes and functional classes. On the other extreme, some developers never use them. At E.A.S., abstract classes are used where they are relevant and necessary -- but not until a proper investigation phase has done. In general, applications are written in a modular way so that an application can be thought of as a series of interconnected modules working together.
  4. Micro-deployment. Some SDLCs call for a detailed end-to-end testing phase prior to deployment, while others call for a partial deployment and a roll out of future features as they are internally tested by the development staff. When possible, E.A.S. will use a "micro-deployment" technique, where a deployment of the current iteration or entire solution (where appropriate) will be deployed, but only to a certain subset of the targeted user-base. Depending on the business needs, this might mean deploying the solution only for certain staff, or only for certain customers who opted to become part of a "beta testing" group. Most times, the end for a detailed end-to-end testing phase is not necessary because end-to-end tests would have been run by the dedicated testing staff throughout the development process up to and including the final development iteration. Thus, the only further tests that would be of substance would be to conduct "real-world" tests -- and these are best done using real world users, but ideally, not the entire user-base at once. This "micro-deployment" strategy allows for useful feedback to be implemented in successive iterations while making the product public to a gradually increasing portion of the targeted user-base.
  5. Constant modernization. Many SDLCs, such as the waterfall model, end the cycle with an ongoing "maintenance and improvement" phase. Although this does fulfill the needs of many businesses, it tends to be more reactive in nature rather than proactive. E.A.S.'s technology research team is constantly researching, testing, and implementing the latest cutting edge technologies, and will suggest to clients how their existing systems can be improved or made more efficient given a particular recent technological innovation, library, toolkit, etc. E.A.S. prides itself in being proactive in this respect, by helping its clients stay ahead of the curve and taking an offensive stance towards new ideas.