‘ongatzations, projects are oon esl an ub a RE nizations - Spring 8 AAS a SG cess 10 help p iplined organizationsCapability Maturity Mode: CMM The Sofvare Engineering stitute (SEI) Capability Matuity Model (CMM) spevifes an increasing series of levels of 8 software develpment organization. The higher the lve, the etter the software development proces, hence reaching each level isan expensive and tine ‘consuming proces, Levels of CMM: ‘+ Level One ‘Init The sofware process is characterized as inconsistent, and ‘ovcasonally even chats. Defined processes and sana! practices tht exist are sharon daring xs, Success ofthe organization majorly depends ona vida flo alent, and heros, The beroes eventually move on 1 other organizations taking ‘hele wealth know or lesions ert wi them, + Level Two: Repeatable- This lve of Software Development Organization has basic and consistent project management processes to rack cst, schedule, and functionality The proces isin place to repeat the cari successes on projects with similar pplietions. Program managements Ley characteristic ofa eel two organization + Level Three: Defined - The sofware process for both management and engineering seis ate documented, standardized, ad ntegzated i a stand soware process 2 ans forthe entre organization and all projets across the organization use an approved tailored version ofthe organization's standard software process for developing esting nd minting the aplication, ‘+ Level Four: Managed - Management can effectively contra the software development cio! aing precise measiremens. Atti level, organization seta quantitative quality 0a for both software process and sotware muintenance. At this maturity level, the performance of processes & contol! using statistical and other- quantitative techniques andi quantitatively predistable ‘+ Level Five: Optimizing - The Key harcteristic of this lve is easing on continually improving process performance though bat incremental and innovative technological improvements. At this level, changes to the proces are 10 improve the process performance and at the same time minting statistical probability 19 achieve the tale quantitative processimprovement objet,2.Evolution of Software Econ Mos software cost models can be sbstaced into a finetion of five basic parameters: size process, porn crornment, al regu gully 3 ans 1. The size ofthe en prods (in human-geneated components, which typically quanti in terms ofthe numberof source inucons or ths mmberoffurctin pit equd to develop therequied tnetonaly 2. The process use to produce the end product. in prtcular the ability ofthe process to woid onvaleaing activites (rework, burentcrati delays, comenntions overhesd) 3. The caabilies of software engineering personnel, nd particularly thei experience with he computer scene issues andthe aplication domain sues the projet 4 The environment, which i made up ofthe tots nd techniques available to sport ficken software developmen and to suomtethe process 5. The required quslty of the rodut, itluding a features, performance, reiabilty, and adspabiy The aig i parame erhed cm be witen ts alos tort = (Persomel (Environment) (Quay) (Size"™—™) (One important aspect of software economics (as represented within todays software cost rods) tht the rtnnship Heween efor alse exits a dissonomy of sal. The iseconomy of sae of sofware developmen a reat of he proces exponent beng grr than 0. Contrary toast manufacturing poseses he more sofware you bul, the mote tnpensve per ut Hem Figure 21 shows tree generations of base technology Sdrancemen in ols, componets, and pewssey The requted level of quay wad permed fe moumed to be content The ciate of he arp reff salwar unt est (pick your generation of sofware development are defined a lows 1) Covet 196 a 1970, can. Osan wd cso t,o teas hy prediable in tht cost ehodule, and’ ually objeeties were almost always 2) Testo hs ad 1, tae ging. Orit, el mesa EEngunges, Some ofthe components (209%) were arial as commercial prs, mclng 3) Moder practices 2000 ander, oftware podution. This bok’ pibsoph rooted inthe te of managed and measted process, egret autraton eivionnen, an! ns) (i he congrats, tap 3% tet me Ce independent of one atthe. Tn each new a, the key is complemenary growth i all technologies For example, the process advance col tbe sed sucefily witout Re Component einai and increased ol atonaion.Life Cycle Phases of Project Management Life cycle phases consist of various separated modules with defined functionalities. Life cycle phases describe the various phases of project management. Life cycle phases are mainly divided into two broad categories: 1. Engineering Phase 2. Production Phase 4th ans eur) cine Production a)These are explained as following below. 1. Engineering Phase: Engineering phase involves establishing the goal and defines the overall scope of the project. Engineering phase involves the small team size and it is usually less predicted. Engineering phase is further divided into 2 Phases: Inception Phase, and Elaboration Phase. Engineering ar) I fale -Johaleya) ar Elaboration dark)* (i). Inception Phase - Inception Phase involves establishing goals and gathering the requirements needed for the software development. It involves the cost estimation and identifying the risk factors. In the inception phase, we mainly work on the scope of the project and architecture. Feasibility analysis is also an important part of the inception phase. Elaboration Phase - Elaboration phase involves in-depth evaluation and study as well as establishing the strong architecture and infrastructure. In the elaboration phase, we work on the efficiency of our architecture. In this phase, we also analyze use cases and other software diagrams. We reduce the risk to a certain extent and a preliminary user module is prepared in this phase.2. Production Phase: In the Production phase, we mainly focus on the Implementation of Project and optimization including the reduced cost and risk factors of our project. It also involves various testing for efficient deployment of the project. It involves the large team size and most of the time it is predictable. It is broadly divided into 2 Phases: Construction Phase, Transition Phase. Production ar ht Construction Transition ed aa)+ (i). Construction Phase - In the construction phase, we perform the implementation of our software. In this phase, we minimize the risk and eliminate it. All the features and components are integrated into an application. In this phase, we perform strict testing and process optimization is done. We minimize the development cost and work to improve its efficiency.Construction phase mainly focuses on the implementation and testing of our software. (ii). Transition Phase - In the Transition phase, we perform strict testings mainly beta testing and deployment of software or project. After receiving the feedback from the user, we perform some changes in our software to make it more efficacious. In this phase, the developer works on a project with an user's view to make software more supportable and user friendly.software artifacts are organized into five distinct ‘that, 0 ofthe set! management (adhoc textual oma), requests tnd socindsors it) sl elon Cena aan ‘source files), Lo} (machil rGfact ses are shown in Figure 10 i u 2 Tost model 3. Sofware architecture Sescription executables Management Set Planning Artifacts ‘Operational Artifacts 4. Work breakdown structure '5. Rélease descriptions: 2! Business case 6, Status assessments 3. Release specifications fare change order database 4; Sofware development plan 8, Deployment documents, 8: enaronmont Me wiranin Ficuae 6-1. Overview of the artifact setsWORKFLOW OF THE FKOCESS —g SOFTWARE PROCESS WORKFLOWS ans ‘The term WORKFLOWS is used to mean a thread of cohesive and mostly sequential activities Workflows are mapped to product artifacts There are seven top-level workflows: |. Management workflow: co stakeholders olling the process and ensuring win conditions for all 2. Environment workMlow: automating the process and evolving the maintenance environment 3. Requirements workHiow: analyzing the problem space and evolving the requirements artifacts 4. Design workflow: modeling the solution and evolving the architecture and design artificts| 5. Implementation workflow: programming the components and evolvis and deployment artifacts the implementation 6. Assessment workflow: assessing the trends in process and product quality 7. Deployment workflow; transitioning the end products tothe user Figure 8-1 illustrates the relative levels of effort expected across the phases in each of the top level workflows, a a — Pevoymet unt 6-1. Actny level acon he Mf cycle phasesCHECK POINTS OF A PROCESS Thre types ofjoint management reviews are conducted thoughout he proces: |, Major milestones, These system wide events te held atthe end of each develpment phase They provide vsbilty to system wie auc, synchronize the management aed enginocing perspetives, sd verify thal the ins of the ae have en achive. 2, Mino misones, These teraton-oeused events are conducted o review the content of an iteration in detail and to authorize continued work 3, Stats asisments, These periodic events provide management with fequent and regula insight ino the progress being made 7 ans Each ofthe four phases-inception, elaboration, construction, and transition consists of one of move detains and concludes wala a major ailestone when a planned technical capably is Produced in demonstrable form. An eration represents eye of activites for which there i Well-defined imermediate result-a minor mikstone-capured with two aif: a release Specification (he evaluation criteria and plan) and a ease description (the resus). Major milestones a the end of each phase ue femal, stakeholder approved exslaton criteria td release descriptions; minor milestones we informal, devslopment-team-contgolled versions of those ait Figure 9-1 ilatrats atypia squense of proj checkpoints fo a elativey larg projet. a comin [Toon ee wee aa sy oe is a a ak Viti enc ot orca tae eta poe “Tact oes on ca cones othe cert erton oooo coo oo ooo oo o° ‘Assosements_ Poradesyptvonzation of saenoler expeditions Ploune 9-1. A sypical sequence of ife-cycle checkpoints