Software Engineering. M Umair.

Transcription

1 Software Engineering M Umair

2 Activity and Sprint An activity is a general term for any part of a project that takes place over time (also known as a task) Each step in the software development process can be broken down into several activities. It is typically something like code this, design that, create test data for suchand-such, automate that, and so on. These tend to be things done by one person.

3 Activity and Sprint A sprint is a set period of time during which a team completes part of a software project. Each sprint will go through most or all of the process steps. A typical sprint might have a team of 6 to 8 people working for 2 to 4 weeks.

4 Sequential Development: The Waterfall Model

5 How Waterfall Deals with Software Requirements Waterfall projects define all software requirements upfront. The project cannot proceed unless these requirements have been identified and documented. Have a dedicated team to capture, collect, and gather these requirements. (Questionnaires, face-to-face or phone interviews, white boards, and modeling tools to capture stakeholder and customer requirements.) Ref:

6 How Waterfall Deals with Software Requirements The team should produce a requirements specification document (sometimes they may create more than one). This document defines what needs to be delivered so everyone understands the scope of the project. Ref:

7 Waterfall Model The waterfall model is a heavyweight process with full documentation of each process step (cont.). Advantages: Process visibility Requires a well documented approach Discipline is enforced Separation of tasks Quality control at each step Cost monitoring at each step Ref:

8 Waterfall Model The waterfall model is a heavyweight process with full documentation of each process step (cont.). Disadvantages: In practice, each stage in the process reveals new understanding of the previous stages, which often requires the earlier stages to be revised. Software isn t delivered until late Gathering accurate requirements can be challenging Ref:

9 Waterfall Model The Waterfall Model is not flexible enough. Your argument?

10 Waterfall Model A pure sequential model is impossible Examples: A feasibility study cannot create a proposed budget and schedule without a preliminary study of the requirements and a tentative design. Detailed design and implementation reveal gaps in the requirements specification. Requirements and/or technology may change during the development. The plan must allow for some form of iteration.

11 Waterfall Model With Feedback

12 Waterfall Model Parallel Development A general design for the whole system is performed. Then the project is divided into a series of subprojects that can be designed and implemented in parallel. Once all subprojects are complete, there is a final integration of the separate pieces the system is delivered.

13 Waterfall Model V Model V-Model, the advantage is that Tester role will be involved in the requirement phase itself. If any changes happen mid way, not only the requirements documents but also the test documentation needs to be updated. It is not proposed for short term projects as it requires reviews at each stage.

14 Iterative Refinement Create a prototype system early in the development process. Review the prototype with clients and test it with users, to improve the understanding of the requirements and clarify the design. Refine the prototype in a series of iterations. Requirements are hard to understand until there is an operational system, particularly with user interfaces. Mistakes in the requirements are the most expensive to correct. Example: Converting a national archive from paper based to computer based.

15 Iterative Refinement

16 Iterative Refinement This is a medium weight process with documentation created during the process. Iterative refinement uses various techniques that enable the client to review the planned system early during development: User interface mock-up Throw-away software components Dummy modules Rapid prototyping Successive refinement Get something working as quickly as possible, for client and user evaluation, but do not release it.

17 Iterative Refinement with a Large System

18 Spiral Development Create a base system that has the overall structure of the final product with dummy stubs for missing components. float f_to_c (float temp_in_f) { float factor = ; return (temp_in_f 32) * factor; } An example of stub In real world the variable temp_in_f should be a Value coming from outstation sensor.

19 Spiral Development Create a comprehensive set of test cases for all completed components. Use a succession of sprints to develop new or improved components, each with a set of test cases. Add these components to the source code library.

20 Spiral Development On a daily cycle, build the entire system from the source code library and run the complete set of test cases. With spiral development there is always a fully tested system, but the functionality is incomplete. Example: Developing a new version of an operating system.

21 Spiral Development

22 Incremental Release of Online Systems When software is released online it is often possible to divide the development into a sequence of sprints that are developed and released in quick succession. Example: Start-up company developing a web based shopping service. Advantages Pay-back on investment begins soon. Requirement are more clearly understood in developing subsequent sprints minimize waste. Feedback from customers and clients can be incorporated in later phases. It is easier for a small team to develop a small sprint correctly than to coordinate large projects with many ramifications.

23 Agile Methodology In February 2001, 17 software developers met in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, which covered how they found better ways of developing software by doing it and helping others do it Agile software development is based on an incremental, iterative approach. Ref:

24 Agile Methodology Ref:

25 Agile Methodology Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Agile methodologies encourages teamwork, accountability, and faceto-face communication. Ref:

26 12 Principles of Agile Methodology 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale. Ref:

27 12 Principles of Agile Methodology 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Ref:

28 12 Principles of Agile Methodology 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. Ref:

29 12 Principles of Agile Methodology 10. Simplicity, the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Ref: