This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
TASCIEEE and Standards DevelopmentIEEE and Standards Development
Software and Systems Engineering StandardsCommittee (S2ESC)“To provide a family of products and services based on softwareengineering standards for use by practitioners, organizations, andeducators to improve the effectiveness and efficiency of their softwareengineering processes, to improve communications between acquirersand suppliers, and to improve the quality of delivered software andsystems containing software.”
In 1996 and 1998 S2ESC conducted two web-based softwareengineering users surveys, the results of these surveys indicated thatusers perceived the standards provided the most value when applied asguidance in support of software process improvement efforts.
TASCCMMI-SW (Staged) Level 2 PAsCMMI-SW (Staged) Level 2 PAs
Level 2 organizations must demonstrate 125 key practices!Level 2 organizations must demonstrate 125 key practices!
Maturity LevelMaturity Level Process Area (PA) NameProcess Area (PA) Name # of KeyPractices# of KeyPractices
5Optimizing
Organizational Innovation and DeploymentCausal Analysis and Resolution
1917
4Quant.Managed
Organizational Process PerformanceQuantitative Project Management
1720
3Defined
Requirements DevelopmentTechnical SolutionProduct IntegrationVerification/ValidationOrganizational Process FocusOrganizational Process DefinitionOrganizational TrainingIntegrated Project ManagementRisk Management
202121201917192019
2Managed
Requirements ManagementProject PlanningProject Monitoring and ControlProcess and Product Quality AssuranceConfiguration ManagementSupplier Agreement ManagementMeasurement and Analysis
TASCCMMI-SW Level 2 / The SpecificsCMMI-SW Level 2 / The Specifics
Requirements Management. Manage requirements associated with a projectand identify inconsistencies between the requirements and the project planand associated work products.
Project Planning. Planning in support of project activities.
Project Monitoring and Control. Processes supporting the effectivemanagement of a software project.
Process and Product Quality Assurance. Activities associated with softwareproject oversight.
Configuration Management. Processes in support of the definition, control,review, and reporting of the work products associated with a software project.
Supplier Agreement Management. Processes supporting the acquisition ofproducts from suppliers for which there exists a formal agreement.
Measurement and Analysis. Processes supporting the development,maintenance, and implementation of software project measurement activities.
TASCDefine and Train the Process Team (Initiate)Define and Train the Process Team (Initiate)
Identify a group of people who are givenresponsibility and authority for improvingorganizational processes:
• Implementing process improvement can be very time-consuming, depending upon the scope and complexity of theeffort.• Expectations for each team member’s time commitments andjob responsibilities must be modified accordingly to reflect thenew responsibilities.• This commitment should reflect time budgeted for processdefinition and improvement and any required refresher training.
IEEE software engineering standards provide valuable support tothe process team. The standards should be used to help define anddocument the initial baseline of recommended processes andpractices.
• The leap from chaos (Level 1) to Level 2 is often the hardeststep for many organizations.
• Defining the initial process baseline is key, in order tounderstand where the organization needs to be; it must firstunderstand where it is.
• Use the CMMI®-SW Level 2 and Level 3 goals to identify areasof weakness or bottlenecks in existing processes. Then refer toeach of the appropriate IEEE Software Engineering standardsusing them as planning tools and as checklists to be consideredwhen determining how to accomplish process completeness.
• It is important to identify which organizationalprocess plans will be developed and thesequence of their development.
Goal driven process improvement is the most effective. Identifyshort and long term goals and time periods; associate thesegoals as schedule milestones.
(0-3 months)• Identify responsible individuals.• Identify participating project managers.• Identify candidate projects.• Solidify backing of Senior Management.• Look at existing processes.• Define the formats for your process plans using IEEE Software
Engineering Standards and measure them against the CMMI®requirements.
• Get project members to provide feedback on process plans,review and incorporate feedback.
TASCBaseline and Implement Processes (Act)Baseline and Implement Processes (Act)
Use IEEE standards to develop your baseline processdocumentation.
• Once a process baseline has been established formulate anaction plan.
• It is also important to evaluate and identify any potential toolsthat may be used in support of process automation:– A tool is not a substitute for a process.– An ideal candidate area for this type of automation is SCM.–
• Many IEEE SWE standards provide documentation templatesand describe in detail what the processes should contain.
Think of these standards as an in-house software processconsultant who has recommended, based upon years ofexperience, the proper methodologies and techniques to beused in support of software development.
• Software Life Cycle– IEEE/EIA 12207.0, Industry Implementation of International
Standard ISO/IEC12207:1995 —Standard for InformationTechnology —Software life cycle processes• IEEE/EIA 12207.1, Industry Implementation of International Standard
ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for InformationTechnology —Software life cycle processes – Life Cycle Data
• IEEE/EIA 12207.2, Industry Implementation of International StandardISO/IEC12207:1995 — (ISO/IEC 12207) Standard for InformationTechnology —Software life cycle processes – Implementationconsiderations
• Systems Life Cycle– ISO/IEC 15288, Systems engineering —System life cycle processes
IEEE Std 830-1998, IEEE Recommended Practice forSoftware Requirements Specifications.
Outlines the requirements for what comprises a good SoftwareRequirements Specification (SRS):
• Establishes the basis for agreement between the customers andthe suppliers on what the software product is to do.
• Reduces the development effort.• Provides a basis for estimating costs and schedules.• Provides a baseline for validation and verification.• Facilitates transfer.• Serves as a basis for enhancement.
Does not directly address Requirements Traceability!
TASCPA - Project Monitoring and ControlPA - Project Monitoring and Control
Simply initially estimating the duration and total cost of asoftware effort is not sufficient.
• Planning must continue throughout the software developmentand maintenance process.
• Project monitoring (tracking) and control of the managementprocess encompasses most of the development process.
This includes all activities that project management has toperform to ensure that the project objectives are met andthat development proceeds according to the plan.
• Monitor cost, schedule, quality, and potential risk.
TASCPA – Process and Product Quality AssurancePA – Process and Product Quality Assurance
• The purpose of IEEE Std 730-1998 is to provideuniform, minimum acceptable requirements for thepreparation and content of Software Quality AssurancePlans:
• Recommended approaches to good SQA practices aredescribe in IEEE Std 730.1-1995.
Combined, these two plans describe the requirements in supportof industry standard SQA practices.
“SCM constitutes good engineering practice for all software projects,whether phased development, rapid prototyping, or ongoing maintenance.It enhances the reliability and quality of software by providing a structurefor identifying and controlling documentation, code, interfaces, anddatabases to support all life cycle phases supporting a chosendevelopment/maintenance methodology that supports the requirements,standards, policies, organization, and management philosophy producingmanagement and product information concerning the status of baselines,change control, tests, releases, audits, etc.”
The plan basically provides a framework fororganizations to follow. Use of this standard offers a
Examine each CMMI Level 2 Key Practice (Co, Ab, Me, Ve, and Ac).
Identify supporting portions of IEEE standards. Do not consider eachstandard in isolation, rather consider the complete set of those mostdirectly supporting CMMI Level 2 items.
Document your processes using the IEEE standards and Level 2capabilities.
• Small projects may require less formality in planning thanlarge projects, but all components of each standard shouldbe addressed by every software project.
• Components may be included in the project leveldocumentation, or they may be merged into a system-levelor business-level plan, depending upon the complexity ofthe project.
TASCWhat to watch out for..What to watch out for..
Each organization using IEEE standards should develop aset of practices and procedures that provide detailedguidance for preparing and updating plans based uponstandards.
• There are some holes relating to PT&O and metrics.
• Pay special attention to CMMI general requirements.
• Funding for process improvement activities is notspecifically referenced in IEEE plans, this must beincluded in the project management plan.
• Need to specifically address requirementstraceability throughout product lifecycle.
IEEE/EIA Standard 12207.0-1996, Industry Implementation ofInternational Standard ISO/IEC12207:1995 — (ISO/IEC12207) Standard for Information Technology —Softwarelife cycle processes, Institute of Electrical and ElectronicsEngineers, Inc. New York, NY, 1998.
IEEE/EIA Standard 12207.1-1997, Industry Implementation ofInternational Standard ISO/IEC12207:1995 — (ISO/IEC12207) Standard for Information Technology —Softwarelife cycle processes – Life cycle data, Institute of Electricaland Electronics Engineers, Inc. New York, NY, 1998.