Presentation is loading. Please wait.

Presentation is loading. Please wait.


Similar presentations

Presentation on theme: "SOFTWARE ENGINEERING METHODOLOGY / MODEL"— Presentation transcript:

In software engineering and project management, a methodology is a set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatedly carried out to produce software. Software engineering methodologies span many disciplines, including project management, analysis, specification, design, coding, testing, and quality assurance.

2 Examples of methodologies in software engineering:
Agile Unified Process (AUP) Constructionist design methodology (CDM) Dynamic Systems Development Method Enterprise Unified Process (EUP) Extreme Programming (XP) since 1999 ICONIX Process (use case driven object modeling with UML) Information Engineering (IE/IEM) Jackson Structured Programming Object Oriented Design using Prototype Methodology (OODPM) since 1994 Open Unified Process Rational Unified Process (RUP) Structured programming since 1969 Structured Systems Analysis and Design Method (SSADM) System Development Methodology Top-down programming Virtual finite state machine (VFSM) since 1990's Waterfall model

3 Software Process Model
A typical process model covers the whole of the life cycle and clearly defines each phase and the tasks and activities to be performed within that phase as well as those activities that are continuous throughout the life cycle.


5 Project management: planning, resource allocation, tracking, deadlines;
Verification and Validation: reduce software defects and make sure that it does what the user wants; Software Configuration Management: handle the actual code, variants, versions and so on; Maintenance: fixing bugs, coping with changes at the boundary of the system, adding new functionality

6 Dictionary Meaning of the word Agile

7 AUP Agile Unified Process : Short for Agile Unified Process, a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

8 Why AUP? What is an ITERATION?
There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks.

9 Activities in Each Iteration
Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

10 Heavyweight vs. Lightweight Methodology
The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods, as typified by a heavily regulated use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, and inconsistent with the ways that software engineers actually perform effective work. Agile methods are called as "lightweight methods." [creating software in a lighter, faster, more people-centric way ].

11 Some of the principles behind the Agile Manifesto are:
Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication Regular adaptation to changing circumstances

12 Adaptive Or Predictive Model
Adaptive methods focus on adapting quickly to changing realities. An adaptive team will have difficulty describing exactly what will happen in the future. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

13 Contrasted with other iterative development methods
Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models as in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner

14 Contrasted with the waterfall model
Agile development does not have much in common with the waterfall model. The waterfall model is the most predictive of the methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts—requirement specifications, design documents, test plans, code reviews and the like.

15 The main problem of the waterfall model is the inflexible nature of the division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change radically in the course of the project. Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it/adding further functionality throughout the life of the project.

16 XP XP means Extreme Programming
Windows eXPerience, not to be confused as Extreme Programming Extreme Programming (or XP) is a software engineering methodology, one of several agile software development methodologies.

17 modularity, bottom-up and incremental design
Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Kent Beck became the C3 project leader in March 1996 and began to refine the development method used in the project.

18 Rapidly-changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development.

19 The main aim of XP is to reduce the cost of change
The main aim of XP is to reduce the cost of change. In traditional system development methods the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage (a common feature of software engineering projects) will be high.

20 Pair Programming Two programmers work together on every module
Projects suited to Extreme Programming are those that: Involve new or prototype technology, where the requirements change rapidly, or some development is required to discover unforeseen implementation problems

21 Projects suited for more traditional methodologies are those that:
Involve stable technology and have fixed requirements, where it is known that few changes will occur

22 Iterative and incremental development
Iterative and Incremental development is a cyclical software development process developed in response to the weaknesses of the waterfall model. It is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks.

23 Incremental development
Incremental development is a scheduling and staging strategy in which the various parts of the system are developed at different times or rates, and integrated as they are completed.

24 Iterative development
Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The iteration involves the redesign and implementation of a task from project control list, and the analysis of the current version of the system.

25 A typical difference is that the output from an increment is released to users, whereas the output from an iteration is examined for modification. An incremental release might include new functions; a new user interface, new algorithm or new technology, by contrast, is more likely to be integrated, examined, tested, with the result that revisions to the UI, algorithm or technology be marked as work in the following iteration, all prior to release.

26 UNIFIED PROCESS = Incremental Development + Iterative Development
The two terms were merged in practical use in the mid-1990s. The authors of the Unified Process (UP) and the Rational Unified Process(RUP) selected the term "iterative development", and "iterations" to generally mean any combination of incremental and iterative development. Most people saying "iterative" development mean that they do both incremental and iterative development.

27 The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system


29 Waterfall development completes the project-wide work-products of each discipline in a single step before moving on to the next discipline in the next step. Business value is delivered all at once, and only at the very end of the project.


31 Iterative development slices the deliverable business value (system functionality) into iterations. In each iteration a slice of functionality is delivered through cross-discipline work, starting from the model/requirements through to the testing/deployment. The unified process groups iterations into phases: inception, elaboration, construction, and transition. Inception identifies project scope, risks, and requirements (functional and non-functional) at a high level but in enough detail that work can be estimated. Elaboration delivers a working architecture that mitigates the top risks and fulfills the non-functional requirements. Construction incrementally fills-in the architecture with production-ready code produced from analysis, design, implementation, and testing of the functional requirements. Transition delivers the system into the production operating environment. Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full.

32 Many utility software systems have been developed using this model, wherein the requirement is basically providing the customer with some working model at an early stage of the development cycle. As new features are added in, a new release is launched which has fewer bugs and more features than the previous release. Some of the typical examples of this kind of model are: Yahoo Messenger, Azureus, Cyber Sitter, Net Meter, PC Security, Limewire, P2P


Similar presentations

Ads by Google