Selection of a suitable lifecycle for the project/product is more of a technical issue. Then why is it covered in Integrated Project Management (IPM) rather than Technical Solution (TS)?
Selecting a suitable lifecycle is a function of the project requirements and the application domain. The selection is something that should be performed when planning the project activities, not while performing the actual software engineering activities. Selecting a lifecycle model and defining the project’s lifecycle phases are necessary for planning and estimating the project. That is why lifecycles appear in Project Planning (SP 1.3) and Integrated Project Management (sub-practice 1 of SP 1.1) . The selection of the lifecycle is a project management activity.
From another perspective, the purpose of Technical Solution is to design, develop, and implement solutions to requirements. And selecting an appropriate lifecycle model is an activity that needs to be done before you can design, develop, and implement a solution to the requirements.
Showing posts with label Technical Solution. Show all posts
Showing posts with label Technical Solution. Show all posts
Friday, October 16, 2009
Monday, June 30, 2008
Does "interface" in CMMI include user interface ?
In interpreting RD SP2.3 "Identify interface requirements", someone told me that the interfaces can also include man-machine interface, or so-called user interface. But the model says "Interface between functions (or between objects) are identified", at first, I thought that the definition of "interface" in CMMI does not include user interface. But however, in some software development methodologies (e.g. object-oriented), the users are also considered as objects, so, maybe user-interface is also a kind of interface? The same question is also in TS SP2.3 "Design interfaces using criteria", PI SP 2.1 "Review interface descriptions for completeness", and PI SP2.2 "Manage interface."
The interface requirements referred to in Requirements Development (RD) Specific Practice (SP) 2.3, Technical Solution (TS) SP 2.3, and Product Integration (PI) SP2.1 and 2.2 cover ALL interfaces. Keep in mind that you have to do whatever is right for your organization and your projects. If the user interface is important to your project and product, then it should be included in the interfaces covered by the referenced SPs.
The interface requirements referred to in Requirements Development (RD) Specific Practice (SP) 2.3, Technical Solution (TS) SP 2.3, and Product Integration (PI) SP2.1 and 2.2 cover ALL interfaces. Keep in mind that you have to do whatever is right for your organization and your projects. If the user interface is important to your project and product, then it should be included in the interfaces covered by the referenced SPs.
Tuesday, June 24, 2008
TS SP 2.2 Establish a Technical Data Package
During our implementation of the Technical Solution (TS) Process Area (PA) we had some discussions on how to implement the Technical Data Package.
Is this Specific Practice (SP) expecting just the design documents with the generic artifacts captured as part of CM plan or SMP deliverables?
OR
Is this SP requiring explicit capture of all the applicable technical data like architecture, data sheets, other technical articles, etc. as a section of the design document?
The quick answer is yes. First go to the CMMI Glossary and look up “technical data package.” There you will find a “shopping list” of the typical contents of the technical data package. The contents of the package are a function of where you are in the development lifecycle. Early in the lifecycle there won’t be a lot of content, but at the end of the lifecycle there should be a lot of information. The organization should decide on what the standard contents of the technical data package should be and then each project will tailor this list for its particular needs.
The purpose of the technical data package is to provide the developer with a comprehensive description of the product or product component as it is developed throughout the lifecycle. You have to decide what the necessary documents and information are to provide a comprehensive description.
Is this Specific Practice (SP) expecting just the design documents with the generic artifacts captured as part of CM plan or SMP deliverables?
OR
Is this SP requiring explicit capture of all the applicable technical data like architecture, data sheets, other technical articles, etc. as a section of the design document?
The quick answer is yes. First go to the CMMI Glossary and look up “technical data package.” There you will find a “shopping list” of the typical contents of the technical data package. The contents of the package are a function of where you are in the development lifecycle. Early in the lifecycle there won’t be a lot of content, but at the end of the lifecycle there should be a lot of information. The organization should decide on what the standard contents of the technical data package should be and then each project will tailor this list for its particular needs.
The purpose of the technical data package is to provide the developer with a comprehensive description of the product or product component as it is developed throughout the lifecycle. You have to decide what the necessary documents and information are to provide a comprehensive description.
Subscribe to:
Comments (Atom)