0% found this document useful (0 votes)
32 views36 pages

SPPM Unit 2

The document discusses the evolution of software project management, highlighting the challenges of conventional methods and the need for improved processes. It emphasizes the importance of iterative development, risk management, and effective stakeholder engagement to enhance software project success rates. Additionally, it outlines strategies for reducing software size and improving economics through better estimation techniques and the adoption of object-oriented methods.

Uploaded by

rohjyoyt
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
32 views36 pages

SPPM Unit 2

The document discusses the evolution of software project management, highlighting the challenges of conventional methods and the need for improved processes. It emphasizes the importance of iterative development, risk management, and effective stakeholder engagement to enhance software project success rates. Additionally, it outlines strategies for reducing software size and improving economics through better estimation techniques and the adoption of object-oriented methods.

Uploaded by

rohjyoyt
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 36
UNIT-I Software Project Management Renaissance Conventional Software Management, The old way and the new way, Life-Cycle Phases and Processartifnets Engineering and Production stages, inception phase, elaboration phase, construction phase, transition Phase, artifact sets, management artifacts, engineering artifacts and pragmatic artifacts, model based software architectures Evolution of Software Economics, Improving Software Economics, Part -I Software Project Managemtent Renaissance Conventional Software Management 1. The best thing about software is its flexibility: ~ It can be programmed to do almost anything, 2. The worst thing about software is its flexibility: ~ The “almost anything” characteristic has made it difficult to plan, monitor, and control software 4 development. 3. In the mid-1990s, three important analyses were performed on the software engineering industry. All three analyses given the same general conclusion: “The success rate for software Projects is very low”. They Summarized as follows: 1. Software development is still highly unpredictable, successfully within initial budget and scheduled time. 2. Management discipline is more differentiator in success or failure than are technology advances, "3. The level of software Scrap and rework js indicative of an immature process, Software management process framework: Only 10% of software projects are delivered 1. It is the baseline process for most conventional software projects have used. 2. We can examine this model in two ways: : IN THEORY IN PRACTICE IN-THEORY:- In 1970, “Winston Royce presented a paper called Development of Large Scale Software Systems” at IEEE WESCON. Where he made three primary points: 2 |. There are two essential steps common to the development of compuier programs: ~ analysis “Managing the offware process and project management ——————————— Page - coding Analysis and coding both involve creative work that directly Coding contributes to the usefulness of «the end product Waterfall Model Part 1: The two basic steps to bullda program 2.1In order to mange and control all of the intellectual freedom associated with software development one should follow the following steps: + System requirements definition + Software requiremehts definition ~ Program design and testing These steps addition to the analysis and coding steps System requirements \ tu Software requirements \ vv Analysis ~Y Program design _ i \ u Coding 4 t. AY Waterfall Model Part 2: The large — scale system approach 3. Since the testing phase is at the end of the development cycle in the waterfall model, it may be risky and invites failure, ware process and project management ra Sq we need to do either the requirements must be modified or a substantial design changes is warranted by breaking the soflware in to different pieces. There are five improvements to the baste waterfall model that would eliminate most of the development rish are as follows: Ja) Complete program design before analysis and coding ~ By this technique, the program designer give surety that data fluctuations. - Begin the design process with program designer, not the analyst = Write an overview document that is understandable, informative, Jcan gain an elemental understanding of the system. 6) Maintain current and complete documentation (Document the design):- -It is necessary to provide a lot of documentation on most software programs. begin (program design comes first): the software will not fail because of storage, timing, and or programmers. and current so that every worker on the project = Bue to this, helps to support later modifications by a separate test team, a separate maintenance team, and operations personne] who are not software literate, Jc) Do the job twice, if possible (Do it twice):- = If'a computer program is developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations are lconcerned. -“Do it N times” approach is the principle of modern-day iterative development. 4) Plan, control, and monitor testing: |- The biggest user of project resources is the test phase. This is the phase of greatest risk in terms of cost and schedule. - In order to carryout proper testing the following things to be done: i) Employ a team of test specialists who were not responsible for the original design. ii) Employ visual inspections to spot the obvious errors like dropped minus signs, missing factors of two, jumps to wrong addresses. * ji) Test every logic phase. : iv) Employ the final checkout on the target computer. Je) Involve the customer:- - Ibis important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery by conducting some reviews such as, i) Preliminary software review during preliminary program design step. ii) Critical software review during program design. iil) Final software acceptance review following testing. IN PRACTICE: Whatever the advices that are given by the software developers and the theory behind the waterfall model, some soflware projects still practice the conventional software management approach, Projects intended for trouble frequently exhibit the following symptoms: i) Protracted (delayed) integration |= Inthe conventional model, the entire system was designed on paper, then implemented all at once, then integrated. Only at the end of this process was it possible to perform system testing to verify that the i NS OS offware process and project management 7 fundamental architecture was sound. What Happens in Practice Sequential activities: Requirements ma Design map Code => Integration mmpTest Integration -——- Bogins Development Progress (% coded) Original Target Date Requirements High 1 ° . | Focused Risk Controlled Risk § | Resolution Management 2 period a x uw x 2 & i o | 3 : © | Risk | Risk a Exploration : Elaboration period } period othe Low Project Life Cycle "Page ii) Late Risk Resolution ~ A serious issues associated with the waterfall life cycle was the lack of early risk resolution, The risk profile of a waterfall model is, _ It includes four distinct periods of risk exposure, where risk is defined as “the probability of missing a cost, schedule, feature, or quality goal”, iii) Requirements-Driven Functional Decomposition “Traditionally, the software development process has been requirement-driven: An attempt is made to provide a [precise requirements definition and then to implement exactly those requirements. -This approach depends on specifying requirements completely and clearly before other development activities begin. - It frankly treats all requirements as equally important. - Specification of requirements is a difficult and important part of the software development process. iv) Adversarial Stakeholder Relationships ot The following sequence of events was typical for most contractual software efforts: - The contractor prepared a draft contact-deliverable document that captured an intermediate artifact and delivered it to the customer for approval. - The customer was expected to provide comments (within 15 to 30 days) ~The contractor integrated these comments and submitted a final version for approval (within 15 to 30days) [Project Stakeholders : >. Stakeholders are the people involved in or affected by project activities > Stakeholders include the project sponsor and project team support staff customers users, suppliers opponents to the project VVVVVV a av Pag oftware process and project management ¥) Focus on Documents and Review Meetings : duct. the software product. - The conventional process focused on various documents that attempted to describe 1 Se ati ait |~ Contractors produce literally tons of paper to meet milestones and demonstrate Pron than spend their energy on tasks that would reduce risk and produce quality so! err nd schedule involved in - Most design reviews resulted in low engineering and high cost in terms of the effort their preparation and conduct. Iterative Development _ [Wteration + . [Iterat ion 2 | : [Iteration 3 + Earliest iterations ad *Each iteration produ + Each iteration inclu dress greatest risks Ces an executable release des integration and test Better Progr ess Profile Sequential Phases, but iterative ac: tivities Prototypes ap, Architecture m=z Functional => Product Releases Release ne Modern Project Profile Watorfant Project Profile Project Schedule a Iterative Development Phases Major Milestones Inception | Elaboration Construction Transition Inception: Agreement on overall scope — Vision, high-level requirements, business case — Not detailed requirements Elaboration: Agreement on design approach — Baseline architecture, most requirements detailed — Not detailed design Construction: Apply approach — Working product, system test complete Transition: Validate solution — Stakeholder acceptance Accelerate Risk Reduction Walker Reyco, 1995 These parameters (aspects) are not independent they are dependent. For example, tools enable sive eduction and process’ improvements, size- reduction approaches lead to process changes, and process improvements drive tool requirements. + GUI technology is a good example of tools enabling a new and different process. GUI builder tools Permitted engineering teams to construct an executable user interface faster and less cost. ~ Two decades ago, teams developing a user interface would spend extensive time analyzing factors, sereen layout, and screen dynamics. All this would done on paper. Where as by using GUI, the Paper descriptions are not necessary. Along with these five basic parameters another important factor that has influenced software technology improvements across the board is the ever- increasing advances in hardware Performance. Taste 3~ ._Important trends in improving software economics ‘COST MODEL PARAMETERS TRENDS Size Higher order languages (C++, Ada 95, Java, Visual Basic, Abstraction and component-based, exc) fe development technologies . Object-oriented (analysis, design, programming) Reuse ‘Commercial components Process Iterative development ~ Methods and techniques Process maturity models Architecture-first development : Acquisition reform Personnel ‘Training and personnel skill development People factors ‘Teamwork Win-win cultures Environment Integrated tools (vis modeling, compiler, editon ‘Automation technologies and cools debugger change manogementsetc.) ‘Open systems Hardware platform performance Auromation of coding, documents, testing, analyses Quality ; ‘Hardware platform performance Performance, reliability, accuracy Demonstration-based assessment Statistical quality control are process and project management ee Pag REDUCING SOFTWARE PRODUCT SIZE: ~ By choosing the type of the language ~ By using Object-Orjented methods and visual modeling ~ By reusing the existing components and building reusable components & By using commercial components,we can reduce the product size of a software. OBJECT ORIENTED METHODS AND VISUAL MODELING: ~ There has been a widespread movements in the 1990s toward Object- Oriented technology. | ~ Some studies concluded thit Object-Oriented programming languages appear to benefit both software productivity and software quality. One of such Object-Oriented method is UML+Unified Modeling Language. Booch described the following three reasons for the success of the projects that are using Object- Oriented concepts: 1) An OO-model of the problem and its solution encourages a common vocabulary between the end user of a system and its developers, thus creating a shared understanding of the problem being solved. 2) The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without weaken the entire development effort. 3) An OO-architecture provides a clear separation among different elements of a system, crating firewalls that prevent a change in one part of the system from the entire architecture. He also suggested five characteristics of a successful OO-Project, 1) A ccruel focus on the development of a system that provides a well understood collection of essential minimal characteristics. 2) The existence of a culture that is centered on results, encourages communication, and yet is not afaid to fail. 3) The effective use of OO-modeling. —— offware process and project management = =

You might also like