Software Project Management..

1. Software Project Management.. presenting PROCESS AUTOMATION Prepared and presented by: ShrutiSogi(1706212) JaspreetKaur(1706213)

2. At a glance…

3. Process Automation • The process automation is required for modern software development projects to operate profitability.. Depends on sort of process and the architecture of the process Mechanizing the process to reduce the manpower efforts.. A wholesome that was actually desired and required.. Better workflow + infrastructure context Time Elapsed is worth the performance

4. Basic Facts for Automation…

5. WORKFLOWS ENVIRONMENT TOOLS AND PROCESS AUTOMATION TOOLS: Automation Building Blocks MANAGEMENT ENVIRONMENT REQUIREMENTS DESIGN IMPLEMENTATION ASSESSMENT DEPLOYMENT PROCESS Life Cycle INCEPTION ELABORATION CONSTRUCTION TRANSITION

6. MANAGEMENT • There are many opportunities for automating the project planning and control activities of the management workflow. • Software cost estimation tools and WBS tools are useful for generating the planning artifacts. • For managing against a plan, workflow management tools and a software project control panel that can maintain an on-line version of the status assessment are advantageous.

7. WORKFLOWS ENVIRONMENT TOOLS AND PROCESS AUTOMATION TOOLS: Automation Building Blocks MANAGEMENT ENVIRONMENT REQUIREMENTS DESIGN IMPLEMENTATION ASSESSMENT DEPLOYMENT PROCESS Life Cycle INCEPTION ELABORATION CONSTRUCTION TRANSITION

8. ENVIRONMENT • Configuration Management and version control are essential in a modern iterative development process. • Most of the iterative approach is dependent on measuring changes in software artifact baselines. • There are some of the change management automation supported by the environment, namely: • Organization Environment • Stakeholder Environment, and more.

9. WORKFLOWS ENVIRONMENT TOOLS AND PROCESS AUTOMATION TOOLS: Automation Building Blocks MANAGEMENT ENVIRONMENT REQUIREMENTS DESIGN IMPLEMENTATION ASSESSMENT DEPLOYMENT PROCESS Life Cycle INCEPTION ELABORATION CONSTRUCTION TRANSITION

10. REQUIREMENTS • Conventional Approach: Component Requirements Unit Requirements

11. REQUIREMENTS…contd VISION STATEMENTS System Requirements • Modern Approach: • Vision statements captures the contract between the development group and the buyer. = EVALUATION CRITERIA

12. Comparing Two Approaches.. • MODERN APPROACH • Time could be utilized as per engineering priorities.. • The info should be evolving but slowly varying.. • The buyers should be understood of the information.. • The lower-level requirements are driven by the process- organized by the iteration- rather than lower-level components.. • Evaluation criteria are derived from vision statements and other considerations.. • CONVENTIONAL APPROACH • The equal treatment of all requirements drained away engineering hours.. • The info is varying but evolving.. • Unit requirements are as prioritized as the system tasks.. • Evaluation criteria are caught in subsequent design understanding

13. Iteration is must… • Iterative process allow the customer and the developer to work with tangible, evolving versions of the system… • Requirements can-andmust be-evolved along with architecture, rather than focusing on consistency and completeness and traceability of the immature requirements specification..

14. Ramification of Modern Approach.. • Requirement is based on textual and model-based representations..so, environment should provide INTEGRATED DOCUMENT AUTOMATION.. • Traceability between requirements and other artifacts needs to be AUTOMATED..

15. DESIGN… VISUAL-MODELING is the primary support Visual modeling is used to capture design models…

16. PROJECT ENVIRONMENT • Three states • The prototyping environment • The development environment • The maintenance environment

17. The prototyping environment • It includes an architecture test bed to evaluate tradeoff during the inception and elaboration phases of life cycle. • It includes following activities:- • Performance trade-off and technical risk analyses. • Fault tolerance/dynamic reconfiguration trade-offs. • Analysis of risk associated with transitioning to full scale implementation. • Development of test scenarios ,tools suitable for analyzing the requirements.

18. The Development Environment • It includes a full suite of development tools needed to support the various process workflows and to support round trip engineering to the maximum extent possible.

19. The Maintenance Environment • It coincides with a mature version of development environment. Maintenance should be applied when project is completed.

20. Four important environment disciplines

21. Round Trip Engineering. • Round Trip Engineering is the environmental support necessary to maintain consistency among the engineering artifacts. • The primary reason for Round Trip Engineering is to allow freedom in changing software engineering data source. • This configuration control of all the technical artifacts is crucial to maintaining a consistent and error free representation of evolving product. • Translation of one data source to another may not provide 100% completeness.

22. Portability among platforms and network topologies Round trip engineering

23. Change management Change management is as crucial to iterative process as planning. Tracking changes in the technical artifacts is crucial to understanding the true technical progress trends and quality trends towards delivering an acceptable end product or interim release. Now change management has become fundamental to all phases and almost all activities.

24. Software Change Orders • The atomic unit of software work is authorized to create ,modify, or obsolesce components within a configuration baseline is called a SCO. • SCO are key mechanism for partitioning, allocating, and scheduling software work against an established software baseline and for assessing progress and quality. • The level at which SCO is written is always an issue. What is a discrete change?, Is it a change to a program unit or component?, Is it a new feature?.

25. BASIC FIELDS OF SCO. • Title :-The title is suggested by the originator and is finalized by the CCB. • Description:-The problem description includes name of originator, date of origination, CCB assigned SCO identifier and relevant version identifiers of related support software. • Metrics:-The metrics collected for each SCO are important for planning ,scheduling, and for assessing quality improvement.

26. SCO cont…….. • Resolution :-This field includes the name of person responsible for implementing the change , the components changed, the actual metrics and a description of the change. • Assessment :-This field describes the assessment technique as either inspection ,analysis, demonstration, or test • Disposition :-The SCO is assigned one of the following states by the CCB.

27. SCO Contd….. • Proposed • Accepted • Rejected • Archived • In Progress

28. Configuration Baseline • A configuration baseline is a named collection of software components and supporting documentation that is subject to a change management and is upgraded, maintained, tested, statused, and obsolesced as a unit. • There are two classes of baselines • External Product Baseline • Internal Testing Releases

29. Change categories • Type 0 :-Critical failures, which are defects that are nearly always fixed before any external release. • Type 1 :-A bug or defect • Type 2 :-A change that is enhancement rather than a response to a defect. • Type 3 :-A change that is necessitated by an update to the requirement. • Type 4 :-Changes that are not accommodated by other categories, example includes documentation only or a version upgrade to commercial components.

30. Configuration Control Board • A CCB is a team of people that functions as the decision authority on the content of configuration baseline. • A CCB usually includes the software manager, software architecture manager, software development manager, software assessment manager, and other stakeholders.

31. THANK YOU