software engineering and project management 3rd module ppt presenetation

se and pm

1. Module-3 Chapter-1 AGILE DEVELOPMENT

2. 1. WHAT IS AGILITY? Modern software development process. Agility means effective ( rapid and adaptive ) response to change by having effective communication among all stockholders. Iterative and incremental approach. Agile team respond to changes in the software development. delivering a working product quickly and frequently . It involves close collaboration between the development team and the customer to ensure that the product meets their needs and expectations .

3. 2. AGILITY AND THE COST OF CHANGE Easy to accommodate a change when a team is gathering requirements early in a project . Costs of doing this work for the changes are minimal. Agile process may “flatten” the cost of change curve by coupling Incremental delivery with agile practices such as continuous unit testing and pair programming.

4. 3. WHAT IS AN AGILE PROCESS Agility principles The Politics of Agile Development Human Factors AGILE PROCESS "Agile Process Model" refers to a software development approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do not directly involve long term planning.

5. Agility principles The Agile Alliance defines 12 agility principles for those who want to achieve agility: H ighest priority is to satisfy the customer. Welcome changing requirements, even late in development. Deliver working software frequently. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. The most efficient and effective method of conveying information. Working software is the primary measure of progress. Agile processes promote sustainable development . Continuous attention to technical excellence and good design enhances agility. Simplicity The best architectures, requirements, and designs emerge from self–organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

6. THE POLITICS OF AGILE DEVELOPMENT There is consider able debate about the benefits and applicability of agile software development as opposed to more conventional software engineering process . Traditional methodologists are a bunch of stick-in-the- mud s who’d rather produce flawless documentation than a working system that meets business needs.

7. HUMAN FACTORS Competence : Individuals skills included in work. Common focus : commitment toward goal. Collaboration : working together. Decision-making ability : making timely decisions. Fuzzy problem-solving ability : capability to handle complex and different problems. Mutual trust and respect : valuing each others contribution. Self-organization: ability of managing themselves in the work.

8. EXTREME PROGRAMMING (XP) XP Values XP Process Industrial XP(IXP) The XP Debate The most widely used agile process. proposed by Kent Beck. XP is lightweight, efficient, low-risk, flexible way to develop the software. Used by small and medium sized teams that work under rapidly changing requirements. A variant of XP, called Industrial XP (IXP)

9. XP VALUES A set of five values that establish a foundation for all work performed as part of XP . Communication : clear and constant Simplicity : simplest solution. Feedback : frequent feedback. Courage : to make necessary changes. Respect : each others work.

10. XP PROCESS Four framework activities: planning, design, coding, and testing.

11. XP Planning: Begins with the creation of “user stories” Agile team assesses each story and assigns a cost. Stories are grouped to for a deliverable increment. A commitment is made on delivery date. After the first increment “project velocity” is used to help define subsequent delivery dates for other increments . XP Design : Follows the KIS(Keep it simple) principle. Encourage the use of CRC cards (class responsibility collaborator ). For difficult design problems, suggests the creation of “spike solutions”,a design prototype

12. XP Coding: Recommends the construction of a unit test for a store before coding commences. Encourages “pair programming ”. Pair Programming: Two people work together at one computer workstation to create code for a story. Encourages “refactoring”—an iterative refinement of the internal program design Refactoring : Improves the internal structure of the code but external behavior not affected . XP Testing : All unit tests are executed daily . “ Acceptance tests” are defined by the customer and executed to assess customer visible functionality.

13. INDUSTRIAL XP It is a expanded role for customers, and upgraded technical practices .” IXP incorporates six new practices that are designed to help ensure that an XP project works successfully for significant projects within a large organization . Readiness assessment : Before starting project evaluate team skill, organizational support and project complexity. Retrospectives: R egular checking to find out the improvement. Continuous learning: Encouraging learning for improvement. Project community : B uilt stakeholders community for strong connection. Project chartering: E stablishing clear vision, goals and constrains. Test-driven management : T o improve code quality

14. THE XP DEBATE Among the issues that continue to trouble some critics of XP are: Requirements volatility: frequent changes in requirement disrupt the development process. Conflicting customer need: due to different stakeholders requirements it is difficult to prioritize. Requirements are expressed informally: through conversation instead of formal documentation. Lack of formal design: lead to poor architecture and maintainability.

15. 5. OTHER AGILE PROCESS MODELS Adaptive Software Development ( ASD) Scrum Dynamic Systems Development Method ( DSDM) Crystal Feature Drive Development ( FDD) Lean Software Development ( LSD) Agile Modeling ( AM) Agile Unified Process (AUP)

16. ADAPTIVE SOFTWARE DEVELOPMENT ( ASD ) Technique for building complex software and systems. ASD focus on human collaboration and team self- organization. ASD features: Mission-driven planning: work on customer mission. Component-based focus : modularity approach. Uses “ time-boxing ”: fixing the time. Explicit consideration of risks: identifying and managing risk. Emphasizes collaboration for requirements gathering: involve all stakeholders to refine requirements. Emphasizes “learning” throughout the process: continuous learning and feedback to improve process and product.

17. ASD “life cycle” incorporates three phase : Speculation Collaboration Learning

18. Speculation : Here the project is initiated plan is conducted . planning uses project initiation information: the customer’s mission statement, project constraints (e.g., delivery dates or user descriptions ), and basic requirements. Collaboration: It encompasses communication and teamwork , it also emphasizes individualism, because individual creativity plays an important role in collaborative thinking. It is, a matter of trust. People working together must trust one another to criticize without disliking it, assist without offence, work as hard as or harder than they do, have the skill set to contribute to the work at hand, and communicate problems or concerns in a way that leads to effective action.

19. Learning : It will help team members to improve their level of real understanding. ASD teams learn in three ways: focus groups, technical reviews and project analyses.

20. SCRUM Scrum features Popular method. Development work is partitioned into “ packets”. Lightweight, incremental and iterative. Testing and documentation are on-going as the product is constructed. Work occurs in “sprints” and is derived from a “backlog” of existing requirements. Meetings are very short and sometimes conducted without chairs. “demos ” are delivered to the customer with the time-box allocated. It incorporates the following framework activities: Requirements Analysis Design Evolution D elivery.

21. Roles : The Scrum Team consists of three roles, namely A Scrum Master, A Product Owner, and The Team . The Product : Manages the Product Backlog and ensure team will work on it. Scrum Master: He/she is responsible for making the process run smoothly, removing obstacles that impact productivity, organizing and facilitating the critical meetings. Team: the team comprises of analysts, designers, developers, testers, etc . as appropriate and as relevant to the project. Size of the team should be 5-9 members .

22. The vital events of scrum are: The Sprint: T ime limit. Sprint planning: work to be performed . Daily Scrum Meetings: 15-minute time-boxed event for the Scrum Team to synchronize the activities and create a plan for that day Questions to be answered by team members during meeting. What did you do since the last team meeting? What obstacles are you encountering? What do you plan to accomplish by the next team meeting? The Sprint Review: to inspect the Increment and make changes to the Product Backlog, if needed. The Sprint Retrospective: occurs after the Sprint Review and prior to the next Sprint Planning. the Scrum Team is to inspect itself and create a plan for improvements to be enacted during the subsequent Sprint.

23. TERMINOLOGIES Sprint : Within each framework activity, work tasks occur within a process pattern called a sprint. Backlog : a prioritized list of project. Product Backlog : entire requirement list. Sprint Backlog : The Sprint Backlog is the set of Product Backlog items selected for the Sprint. Demos: deliver the software increment to the customer so that functionality that has been implemented can be demonstrated and evaluated by the customer.

24. DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)/ ATERN It is an Agile software development approach. “ P rovides a framework for building and maintaining systems which meet tight time constraints through the use of incremental prototyping in a controlled project environment ” The DSDM philosophy is borrowed from a modified version of the Pareto principle: 80 percent of an application can be delivered in 20 percent of the time it would take to deliver the complete (100 percent) application. Effort=20% and result= 80% Mainly focus on 80% of work.

25. GUIDING PRINCIPLES OF DSDM Active user involvement is imperative. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution . All changes during development are reversible . Requirements are baseline at a high level.

26. DSDM life cycle that defines three different iterative cycles, preceded by two additional life cycle activities : Feasibility study : establishing basic requirements and constraints. Business study: I dentifies functional and non-functional requirements. Functional Model Iteration: producing incremental prototypes and demonstrating to customer. Design and build iteration: Revisit prototypes built during the functional model iteration to ensure incorporation. Implementation: place latest software increment into operation.

27. CRYSTAL Proposed by Cockburn and Highsmith Crystal used for distinguishing features. It is resource-limited, cooperative game of invention and communication, means working together creatively and sharing ideas while dealing with limited resources. Face-to-face communication is emphasized Suggests the use of “reflection workshops” to review the work habits of the team : look back to work progress

28. It places focus on people over processes rather than strictly adhering to predefined processes and tools . Crystal recognizes that different teams will perform differently depending on team size, criticality and priority of the project and encourages users to adapt the framework for their individual situation . Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others. These are categorized by color, according to the number of people in the project; Crystal Clear - Teams with less than 8 people Crystal Yellow - Teams with between 10 and 20 people Crystal Orange - Teams with between 20-50 people Crystal Red - Teams with between 50-100 people

29. Crystal Clear - Teams with less than 8 people Lightweight and simple, Face to face communication, Frequent deliveries, regular workshop and min documentation. Crystal Yellow - Teams with between 10 and 20 people More structured than crystal clear, Daily standups, code reviews and testing, More documentation, Formal communication channel. Crystal Orange - Teams with between 20-50 people More defined processes and roles, Inter-team communication and coordination, Regular delivery, Risk management, Comprehensive documentation. Crystal Red - Teams with between 50-100 people High structured process with rigorous documentation, Quality assurance, Strong emphasis on risk management, Detailed project planning, frequent integration and testing.

30. Key Principles of the Crystal Framework: Frequent Delivery: delivering the code frequently . Reflective Improvement: Look back on what you've done, how you've done it and why to improve future. Osmotic Communication: co-location (having teams in the same physical space ) is critical. Personal Safety: Team members should feel safe to discuss ideas openly, without fear . There are no wrong answers or bad suggestions in a Crystal team. Focus on Work: Team members should know what to work on next and be able to do it. Access to Subject Matter Experts and Users: Team members should be able to get feedback from real users and experts when required. Technical Tooling: Teams should have access to tooling's like continuous deployment, automated testing and configuration management.

31. FEATURE DRIVEN DEVELOPMENT Originally proposed by Peter Coad is a model for object oriented software engineering . FDD adopts a philosophy that: E mphasizes collaboration among people on an FDD team. M anages problem and project complexity using feature-based decomposition followed by the integration of software increments. C ommunication of technical detail using verbal, graphical, and text-based means. FDD used for distinguishing the features. A feature “is a client-valued function that can be implemented in two weeks or less.” Uses a feature template < action> the <result > Examples of features for an e-commerce application might be: Making a product sale is a feature. Then the feature set would include : Add the product to shopping cart Display the technical-specifications of the product Store the shipping-information for the customer

32. Breaking down the project into a list of features Example User registration User login Browse products by category Search products Add products to cart View cart Remove product Checkout Payment Order confirmation Order tracking.

33. LEAN SOFTWARE DEVELOPMENT (LSD ) Lean Software Development (LSD) is an agile framework based on: optimizing development time and resources , eliminating waste , and ultimately delivering only what the product needs . Goal Is to delivering valuable features and products as quickly and effectively as possible. LSD process can be summarized as: eliminate waste , build quality in, create knowledge, Stay for commitment , deliver fast, respect people, and optimize the whole.

34. Example of Eliminate waste: adding no extraneous features or functions, assessing the cost and schedule impact of any newly requested requirement , removing any superfluous process steps, establishing mechanisms to improve the way team members find information, ensuring the testing finds as many errors as possible, reducing the time required to request and get a decision that affects the software or the process that is applied to create it, and streamlining the manner in which information is transmitted to all stakeholders involved in the process.

35. AGILE MODELING (AM) Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation It is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner . AM suggests a wide array of “core” and “supplementary” modeling principles : Model with a purpose : A developer who uses AM should have a specific goal before creating the model Use multiple models : when multiple models used it should provide value to their intended audience should be used. Travel light : keeping only those models that will provide long-term value and discard the rest . Content is more important than representation : Modeling should impart information to its intended audience . Know the models and the tools you use to create them : Understand the strengths and weaknesses of each model and the tools that are used to create it. Adapt locally : The modeling approach should be adapted to the needs of the agile team.

36. AGILE UNIFIED PROCESS (AUP ) AUP adopts a “ serial in the large ” and “ iterative in the small ” philosophy for building computer-based systems. C lassic UP phased activities are inception , elaboration, construction, and transition. AUP provides a serial overlay i.e ., a linear sequence of software engineering activities. I t enables a team to visualize the overall process flow for a software project.

37. Each AUP iteration addresses the following activities : Modeling : UML representations of the business and problem domains. It should be “just barely good enough”. Implementation: Models are translated into source code. Testing: Series of tests to uncover errors and to ensure that the source code meets its requirements. Deployment: software delivery and feedback. Configuration and project management: controlling the work products that are produced by the team. Project management tracks and controls the progress of the team and coordinates team activities. Environment management : It coordinates a process infrastructure that includes standards, tools, and other support technology available to the team.

38. A TOOL SET FOR THE AGILE PROCESS There are many different types of Agile tools out there. Some are free, some are paid. Some tools that support end-to-end flow of software development life cycle including requirements management, test management, defect tracking. Different tools: Social tools : starting even at the hiring stage. e .g., linkedln Technological tools: teams simulate being physically present. e . g.., virtual meetings. Physical tools: allowing people to manipulate them directly for better interaction . e.g., sticky notes.

39. CHAPTER-2 PRINCIPLES THAT GUIDE PRACTICE 1. SOFTWARE ENGINEERING KNOWLEDGE Many software practitioners often think software engineering knowledge is just about knowing specific technologies like Java, Perl, HTML, C, and Linux . People often say that software development knowledge has a " three-year half-life ," meaning that half of what you know today will be outdated in three years . This is true for technology-related knowledge, where new tools and languages quickly replace old ones . However , there's another type of software development knowledge called " software engineering principles " that does not become outdated so quickly. These principles can help a professional programmer throughout their entire career.

40. 2. CORE PRINCIPLES G eneral principles that span software engineering process and practice : P rovide value to end users , K eep it simple, M aintain the vision (of the product and the project ), R ecognize that others consume (and must understand) what you produce, B e open to the future, P lan ahead for reuse, and T hink !

41. Set of core principles can be applied to the framework, and by extension, to every software process: Principle 1: Be agile. Improve software incrementally. Principle 2: Focus on quality at every step. Proper testing & ensure it meet requirements. Principle 3: Be ready to adapt. Open to new tools. Principle 4: Build an effective team. To enhance productivity. Principle 5: Establish mechanisms for communication and coordination. Clear communication and coordination. Principle 6: Manage Change. Handling changes smoothly Principle 7 : Assess risk. Identify and evaluate risk. Principle 8: Create work products that provide value for others .

42. 3. PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY. Communication Principles [ 10] Planning Principles [ 10] Modeling Principles [ 10] a ) Requirements Modeling Principles [ 5] b ) Design Modeling Principles [ 5] Construction Principles a ) Preparation Principles [ 5] b ) Programming Principles [ 9] c ) Validation Principles [ 3] Testing Principles [ 5] Deployment Principles [ 5]

43. Communication Principles Principle1 . Listen . Principle2 . Prepare before you communicate . Spend the time to understand the problem. Principle3 . Someone should facilitate the activity . E.g. leader for communication. Principle4 . Face-to-face communication is best . Principle5 . Take notes and document decisions . Principle6 . Strive for collaboration . Team formation Principle7 . Stay focused, modularize your discussion . If more people for communication, topic may bounce. Principle8 . If something is unclear, draw a picture . Principle9 . Once you agree to something, move on ; If you can’t agree to something, move on; If a feature or function is unclear and cannot be clarified at the moment, move on. Principle10 . Negotiation is not a contest or a game. It works best when both parties win.

44. 2.Planning Principles Principle1: Understand the scope of the project . Provides destination. Principle 2: Involve the customer in the planning activity . Principle 3 : Recognize that planning is iterative . Since work begins, it very likely that things will change. Principle 4 : Estimate based on what you know : effort , cost, and task duration. Principle5 . Consider risk as you define the plan . Level of risk. Principle6 : Be realistic . People don’t work 100 percent of every day. Principle 7: Adjust granularity as you define the plan . Granularity refers to the level of detail that is introduced as a project plan is developed. Principle 8: . Define how you intend to ensure quality . aim Principle 9: Describe how you intend to accommodate change . Even the best planning can be obviated by uncontrolled change. Principle 10 : Track the plan frequently and make adjustments as required . Software projects fall behind schedule one day at a time.

45. 3. Modeling Principles Principle1 . The primary goal of the software team is to build software, not create models. Principle2 . Travel light, don’t create more models than you need. Principle3 . Strive to produce the simplest model that will describe the problem or the software. Principle 4 . Build models in a way that makes them amenable to change . Principle5 . Be able to state an explicit purpose for each model that is created Principle6 . Adapt the models you develop to the system at hand. Principle7 . Try to build useful models, but forget about building perfect models. Principle8 . Don’t become rigid about the syntax of the model. If it communicates content successfully, representation is secondary. Principle9 . If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have reason to be concerned . Principle10 . Get feedback as soon as you can.

46. REQUIREMENTS MODELING PRINCIPLES Principle1 : The information domain of a problem must be represented and understood. Principle2 : The functions that the software performs must be defined . Principle3 :The behavior of the software must be represented. Principle 4 : The models that depict information, function, and behavior Must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Principle5 : The analysis task should move from essential information Toward implementation detail .

47. DESIGN MODELING PRINCIPLES Principle1 : Design should be traceable to the requirements model. Principle2 : Always consider the architecture of the system to be built. Principle3 : Design of data is as important as design of processing functions. Principle4: Interfaces (both internal and external ) must be designed with care. Principle5 . User interface design should be tuned to the needs of the end-user. However in every case, it should stress ease of use.

48. CONSTRUCTION PRINCIPLES The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end-user. Coding principles and concepts are closely aligned programming style, programming languages, and programming methods . Testing principles and concepts lead to the design of tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort.

49. PREPARATION PRINCIPLES : Before you write one line of code, be sure you: Understand of the problem you’re trying to solve. Understand basic design principles and concepts. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate. Select a programming environment that provides tools that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed.

50. PROGRAMMING PRINCIPLES As you begin writing code, be sure you: Constrain your algorithms by following structured programming practice. Consider the use of pair programming . Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting. Create a visual layout that aids understanding

51. VALIDATION PRINCIPLES After you’ve completed your first coding Pass ,be sure you Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered. Refactor the code.

52. TESTING PRINCIPLES Principle1 : All tests should be traceable to customer requirements. Principle2 : Tests should be planned long before testing begins. Principle3 : The Pareto[80% outcome from 20% cause] principle applies to software testing. Principle4 : Testing should begin “ in the small ” and progress toward testing “in the large .” Principle5 . Exhaustive testing is not possible.

53. DEPLOYMENT PRINCIPLES Principle1 : Customer expectations for the software must be managed . Principle2 : A complete delivery package should be assembled and tested . Principle3 : A support system must be established before the software is delivered. Principle4 : Appropriate instructional materials must be provided to end-users . Principle5 : Buggy software should be fixed first, delivered later