SdLC Phases and Software Process Models PDF

CHAPTER#2: SDLC Phases and Software Process Models Prepared by Prof. Dr. M. Alper TUNGA  Agenda Phases of SDLC Software Process Models 2  Software Development Life Cycle Software Development Life Cycle (SDLC) is a process of...

CHAPTER#2: SDLC Phases and Software Process Models Prepared by Prof. Dr. M. Alper TUNGA  Agenda Phases of SDLC Software Process Models 2  Software Development Life Cycle Software Development Life Cycle (SDLC) is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems. 3  Phases of SDLC Planning Requirements Analysis Software Design Development Testing Deployment Maintenance 4  SDLC – Planning Phase This is the phase where a project plan that identifies the high level activities, work items, schedule, resources and cost is developed.  This plan is a rough estimate that needs to be modified and adapted throughout the lifetime of the project. 5  SDLC – Planning Phase The main GOAL is to formulate a plan to produce the target software application. The important OUTPUT is the Software Project Management Plan (SPMP). The involved STAKEHOLDERS are owners, managers, analysts, users. 6  SDLC – Planning Phase Activity: A problem statement including problems (issues that need corrective actions), opportunities (situation improvement despite the absence of complaints), directives (situation change regardless of whether anyone has complained about the current situation) and constraints (restrictions on the actions of the project team) is assigned. 7  SDLC – Planning Phase Project Constraints  Schedule: The new system must be operational by April 15.  Cost: The new system cannot cost more than $350,000.  Technology: The new system must be web-enabled.  Policy: The new system must bill customers every 15 days. 8  SDLC – Planning Phase Activity: Initial product ideas are formulated to clarify what is to be built. Activity: A vision of the software is defined to clarify what an organization wants to achieve over time. Activity: Target customers and market segments are identified to discuss if the target application is feasible to implement. 9  SDLC – Planning Phase Activity: Major functionality and project scope is defined to clarify the boundaries of the project.  project goals,  deliverables,  tasks,  costs,  deadlines 10  SDLC – Planning Phase The Software Project Management Plan covers  Vision and scope definitions,  High level user requirements,  Initial feasibility analysis,  Phases, activities, tasks and deliverables,  Resources,  Schedule estimations,  Cost estimations 11  SDLC – Requirements Analysis Phase This is the phase where the user expectations are determined for a new or a modified software product.  Requirements are the specifications that define the user expectations.  Requirements describe what the application is intended to accomplish.  Requirements are presented using use case modeling with scenarios and a diagram. 12  SDLC – Requirements Analysis Phase The main GOAL is to identify the user and business requirements for the target application. The important OUTPUT is Software Requirements Specification (SRS) document. The involved STAKEHOLDERS are owners, managers, analysts, users. 13  SDLC – Requirements Analysis Phase Activity: The problems are identified and analyzed to find out the root cause.  Problem discovery – Ishikawa (Fishbone) diagram Activity: Actors are specified.  An actor is anyone or anything that needs to interact with the system to exchange information. 14  SDLC – Requirements Analysis Phase Activity: Data are collected from the actors of the target application to understand what they want and need.  Requirements discovery  Data collection techniques are sampling, research, observation of the work environment, applying questionnaires, conducting interviews, prototyping, organizing brainstorming meetings. 15  SDLC – Requirements Analysis Phase Activity: Requirements are generated.  Business requirements  Stakeholder requirements  Solution requirements 16  SDLC – Requirements Analysis Phase Activity: Use case scenarios are prepared.  A use case is a single unit of meaningful work ❖ Business event  A use case scenario is a textual description of the business event and how the actors will interact with the system to accomplish the task. 17  SDLC – Requirements Analysis Phase Activity: User stories are prepared.  A user story is a documented description of a software feature seen from the end-user perspective.  User stories are part of an agile approach. 18  SDLC – Requirements Analysis Phase Activity: A use case diagram is drawn.  A use case diagram is a UML behavior diagram that represents the interactions between the system and external systems and users. 19  SDLC – Software Design Phase This is the phase where the internal structure of the software is defined in terms of modules, interfaces, databases, algorithms, and data structures. There are two levels of software design  Software architecture design,  Detailed design 20  SDLC – Software Design Phase Software architecture design specifies how the software is broken into subsystems or modules and the software interfaces between them.  Class model, data model, use case model, process model, state model Software architecture design translates the requirements in words into pictures  UML and some other diagrams 21  SDLC – Software Design Phase Detailed design specifies algorithms and data structures. Detailed design translates the requirements into a system model that depicts a technical implementation of user requirements.  Data types, data constraints, input types, output types, algorithm types, data structure types 22  SDLC – Software Design Phase The main GOAL is to define how the software will be constructed to satisfy the requirements. The important OUTPUT is Software Design Document (SDD). The involved STAKEHOLDERS are managers, analysts, designers, users. 23  SDLC – Software Design Phase Activity: Draw UML diagrams  Class, Component, Deployment, Object, Package, Profile, Composite Structure, Use Case, Activity, Sequence, State Machine, Communication, Interaction Overview, Timing 24  SDLC – Software Design Phase Activity: Draw E-R diagram Activity: Draw data flow diagrams Activity: Construct decision tables 25  SDLC – Development Phase This is the phase where programming occurs and integration is involved.  Programming is the translation of the software design to a programming language.  Integration is the assembly of the software parts (mounting) 26  SDLC – Development Phase The main GOAL is to build a system that fulfills the requirements and specifications and to implement the necessary interfaces. The important OUTPUT is the program code that is ready to be tested for correctness. The involved STAKEHOLDERS are managers, analysts, designers, builders, users. 27  SDLC – Development Phase Activity: Implement the source code of the individual modules. Activity: Implement the interfaces. Activity: Integrate the software parts. 28  SDLC – Testing Phase This is the phase where the code produced during the implementation phase is tested for correctness. The main GOAL is to test the system that fulfills requirements and specifications. The important OUTPUT is a tested system that is ready for the installation. The involved STAKEHOLDERS are managers, analysts, designers, builders, testers, users 29  SDLC – Testing Phase Activity: Unit testing is performed.  Individual models are tested. Activity: Integration testing is performed.  Modules are integrated and tested to ensure that they interface properly. 30  SDLC – Testing Phase Activity: Regression testing is performed.  It is confirmed that a recent program or code change has not adversely affected existing features. Activity: System testing is performed.  The entire system is tested to ensure that it meets the user requirements. 31  SDLC – Testing Phase Activity: User testing is performed.  Beta testing ❖ The software is as close to the final release as possible at this level. ❖ The goal is to uncover problems that could only be discovered by the users. ❖ Conducted by the users – Real world testing  Acceptance testing ❖ Process of verifying that a solution works for the user ❖ Conducted by the project owner once beta testing is complete ❖ Performed on the software to ensure that the application meets the customer's criteria for release. 32  SDLC – Deployment Phase This is the phase where the product is put into production.  After the project team tests the product, the product passes each testing phase, and the product is accepted by the user, the product is ready to go live.  This means that the product is ready to be used in a real environment by all end users of the product. This is the final phase of the software development life cycle (SDLC) 33  SDLC – Deployment Phase The main GOAL is to make the system or system modifications operational in a production environment. The important OUTPUTS are delivered system, release/version description document and trained users. The involved STAKEHOLDERS are managers, analysts, builders, users. 34  SDLC – Deployment Phase Activity: New deployment is communicated to the users.  The schedule of the deployment  A brief description of the benefits of the new system  The difference between the old and new system  Responsibilities of end user affected by the deployed changes  The process to obtain technical support, including contact names and phone numbers 35  SDLC – Deployment Phase Activity: Training plan is executed. Activity: Data entry and/or data conversion is executed. Activity: The system is installed.  First, install the system in a production environment to ensure that it is fully operational.  Then, install the system to the working environment. 36  SDLC – Deployment Phase Activity: Post-deployment review is conducted.  to document deployment experiences,  to recommend system enhancements  to provide guidance for future projects,  to document any user request for a change to a system. 37  SDLC – Deployment Phase Activity: Previous documentation is revised.  All relevant documents need to be reviewed and updated taking into consideration changes introduced by the project.  Report documentation should always reflect current state of the report. ❖ production version of the documentation 38  SDLC – Maintenance Phase This is the phase where modifications are made to the software after the release of that software.  The repair of software defects that are discovered during normal customer use of the system,  Customer requests for enhancements,  A desire to improve attributes of the system such as performance, reliability, etc. 39  SDLC – Maintenance Phase The main GOAL is to support the released software during its life cycle in terms of fixing defects and making improvements. The important OUTPUTS are the outputs of the related phases. The involved STAKEHOLDERS are the stakeholders of the related phases. 40  Software Process Models Software Process is a set of activities, methods, practices, deliverables, and automated tools that stakeholders use to develop and continuously improve ISs and software.  Prescribes the interrelationship among the phases by expressing their order and frequency,  Specifies criteria for moving from one phase to the next,  Defines the deliverables of the project. 41  Software Process Models There are several software process models  The waterfall process model  The iterative development model  Prototyping  Spiral model  Agile development model 42  The Waterfall Process Model The waterfall executes in a sequential manner through each phase.  Each phase is completed one after another.  A phase is not started until the previous one has completed.  Each phase is executed only once.  The output from one phase is used as input for the next phase. 43 The Waterfall Process Model 44  The Waterfall Process Model In practice, an iterative relationship between successive phases must be defined.  Feedback loops must be defined between adjacent phases 45  The Waterfall Process Model Advantages:  Simple and easy to use – phases are executed and completed serially.  Practiced for many years – people have much experience with this process.  Easy to manage – each phase has specific deliverables.  Facilitates allocation of resources – due to sequential nature of phases.  Works well for smaller projects – requirements are very well understood. 46  The Waterfall Process Model Disadvantages:  Requirements must be known up front – projects start out with some uncertainty.  Hard to estimate reliably – projects start out with some uncertainty.  Major problems are not discovered until late in process – the testing phase is where these problems are found.  Lack of parallelism – each phase is executed to completion.  Inefficient use of resources – team members can be idle while waiting for others to complete their tasks. 47  The Waterfall Process Model The problem arises when the process is scaled up to  gather all the requirements, then  do all of the design, then  implement all of the code, then  test all of the system. 48  The Waterfall Process Model Solution:  The software can be developed in a cyclical manner ❖ a part of the software is developed and tested, then ❖ feedback is gathered, then ❖ based on the feedback more of the software is developed, then ❖ … ==> Iterative Development 49  The Iterative Development Model Iterative development completes the entire information system in successive iterations. Each iteration does some analysis, some design, some development, and some testing. 50 The Iterative Development Model 51  The Iterative Development Model An iterative process is a repeated execution of the waterfall process resulting in a refinement of the requirements, design, implementation, and testing. The iterations can be developed in parallel by separate teams. Iterations need not be executed serially. 52  Agile Development Model Highly iterative process. The purpose is to speed up development and effectively respond to change. 53  Agile Development Model The agile process model employs the following:  Small teams  Periodic customer requirements meetings  A code-centric approach ❖ Documentation on an as-needed basis (high level requirements only) 54  Agile Development Model The agile process model employs the following:  The use of user stories as the basis for requirements  Refactoring ❖ Restructuring an existing body of code, altering its internal structure without changing its external behavior. 55  Agile Development Model The agile process model employs the following:  Pair programming ❖ Two programmers work together at one workstation. ❖ One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in.  Continual unit testing and acceptance tests ❖ To set customer expectations 56  Agile Development Model The basis of agile development model:  Highly skilled individuals and interactions over processes and tools ❖ Highly skilled individuals get the jobs done quickly and efficiently.  Working software over comprehensive documentation ❖ Producing working code at the end of each iteration helps to get representative product and provide timely feedback. 57  Agile Development Model The basis of agile development model (cont.):  Customer collaboration over contract negotiation ❖ Keeping as close as possible to the customer helps to change direction quickly.  Responding to change over following a plan ❖ Short iterations to provide timely feedback gets the project team ready to respond necessary changes in the project plan. 58  Agile Development Model Advantages:  The project always has demonstrable results – the product of each iteration is working software.  Developers tend to be more motivated – developers do not like creating documentation.  Customers are able to provide better requirements – customers can see the evolving project. 59  Agile Development Model Disadvantages:  Problematical for too small and too large projects.  Documentation output is questionable – documentation takes second place 60  Agile Development Model Two important agile methodologies:  Extreme Programming (XP)  Scrum 61  Extreme Programming (XP) XP aims to provide iterative and frequent small releases throughout the project, allowing both team members and customers to examine and review the project’s progress throughout the entire SDLC. The Quarterly Cycle is synonymous to a release.  The purpose is to keep the detailed work of each weekly cycle in context of the overall project. 62  Extreme Programming (XP) The weekly cycle is synonymous to an iteration.  The team meets on the first day of each week ❖ to reflect on progress to date, ❖ to allow the customers to pick the stories they would like delivered in that week, ❖ to determine how they will approach those stories.  The goal by the end of the week is to have running tested features of the target product. 63  Extreme Programming (XP) Extreme Values  Communication ❖ Everyone is part of the team and there is a communication face to face daily.  Simplicity ❖ What is the simplest thing that will work? ❖ Do what is needed and asked for, but no more. 64  Extreme Programming (XP) Extreme Values (cont.)  Feedback ❖ Take every iteration commitment seriously by delivering working software. ❖ Demonstrate the software early and then listen carefully and make any changes needed.  Respect ❖ Everyone gives and feels the respect they deserve as a valued team member. ❖ Everyone contributes value even if it’s simply enthusiasm. 65  Extreme Programming (XP) Extreme Values (cont.)  Courage ❖ Tell the truth about progress and estimates. ❖ Do not document excuses for failure because the plan is to succeed. ❖ Adapt to changes when ever they happen. 66  Extreme Programming (XP) Extreme Practices  The Planning Game ❖ Planning for the project – Release Planning, Iteration Planning  Small Releases ❖ Producing a working product at the end of each iteration ❖ Allows the customer as well, as all team members, to get a sense of how the project is developing 67  Extreme Programming (XP) Extreme Practices (cont.)  System Metaphor ❖ The idea that every person on the team should be able to look at the high-level code that is developed, and have a clear understanding of what functionality that code is performing.  Simple Design ❖ Do not complicate things whenever a simpler option is available. 68  Extreme Programming (XP) Extreme Practices (cont.)  Test-driven Development ❖ Instead of following the normal path which is develop code -> write tests -> run tests, follow the path: Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat.  Refactoring ❖ Improve and redesign the structure of already existing code, without modifying its fundamental behavior. 69  Extreme Programming (XP) Extreme Practices (cont.)  Pair Programming ❖ Two people work in tandem on the same system when developing any production code  Collective Ownership ❖ Allows for any developer across the team to change any section of the code, as necessary. 70  Extreme Programming (XP) Extreme Practices (cont.)  Continuous Integration ❖ All code developed across the entire team is merged into one common repository many times a day. ❖ This ensures that any issues with integration across the entire project are noticed and dealt with as soon as possible. 71  Extreme Programming (XP) Extreme Practices (cont.)  Whole Team ❖ XP promotes the inclusion of customers and clients throughout the entire process, using their feedback to help shape the project at all times.  Coding Standard ❖ Promotes better understanding and readability of the code not only for current members, but for future developers as well. 72  Extreme Programming (XP) Extreme Practices (cont.)  Sustainable pace ❖ Nobody should be required to work in excess of the normal scheduled work week. ❖ 40-hour week ❖ Developers are expected to work extreme hours near the end of a release to get everything completed on time. 73  Extreme Programming (XP) Extreme Rules  Planning ❖ User stories are written. ❖ Release planning creates the release schedule. ❖ Make frequent small releases. ❖ The project is divided into iterations. ❖ Iteration planning starts each iteration. 74  Extreme Programming (XP) Extreme Rules (cont.)  Managing ❖ Give the team a dedicated open work space. ❖ Set a sustainable pace. ❖ A stand up meeting starts each day. ❖ Move people around. 75  Extreme Programming (XP) Extreme Rules (cont.)  Designing ❖ Simplicity ❖ Choose a system metaphor ❖ Create spike solutions to reduce risk. ❖ No functionality is added early. ❖ Refactor whenever and wherever possible. 76  Extreme Programming (XP) Extreme Rules (cont.)  Coding ❖ The customer is always available. ❖ Code must be written to agreed standards. ❖ All production code is pair programmed. ❖ Integrate often. ❖ Set up a dedicated integration computer. ❖ Use collective ownership. 77  Extreme Programming (XP) Extreme Rules (cont.)  Testing ❖ All code must have unit tests. ❖ All code must pass all unit tests before it can be released. ❖ When a bug is found tests are created. ❖ Acceptance tests are run often and the score is published. 78  Scrum Project is broken into teams or scrums  No more than 6 – 9 members  Each team focuses on a self-contained area of work A scrum master is appointed  Responsible for conducting the daily scrum meetings, measuring progress, making decisions  A daily scrum meeting should last no more than 15 minutes. 79  Scrum At the beginning of a project, a list of customer wants and needs is created,  Called backlog.  Each item in the backlog is a user story. The scrum methodology proceeds 30-day cycles  Called sprints. 80  Scrum Each sprint takes on a set of features (stories) from the backlog for development At the end of a sprint, a customer demonstration is conducted for the customer  To show what has been accomplished  To ensure that the software is properly integrated and tested  To ensure that real progress is made on the project 81  References www.agilealliance.org https://airbrake.io/blog/sdlc/extreme-programming https://study.com/academy/course/index.html https://robertdblog.wordpress.com/sdlc-software-deployment-phase/ 82