Recent and-future-trends spm
Download as PPTX, PDF0 likes282 views
The document discusses principles of software management and development practices. It covers: 1. Establishing iterative lifecycle processes that identify risks early through multiple iterations of problem understanding, solution design, and planning. 2. Transitioning design methods to emphasize component-based development using pre-existing code to reduce custom development. 3. Enhancing change freedom through automated tools that support round-trip engineering and synchronization across different formats and stages of the iterative development process.
Recent and-future-trends spm
- 1. Recent and Future Trends
- 3. Introduction • Continuous Integration was first introduced in the year 2000 with the software known as Cruise Control. • Over the years, Continuous Integration has become a key practice in any software organization. • This is a development practice that calls upon development teams to ensure that a build and subsequent testing is conducted for every code change made to a software program. This concept was meant to remove the problem of finding late occurrences of issues in the build lifecycle. • Instead of the developers working in isolation and not integrating enough, Continuous Integration was introduced to ensure that the code changes and builds were never done in isolation.
- 5. Why Continuous Integration? • The continuous Integration process helps to answer the following questions for the software development team. • Do all the software components work together as they should? – Sometimes systems can become so complex that there are multiple interfaces for each component. In such cases, it’s always critical to ensure that all the software components work seamlessly with each other. • Is the code too complex for integration purposes? – If the continuous integration process keeps on failing, there could be a possibility that the code is just too complex. And this could be a signal to apply proper design patterns to make the code lesser complex and more maintainable.
- 6. Continue • Does the code adhere to the established coding standards? – Most of the test cases will always check that the code is adhering to the proper coding standards. By doing an automated test after the automated build, this is a good point to check if the code meets all the desired coding standards. • How much code is covered by automated tests? – There is no point in testing code if the test cases don’t cover the required functionality of the code. So it’s always a good practice to ensure that the test cases written should cover all the key scenarios of the application. • Were all the tests successful after the latest change? – If a test fails, then there is no point in proceeding with the deployment of the code, so this is a good point to check if the code is ready to move to the deployment stage or not.
- 7. Workflow
- 8. Continuous Integrations Tools • Jenkins (Hudson) • TravisCI • Cruise Control • TeamCity • BuildBot • Bamboo • Team foundation server • Gerrit
- 10. Introduction To Risk • Risk is the possibility of suffering loss. • In a development project, the loss describes the impact to the project which could be in the form of diminished quality of the end product, increased costs, delayed completion, or failure.
- 11. Introduction to Early Risk Resolution • The engineering stage of the life cycle (inception and elaboration phases) focuses on confronting the risks and resolving them before the big resource commitments of the production stage. • Conventional projects usually do the easy stuff first, thereby demonstrating early progress. A modern process attacks the important 20% of the requirements, use cases, components, and risks.
- 12. Continue • The effect of the overall life-cycle philosophy on the 80/20 lesson provides a useful risk management perspective. • 80% of the engineering is consumed by 20% of the requirements. • 80% of the software cost is consumed by 20% of the components. • 80% of the errors are caused by 20% of the components. • 80% of the progress is made by 20% of people.
- 13. Why Do we need Early Risk Resolution • Assess continuously what can go wrong (risks identification and assessment). • Determine what risks are important to deal with (risk prioritization). • Implement strategies to deal with those risk (risk resolution). • Ensure that high priority risks are aggressively managed and that all risks are cost-effectively managed throughout the project.
- 15. • Requirements are capabilities and conditions to which the system—and more broadly, the project—must conform. • A prime challenge of requirements work is to find, communicate, and remember. • The UP promotes a set of best practices, one of which is manage requirements. • This does not refer to the waterfall attitude of attempting to fully define and stabilize the requirements in the first phase of a project, but rather— in the context of inevitably changing and unclear stakeholder’s wishes– “a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system”. Introduction
- 16. Evolutionary Vs Waterfall Requirements • Notice the word changing in the definition of what it means to manage requirements. • The UP embraces change in requirements as a fundamental driver on projects. • That’s incredibly important and at the heart of waterfall versus iterative and evolutionary thinking.
- 17. Skillful Means to Find Requirements • Besides changing, the word finding is important; that is, the UP encourages skillful elicitation via techniques • such as writing use cases with customers, requirements workshops that include both developers and customers, focus groups with proxy customers, and a demo of the results of each iteration to the customers, to solicit feedback
- 18. Types and Categories of Requirements • Functional—features, capabilities, security. • Usability—human factors, help, documentation. • Reliability—frequency of failure, recoverability, predictability. • Performance—response times, throughput, accuracy, availability, resource usage. • Supportability—adaptability, maintainability, internationalization, configurability.
- 19. The “+” in FURPS +Indicates ancillary and sub factors such as • Implementation—resource limitations, languages and tools, hardware,… • Interface—constraints imposed by interfacing with external systems. • Operations—system management in its operational setting. • Packaging—for example, a physical box. • Legal—licensing and so forth.
- 20. Continue • It is helpful to use FURPS+ categories as a checklist for requirements coverage, to reduce the risk of not considering some important facet of the system. • In common usage, requirements are categorized as functional or nonfunctional • Some dislike this broad generalization, but it is very widely used
- 21. Functional Requirements • Functional requirements are explored and recorded in the Use-Case Model, In the system features list of the Vision artifact. • Other requirements can be recorded in the use cases they relate to, or in the Supplementary Specifications artifact.
- 23. Stakeholder and Teamwork's • Stakeholder is any individual or an organization that is actively involved in a project, or whose interest might be affected (positively or negatively) as a result of project execution or completion. • Teamwork is working in partnership with others toward a common goal, a combined action of various individuals, or even just efficient and effective combination with other people. However, just because people working with one another doesn’t mean that they’re participating into a successful teamwork.
- 24. Four steps of Stakeholders Management to complete task of project • Step 1: Identify Your Stakeholders • Step 2: Determine a Stakeholder’s Influence • Step 3: Develop a Communication Management Plan • Step 4: Engage With Your Stakeholders
- 25. Stake Holder Roles • User:- Define the system’s functionality and ultimately make use of it. • Tester:- Test the system to ensure that it is suitable for use. • Developer:- construct and deploy the system from specification. • Other Roles:- • Quick and easy problem solving. • Strong staff relationships. • Healthy competition.
- 26. Benefits of Teamwork • Saves time. • Generate more brilliant and creative idea. • Encourage healthy risk-taking. • Attention to Results • Confront of Accountability • Fearless In Conflict’s • Presence of Trust
- 28. Top 10 Software Management Principles
- 29. 1: Base the process on an architecture first approach: • To start the software development, the developer first thoroughly identifies the requirements then chooses the significant design decision. • Before starting with the lifecycle (development) process check the selected resources are sufficient for complete software development.
- 30. 2:Establish iterative lifecycle process that face risk early: • Today the organizations not follow to define the entire problem at once, design the entire solution, build the software, then test and deploy in sequence. • The organizations adopt follows iterative development approach which facilitates, problem understanding, effective solution, and an effective plan over several iterations. • It also balances the stockholder’s objectives. The main advantage of iterative approach is risks are identified early to avoid software scrap and rework.
- 31. 3:Transition design methods to highlight Component based development: • The developers should transits from line-of-code mentality to component based mentality to reduce the amount of human generated code and custom development. • A component based model is unified set of interface and behavior. Pre-existing line of code either in source or executable format, with a defined
- 32. 4: Establish change management environment: • The dynamics of iterative development, concurrent workflows require the controlled baselines.
- 33. 5: Enhance change freedom through tools that support round trip engineering (iterative): • The iterative development process supports automate and synchronize engineering information in different formats. • Without substantial automation, change management, documentation, and testing it is difficult to reduce project development time. • Change freedom is necessity in iterative process at the same time the role of environment is crucial.
- 34. 6: Capture design artifacts in rigorous, model based notion: • Generally model based approach supports rich graphical and textual design notions. • Visual modeling and formal machine processable language provides good measures than traditional design approach.
- 35. 7: Instrument the process for objective quality control and progress assessment: • Project development progress and the quality should be assessed in the middle of the development lifecycle. • The best assessment mechanisms are derived directly from the engineering artifacts and able to integrate all the activities in the development process.
- 36. 8: Use demonstration based approach to assess intermediate artifacts: • Transit from current development artifacts to executable one to early elimination of architectural defects.
- 37. 9:Plan intermediate releases in groups of usage situations with evolving levels of detail: • It is necessary that the software management process has continuous demonstrations within the operational context. • The evolution of project increments and generations must be equal with current level of understanding of requirements and architecture.
- 38. 10: Establish configurable process that is economically scalable: • No single process is suitable for software development. A practical process framework must be organizing a broad spectrum of applications. • The software development process must integrate economy of scale, development automation, architecture patterns and components.
- 40. • Software Engineering Process • A disciplined approach to assigning and managing tasks and responsibilities in a development organization • goal is to produce a software that is: • Within a predictable schedule and budget • High-quality • Correspondent to the needs of its end users • People involved in software development: • Project managers • Developers •Qualities engineers • Process engineers • Method specialists • System engineers Analysts
- 41. Symptoms of Software Development Failure • Inaccurate understanding of end-user needs • Inability to deal with changing requirements • Modules that don't fit together • Software that's hard to maintain or extend • Late discovery of serious project flaws • Poor software quality • Unacceptable software performance • Team members in each other's way, making it impossible to reconstruct who changed what, when, where, and why • An untrustworthy build-and-release process.
- 42. Root Causes of Software Development Problems • Ad hoc requirements management • Ambiguous and imprecise communication • Brittle architectures • Overwhelming complexity • Undetected inconsistencies in requirements, designs, and implementations • Insufficient testing • Subjective assessment of project status • Failure to attack risk • Uncontrolled change propagation • Insufficient automation
- 43. Software Best Practices • Treat root causes of problems to eliminate symptoms. • To develop and maintain quality software in a repeatable and predictable fashion Successful organizations use best practice as follows: • Develop software iteratively • Manage requirements • Visually model software • Continuously verify software quality • Control changes to software
- 44. Develop Software Iteratively • It offers solutions to the root causes of the software development problem • Serious misunderstandings are made evident early in the lifecycle (when it’s possible to react to them). • It enables and encourages user feedback so as to elicit the system’s real requirements. • The development team is forced to focus on those issues that are most critical to the project and are shielded from those issues that distract them from the project's real risks.
- 45. Manage Requirements • A requirement is a condition or capability a system must have. • The challenge of managing the requirements is how to deal with the change of requirements during the life of a software process. • It is hard to completely and exhaustively state a system's requirements before the start of development. • As a new or evolving system changes, a user's understanding of the system's requirements also changes.
- 46. Visually Model Software • A model is a simplification of reality that completely describes a system from a particular perspective. • Model helps development team visualize, specify, construct, and document the structure and behavior of a system's architecture. • Visual modeling also helps to maintain consistency among a system's artifacts: its requirements, designs, and implementations. • Modeling software visually offers solutions to the root causes of the software development problems.
- 47. Continuously Verify Software Quality • Software problems are 100 to 1,000 times more expensive to find and repair after deployment than beforehand. • It's important to assess continuously the quality of a system with respect to its: functionality, reliability, application performance, and system performance. • Verifying a system's functionality involves creating tests for each key scenario, each of which represents some aspect of the system's desired behavior. As software is developed iteratively, tests are performed at every iteration.
- 48. Control Changes to Software • A key challenge to developing software-intensive systems is to cope with developers organized into teams. In the absence of disciplined control, the development process rapidly degenerates into chaos. • Coordinating activities and artifacts of developers and teams involves establishing repeatable workflows for managing changes to software. • Coordination allows a better allocation of resources based on the project's priorities and risks.
- 50. Introduction • A next generation software cost model should explicitly separate architectural engineering from application production, just as an architecture-first process does. • The cost of designing, producing, testing, and maintaining the architecture baseline is a function of scale, quantity ,quality, technology, process and team skill • Software experts hold widely varying opinions about software economics and its manifestation in software cost estimation models: • Source lines of code versus function points. • Economy of scale versus diseconomy of scale.
- 51. Effort = F( TArch, SArch ,QArch,PArch ) + F(TApp,SApp,QApp,PApp) Time = F( PArch, EffortArch) + F( PApp ,EffortApp ) Where, T = technology parameter S = scale parameter Q = quality parameter P = Process parameter
- 52. Engineering Stage • Risk resolution, low-fidelity plain, schedule/technology-driven, risk sharing contracts • Team Size: • Architecture: Small team of software engineers Application: Small team of domain engineers Small and expert as possible • Product: Executable architecture, Production plans, Requirements • Focus: Design and integration, host development environment • Phases: Inception and elaboration Production Stage • Low risk, high-fidelity plan, cost-driven Fixed-price contracts/funding • Team Size: • Architecture: Small team of software engineers Application: As many as needed Large and diverse as possible • Product: Deliverable, useful function, tested baselines, warranted quality • Focus: Implement, test and maintain , Target technology • Phases: Construction and transition
- 53. Modern Software Economics, Cultural Impact and Denouement
- 54. Modern Software Economics • Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases. • You can compress software development schedules 25% of nominal, but no more. • For every $1 you spend on development, you will spend $2 on maintenance. • Software development and maintenance costs are primarily a function of the number of source line of code. • Variations among people account for the biggest difference in software productivity.
- 55. • Only about 15% of software development effort is devoted to programming. • Software systems and product typically cost times as much per SLOC as individual software programs. Software-system product- an economy of scale is achievable. • Walkthroughs catch 60% of the errors. • 80% of the contribution comes from 20 % of the contributors. • The overall ratio of software to hardware costs is still growing. In 1955, it was 15:85; in 1985, 85:15.
- 56. Culture Shifts • Lower level and mid-level manager are performers. • Requirements ad designs are fluid and tangible. • Ambitious demonstrations are encouraged. • Good and bad project performance is much more obvious earlier in the cycle. • Early increment will be immature. • Artifacts are less important early, more important later. • Real issues are surfaced and resolved systematically. • Quality assurance is everyone’s job, not a separate discipline. • Performance issues arise early in the life cycle. • Investments in automation are necessary. • Good software organization should be more profitable.
- 57. Denouement • Sequentially transitioning from requirement to design to code to rest. • Achieving 100% completeness of each artefact at each life-cycle stage. • Treating all requirements, artifacts, components, and so forth, as equals. • Achieving high-fidelity traceability among all artifacts at each stage in the life cycle.
- 58. Modern Iterative development process Framework • Continuous round-trip engineering from requirements to test at evolving levels of abstraction. • Achieving high-fidelity understanding of the drivers(the 20%) as early as practical • Evolving the artifacts in breadth and depth based on risk management priorities. • Postponing completeness and consistency analyses until later in the life cycle. • A better way to transition to a more mature iterative development process that supports automation technologies and modern architectures is to take the following shots:- • Ready - Do your homework. • Aim – Select a critical project. • Fire – Execute with vigor and follow-through.