A project life cycle consist of different stages:
Depending on the stage we are, we have different documents to draft, tests to accomplish and come up with all the other steps required to sucessful accomplishment of that stage of the project life cycle. We have Project Management document to manage a project.
Project Management Plan document forms the bible of a project. It has normally these sections:-
√ Project summary
√ Project organization hierarchy
√ WBS / Activity list to be performed with schedule.
√ Work product identification (In short who will do what)
√ Project schedule( GANNT chart or PERT chart)
√ Estimated Cost and completion
√ Project requirements
√ Risk identification
√ Configuration management section
√ Quality section
√ Action Item status
SDLC (System Development Life Cycle) is overall process of developing information systems through multi stage process systems from investigation of initial requirements through analysis, design, implementation and maintenance. The days are gone when one COBOL programmer used to analyze, test and implement software systems. Systems have become complex, huge team members are involved, architects, analyst, programmers, testers, users etc. To manage this number of SDLC models have been created. Following are popular models which are listed:-
√ Waterfall Model.
√ Spiral Model.
√ Build and Fix model.
√ Rapid prototyping Model.
√ Incremental Model.
This section we will go into depth of different SDLC models.
Water Fall Model
This is the oldest model. It has sequence of stages; output of one stage becomes input of other. Following are stages in Waterfall model:-
√ System Requirement: - This is initial stage of the project where end user requirements are gathered and documented.
√ System Design: - In this stage detail requirements, screen layout, business rules, process diagram, pseudo code and other documentations are prepared. This is first step in technical phase.
√ Implementation: - Depending on the design document actual code is written here.
√ Integration and Testing: - All pieces are brought together and tested. Bugs are removed in this phase.3 4 1
√ Acceptance, Installation and Deployment: - This is final stage where software is put in production and runs actual business.
√ Maintenance: - This is least glamorous phase which runs forever. Code Changes, correction, addition etc are done in this phase. Waterfall is suited for low risk in areas of User Interface and performance requirements, but high risk in budget and schedule predictability and control. Waterfall assumes that all requirements can be specified in advance. But unfortunately requirement grows and changes through various stages, so it needs feedback from one stage to other.
Spiral Model
Spiral Model removes the drawback of waterfall model, by providing emphasis to go back and reiterate earlier stages a number of times as project progresses. On broader level it’s a series of short waterfall cycles, each producing an early prototype representing a part of entire project. It also helps demonstrate a Proof of Concept at early software life cycle.
Build and Fix Model
This is the way free-lancers work Write some code and keep modifying it until the customer is happy. This approach can be quite dangerous and risky.
Rapid Prototyping Model
This model is also called as Rapid Application Development. The initial emphasis is on creating prototype that look and acts like the desired product. Prototype can be created by using tools which is different from those used for final product. Once the prototype is approved, its discarded and real software development is started from scratch. The problem with this model is that sometimes the prototype moves ahead to become the final live product which can be bad from design point of view. It’s a effective model but can have higher costing than other models as you require programmers during the initial phase of the software cycle.3 4 2
Incremental Model
In this model we divide products into builds, where section of product are created and tested separately. Here errors are found in requirement phase itself, user feedback is taken for each stage and code is tested after it is written.
Extreme Programming
There is one more type of programing model which is also very prominent in some companies, known as XP programming practice or extreme programming.
Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
In Extreme Programming, every contributor to the project is an integral part of the "Whole Team". The team forms around a business representative called "the Customer", who sits with the team and works with them daily.
Extreme Programming teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be done. Focused on business value, the team produces the software in a series of small fully-integrated releases that pass all the tests the Customer has defined.
Extreme Programmers work together in pairs and as a group, with simple design and obsessively tested code, improving the design continually to keep it always just right for the current needs.The Extreme Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs, and all work together all the time. They code in a consistent style so that everyone can understand and improve all the code as needed.The Extreme Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely.
Test-Driven Development: Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops. (If your programmers are already doing even more sophisticated testing, more power to you. Keep it up, it can only help!) It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.
Metaphor: Extreme Programming teams develop a common vision of how the program works, which we call the "metaphor". At its best, the metaphor is a simple evocative description of how the program works, such as "this program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system.
Sometimes a sufficiently poetic metaphor does not arise. In any case, with or without vivid imagery, XP teams use a common system of names to be sure that everyone understands how the system works and where to look to find the functionality you're looking for, or to find the right place to put the functionality you're about to add.
<--------------------- End --------------------->
No comments:
Post a Comment