Software Engineering

14.4.1 
Assess developmental implications
Each alternative should be evaluated to determine the work involved with imple-
menting the design approach within the project and technical plans. The integrated 
master plan, schedule, and technical work packages should be reviewed to deter-
mine how the alternative corresponds to and complements the anticipated work 
assignments. The software engineering team must negotiate the adjustment of tech-
nical plans, schedules, and work packages with software development organiza-
tions. The objective is to ensure that the effort to pursue an architectural solution 
can be accommodated within established organizational resources.
Elements of architectural solutions may challenge the competencies of devel-
opment organizations to assimilate a design solution within their plans. Each 
challenge should be identified as a technical risk to the adoption of a proposed 
architectural solution. Technical risks should be mitigated in a manner that presents 
an inconsequential liability to achieving project objectives. Development factors 
involve the ability to implement, test, and deploy the software product. Associated 
factors involve software operational stability, usability, user training and educa-
tion, and software sustainment. This may necessitate the adoption of an innova-
tive or unconventional programming paradigm, language, or computing platform. 
It is important to ensure that the full range of software product life-cycle factors is 
addressed before adopting an architectural design solution. The integrated product 
and process (IPPD) philosophy embraces considering the complete life-cycle set of 
factors when evaluating architectural design alternatives.