Principles of conventional software Engineering

1. Make quality
2. High quality software is possible
3. Give products to customer early
4. Determine the problem before writing the requirements.
5. Evaluate design alternatives
6. Use an appropriate process model
7. Use different language for different phases.
8. Minimize intellectual distance.
9. Put techniques before tools.
10. Get it right before u make it faster.
11. Inspect code
12. Good management is more important than good technique.
13. People are the key to success.
14. Follow with care
15. Take responsibility
16. Understand the customers priorities
17. The more they see, the more they need
18. Plan to throw one way
19. Design the change
20. Design without documentation is not the design
21. Use tolls but realistic
22. Avoid tricks
23. Encapsulate
24. Use coupling and cohesion
25. Use the McCabes complexity measure
26. Dont test your own software
27. Analyze causes for errors
28. Realize the software entropy increases
29. People and time are not interchangeable
30. Expect excellence

PRINCIPLES OF MODERN SOFTWARE MANAGEMENT

Focus the process on ARCHITECTURAL FIRST APPROACH.

Attacks risks early with an ITTERATIVE LIFE CYCLE
Emphasis the COMPONENT BASED DEVOLOPEMENT
Establish a CHANGE MANAGEMENT ENVIRONMENT.
Enhance change freedom with tools for SUPPORTS ROUND-TRIP
ENGINEERING.
Use Rigorous MODEL BASED NOTATIONS
Instrument the process for OBJECTIVE QUALITY CONTROL
Use DEMONSTRATION BASED ASSESMENT for intermediate
Artifacts.
Plan release with EVOLVING LEVEL OF DETAIL
ESTABLISH A SCALABLE,CONFIGURABLE PROCESS

MODERN PROCESS APPROCHES FOR SOLVIN CONVENTIONAL

PROBLEMS
Attribute of skilled workers / QCS / Good Management
planning,successful early iteration.
Insufucient performance / Q /component based
Insufucient function/Q/iterative development
Advertaisel of stake holeder/CS/model based design notations
TRANSITIONING TO AN ITERATIVE PROCESS
PROCESS FLEXIBILITY:change management
APPLICATION PRECEDENTEDNESS :domain expirence
SOFTWARE PROCESS MATURITY:Software process
assesments are based on CMM ,software development
process risks depends on the domain expirence

 ARCHITECTURAL RISK RESOLUTION:

TEAM COHESION:
LIFE CYCLE PHASES
LIFECYCLE STAGES;
ENGINEERING STAGEINCEPTION
ELABORATION
PRODUCTION STAGE CONSTRUCTION
TRASITION
ENGINEERING STAGE:team focus on design and synthesis
Inception : to achive concurens among the stakholders on
the life cycle objective.
Elaboration:it is the last stage of the engg stage and here it
reckoning the project and take the decision that need to take the
project to production or not.
PRODUCTION STAGE:Large teams concentrated in construction
depolayment and testing .it is composed on construction and
transition.
Construction :it represent a process of production.
Which involves schedule,quality,optimize costs,controlling
operations.
Trasisiton:it enter when the base line of the project is
reached and the end user product is released with beta version.

ENGINEERING AND PRODUCTION STAGES

Engineering stage:2 risk reduction factors
Schedule
Technical feasibility
Production Stage. All phaces & diag
INCEPTION PHACE
Primary Objectives:
1. Understand what to build. Determine an overall vision,
including the scope of the system and its boundaries. Identify
the stakeholders: who is interested in this system and what
are their success criteria?
2. Identify key system functionality. Decide which requirements
are most critical.
3. Determine at least one possible solution. Assess whether the
vision is technically feasible. This may involve identifying a
candidate high-level architecture or doing technical
prototypes, or both.
4. Understand the high-level estimate for cost, schedule, and
risks associated with the project.
ESSENTIAL ACTIVITIES:
Devoloping the scope of the project
Building a Architecture
Planning and Producing a Business plan.
PRIMARY ACTIVITIES:

ELABORATION PHACE:nan excutabble architecture is build in

one are more iterations.
PRIMARY OBJECTIVES:

Get a more detailed understanding of the

requirements. Having a good underst'anding of the majority
of requirements enables you to create a more detailed plan
and to get buy-in from stakeholders. Be sure to gain an indepth understanding of the most critical requirements to be
validated by the architecture.
Design, implement, validate, and establish the baseline for the
architecture. Design, implement, and test a skeleton
structure of the system. Although the functionality is not
complete yet, most of the interfaces between the building
blocks are implemented and tested. This is referred to
as an executable architecture.
Mitigate essential risks, and produce accurate schedule and
cost estimates. Many technical risks are addressed as a result
of detailing the requirements and of designing,
implementing, and testing the architecture. Refine and detail
the high-level project plan.

ESSENTIAL ACTIVITIES
Vision eloboratin
Process elaboration
architecture elaboration
Primary evalution:

CONSTRUCTION PHASE
PRIMARY OBJECTIVES:
reduce development cost
avoide unnesesary rework
gain desired quality
obtain the useful version
ESSENTIAL ACTIVITIES
controllling and maintiaing the resource and process
optimization
complete component development
Estimate Product release date based on criteria
Primary Evalution:
TRANSITION PHASE
PRIMARY OBJECTIVES
1. Beta test to validate that user expectations are met. This
typically requires some fine-tuning activities, such as bugfixing and making enhancements for performance and
usability.
2. Achieve stakeholder concurrence that deployment is
complete. This may involve various levels of tests for product
acceptance, including formal and informal tests and beta
tests.
ESSENTIAL ACTIVITIES :same as above objectives

3. Improve future project performance through lessons

learned. Document lessons learned and improve the process
and tool environment for the project.
IMPROVING AUTOMATION THROUGH SOFTWARE ENVIRONMENT
Upto 20 to 40% of eefort is reduced .software is developed
using automated tools editprs,gui,.import contribution of
environment is to minize the iterations or improveing the
effiency
50% of project resources can be consume bytesting
30% o fproject resources can be conseum by documentation
activities
50% of testing and coding activities
In large-scale projects 25% change management configuration
control
In LS 30% consume business administration
245% is out bounded over the project budjet
ROUNDTRIP ENGG
REVERSE ENGG
FORWARD ENGG