Conventional software Management---.pptx

Software project management

1. Conventional Software M anagement The traditional method for the development of software is called as conventional approach. The best thing and worst thing about software is “FLEXIBILITY”…because the outcome of flexibility is unpredictable. The 3 important analyses of the state of software engineering are Highly unpredictable …only 10% of software project are delivered successfully Management discipline is more of a discriminator The level of software scrap and rework is indicative of an immature process

2. WaterFall model The waterfall model is a linear, sequential approach to the  software development lifecycle  (SDLC) that is popular in software engineering and product development. The waterfall model uses a logical progression of SDLC steps for a project, similar to the direction water flows over the edge of a cliff. It sets distinct endpoints or goals for each phase of development. Those endpoints or goals can't be revisited after their completion.

3. WaterFall model The two basic steps to building a program or project- Analysis Coding These two involve creative work that directly contributes to the usefulness of end product.

4. 1.System Requirements 2.Software Requirement 3.Analysis 4.Program Design 5.Coding 6.Testing 7.Operations Or Maintain The Large Scale System Approach for SPD stages

5. DRAWBACKS OF WATERFALL MODEL The Basic framework described in the waterfall model is risky and invites failure, because the testing phase occurs at the end of development cycle. This is the first event for which timing ,storage ,input/output transfers are experienced as distinguished from analyzed . If the result outcome is failure as per client needs. Either the requirements must be modified or Substantial change is warranted.

6. Five Necessary improvements for this approach to work: Program design comes first Insert a preliminary program design phase between the software requirements generation phase and the analysis phase. Advantages: 1.) By this technique, the program designer assures that the software will not fail because of storage, timing, and data flux (continuous change). 2.) As analysis proceeds in the succeeding phase, the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences. 3.) If the total resources to be applied are insufficient or if the embryonic(in an early stage of development) operational design is wrong, it will be recognized at this early stage and the iteration with requirements and preliminary design can be redone before final design, coding, and test commences.

7. 2.Document The Design: Document each step thoroughly. Advantages- Easy communication among the team members. Support later modifications by a separate test team, separate maintenance team and operations personnel who are not software literates 3.Do It Twice: Major problems and alternatives are addressed Do it for N times approach Finally Major requirements are implemented Five Necessary improvements for this approach to work:

8. 4.Plan ,Control, And Monitor Testing: Why? Required a lot of project resources (manpower, computing time ) is the test phase Greatest risk in terms of cost and schedule. The previous 3 recommendations were all aimed at uncovering and solving the problems before entering the test phase How? Employ a team of test specialists who are not responsible for the original design Employ visual inspections to spot the obvious errors like dropped minus sign, missing factors of two, jumps to wrong addresses Test every logic path Employ the final checkout on the target computer Five Necessary improvements for this approach to work:

9. 5.Involve The Customer : Involve customers in the project at all the earlier points. These include - ”Preliminary software review ” following the preliminary program design step, A sequence of ”critical software design reviews” during program design A final software acceptance review followed by testing. Advantages: Their insight, judgement and commitment of the customer can boost the development effort. Five Necessary improvements for this approach to work:

10. The software development plan :old version Define precise requirements Define precise plan to deliver system constrained by specified time and budget Execute and track to plan Initial project situation stakeholder satisfication space reused or legacy assets Detalied plans ,scope But:less than 20% of success rate

11. Water fall model in practice: Projects following the conventional software management process are- Not delivered on time Not within initial budget, and Rarely meet user requirements.

12. The 5 Major Problems with Conventional Software Management Process. Protracted integration and late design breakage. Late risk resolution. Requirements driven functional decomposition. Adversarial stakeholder relationships. Focus on documents and review meetings.

13. Expenditures By Activity For A Conventional Software Project

14. Protracted integration and late design breakage The diagram shows development progress versus time. The following sequence of issues is common in this phase; Early success via paper designs and through briefings. Commitment to code late in life cycle. Integration difficulties due to unforeseen implementation issues and interface ambiguities. Heavy budget and schedule pressure to get the system working. Late response of non-optimal fixes, with no time for design. A very delicate, unmaintainable product delivered late.

15. Protracted integration and late design breakage • In conventional approach the use of immature languages and technologies is difficult to understand the software project design and to change it in future. • In conventional model the entire system was designed on paper, and implemented all at once, then integrated. Here we perform system testing at the end of the process to check the fundamental architecture is good or not.

16. 2.Late risk resolution A serious problem in waterfall model was lack of early risk resolution. The diagram shows risk profile for conventional model projects covers four distinct periods. They are – At the early stage risk is defined as missing a cost, schedule, feature or quality At this stage requirement being specified so risk exposure was unpredictable.

17. 2.Late risk resolution After the design concept was available even on paper, risk exposure stabilized. In the next step, after the system was coded some of the individual component risks was resolved. When begin the integration the real system level risks are addressed.

18. Requirements driven functional decomposition. The diagram shows the Suboptimal software component organizations resulting from a requirements driven approach. Another issue in conventional process is requirements are specified in functional manner. In waterfall model requirements are allocated to the components. The decomposition is very difficult based on object oriented design and use of existing components.

19. The conventional process cause adversarial stakeholder relationships, in large part because of the difficulties of requirements specification and the exchange of information only through paper documents and engineering information in adhoc formats. The following sequence of things happened in contractual software development. 1.The contractor prepared a draft contract deliverable document that captured an intermediate artifact and delivered it to the customer for approval. 2.The customer as expected to provide comments. 3.The contractor incorporated these comments and submitted a final version for approval. 4.This one shot review process is highly sensitive on the part of customers and contractors. The exchanges of paper reviews are intolerable. 3.Adversarial stakeholder relationships:

20. The conventional software development process focuses on producing various documents that attempt to describe the software product. Here formal meetings are conducted to exchange specific documents. The developers produce tons of papers to describe the project progress to the customers rather than to reduce risk and produce quality software. Most review meetings has low engineering values and high cost in terms of effort and schedule involved in their preparation and conduct. 5.Focus on documents and review meetings:

21. Results of conventional software project design reviews

22. Need For A Modern Software Management System Diagnosing the five symptoms of projects headed for trouble can be difficult, especially in early phases of the life cycle when problems with the conventional approach would have been most easily cured. Consequently, modern software projects must use mechanisms that assess project in early life cycle phases and that continue with objective, periodic checkup.