01-IntroToSDLCAndAgile.pdf

Introduction SE3352 - Fall2022 by Shaimaa Ali, PhD 1 Software Engineering is more than writing Code SE3352 - Fall2022 by Shaimaa Ali, PhD 2   Problem solving Software  Creating a solution Engineering is  Engineering a system based on...

Introduction SE3352 - Fall2022 by Shaimaa Ali, PhD 1 Software Engineering is more than writing Code SE3352 - Fall2022 by Shaimaa Ali, PhD 2   Problem solving Software  Creating a solution Engineering is  Engineering a system based on the solution more than  Modeling writing Code  Knowledge acquisition  Rationale management SE3352 - Fall2022 by Shaimaa Ali, PhD 3   The ‘Ad Hoc’ approach was used before computer programs evolved into software systems. Software Engineering is  A software system is a complicated artifact with multiple components interacting with each other. more than writing Code  The creation of such system is a ‘process’ of defined activities and tasks. SE3352 - Fall2022 by Shaimaa Ali, PhD 4 The objective Real System Computerized System of SE SE3352 - Fall2022 by Shaimaa Ali, PhD 5 The objective Computerized System Real System of SE Vaguely / ambiguously described in plain human language SE3352 - Fall2022 by Shaimaa Ali, PhD 6 The objective Computerized System Real System of SE Very specific, Vaguely / written in ambiguously programming described in plain language human language SE3352 - Fall2022 by Shaimaa Ali, PhD 7  Various activities that involve modeling certain aspects of the system are performed to move us from the vague to the specific The objective Computerized System Real System of SE Very specific, Vaguely / written in ambiguously programming described in plain language human language SE3352 - Fall2022 by Shaimaa Ali, PhD 8 The objective Requirements & Implementation Analysis & testing Real System Computerized System of SE System & Object Very specific, Vaguely / Design written in ambiguously programming described in plain language human language SE3352 - Fall2022 by Shaimaa Ali, PhD 9 The objective Requirements & Implementation Analysis & testing Real System Computerized System of SE System & Object Very specific, Vaguely / Design written in ambiguously programming described in plain language human language SE3352 - Fall2022 by Shaimaa Ali, PhD 10 The objective Requirements & Implementation Analysis & testing Real System Computerized System of SE System & Object Very specific, Vaguely / Design written in ambiguously programming described in plain language human language This arrow is to indicate the objective but the real application of the process is never linear SE3352 - Fall2022 by Shaimaa Ali, PhD 11  Requirement Elicitation Requirements Testing Analysis Software Development Life Cycle (SDLC) Implementation System Design Object Design SE3352 - Fall2022 by Shaimaa Ali, PhD 12  Requirements Elicitation Requirements Testing Analysis Software Development Life Cycle (SDLC) Implementation System Design Object Design If you google SDLC you would see several variations of this, however, they all include similar activities SE3352 - Fall2022 by Shaimaa Ali, PhD 13  What Verify it’s needs to doing Requirement be done? what it is Elicitation supposed to Requirements Testing Analysis Software Development Life Cycle Do it. (SDLC) Implementation System Design Object Design How If you google SDLC you would see would it be several variations of this, however, done? they all include similar activities. SE3352 - Fall2022 by Shaimaa Ali, PhD 14  Requirement Elicitation Requirements Testing Analysis Software Development Life Cycle (SDLC) Implementation System Design Object Design Generally the “Cycle” part is to indicate that it’s not linear SE3352 - Fall2022 by Shaimaa Ali, PhD 15   Requirements Elicitation  Requirements Analysis  System Design Software  Object Design Engineering  Implementation Activities  Testing SE3352 - Fall2022 by Shaimaa Ali, PhD 16  Requirements Engineering  Requirements Elicitation  Requirements Analysis  System Design Software  Object Design Engineering  Implementation Activities  Testing SE3352 - Fall2022 by Shaimaa Ali, PhD 17  Requirements Engineering Has major overlap  Requirements Elicitation with Business Analysis (BA)  Requirements Analysis  System Design [When the solution of the current problem Software  Object Design is to create or update a software system] Engineering  Implementation Activities  Testing SE3352 - Fall2022 by Shaimaa Ali, PhD 18  Requirements  Requirements Elicitation Engineering  Requirements Analysis  System Design Software  Object Design Architecture Design Engineering  Implementation Activities  Testing SE3352 - Fall2022 by Shaimaa Ali, PhD 19 Software Development “Management” Models SE3352 by Shaimaa Ali The earliest ‘model’: build-and-fix SE3352 by Shaimaa Ali The stage- wise and classical waterfall models SE3352 by Shaimaa Ali  Two problems with this approach The stage- wise and classical waterfall models SE3352 by Shaimaa Ali  Two problems with this approach The stage- wise and classical waterfall models The user’s and our understanding of the problem my be unclear until later stages of the development SE3352 by Shaimaa Ali  Two problems with this approach The stage- wise and classical waterfall models The problem itself The user’s and our understanding of the may change overtime problem my be unclear until later stages of the development SE3352 by Shaimaa Ali  Can be useful only if you are confident that you fully The understand the requirements of the system or they have stage- already been provided to you in an wise and unambiguous way by the client classical waterfall models SE3352 by Shaimaa Ali The incremental model SE3352 by Shaimaa Ali   The waterfall and incremental models can be used in projects where the problem is well defined, the requirements can be clearly elicited and defined, and the technical The feasibility of a solution is understood. incremental model  However, in many projects it is often difficult to pin down exactly what is required from a software system at the start of the project and/or we may not have a clear understanding of the technical issues surrounding that system. SE3352 by Shaimaa Ali  In case of working on a new project or field it is useful to produce a prototype in order to:  explore the requirements of the system with the user – requirements capture; Prototyping  explore the concepts for a proposed system – conceptual prototyping;  explore the technical feasibility of a system – experimental prototyping. SE3352 by Shaimaa Ali  In case of working on a new project or filed it is useful to produce a prototype in order to: Throw-away prototyping  explore the requirements of the system with the user – requirements capture; Creating a prototype with  explore the concepts for a proposed system – conceptual prototyping; the intention to throw it  explore the technical feasibility of a system – away experimental prototyping. SE3352 by Shaimaa Ali  In case of working on a new project or filed it is Advantages: useful to produce a prototype in order to: Throw-away Something tangible is produced quickly which keeps you and your user happy. prototyping  explore Thethe requirements tangible ofsystem nature of the the system with helps the user to the user – requirements clarify capture; their ideas and refine their requirements. Creating a Misunderstandings, errors and omissions in the requirements can be sorted out. prototype with  explore the concepts for a proposed system – It improves conceptual communication with the user. It is easier prototyping; the intention to look at a working model than a document. to throw it The prototype can test the feasibility and usefulness  explore theproduct. of the technical feasibility of a system – away Alternatives experimental prototyping. can be compared using different prototypes. SE3352 by Shaimaa Ali  In case of working on a new project or filed it is Advantages: useful to produce a prototype in order to: Throw-away Disadvantages Something tangible is produced quickly which keeps The throw-away prototype might look messy, unsophisticated prototyping and  explore you and your user happy. contain bugs. the This might give of requirements a bad theimpression system to the user. with The tangible nature of the system helps the user to Thethe useruser might– think your prototype requirements is really good and may want capture; clarify their ideas and refine their requirements. you to develop it into the final system, even though you had Creating a Misunderstandings, errors and omissions in the intended to throw it away. Then you will end up building your requirements can be sorted out. prototype  explore final system the concepts on perhaps forstructured poorly a proposedcode.system – It improves conceptual communication with the user. It is easier prototyping; If you develop the throw-away prototype on a different system or with the to look at a working model than a document. in a different programming language you may not spot a The prototype can test the feasibility and usefulness intention to technical issue that will be difficult/impossible to overcome on  explore theproduct. of the technical feasibility of a system – the target system. throw it away Alternatives experimental prototyping. can be compared using different It can take a lot of effort and commitment to develop something prototypes. that you are eventually going to discard. SE3352 by Shaimaa Ali Evolutionary Prototyping Creating a prototype with the intention to build on SE3352 by Shaimaa Ali  Approaches to software development that Agile reduce risk by delivering software systems Methodologies in short releases. SE3352 by Shaimaa Ali  The evolutionary prototyping approach and incremental model introduced in the previous Agile sections are, from a process point of view, agile Methodologies methods. SE3352 by Shaimaa Ali   Created in 2001 by 17 experienced software developers including the two Scrum founders Ken Schwaber and Jeff Sutherland,  Formed the central values of agile software The Agile development. Manifesto  The Manifesto includes a set of value pairs.  In each pair the value on the left should be given higher priority than the value on the right  agilemanifesto.org SE3352 by Shaimaa Ali  Individuals and interactions over processes and tools Working software over comprehensive documentation The Agile Manifesto Customer collaboration over contract negotiation Responding to change over following a plan SE3352 by Shaimaa Ali  Individuals and interactions over processes and tools Working software over comprehensive documentation The Agile Manifesto Customer collaboration over contract negotiation Responding to change over following a plan Agile Alliance backed up the Manifesto with the twelve principles. SE3352 by Shaimaa Ali  Twelve Agile Principles behind the Manifesto 1- Satisfy the customer: Our highest The Agile priority is to satisfy the customer Manifesto through early and continuous delivery of valuable software.  Twelve Agile Principles behind the Manifesto 2- Welcome changing requirements changing requirements, even late in The Agile development. Agile processes harness Manifesto change for the customer's competitive advantage.  Twelve Agile Principles behind the Manifesto 3- Deliver frequently: Deliver working software frequently, from a couple of The Agile weeks to a couple of months, with a Manifesto preference to the shorter timescale.  Twelve Agile Principles behind the Manifesto 4-Cross-functional and cross-divisional The Agile collaboration: Business people and Manifesto developers must work together daily throughout the project.  Twelve Agile Principles behind the Manifesto 5- Provide support and trust: Build projects around motivated individuals. The Agile Give them the environment and support Manifesto they need and trust them to get the job done.  Twelve Agile Principles behind the Manifesto 6- Personal communication: The most The Agile efficient and effective method of Manifesto conveying information to and within a Development Team is face-to-face conversation.  Twelve Agile Principles behind the Manifesto 6- Personal communication: The most The Agile efficient and effective method of Manifesto conveying information to and within a Development Team is face-to-face conversation.  Twelve Agile Principles behind the Manifesto The Agile 7- Working Software: Working software Manifesto is the primary measure of progress.  Twelve Agile Principles behind the Manifesto 8-Sustainable pace: Agile processes The Agile promote sustainable development. The Manifesto sponsors, developers, and users should be able to maintain a constant pace indefinitely.  Twelve Agile Principles behind the Manifesto The Agile 9- Pursuit of technical excellence: Manifesto Continuous attention to technical excellence and good design enhances agility.  Twelve Agile Principles behind the Manifesto The Agile Manifesto 10- Simplicity is essential: Simplicity is the art of maximizing the amount of work that is not done.  Twelve Agile Principles behind the Manifesto The Agile 11- Acting self-organized: The best Manifesto architectures, requirements, and designs emerge from self-organizing teams.  Twelve Agile Principles behind the Manifesto The Agile 12- Inspection & adaption: At regular Manifesto intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Framework - SCRUM SE3352 by Shaimaa Ali Agile Framework - SCRUM User Stories SE3352 by Shaimaa Ali Agile Framework - SCRUM Requireme nt Elicitation Testing Analysis Implement System User ation Design Object Stories SE3352 by Shaimaa Ali Design  Scrum  Teams in this approach usually range from around five to seven team members.  Three main roles are identified in Scrum:  the Scrum Master (essentially the project man- ager – who coaches and facilitates the team); Agile  the Product Owner (represents the views of the customer and itemizes the order of product development); Methodologies  Team Member (who creates and owns his or her own estimates for work).  The work in Scrum is broken down into manageable chunks referred to as Sprints. These are cycles of the incremental or evolutionary approaches and are sized to take between one week and one month to complete.  Each sprint produces something of value – a deliverable product increment. SE3352 by Shaimaa Ali