Loading in 2 Seconds...
Loading in 2 Seconds...
SDLC Models Bessy Charles & Meera Vijayaraghavan Cognizant Technology Solutions Software Development Life Cycle A series of steps that organizes the development of a software product Duration can take several days or years
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Know what is going to be built
Deliver in stages or increments
For each increment:
Summing up, the fundamental differences between an “iteration” &
an “increment” are:
High priority features
Medium priority features
Low priority features
For each increment:
Industry Methodologies based on (some of) these models
Cycle Effort variation
Cycle Schedule variation
Cycle Defect Density Trend
The basic tenets of RUP are:
In RUP, the development lifecycle is presented from 2 perspectives:
Define the System
Manage Scope of the System
Plan and Design Test
Structure the implementation Model
Integrate each subsystem
Execute Integration test
Integrate the System
Execute System TestModel Schematic
Agile is the label given to a growing number of methodologies with names like Scrum, Crystal, Adaptive, Feature-Driven Development and Dynamic Systems Development Method (DSDM).
These new development approaches are based on the premise that if you hire competent developers, presumably they know how to write code. Any problems your developers encounter, therefore, aren't coding issues but organizational and communications ones, and those are what the agile approaches attempt to address.
Built around 12 basic practices ranging from pair programming to frequent refactoring, this approach is more prescriptive than the others. For more information, visit www.extremeprogramming.org and www.xprogramming.com or read Extreme Programming Explained: Embrace Change, by Kent Beck (Addison Wesley Longman Inc., 1999).
Based on the empirical process control model, Scrum programming relies on self-directed teams and dispenses with much advanced planning, task definition and management reporting. To learn more, visit www.controlchaos.com or read Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle (Prentice Hall PTR, 2001).
This approach empowers the team to define the development process and refine it in subsequent iterations until it's stable. To learn more, visit crystalmethodologies.org/ or read Agile Software Development: Software Through People, by Alistair Cockburn (Addison Wesley Longman, 2001).
Based on adaptive rather than deterministic theories, this approach offers a series of frameworks to apply adaptive principles and encourage collaboration. For more information, visit www.adaptivesd.com or read Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by James A. Highsmith III (Dorset House Publishing, 2000).
Dynamic Systems Development Method
Conceived as a methodology for rapid application development, DSDM relies on a set of principles that include empowered teams, frequent deliverables, incremental development and integrated testing. For more information, visit www.dsdm.org or read DSDM: The Method in Practice, by Jennifer Stapleton (Addison Wesley Longman, 1997).
FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in 1997. What Jeff De Luca delivered was a set of five processes that covered the development of an overall model and the listing, planning, design and building of features. The first process is heavily influenced by Peter Coad´s approach to object modeling. The second process incorporates Peter Coad´s ideas of using a feature list to manage functional requirements and development tasks. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca´s experience. Since its successful use on the Singapore project there have been several implementations of FDD.
The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form <action> <result> <object>, for example: ´Calculate the total of a sale´ or ´Validate the password of a user´. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.
Now that the feature list is complete, the next step is to produce the development plan. Class ownership is done by ordering and assigning features (or feature sets) as classes to chief programmers.
A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held.
After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build.
Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. In the table below the milestones (and their completion percentage) are shown. A feature that is yet to be coded is 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%).
The Five Processes of FDD