Question

1.Discuss the following system development methods

Structured development – Object oriented development – Agile development – Rapid Application Development

2.What is project creep? Which system development methods are more prone to project creep? What could be a strategy to avoid it?

Answer 1

Answer:-

1)ans

Structured development:-

The structured design approach helps developers deal with the size and complexity of large scale projects. The structured approach is a process oriented approach, aiming to break a large complex project into a series of smaller, more manageable modules.

The Structured approach is usually associated with projects that have the following characteristics :

• long time periods : The time involved in a structured approach is generally measured in months, or even years.

• large-scale projects : The structured approach is usually applied to large projects which involve a huge amount of detail and coordination between various parts of the business and other systems.

• large budgets : Large projects will involve a large number of people and will employ them over a long time scale. The budget, consequently, will be large. New hardware and software is often required for completion of the project, elevating the cost of the project - though the amount spent upon personnel is usually the highest cost factor.

This approach, however, may be implemented as part of each of the other design approaches studied in this course. For example, an end user creating their own solution to a problem, may follow ( in a simplified form) the steps of the structured approach. Similarly, the Rapid Application Development paradigm is an iterative approach (meaning the product may undergo many "incarnations" before a final product is developed). Each of the iterations may follow a simplified structured design approach.

The steps of the Structured approach are as follows :

• Defining the problem. In this stage, the requirements for the software are gathered and analyzed, to produce a complete and unambiguous specification of what the software is required to do. The problem will need careful analysis so that the "true" issues involved are identified. For example, if your car won't start, your "problem" is "My car is not working". However, this is merely an analysis of the "symptoms". Deeper analysis may reveal that there is no petrol in the car, or the battery is flat or some other problem. Until the true cause of the problem is discovered, a useable solution can not be developed. This stage is sometimes called Requirements Analysis.

• Planning. During this phase, a software architecture for the implementation of the requirements is designed and specified, identifying the components within the software and the relationships between the components. Inputs, Outputs and Processes required for the new system are identified and a basic plan in the form of flowcharts or pseudocode are developed. A "Top Down" approach would almost certainly be used. This involves breaking a larger and complex problem into smaller more manageable modules - each module being coded separately. Thus, a structure chart is an important document developed during this phase. This stage is sometimes called Architectural and Detailed design.

• Building. This is the Code and Test phase, in which each component of the software is coded and tested to verify that it faithfully implements the detailed design outlined in the previous phase. Finally, once all of the modules have been coded and tested the software is integrated. Progressively larger groups of tested software components are integrated and tested until the software works as a whole. This process is sometimes called Software Integration.

• Checking the solution. This involves Acceptance Testing, where tests are applied and witnessed to validate that the software faithfully implements the specified requirements. Real data may be used and this is compared to outputs from a previous system. The system may also be tested under full load. A program may work well for a small data set, but have problems when thousands or millions of records and transactions are required of it. Beta testing may be used during application software development. Users are also involved in this process to ensure that their expectations of the system are fulfilled. In addition to the feedback that the development team receives, users also benefit by being able to use the system. In addition to checking that the program can process the data correctly, the user interface is evaluated for ease of use and intuitive design.

• Modifying the solution. During the testing phase, problems or possible improvements (from beta testing) may be found. If problems are found, modifications may be made to solve the problems and another round of testing will occur.

Object oriented development:-

The terms object and object-oriented are applied to different types of entity, design methods, systems and programming languages. An object-oriented system is made up of interacting objects that maintain their own local state and provide operations on that state. There is a general acceptance that an object is an encapsulation of information. The representation of the state is private and cannot be accessed directly from outside the object [ 1 ] [ 2 ] [ 4 ].

An object is an entity that has a state and a defined set of operations that operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects that request these services when some computation is required. Objects communicate by exchanging the information required for service provision. The copies of information needed to execute the service and the results of service execution are passed as parameters.

Objects are created according to an object class definition. An object class definition is both a type specification and a template for creating objects. It includes declarations of all the attributes and operations that should be associated with an object of that class.

Object-oriented design processes involve designing object classes and the relationships between these classes. These classes define the objects in the system and their interactions. When the design is realised as an executing program, the objects are created dynamically from these class definitions.

Object-oriented design is part of object-oriented development where an object-oriented strategy is used throughout the development process:

1. Object-oriented analysis. It is concerned with developing an object-oriented model of the application domain. The objects in that model reflect the entities and operations associated with the problem to be solved.

2. Object-oriented design. It is concerned with developing an object-oriented model of a software system to implement the identified requirements.

3. Object-oriented programming. It is concerned with implementing a software design using an object-oriented programming language, such as Java.

The transition between these stages of development should, ideally, be seamless, with compatible notations used at each stage. Moving to the next stage involves refining the previous stage by adding detail to existing object classes and devising new classes to provide additional functionality.

The object-oriented systems might have some advantages in comparison to systems, which have been developed with other methods, for example realizing changes with an object-oriented system can be easier because the objects are independent. They may be understood and modified as standalone entities. Changing the implementation of an object or adding services should not affect other system objects.

Objects are, potentially, reusable components because they are independent encapsulations of state and operations. Designs can be developed using objects that have been created in previous designs. This reduces design, programming and validation costs. It may also lead to the use of standard objects and reduce the risks involved in software development.

In 1990s several object-oriented design methods have been proposed and the Unified Modelling Language (UML) became a unification of the notations used in these methods. In year 2000 the UML was accepted by the International Organization for Standardization (ISO) as a standard for modelling software-intensive systems [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 9 ] [ 18 ].

In the UML, an object class is represented as a named rectangle with two sections. The object attributes are listed in the top section. The operations that are associated with the object are set out in the bottom section. Figure 5.1. illustrates this notation using an object class that models an employee in an organisation. The UML uses the term operation to mean the specification of an action; the term method is used to refer to the implementation of an operation.

Agile development :-

Agile software development is more than frameworks such as Scrum, Extreme Programming or Feature-Driven Development (FDD).

Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions and sprints.

Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.

One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.

There’s a big focus in the Agile software development community on collaboration and the self-organizing team.

That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.

It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.

There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.

When most teams and organizations start doing Agile software development, they focus on the practices that help with collaboration and organizing the work, which is great. However, another key set of practices that are not as frequently followed but should be are specific technical practices that directly deal with developing software in a way that help your team deal with uncertainty. Those technical practices are essential and something you shouldn’t overlook.

A Short History of Agile

Here is a look at how Agile emerged, how it acquired the label Agile, and where it went from there. It’s important to take a look at where Agile software development came from to get an understanding of where things are at today.

Pre 2001 – Practices and Methods Develop Independently through Experience

A lot of people peg the start of Agile software development, and to some extent Agile in general, to a meeting that occurred in 2001 when the term Agile software development was coined.

However, people started working in an Agile fashion prior to that 2001 meeting. Starting in the mid-nineties, there were various practitioners, either people working inside organizations developing software products or consultants helping organizations build software who thought, “You know what? The way we’ve been building software just isn’t working for us. We’ve got to come up with something different.”

These software developers started mixing old and new ideas, and when they found a combination that worked, they created a methodology for their team to help them remember the combination of ideas that worked in a given situation.

These methodologies emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, tight, self-organizing teams; and smart ways to craft, confirm, and deliver code.

The people who created those methodologies figured that others may be interested in getting some of the same benefits they were experiencing, so they created frameworks to spread the ideas to other teams in other organizations and contexts. This is where frameworks such as Scrum, Extreme Programing, Feature-Driven Development (FDD), and Dynamic Systems Development Method (DSDM), among others, started to appear.

The spread of the ideas at this time was very organic, and all of those different approaches started to grow in a very grassroots manner. People borrowed the original frameworks and tweaked them with different practices in order to make them appropriate for their own contexts.

Rapid Application Development:-

Rapid application development is a form of Agile software development methodology. Unlike Waterfall methods, RAD emphasizes working software and user feedback over strict planning and requirements recording.

In other words, RAD is less talk, more action. Oh, and testing. Lots and lots of testing.

While RAD de-emphasizes strict planning, there are still a handful of steps or phases each development project goes through when using the rapid application development methodology, which we’ll discuss below.

RAD NSTRA DEMONS ANALYSIS AND QUICK DESIGN PROTOTYPE CYCLES TESTING IMPLEMENTATION BUILD REFINE

1. Figure out the requirements

Every piece of software or app is built for a reason. RAD starts with figuring out what your project is supposed to accomplish.

Get your users, developers, and designers into a room (or on a conference call) to discuss the purpose of the system you’re about to build and test. Once you’ve figured out the system requirements, you should also come up with an estimated project timeline. And, of course, you’ll need to figure out how you can create a system within the confines of your budget.

2. Build prototypes, on the double!

RAD stands for rapid application development, so it shouldn’t be surprising that your team will start working on building functional models right away. Once you’ve got the requirements, deadline, and budget figured out, your engineers and designers will create and improve upon working prototypes until you’re ready to unveil your finished product.

3. Get user feedback

With RAD, your users should already be familiar with most, if not all, parts of your finished product before you announce your project’s completion. Like most Agile methodologies, RAD calls for ongoing collaboration between your team and users in order to create a high-quality system. Your users will be the ones providing feedback so that you can tweak and improve your prototypes, creating the best possible finished product.

4. Do it again!

You’ll repeat steps two and three until you feel like your project is done or until you have all working parts assembled together to meet a client’s requirements.

5. Test, test, test

You’re not ready to pronounce a project complete until you’ve made sure that it works the way it’s supposed to. Run your system through different scenarios and make sure all of the moving parts work together to accomplish the system’s goal.

In addition to your engineers testing and retesting your code, this will involve more user testing before you take your system live.

6. Go present your system!

Once you’ve got a working system, pat yourself on the back! That’s not an official part of RAD, but your team has worked hard to get your project done rapidly. They deserve congratulations. Now you’re finished… until the next update is required, of course.

2)ans

.What is project creep?

Scope creep is when you move outside of the initially planned scope. The initially planned scope is usually also what specified the budget you have and the profit you’re going to make by taking on this particular project. So, moving outside of the scope and spending time on other things will directly affect your profit margins.

The main cause of scope creep is a poorly defined Statement of Work (SOW). Scoping your projects right is paramount to keeping your projects on-track and running a profitable business.

A clearly defined SOW should be set up in collaboration with your stakeholders, incl. the client and end users. This ensures a shared foundation of expectations on the finished product following the implementation stage. Discuss the overall goal and requirements of the product, and make sure both parties understand how the product should behave in the end.

Set up a proposal based on this SOW, and have both stakeholders sign it. This way you have an agreed document for future reference if needed. Look out for sentences, like, “I have an idea …”, “What if we …”, etc. from your client. Those ideas can be great, but in many cases this is exactly when scope creep can begin to build up.

During your project, make sure to set up meetings with your internal team and your client, to align and remind all parties of the goal, mission, and scope of the project.

Which system development methods are more prone to project creep? What could be a strategy to avoid it?

Scope creep is such a prevalent thing in business that it's expected. The key to combatting scope creep is understanding the sources and staying ahead of the game.

Your first line of defense, and the largest risk comes from that business case that was agreed at the beginning. You don't have to be an expert in the area to know if it was poorly written, don't be fooled by graphics or the confidence of the person that wrote it.

This is when you bring your ‘A’ game to the table, and by that I mean you scour your organization for the guys that know how the solutions come together and you get that list of questions and concerns.

You draft your scope based on these discussions and begin the negotiation on work to be done. Don't agree to anything until each scope item is understood on both sides of the table. Remember 6th grade English, nothing fancy for these discussions.

Your worst enemy can be jargon. I remember on a business integration project they had the same wording in their documents but different meaning. I made it a point to highlight their meaning in a call between the technical teams because it would have created a big process and solution change otherwise.

So talk the same language and keep it to simple terms when communicating, avoid acronyms without spelling and defining it later. Ok, big source of creep covered, now comes the sneaky one.

Your technical team is probably working with business operations also in a support capacity or they have a long relationship. So it starts innocently like can we change where this appears in the report or can we sort on this field. Neither of which were in the business proposal or the report mockup because the scope likely didn’t have it fully defined.

Your IT team will be guilty of this too, watch for those guys that customize solutions to enable end users to maintain data later. Is it a requirement, no. Does it save time and improve processes in production, yes. Will it impact scope and schedule, possibly.

The only way this will change is by actively enforcing it. Change control procedures can be time consuming especially if it includes cosmetic changes that may just be changing text in a field. You absolutely have to be the gatekeeper though. This also means you have to be part time detective and sniff for the clues. No one volunteers this willingly until it delays their work or they're caught.

Establish this change funneling culture and reward them as best you can to encourage its enforcement. Don’t be the bottleneck after you establish it. Establish a process for cosmetic vs. real work so it's not overdone. Ask those questions and be decisive, this is your budget and schedule that’s being played with so it better be something worth it if you agree to a change.