SOFTWARE DEVELOPMENT PROCESS

1. SOFTWARE DEVELOPMENT PROCESS INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT JUSTIFY define and validateREQUIRE-MENTS MODEL TESTin the small TESTin the large RELEASE SUPPORT define initialmanagementDOCUMENTS define INFRA-STRUCTURE GENERALIZE PROGRAMPROCESS REWORK ASSESS identifydefects andenhance-ments quality assurance, manage project, trainig&education, manage people, manage risk, manage reuse, manage metrics, manage deliverables, manage infrastructure

2. SUPPORT PROCESSES FOR THE SOFTWARE DEVELOPMENT PROCESS QUALITYASSURANCE RISK MANAGEMENT TRAINING & EDUCATION IDENTIFYA RISK ASSESSTHE RISK DEVELOPMITIGATIONSTRATEGIES PERFORM INTROTRAININGS PERFORM DETAILEDTRAININGS FOLLOWISOSTANDARDS DEVELOPA RISKMANAGEMENTPLAN MITIGATETHE RISK REPORTRISK DEVELOPA TRAININGPLAN REUSEMANAGEMENT METRICSMANAGEMENT DELIVERABLESMANAGEMENT INFRA-STRUCTUREMANAGEMENT COLLECTREUSABLEITEMS DEVELOPMETRICSPLAN PERFORMAND DISCUSS MANAGE SOFTWARECONFI-GURATION APPLYCMM, …TECHNIQUES

3. quality assurance engineer tools specialist process specialist estimator / planner subject matter expert analyst standards specialist project sponsor JAD / meeting facilitator technical writer infrastructure engineer project manager allocated maintenance changes INITIATE PHASE from maintain & support phase The main goal is to lay the foundation for a successful project. This is hard due to pressures by senior management and developers to start “real work” as soon as possible. JUSTIFY define and validateREQUIRE-MENTS management documentsinitial requirementproject infrastructureproject fundingproject charter define initialmanagementDOCUMENTS define INFRA-STRUCTURE potential roles during this phase:

4. domain programmer infrastructure engineer technical writer test engineer reuse engineer component engineer project manager team leader proof-of-concept engineer software conf. manager test manager architectural modeler subject matter expert mentor quality assurance engineer domain modeler allocated maintenance changes from maintain & support phase CONSTRUCT PHASE The main goal of the construct phase is to build working software that is ready to be tested and delivered to its user community. MODEL TESTin the small management documentsinitial requirementproject infrastructureproject fundingproject charter software applicationdocumentationrequirement allocation matrix models, source codemanagement documents GENERALIZE PROGRAMPROCESS potential roles during this phase:

5. training manager support engineer operations manager support manager project manager operations engineer developer project auditor testing manager test engineer technical writer trainer DELIVER PHASE The main goal here is to deploy the application, including the appropriate documentation, to the user community. TESTin the large RELEASE packaged applicationdocumentationmodels and source codemanagement documentsrequirement alloc. matrix tested applicationdocumentationmodelsrequirement alloc. matrix REWORK ASSESS potential roles during this phase:

6. support manager support engineer operations manager operations engineer config. control board mgr. configuration item owner MAINTAIN & SUPPORT PHASE The goal here is to keep the application running in production and to ensure that changes to the application are well identified and acted on. to initiate or construct phase allocatedmaintenancechanges SUPPORT tested applicationdocumentationmodelsrequirement alloc. matrix identifydefects andenhance-ments potential roles during this phase:

7. This is determining what needs to be built. Initial requirements are a foundation from which modeling can begin. DEFINE AND VALIDATE INITIAL REQUIREMENTS DEFINESYSTEMFUNCTIONS DEFINESYSTEMSCENARIOS DRAWPROCESMAPS visioncommitmentreasibility studyexisting applicationsmaintenance changes requirement documentation(forms, tables, diagrams, ...)project scope HOLD SESSIONS CREATEMODELINGCARDS PRIORITIZEREQUIRE-MENTS INTERVIEWUSERS SIMULATESCENARIOS WALK THROUGHPROTOTYPES

8. Purpose of this process is to initiate documents such as the project plan and project risk assessment. They must be started at the beginning of the project and then maintained throughout its life. DEFINE INITIAL MANAGEMENT DOCUMENTS DEFINETASKS CREATEINITIALSCHEDULE DEFINEPROJECTSCOPE reasibility studyproject infrastructureinitial requirementsproject objectives project planrisk assessmentmaster testquality assurance plan CREATEINITIALESTIMATE CREATEINITIAL RISKASSESMENT CREATEINITIAL QUALITY ASSUR. PLAN

9. The purpose is to determine whether or not an application should be built. It is a reality check to determine whether or not a project makes a sense. JUSTIFY IDENTIFYIMPLEMEN-TATIONALTERNATIVES DETERMINEOPERATIONALFEASIBILITY IDENTIFYRISKS visionestimaterequirements documentationschedulerisk assessment feasibility studyrecommendationsproject fundingrisk assessment DETERMINEECONOMICFEASIBILITY DETERMINETECHNICALFEASIBILITY CHOOSEALTERNATIVE

10. The project infrastructure is made up of the project team, the tools that they will use, and a tailored version of the software development process that the team will follow. DEFINE INFRASTRUCTURE SELECTTOOLS DEFINE TEAM GREATEGROUPKNOWLEDGEBASE project planinitial requirementsfeasibility studyexisting infrastructure team definition(profile, skill database, ...)tools selectiontailored software processgroup knowledges SELECT METHODO-LOGY SELECT STANDARDSANDGUIDELINES NEGOTIATEDELIVE-RABLES

11. The developers first need to understand what the are supposed to build. This “software analysis and design” process should be performed iteratively, because of developers do not need to do all of the analysis first time, then do all of the design and then all of the coding. MODEL ARCHITECTU-RALMODELING TECHNICALMODELING TASKMODELING requirement documentationmodeling standards models (diagrams, docs)test planrequirement alloc. matrix PROBLEMDOMAINMODELING HUMAN INTERACTIONDOMAINMODELING MANAGEMETRICS

12. During this process the source code is written, documented, reviewed, tested and packaged for delivery. For this to be successful, the models must drive the development of the source code. This process is far more to writing source code of programs. PROGRAM PROCESS UNDERSTANDMODELS MAKESOURCECODE SYNCHRONIZESOURCE CODEWITHMODELS PREPARECODE FORINSPECTIONS PREPAREPROJECTINTEGRATIONPLAN INTEGRATEAND PACKAGE modelsproject infrastructure packaged applicationsource codesoftware components BUILDSOFTWAREAPPLICATION OPTIMIZE CODE REUSEEXISTINGCODE ANDCOMPONENTS DOCUMENTSOURCECODE DOCUMENTSOFTWAREAPPLICATION PERFORMMETRICS

13. This is the recognition that the short-term pressures of software development result in the temptation for developers to settle for specific, non-reusable solutions. In this process, application specific items are identified and then reworked to be reusable by other development teams. GENERALIZE IDENTIFYPOTENTIALREUSABLEITEMS HOLDGENERALIZA-TIONSESSIONS REFACTORCODE project deliverables reusable items MAKEDOCUMENTA-TION RELEASE PERFORMMETRICS

14. This process focuses on the verification, validation, and testing of documents, models, and source code produced. In many ways it is quality assurance techniques such as peer reviews and inspections combined with unit testing techniques for validating code. TEST IN THE SMALL DEVELOPTEST PLAN SCENARIOANDPROCESSTEST REVIEWPROTOTYPES modelssource coderequirementsmaster test quality assurance plan tested artifactstest resultsmaster testquality assurance plan WALK- THROUGHMODELS RECORDDEFECTS PROGRAM CODETESTING USERINTERFACETESTING INSPECTSOURCECODE REVIEWTECHNICALDESIGN

15. The goal here is to ensure that the application works on its entirety. This includes user testing in which the application is specifically tested by members of user community. TEST IN THE LARGE ACCEPTTESTPLAN FUNCTIONTEST INSTALLATIONTEST packaged applicationmaster testquality assurance planprevious test results tested applicationtest results STRESSTEST OPERATIONSTEST ALPHA/BETATEST USERACCEPTANCETEST PERFORMMETRICS RECORDDEFECTS

16. The focus of this process is to fix the critical defects discovered by the “test in the large” process to ensure the successful deployment of the application. It is like a miniature version of the “construct” process. REWORK PRIORITIZEDEFECTS REMODEL REPROGRAM tested application tested results, documents models, source coderequirement alloc. matrix organizational priorities reworked applicationmodels, source codedocumentation requirement alloc. matrix UPDATEDOCUMENTA-TION TESTIN THESMALL PERFORMMETRICS

17. The goal of this process is to deploy the application and its corresponding documentation successfully to the user community (end users and also operations department staff that will help the users work with the application effectively). RELEASE ACCEPT TRAINING AND RELEASEPLANS ACCEPT USERSUPPORT ANDOPERATIONSDOCUMENTS PACKAGEAPPLICATION FINALIZECONVERSIONOF LEGACY DATA DEPLOY THE OPERATIONPROCESS TRAINOPERATIONSSTAFF release procedures training plans application package operations and support documentation released application procedures documentation DEPLOY THESUPPORTPROCESS TRAINSUPPORTSTAFF ANNONCEACTUALRELEASETO USERS TRAINUSERS DEPLOY THEAPPLICATION PERFORMMETRICS

18. This process has two goals: a) for the project team, to learn from its experiences developing the applicationb) to provide an opportunity to evaluate the members of the project team to support their personal growth ASSESS REVIEWPROJECTDELIVERA-BLES DEVELOPPROJECTASSESSMENT ASSESSTEAMMEMBERPERFORMANCE DEVELOPLEARNINGHISTORY project deliverables project metrics group knowledge base learning history project and staff assessment process improvement plan ANALYZEMETRICS DEVELOPSTAFFASSESSMENT ASSESSUSERINVOLVEMENT DEVELOPSOFTWAREPROCESSIMPROV. PLAN

19. The objective of this process is to respond to incoming support requests from users, to identify a resolution for the request, and then to oversee the implementation of that resolution. This is performed on a continual, daily basis way. SUPPORT RESPONDTO REQUEST DETERMINESOLUTION PROVIDERESOLVEINFORMATION support requests solution software change requests IDENTIFYTRAININGPLAN IDENTIFYHW AND SWUPGRADES RECORDSOFTWARECHANGEREQUESTS

20. The purpose of this process is to analyze software change requests defined during the “support” process so that maintenance changes to the application may be identified and allocated to the appropriate configuration items. This manages basic change control issues and identifies requirements for future releases of the application. IDENTIFY DEFECTS AND ENHANCEMENTS software change requests models requirement alloc. matrix documentation release schedule allocated maintenance changes ANALYSESOFTWARECHANGEREQUESTS PRIORITIZEMAINTENANCECHANGES ALLOCATEMAINTENANCECHANGES TOCONF. ITEMS