Under 1000 messages now.

Day 2…

  • A basis for selecting the permanent members to the PPQA (Product and Process Quality Assurance) team is that it should have the members who are proficient in their phases of SDLC. For example, it would 2 members from Development, 2 from Testing (1 manual and 1 automation) 2 from SQA, 1 person having On-site experience, 2 members having knowledge of all the tools used in the organization.
  • A tool to help guide appraisals. Could be handy in doing self-assessments.
  • There is a difference though between just having good people and having good people and a good method.
  • International Function Point Users Group
  • Risk
    • Risk management is everywhere. You can not say that PMC or PPQA is enough to “replace” RISK management. It only support risk management…
    • Risks must be identified, systemized, must have response plan when you plan for your project (PP). That response plan will impact the way project decides training plan, process (IPM), resources, requirement (REQM/RD), outsource/supplier (SAM/ISM)…
  • Requirements Management for Small Organizations
  • Delivery Audit
    • All the Process Areas include GP 2.9 (VE 1) Objectively Evaluate Adherence
    • Objectively evaluate adherence of the project monitoring and control process against its process description, standards, and procedures, and address noncompliance, which is audit kind function. And delivery audit is very important to ensure (before delivery) that all steps (actvities including GP2.9 & PPQA) have been undertaken to ensure ‘quality’ of the delivery.
  • The purpose of Product Integration is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product. The Product Integration process area establishes the expected specific practices associated with generating the best possible integration sequence, integrating product components and delivering the product to the customer. Product Integration uses the specific practices of both Verification and Validation in implementing the product integration process. Verification verifies the interfaces and interface requirements between product components prior to product integration. This is an essential event in the integration process. During product integration in the operational environment, the specific practices of the Validation process area are used.
  • ML3 requires that all processes be tailored versions of the organisation’s standard processes (note the plural). It is NOT required that all instantiations of a process be identical.
  • RTM (Requirements Tracibility Matrix
    • Start with user stories or use cases written by the users. Focus on scenarios, actors, and system interfaces. Don’t talk about user interface design too much. Call these the Business Use Cases/User Stories. When the users start wanting to see “what the screens look like,” it’s time to move on.
    • For each Business Use Case Scenario/User Story, define one or more system use cases. Create a set of system use cases that you are confident encompasses the scope of the business use cases. Kulak and Guinney call this the ‘Facade’ stage. Look to factor out system use cases according to existing or planned system structure.
    • Limit each system use case to a single scenario. If an exception or variation cannot be described with a single, simple statement, place it into its own use case at first. Ivar Jacobson and others cringe at the number of use cases at this stage, but it’s easier to combine use cases than split them in later stages.
    • The goal description of the system use case can be considered to be a user requirement. Write as “shall” statements.
    • The steps in the system use case scenario can be considered to be functional requirements.
    • Once you’ve captured all of the information from the Business Use Cases/User Stories in this fashion, you’re at what Kulak and Guiney call the ‘Filled’ stage.
    • Review the System Use Cases with the users who wrote the Business Use Cases/User Stories to ensure you’ve captured their desires. There will be changes. You can talk more about user interface design now.
    • Refine the system use cases to specify details about interfaces and data (formats, validation, etc.) Start recording quality attribute information (e.g. performance, the “-ilities”, etc.) This is Kulak
      and Guiney’s “Filled” stage. Start to compose sequence and collaboration models.
  • The intent of the REQM PA is to enable the development team to keep requirements in synch with the rest of the project activities.
  • Commitments
    • For projects with a waterfall life cycle, the committments are generally made at periodic reviews (e.g. Preliminary Requirements Review, Critical Design Review, etc.)
    • For iterative or agile life cycles, committments may be made at regular daily/weekly/monthly meetings.
    • The method you use to document the committment is up to you.
    • Large, formal waterfall projects typically have signature sheets for every artifact. Less formal (and more agile) projects may record approval votes from regular meetings in meeting minutes.
  • Maintenance
    • Many maintenance projects encompass all 3 types of maitenance work.
    1. Corrective (bug fixes if you like)
    2. Preventive (making changes so that the resulting software will be robust and easier to maintain, aka refactoring)
    3. Enhancement (adding new features to the software/system).
  • The CMMI should be used to supplement existing good practices, not to completely replace them
  • Group – The collection of departments, managers, and individuals who have responsibility for a set of tasks or activities. A group could vary from a single individual assigned part time, to several part-time individuals assigned from different departments, to several individuals dedicated full time.
  • QA people can be part-time, a dedicated number of hours per month, but be independent (cmmi term “objective”) from the work they are QAing.
  • As with the entire model, you need to achieve the goal; always think goal-oriented. If you use one document for your whole project or you have hundreds of documents, a lead assessor won’t care.
  • Process is a set of interrelated or interacting activities, which transforms INPUT in to OUTPUT
  • Procedure is specified way to carryout an activity or a process.
  • Waterfall projects are often concerned with “managing requirements creep” and “controlling schedule changes”. Agile projects are not concerned with these issues in the same way that waterfall projects are.
  • PPTS – Project Planning and Tracking System. A WEB-based environment supporting teams who have chosen to develop software according to the agile methodologies Scrum and/or eXtreme Programming.
  • Certifying for CMM Level 2 and ISO 9000 with XP & Scrum
  • Agile Methods and Process Disciple from CrossTalk – The Journal of Defense Software Engineering
  • Managing Knowledge Capability and Maturity
  • SLOCCount – A tool for doing line counts on large projects
  • An Empirical Study of Process Discipline and Software Quality
  • Performing Earned Value Analysis with MS Project
  • Applications of the Indicator Template for Measurement and Analysis
  • Avoiding Failure in SPI Initiation
  • Making SPI Happen: The Roads to Process Implmentation
  • Using Continuous Models as “Dynamic and Specific Staged Models” for Process Improvement