SAD assign4 :)

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process.

Developers worldwide will agree that building software takes more than just writing complex codes and implementing them in an environment. Developers usually start out their career in programming by developing programs or software according to their own plan and hope that someone will appreciate it. But once the developer is associated with a business or another software company, the creativity is limited to business and consumer needs. The pressure in creating accurate and efficient software is even bigger in the entrepreneurial stage.

To ensure developers have come up with the right software for the specific need, programmers have created steps on how a program could specifically created. This will ensure everything is built according to plan and tested extensively before it could be implemented for public or formal use in business. Under these circumstances the term “Systems Development Life Cycle” was born. The need to create accurate and efficient software has led to the formalization on certain stages and phases on how a program should be built.

Simply put, SDLC or Systems Development Life Cycle is a series of steps observed by developers on building specific software. Developers follow certain steps to ensure they have the right software for the right demand.

The history of the term “Systems Development Life Cycle” is very vague but it naturally came into being since the 1960s when developers started to create programs specific to a certain need. Slowly, the term has been observed by different software development companies. From a simple format of planning, building, testing and implementing, software companies have developed their own version of developing specific products for their clients. Each version of software development is called “Model”. As of this writing, there are 18 known software development models observed by differentsoftware development companies . These development models could be applied in a certain situation to ensure the product created is a success, since not all models could be used in a certain application. Skills and experience in software development will also dictate which model will work for software development.
There is a great temptation to just resign to the fact of creating software based on the problem. For example, the business needs a simple computing software embedded in their website. That is a simple problem that could be done by programmer, anytime. It is just a matter of using code to efficiently implement the software in a website.

But if you take a look at it deeply, there are steps that should be done before you can actually create the software. First you have to know what type of computing software and the components that should be added. Then they have to plan the actual codes that will be used and test it extensively before implementation. Without any of these steps, something will definitely go wrong once the program is implemented. With SDLC, software development companies or in-house developers will ensure the software released will have the following behaviors:

1. Software created are of high standard. Building a software is different from building a well built software. Anyone could create a software as there are available tools that does not even require a knowledge in extensive programming. But with SDLC, programmers have to look further than tapping in shortcuts to create a specific tool that the customer wants.

2. Project implementation and control will be easier. The role of developers does not end when the program is implemented. Even though a specific software is highly efficient when implemented, anything found wrong or a bug in the system should be worked on especially when the software did not go through beta testing. In this account, SDLC will ensure that controls of the software are stable. This is usually done be creating better documentation to guide the developers in controlling the specific function of a software.

3. Answer the need of the users or even exceeding their expectations. Every software that is created should answer the specific needs of their clients. Having a highly stable software will be nothing if the intended users cannot use the software. SDLC will make sure the needs are answered and could even provide more than they need. The steps they will be using are geared towards creating a software that is highly efficient as well as problem solving for better time management.

Although SDLC has different models, most of the models observe the following stages to ensure their software is a success.

1. Project planning, feasibility study. Developers have to study the market and know their needs. The theoretical plan of the software is created in this stage. Developers will conduct a study on how will this software affect the users and if there is an actual need for this software.

2. Systems analysis, requirements definition. After creating the theoretical plan and mapping out the need of the users, developers will have to sit down and determine the technical requirements in building the software. In this stage, developers will create a workflow that will be the basis of the actual design.

3. Systems design. Developers will now build the software based on the needs and the architectural plan of the software. Developers will either use a specific language to create a software or they could use an available component. This stage usually differentiates different models wherein some will actually use a specific language, some will use tools without the use of a specific language while other models will use the available components to create a software.

4. Implementation. As the software progresses, developers will need to test the software for proper implementation. Slowly the program is built from the scratch and each component is tested if the code or language used actually works.

5. Integration and testing. Once the software is completed, it will go through serious testing before integration to the actual working environment. The software will be placed on beta version. Usually the software will be available for selected users (closed beta) and gradually the software is opened for public use but will still be in beta version (open beta). Going from “closed beta” to “open beta” will test the software capability for simultaneous and multiple users. Bugs will be detected and developers can work on them before they are completely integrated on to the system.

6. Acceptance, installation, deployment. After a rigorous testing in beta version, the program is now ready to be used publicly. Complete installation of the program is offered with all the components applied.

7. Maintenance. Although the software is now stable it does not guarantee it will work properly at all times. But instead of looking out for bugs, developers will be reactive to the problem. The developers will only monitor the performance of the software and create the necessary adjustments to maintain the software.

8. Disposal phase. In course of time a software can no longer be required. A better software may take its place in the market, the software may no longer answer the concerns of its users or the project could not live according to the expectations, these are some of the reasons why a software should be disposed. Before actually disposing a software, Developers will have to inform its users in advance the discontinuation of support to the said product. Users, then will have the option to uninstall or disregard the software completely. In a software development environment, the disposal phase usually means another system is in the works to replace the software said to be disposed.


SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results.

THE WATERFALL MODEL. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

The waterfall model is argued by many to be a bad idea in practice. This is mainly because of their belief that it is impossible for any non-trivial project to get one phase of a software product's lifecycle perfected, before moving on to the next phases and learning from them.

For example, clients may not be aware of exactly what requirements they need before reviewing a working prototype and commenting on it; they may change their requirements constantly. Designers and programmers may have little control over this. If clients change their requirements after the design is finalized, the design must be modified to accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means increased cost, especially if a large amount of the projects resources has already been invested in Big Design Up Front.

Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas.

The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. As a solution can serve some "investment of man-time", ordering some experienced developer to spend time on refactoring, to consolidate the SW back together. Another approach is to prevent these needs by a predicting design, targeting modularity with interfaces.

THE SPIRAL MODEL. The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement". This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.

As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects.

THE AGILE SOFTWARE DEVELOPMENT. Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features.

Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.
Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.