1 / 32

Software Project Management..

Software Project Management. presenting PROCESS AUTOMATION Prepared and presented by: Naveesha Saharan (1706222) Ruchi Goyal (1706232). At a glance…. Process Automation. Depends on sort of process and the architecture of the process.

linus-jenkins
Download Presentation

Software Project Management..

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Project Management.. presenting PROCESS AUTOMATION Prepared and presented by: Naveesha Saharan (1706222) RuchiGoyal (1706232)

  2. At a glance…

  3. Process Automation Depends on sort of process and the architecture of the process Mechanizing the process to reduce the manpower efforts.. • The process automation is required for modern software development projects to operate profitability.. • By the way..What is • PROCESS AUTOMATION? 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 TOOLS: Automation Building Blocks ENVIRONMENT TOOLS AND PROCESS AUTOMATION 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 TOOLS: Automation Building Blocks ENVIRONMENT TOOLS AND PROCESS AUTOMATION 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 TOOLS: Automation Building Blocks ENVIRONMENT TOOLS AND PROCESS AUTOMATION 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 • Modern Approach: • Vision statements captures the contract between the development group and the buyer. VISION STATEMENTS System Requirements = 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-and must 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. WORKFLOWS TOOLS: Automation Building Blocks ENVIRONMENT TOOLS AND PROCESS AUTOMATION MANAGEMENT ENVIRONMENT REQUIREMENTS DESIGN IMPLEMENTATION ASSESSMENT DEPLOYMENT PROCESS Life Cycle INCEPTION ELABORATION CONSTRUCTION TRANSITION

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

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

  18. 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.

  19. 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.

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

  21. Four important environment disciplines

  22. 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.

  23. Portability among platforms and network topologies Round trip engineering

  24. 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.

  25. 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?.

  26. 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.

  27. 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.

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

  29. 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

  30. 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.

  31. 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.

  32. THANK YOU

More Related