Information Technology

Course Number: Y52.1240 Prof. George Pefanis Team Yankees Group Assignment #5 Submitted on: Thursday, August 12th, 2010 Submitted by: Sean Hennessey, Shelley Ann Maule, Joseph Xing Ng , Lois Mannon, Gisselle Escotto, Jyoti Bajaj, Janel Alexander Assignment: Part 1: Name each type of person involved in each phase of SDLC Part 2: Try to condense the seven phases of SDLC to five. What are the risks? Part 1

System Development Life Cycle (SDLC) Introduction The System Development Life Cycle (SDLC) is the process by which a new system is planned, created, implemented, and supported by building or changing information systems through development of modules and methodologies that people use to create these systems. The Life Cycle approach to system development recognizes the constantly evolving nature of systems, and respects the influence that time holds not only over the process of designing and implementing a system, but also how it can change ones perceptions of how a system can and should operate (Browning & Honour, 2007). As Browning and Honour (2007) conclude in their piece entitled Measuring the Life-Cycle Value of Enduring Systems, a key component in ensuring the high Life Cycle Value (LCV) of a systems development is flexibility: [in order] to provide maximum LCV, a system may need to be designed to facilitate adaptability to changing circumstances and stakeholder preferences (Browning & Honour, 2007, p. 187). In this sense, while the careful design and implementation of a system are vital components to consider in the life cycle of system development, so too is the planning for change and adaptability for the future needs of the end user and the organization as a whole. This paper will explore the different phases of SDLC, and how they relate to the process as a whole to each other. While each phase supports the whole,

the whole also supports each phase; one cannot exist without the other as every building block is as important to the whole as the next. Once the SDLC process is complete and a new system is in place, an organization is can able to look back at the different phases individual components of the SDLC process and see where there were successes and where improvements could have been made. Phase One- Planning The first phase in SDLC is the Planning phase and this creates a solid plan foundation for developing the system. There are multiple individuals that are involved with the process. After the Area Lead approves of the system, a Product Manager is appointed to lead the system development. Product Managers are given the task to define the system that will be developed. The system should support the strategic goals of the organization. Product Managers set the project scope to help avoid scope creep and feature creep. The project scope document is a written document that defines the high-level requirements of the system. Product Managers can select Project Managers (PM) to develop the project plan that defines the what, when, and who questions and includes all the required resources and tracking of the activities to be completed. PMs also define the project stakeholders are in the whole SDLC life-cycle. However, in smaller companies, the Product Managers may also fill the role of the PM and/or the Area Lead. The project plan includes milestones that indicate the key dates at which resources complete certain processes. Other duties of the PM can be creating an estimation model, indicating project risks, and creating project status reports for senior management. Also, the PM will update any document information with notes pertaining to the system as a whole to keep the project plan up-to-date.

Phase Two- Analysis The second phase of the SDLC is the analysis phase. This is where the scope of the project gets narrowed down to what is most important, what is achievable, what is unachievable (outside of scope) and how other factors will impact the scope of the project. It involves taking the large concepts and breaking them down into attainable parts. This phase involves an analyst (or a team of analysts) whose responsibilities include collecting, analyzing, and presenting information about the system to be developed. These analysts use several tactics to gather this information, which may include written documents, interviews, questionnaires, observations, and sampling. What is critical about this phase is the information that needs to reach down to the individual contributors at all levels that are involved with the system development. Written documents may work well to illustrate the current process and simply work to automate it, but more user interface such as interviews and observations may be needed if a more complex system currently exists or is being designed. Also, this part of the process also may include a request to change business processes related to the technology or not.

An analysis of the risks to the organization is also heavily evaluated in this phase. This piece of work is often referred to as risk assessment and includes, among other things, things like the financial impact to the organization, natural disasters, and increased traffic or loss of critical information or data. Once these factors have been captured, scenarios can be created to create workable solutions for the risks. Phase Three- Design The third phase of SDLC is the design phase. This phase of SDLC converts the planning and analysis phases business requirement information (documentation) into design specifications that will be used during the development phase. This phase is often considered the technical blueprint because during this phase the technical architect and system models are designed (plans for initial testing, conversion, implementation, and training may also be created during this phase as well as training and system maintenance manuals). Designers, developers, end users (i.e. management,; employees), database managers, and/or network administrators can be involved in these design phase as they are the team members that must review and ensure the technical blueprint is aligned with the systems business requirements. Also, they are usually the team members signing off on the designs. As needed, also, audit, quality assurance, and/or security employees may also get involved, as needed, in the review and approval process. Phase Four- Development The fourth phase of SDLC is the development. Within the Development phase, the Development Team Leaders possess a broad knowledge of software infrastructure tools used for SDLC with recommended mastery in active server pages (ASP), Java, data mining, and various programming languages. The Development Team Leads are experienced individuals responsible for overseeing the developers. They are responsible for leading the development phase, the delivery of code, and release features as well as functionality. Developers are software engineers proficient in knowledge of SDLC, programming codes, and system modules. They and also operate under the direction of a Development Team Leader and they write code and pre-quality assurance test the code.

Phase Five- Testing Within the testing phase, testing with the users must be performed before an implementation can occur to document carefully any issues that may arise from a users standpoint. The users also must be trained and any existing data have to be migrated over to the new system. In order to mitigate new issues rigorous testing must occur to catch errors during the implementation stage, as it is easier to correct problems earlier in the developmental process. Quality assurance analysts can be involved to test and detect potential system issues to avoid later issues. Poor quality testing can result from inaccurate requirements, design problems, coding error, faulty documentation and ineffective testing. To achieve standards of quality, software systems developers should consider software engineering concepts. Quality is extremely important to software engineering and should be used to manage and improve the quality of the information system completed project. A software development process that stresses solid design, accurate documentation and careful testing is necessary. Furthermore, what is required is user documentation, which gives instruction and information to users who will interact with the system and may include user manual and tutorials. Also webinars (which is an internet-based training sessions), webcasts (one-way transmission used when users wants or needs training support), and/or pod casts (web based broadcast that allows a user to receive audio or multimedia files) that provides an interactive experience can be useful tutorials and/or system training/technical support mechanisms. In addition, a testing review or structural walk through is performed. To review the project team members work by other members of the team, generally system analysts review the work of other systems analyst and programmers review the work of other programmers, as a form of peer review. Structural walk through take place through-out the SDLC and are called requirements reviews, design reviews, code reviews or testing reviews depending on the phase in which they occur. Phase Six- Implementation Implementation involves the preparation for the implementation of a new system, the actual implementation itself, and support for the newly implemented system (Wikipedia, 2010). Such support will include not only troubleshooting problems that occur during and after implementation, but also the careful documentation of best practices, and how-to prior to the roll-out to the end user (Haag & Cummings, 2008). The documentation created prior to the roll-out will be of great use to the end-user and to administrators alike, as the end user appreciates it as a guide, and administrators can keep the best-practices as a

record of how the system should best be used, or perhaps modified going forward. The training required for the end user as the system is implemented can be offered in a variety of ways depending both on the type or complexity of the system and on the preferences of the end user (Haag & Cummings, 2008). The best way to train end users will depend on the system being implemented, the dynamic of a particular office or department, and the individual end users schedule and preferences (Haag & Cummings, 2008). The process of implementation goes far beyond simply introducing a system to the end user, rather it is a period, often of several months, over which the new system is tested and support is provided to work out any problems that might be encountered.(Meneklis, 2010). Since implementation often occurs across on a large scale, and across various departments and offices, the problems that one might encounter in this phase are as varied as the departments the system hopes to serve (Meneklis, 2010). The implementation process, then, necessarily differs depending on the particularities of each department that seeks to use a new system, and the process of implementation will be unique for each environment in which the new system is implemented (Meneklis, 2010). Some types of implementation described by Haag & Cummings (2008) are:

Parallel implementation - where both old and new systems remain live until it is clear the new system performs correctly. Plunge implementation - where the old system is immediately expunged and the new system is used exclusively. Pilot implementation - where only a small group of users are selected to use the new system while the majority continues to use the old system; the latter being added as the pilot group finds the system fit to use. Phased implementation - where the system is implemented in phases, for example office by office, or department by department. Once it is clear that the system works perfectly, it can be rolled out on a wider basis.

Since it will depend on the system being implemented and on an organizations structure, the way in which a system is to be implemented will require careful consideration. Phase Seven- Maintenance Maintenance is primarily a reactive process where developers try to find ways in fixing problems. There will always be a time where a bug or the lack of a certain process hinders the proper execution of the software. Developers will take a look at the problem and possibly create an answer to the concern. But maintenance does not end there for SDLC. Developers always conduct a preventive maintenance for their software. There are also companies that adhere to the idea of constant monitoring to ensure that the software works well.

Although any developer would not wish for a problem, it poses a great opportunity to learn more about the industry and release updates to combat problems once and for all. The end result of constant updates will be better software that can adapt to the changing environment. When a business spends thousands of dollars on project development, they expect more from the software. Maintenance will ensure that the software will last for a very long time. Conclusion In summary, there are risks to combining the SDLC process and this consolidation should be done by senior level personnel who understand there is some overlap of phases. The sequential process of SDLC puts emphasis on the structure, planning, delivery dates, timing and budgets in order to launch the deliverable on time. The limitation of this process is it tends to be slow because of its structure and controls. In large projects where there are many changes, external or internal, the process can not adapt well due to its strict constraints. SDLC should be viewed as an approach with different methodologies being suited to specific kinds of projects. This suitability is based on the types of projects, organizational considerations, as well as project and team considerations.

Part Two The SDLC has several methods of deployment. The most thorough of these is the waterfall method which involves all seven steps being performed individually. Some of the steps of the waterfall process for SDLC could be combined to create more of a RAD (Rapid Application Development) approach. These are the planning and analysis phases and the design and development phases. The planning and analysis phases could be combined into a single phase. The plan for the system would be created including milestones, dates and tactical requirements. At the same time the analysis of what the requirements are for the system could be worked into this plan. This approach has both the planning and the details of what the system will achieve factored in simultaneously. The design and development phases could be combined so that as the technical blueprint is developed for each requirement, the code for the system is simultaneously written to support it. Combining any of the steps in the process individually creates the same set of risks and benefits. The benefits of this approach are that combining some of these phases can lead to a more robust scheme. The overall project can best be broken into modules that can be tackled in a two phase approach simultaneously. This combination also allows the different steps to work in

conjunction with each other. The risks of combining these steps would be the same for combining any of the phases. Premature decisions might be made before the proper analysis of each step is performed. For example, in the combined design/development phase-the maximum set of design options might not be thoroughly considered before jumping to the development of these designs. Proper time must still be reserved by each team of people to thoroughly flush out the individual steps of the life cycle. Time may also be wasted in a large amount of rework when any of the phases are combined if changes are made in direction. Also, there is the financial risk to steps being combined. More rework or backtracking if the project takes a different direction will ultimately become more costly. It may also cost more to have different teams of people working in teams on the combined steps simultaneously instead of separating them out to focus on their individual parts. For example, developers may have no role in the design phase-but are forced to work together or wait for their part in the process when these two steps are combined. Combining Design and Development Risks

Risk of starting to write code with no clear plan or format from the design phase Code could be written that would not support the functionality of the program as a whole Performing analysis in conjunction with design could lead to premature decisions being made without the proper analysis

Benefits

Project can be broken into modules and as analysis is done, the technical blueprint is written

System Development Life Cycle: 7 phases to 5 phases diagram Phase 1: Planning and Analysis Phase 2: Design and Development Phase 3: Testing Phase 4: Implementation Phase 5: Maintenance

Two diagrams were created to illustrate our point: Option 1:

Once the initial part of phase 2 is complete, the testing, implementation, and maintenance phases are carried out. Later on in the system's life when changes need to be made this diagram depicts how phases 2, 3, 4, and 5 are a continuous cycle that work together to ensure successful system changes.

Option 2:

This diagram illustrates how each phase is separate and the approach is like a ladder Once a phase is complete, the other phase begins.

References:

Browning, T. & Honour, E. (2007). Measuring the Life-Cycle Value of Enduring Systems. Systems Engineering, Vol. 11, No. 3. Haag, S. & Cummings, M. (2008). Management Information Systems for the Information Age. New York: McGraw-Hill. Management Information Systems textbook: Chapter 5: Phase 3: Design section Meneklis, V. (2010). Bridging theory and practice in e-government: A set of guidelines for architectural design. Government Information Quarterly, 70-81. Rosenblatt-Cashman, Shelly, Thomas J. Cashman, Harry J. Rosenblatt, Systems Analysis and Design, Seventh Edition. http://www.computerfreetips.com/main_page/System_Analysis.html http://www.startvbdotnet.com/sdlc/sdlc.aspx http://www.ffiec.gov/ffiecinfobase/booklets/d_a/08.html http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle#Design http://www.justice.gov/jmd/irm/lifecycle/ch8.htm#para8 http://www.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopme ntApproach.pdf http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle#cite_note-4 http://www.learn.geekinterview.com/it/sdlc/software-maintenance.html http://www.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopme ntApproach.pdf http://www.google.com/imgres?imgurl=http://www.f14testing.com/wpcontent/uploads/2010/02/waterfall_model1.png&imgrefurl=http://www.f14testing.c om/%3Fp %3D550&h=396&w=515&sz=20&tbnid=Y52LWdJirHiX3M:&tbnh=101&tbnw=131 &prev=/images%3Fq%3Dwaterfall%2Bmodel %2Bdiagram&hl=en&usg=__M2iiKyTmvLn47tXwFOfCLgOHjaQ=&sa=X&ei=Awt ZTIuNE42gnQftjNzaCA&ved=0CBsQ9QEwAQ http://www.learn.geekinterview.com/it/sdlc/sdlc-stages.html